This document provides an overview of modern web development including products, languages, frameworks, content management systems, architecture, services and case studies. It discusses key concepts like what constitutes a product versus a project, popular programming languages for web and mobile including JavaScript, frameworks like Express and React, CMS options, client-side rendering, and using external services.
Building Products: A Guide to Modern Web Development
1. Building Products
A brief overview on modern web apps, tech stacks,
languages, frameworks, services, APIs and more.
2. Hayden Bleasel
Product Designer, Full-Stack
Developer, Entrepreneur.
Currently working on Presumi,
previously working at Palantir,
Sumry and Zookal.
@haydenbleasel on the
internet.
Nice to meet you.
4. Overview
1. Products
2. Web vs Mobile
3. Languages
4. Frameworks
5. Content Management Systems
6. Architecture
7. Services
8. Case Studies
5. Let’s just get started
I can’t stall much longer. Time to get into it.
6. 1. Products
• Working on a website that you personally own and
focuses more on your needs? Project
• Working on a website that you or a few others own
and focuses on user needs? Product
• Working on a website that is owned by an entity
(company) and focuses users, investors and
growth? Startup
7. What is a Product?
• Tech startups and larger companies usually focus
on a single entity as their business operations.
• Slack, Facebook, Twitter, Spotify - all companies
focus on a single piece of ecosystem / platform
(usually released on multiple devices)
• This ecosystem is called a Product.
8. Tech Products
• There’s a whole new range of jobs coming out that
focus on this, namely Product Design (my job title)
• A new spin on Industrial Product Design, this sort
of Product Design focuses on the end-to-end
creation of an entity.
• Facebook, for example, is a massive product.
Visualising, understanding and designing for the
entire ecosystem at once is usually my work.
9. Distribution methods
• Products can come in many forms, but they’re all
part of the same ecosystem.
• Facebook released a website, an iOS app, an
Android app and a Windows Phone app (plus more)
• Which of these are the most important? Where do
you start? This entirely depends on the context.
10. 2. Web vs Mobile
• What works best for your idea?
• What skills does your team have?
• What is your platform preference?
• Do you have the resources to do both?
• There are some ways around this…
13. How do I choose?
• Are you making Uber? Mobile apps.
• Are you making Atlassian? Desktop apps.
• Are you making Facebook? Probably both.
14. Which do I choose?
• You’ve got a few options:
1. Create a responsive website (no native apps)
2. Hire a developer per-platform (web, iOS,
Android)
3. Wrap your website in an app frame (Cordova,
UIWebView)
4. Bind web code to native handlers (React Native)
15. 3. Languages
• Picking a language is one of the hardest parts. Everyone
wants to jump on the new hotness.
• Go with what your team knows best. It’s better to build a
MVP in PHP that actually works, as opposed to a MVP in
Node.js that runs like shit. You can always rebuild later on.
• Some languages are reserved for back-end development,
some for front-end development. The languages you use
depend on your platform. What are your options?
• And why are there so many coming out recently?
19. Web App
• Back-end: PHP, Ruby, Python,
Java, JavaScript (anything can
be used to write a website
back-end basically)
• Front-end: HTML, CSS,
JavaScript (but you can
preprocess these with a bunch
of other languages)
20. Web App
• Back-end: PHP, Ruby, Python,
Java, JavaScript (anything can
be used to write a website
back-end basically)
• Front-end: HTML, CSS,
JavaScript (but you can
preprocess these with a bunch
of other languages)
What? I thought you said languages are separated?!
21. JavaScript hotness
• There’s a reason JS is the new hotness.
• TL;DR: JS was originally a web browser scripting language written
in 10 days by a guy at Netscape. Google made their own JS engine
some time later to run Chrome, called the JavaScript V8 engine.
• Some yung money™ a few years ago decided it’d be a great idea
to pull that engine out of Chrome and make it into a server side
compiler called Node.js. Same language on the server and client?
Ridiculous.
• Node.js now runs GoDaddy, Groupon, IBM, LinkedIn, Microsoft,
Netflix, PayPal, Walmart, Yahoo! and Cisco Systems.
23. Side note on machines
• I’m not going to argue for Mac or Windows - that
arguments been going on far too long. And also because
Mac is naturally superior.
• There’s plenty of reasons (unix-based commercial
software, build quality, cross-platform compatibility, etc.)
• I actually made the switch because of development.
Running any programming environment (Node, Rails,
PHP, etc) is super easy on Mac and super painful on
Windows because Mac is based on Unix.
24. 4. Frameworks
• Frameworks make creating web apps easier. Native apps
don’t need them most of the time (you can make smaller
framework-module-things yourself though)
• The framework depends on the language you pick and
what you want to accomplish.
• Every language usually has a few popular frameworks
that “everyone” uses.
• You can create your own framework of course (really not
recommended) or just not use one at all.
26. Why a framework?
function router (request, response) {
if(request.url === ‘/index.html’ || request.url === ‘/‘) {
response.writeHead(200, {
'Content-Type': 'text/plain'
});
response.write('Hello World!')
response.end();
}
var http = require(“http”);
var server = http.createServer(router);
server.listen(3000);
27. Why a framework?
var app = require(‘express’)();
app.get('/', function (req, res) {
res.send('Hello World!');
});
app.listen(3000);
28. Plus…
• Better wrappers to the request and response
• Support for view-engines
• Routing mechanism
• Cookies manipulation
• Basic authentication
• Much much more…
29. 5. Content Management Systems
• Sometimes you don’t need to build a product from
ground up.
• If you want to make a store, a blog or a simple website,
you could use a CMS
• A CMS helps you manage your content on your website
and usually the website itself
• Usually really easy to install (click to install) and don’t
require much (or any) code to operate. A lot like off-the-
shelf software for websites.
31. FindMyPlan
• The value proposition for FindMyPlan is getting a
Sim Card to you from any country in the world to
avoid expensive roaming bills when you travel.
• There isn’t a huge tech focus - they need a system
that works for them and allows them to create
value and manage clients easily.
• They’ve moved to from a custom Angular/PHP
web-app to a Shopify site. Why?
32. Do what works for you
• Don’t pick a damn language because it’s hot. Pick it because you love it
and know it (or at least want to know it eventually).
• Too many startups get told what technology to use and end up
regretting it, some are next door. Don’t be pressured into building a
product a certain way, or even building a product at all.
• A tech startup should be using technology to enable the startup to
reach it’s goals, not building a custom product with super hot code for
their own satisfaction.
• Your tech doesn’t matter to the customer. What matters is how easy it
is to reach their goal.
• JavaScript is the best tho.
33. 6. Architecture
• Picking a language, framework and/or CMS is
great but we need to talk about how these things
work.
• Back in the day it used to be super clear, but
modern technology is enabling crazy things that
don’t seem normal to traditional developers but
they work in amazing ways.
34. TL;DR: How apps work
Request a page Fetch things for page
Return thingsSend webpage to browser
Figure out what’s needed
Render HTML, CSS, JS,
return all the requests
HTTP Requests API requests to DB
Find things for pageReload page
36. Why client-side JS is hot
Request first page Fetch things for page
Return thingsSend webpage to browser
Just grab everything
Render every page
scaffold and controllers
and return
HTTP Requests API requests to DB
Find things for pageReload page
39. This means what exactly
• Firstly, the server’s getting a lot less hits. This means
server usage could drop dramatically causing less crashes.
• Secondly, the server isn’t doing any processing for clients.
This means everything is done on the client’s computer,
again causing less server usage.
• Third, EVERYTHING IS SO FAST BECAUSE WE DON’T
NEED TO RELOAD EVERY PAGE.
• It also means all our code is on the client’s computer to
potentially steal but I dunno, c’est la vie I suppose.
42. 7. Services
• Services and APIs are the most useful thing when
you’re building a product.
• Basically, you don’t have to do all the work yourself.
• Products typically have a lot of things in common.
Live chat, payment gateway, error reporting.
• Smart companies identify these needs, build an
entire product out of the one focus, turn them into
drop-in widgets or APIs and monetise on them.
44. Why invest in services
• There’s a reason these services are so successful
and you should look into using them.
• They take a pain point of building products and do
it really, really well.
• You can chuck out the trash code you wrote to
handle user’s error reports and replace it with a
Rollbar installation for free!
45. “I’ll just write it myself”
<script>
var YOUR_API_KEY = “XXXXXXXX”;
!function(){var t;return t=window.driftt=window.drift=window.driftt||
[],t.init?void 0:t.invoked?
void(window.console&&console.error&&console.error("Drift snippet
included twice.")):(t.invoked=!
0,t.methods=["identify","track","reset","debug","show","ping","page","hi
de","off","on"],t.factory=function(e){return function(){var n;return
n=Array.prototype.slice.call(arguments),n.unshift(e),t.push(n),t}},t.met
hods.forEach(function(e){t[e]=t.factory(e)}),t.load=function(t){var
e,n,o,r;e=3e5,r=Math.ceil(new Date/
e)*e,o=document.createElement(“script”),o.type=“text/
javascript”,o.async=!0,o.crossorigin="anonymous",o.src="https://
js.driftt.com/
include/"+r+"/"+t+".js",n=document.getElementsByTagName("script")
[0],n.parentNode.insertBefore(o,n)})}
(),drift.SNIPPET_VERSION="0.2.0",drift.load(YOUR_API_KEY);
</script>
47. 8. Case Studies
• Every product is built differently.
• Every product has had complete rebuilds.
• Every product has a storied history.
• Here’s a couple of them…
48. Facebook
• Back-end originally built with PHP, likely with a basic WAMP setup (Windows,
Apache, MySQL, PHP). Front-end naturally rendered HTML (rendered by
PHP), CSS and JS. No sense of business logic separation (too much effort).
• Now, front-end is still written in PHP-backed HTML but runs through their
weird crazy “HipHop” compiler: PHP -> AST -> C++ -> G++ -> x64. Business
logic exposed through Thrift in PHP, C++ or Java based on service. Also
running Java on custom application servers. Database is MySQL, caching is
done through memcached (300TB at a time) and HBase. Offline processing
done through Hadoop and Hive. Data logging through Scribe, stored in HDFS
through MapReduce. Page acceleration through BigPipe (pipelining logic).
Varnish Cache for HTTP proxying. User storage through Haystack.
• Messenger is another thing entirely with all sorts of insane shit like
infrastructure sharding, dynamic cluster management and cell structures.
Based on Epoll server developed in Erlang and Thrift.
49. Twitter
• Twitter has always run on Rails but originally based on
regular Ruby. MySQL database, temporarily sharded.
• “Search” replaced Rails with Java server called Blender.
• “Messages” replaced Rails with Starling (Ruby) then
replaced with Scala.
• Database replaces MySQL with Gizzard and FlockDB
• Lots of custom stuff - Snowflake, Rockdove, Firehose.
50. Presumi
• Back-end in Express and Handlebars (hybrid rendering engine), front-
end originally in Handlebars and jQuery. Database on MongoDB.
• Live chat with Drift, error reporting with Rollbar, analytics with Google
Analytics, payments with Stripe, email with Sendgrid, A/B with
Optimizely.
• Replaced front-end with jQuery with React, Handlebars with JSX.
• Actual build process takes my JSX, transpiles through Babel (+React
plugin) and Webpack and spits out JS. Basically I write super hot
futuristic code and it converts it to pleb browser code.
• Currently replacing internal app hybrid-rendering with full JS rendering
and implementing React properly, reducing server usage by >50%.
51. That’s all I’ve got
Thanks for listening. I’m here for questions :)