Evolution of the “Web App”
@HenrikJoretegThis used to be simple!
- Write some HTML
- Lay it out with frames or tables
- FTP it to a server
- bam!
Congratulations,
You're a web developer!
You're a web developer!
Then it got harder
Who's written their
own blog software?
own blog software?
Over-engineering a
blog was a rite of passage
blog was a rite of passage
- Write some PHP/PYTHON/ASP/COLDFUSION
- set up a relational database
- write some bad SQL
- some dynamic data into html
- lay it out with CSS (no tables this time)
- run it on shared hosting somewhere
Congratulations,
You're a web developer!
You're a web developer!
Phew!
Then we got “smart”
Use a framework!
- Rails
- All them php frameworks
- django
- etc.
Our excessively dynamic blog...
is now better organized
and has more dependencies
is now better organized
and has more dependencies
Congratulations,
You're a web developer!
You're a web developer!
What about today?
BACK-END FRONT-END ISOMORPHIC RESPONSIVE
ES6(2015) BABEL TRACEUR AMD COMMONJS MVC
MVVM FLUX RELAY GULP GRUNT API-GATEWAY
CORS JSON-WEB-TOKENS NODE.JS HTTP 2.0
OFFLINE-FIRST MOBILE-FIRST WEBGL WEBRTC
WEBSOCKET GRAPHQL AMPERSAND EMBER
REALTIME REDIS RIAK LEVELDB RABBITMQ
PUSH-NOTIFICATION ENABLED BACKBONE APP
WITH POLYFILLED POLYMER WEB COMPONENTS
Congratulations
You might be a
“web developer”
You might be a
“web developer”
What does
“web developer”
even mean?
“web developer”
even mean?
What does
“web app”
even mean?
“web app”
even mean?
Is twitter a web app?
It's getting a bit Fuzzy
We're not just building
“web apps”
“web apps”
We're building
services
services
The browser isn't
just our renderer
just our renderer
The browser is
our runtime
our runtime
The webview is
our runtime
our runtime
More logic moving
to frontend JS
to frontend JS
devs with different
backgrounds
converging on js
backgrounds
converging on js
bringing their patterns
and preferences
and preferences
BACK-END FRONT-END ISOMORPHIC RESPONSIVE
ES6(2015) BABEL TRACEUR AMD COMMONJS MVC
MVVM FLUX RELAY GULP GRUNT API-GATEWAY
CORS JSON-WEB-TOKENS NODE.JS HTTP 2.0
OFFLINE-FIRST MOBILE-FIRST WEBGL WEBRTC
WEBSOCKET GRAPHQL AMPERSAND EMBER
REALTIME REDIS RIAK LEVELDB RABBITMQ
PUSH-NOTIFICATION ENABLED BACKBONE APP
WITH POLYFILLED POLYMER WEB COMPONENTS
This is good!
The web is clearly
alive and well
alive and well
how do we build
web apps these days?
web apps these days?
how should we build
web apps these days?
web apps these days?
Everything I build is split
backend & frontend
Server & Client
two distinct codebases
API Server only
speaks data
speaks data
API Server is
- centralized
- source of truth
- running process
- connected to data sources
Exposes data
and/or capabilities
to clients
and/or capabilities
to clients
Enforces all the
business rules
business rules
Carries out the
business logic
business logic
Everything using the API
is a client
is a client
Doesn't care what those are...
...because all clients have to
play by its rules
play by its rules
- Apple Watch
- An Android/iOS App
- A CLI
- Another API
- Your admin interface
- Third party apps
- Your main web interface
your “main web app” is
just another client
just another client
Additionally, now there's
nothing secret about your clients
nothing secret about your clients
You may as well
open source them!
open source them!
Imagine this in an educational setting:
- Expose functinality through APIs
- Document how it works
- Put the client on GitHub
- Give students access!
- Just see what happens
Why not, right?!
I'd bet you get bugfixes
I'd bet you get alternate clients
You'd certainly get some
marketing out of it
marketing out of it
“So what is a client, anyway?”
It's the User Interface
only concerned
with presentation
with presentation
I <3 building
clients with web tech
clients with web tech
I <3 browsers
Threy're friggin' incredible!
High Performance
- rendering
- networking
- peer to peer Voice/Video
- file read/write
- storage
- web audio apis
- webGL
Browsers are not
dumb document renderers
dumb document renderers
most capable
ubiquitous
runtimes
on the planet
- javascript
- html
- css
- browser apis
Single Page apps
“native”
I'm a web developer
Native web app
Fundamental distinction...
The browser is
your runtime
your runtime
Send the app itself
instead of the
result of running it
instead of the
result of running it
Let me explain
Who's used Rails, Django, PHP?
book.com/books/the-martian
- browser requests url
- router
- hits a handler:
- query a database
- template out some HTML
- respond
"single page apps"
by contrast
by contrast
often let the client
decide what to show
decide what to show
Does this via a
wildcard handler
wildcard handler
No matter what page
the browser requests...
the browser requests...
The server responds
with the same HTML
with the same HTML
Route: Asset:
site.com/help -> index.html
site.com/about -> index.html
site.com/books/1 -> index.html
<!doctype html>
<script src="app.1.3.7.js"></script>
it downloads, parses, runs
reads own url:
to determine what data to fetch
and render from the API
window.location.pathname
and render from the API
updates and responds to changes to url
history.pushState()
window.addEventListener('popstate')
So here's the cool part...
Route: Asset:
site.com/help -> index.html
site.com/about -> index.html
site.com/books/1 -> index.html
This can be done as
100% static files
100% static files
Yup, static files.
It's web 1.0 again
I've started building
everthing
as static sites
everthing
as static sites
I even re-built my blog
Still get clean URLs
Route: Asset:
site.com/pic.png -> pic.png
site.com/* -> index.html
Any modern
file server
can do that!
file server
can do that!
It's incredibly scalable
Practically
zero downtime
for updates
zero downtime
for updates
It's a lot
harder to break
a static file server
harder to break
a static file server
You have way better uptime
“What about performance?”
Loadtime Performance
Runtime Performance
Runtime Performance
white screen of death
<!doctype html>
<script src="app.1.3.7.js"></script>
Target: < 1 second to first render
“Hacker News told me I need to do
universal/isomorphic rendering!”
universal/isomorphic rendering!”
What is “Universal JavaScript”?
Code structured
to run in any
JavaScript runtime
to run in any
JavaScript runtime
You run a JavaScript
environment on the server
environment on the server
run the same app code
on the server
to generate HTML
on the server
to generate HTML
- browser requests url
- router
- hits a handler:
- run client app code here
- have it kick out the HTML
- and include the script tag for the app
- respond
Sounds messy right?
it is.
Massive overkill for
most small apps
most small apps
Route: Asset:
site.com/pic.png -> pic.png
site.com/* -> index.html
<!doctype html>
<script src="app.1.3.7.js"></script>
Target: < 1 second to first render
You're fine!
But, here's the thing...
It's not all or nothing!
What if we
pre-render everything
we know ahead of time?
pre-render everything
we know ahead of time?
Much of the complexity of
server-rendering comes from
trying to do it for each request
server-rendering comes from
trying to do it for each request
Doing it once ahead of time
isn't all that hard
isn't all that hard
clients usually have:
- static content pages
- all the stuff behind the login
we can make “content” pages
and shared html layout
universal components
and shared html layout
universal components
that can generate static
HTML files at build time!
HTML files at build time!
Instead of:
<!doctype html>
<script src="app.1.3.7.js"></script>
We could do:
index.html
<!doctype html>
<body>
<h1>Some actual content</h1>
<p>Stuff</p>
<p>And things!</p>
</body>
<script src="app.1.3.7.js"></script>
layout.html (catch all)
<!doctype html>
<body>
<nav>
<a href="/">home</a>
<a href="/help">help</a>
</nav>
<div class='main-content'>
</div>
<footer>footer links</footer>
</body>
<script src="app.1.3.7.js"></script>
Extend our routing rules...
Route: Asset:
site.com/pic.png -> pic.png
site.com -> index.html
site.com/page -> page.html
site.com/asdf -> 404.html
or
200.html
(this is precisely how surge.sh works)
Could potentially even do this
for dynamic/public data
for dynamic/public data
Think about what we get
pixels on screen immediately
totally crawlable (SEO)
JS Takes over routing
When loaded
When loaded
deployment and ops
become as simple as FTP
become as simple as FTP
we get 90% of benefit from
“universal” rendering
“universal” rendering
Users will end up with primed
cache just by visiting your
marketing pages
cache just by visiting your
marketing pages
ready for:
phonegap/cordova
desktop app
phonegap/cordova
desktop app
now we have an app
with a singular concern:
presentation
with a singular concern:
presentation
I've started building
all my apps as static
native web apps
all my apps as static
native web apps
totally <3 it!
It's renewed my
love for the web!
love for the web!
For so long the trend
has been toward complexity
has been toward complexity
“What's the next step in the
evolution of the web app?”
evolution of the web app?”
Going back to
simple
simple
Going back to
the static web
the static web
powered by APIs/services
some of which we build
many of which we rent
some of which we build
many of which we rent
surge.sh
divshot
Auth0.com
Firebase
Parse
divshot
Auth0.com
Firebase
Parse
“how can we be sure we're building
with the right tools?”
with the right tools?”
We can't!
what do we know?
Things will
change
change
optimize for change
it's the only constant
it's the only constant
building modular systems
that strive to be as
simple as they can be
that strive to be as
simple as they can be
Let' build for the future
of the web, not its past
of the web, not its past
Thank you very much!
@HenrikJoreteg