Evolution of the “Web App”

@HenrikJoreteg

This 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!

Then it got harder

Who's written their
own blog software?

Over-engineering a
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!

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

Congratulations,
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”

What does
“web developer”
even mean?

What does
“web app”
even mean?

Is twitter a web app?

It's getting a bit Fuzzy

We're not just building
“web apps”

We're building
services

The browser isn't
just our renderer

The browser is
our runtime

The webview is
our runtime

More logic moving
to frontend JS

devs with different
backgrounds
converging on js

bringing their patterns
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

how do we build
web apps these days?

how should we build
web apps these days?

Everything I build is split

backend & frontend

Server & Client

two distinct codebases

API Server only
speaks data

API Server is

centralized
source of truth
running process
connected to data sources

Exposes data
and/or capabilities
to clients

Enforces all the
business rules

Carries out the
business logic

Everything using the API
is a client

Doesn't care what those are...

...because all clients have to
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

Additionally, now there's
nothing secret about your clients

You may as well
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

“So what is a client, anyway?”

It's the User Interface

only concerned
with presentation

I <3 building
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

most capable

ubiquitous

runtimes

on the planet

javascript
html
css
browser apis

Single Page apps

~~Single Page apps~~

“native”

I'm a web developer

Native web app

Fundamental distinction...

The browser is
your runtime

Send the app itself
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

often let the client
decide what to show

Does this via a
wildcard handler

No matter what page
the browser requests...

The server responds
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:

window.location.pathname

to determine what data to fetch
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

Yup, static files.

It's web 1.0 again

I've started building
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!

Services like surge.sh
Make it a breeze

It's incredibly scalable

Practically
zero downtime
for updates

It's a lot
harder to break
a static file server

You have way better uptime

“What about performance?”

Loadtime Performance
Runtime Performance

white screen of death

<!doctype html>
<script src="app.1.3.7.js"></script>

Target: < 1 second to first render

joreteg.com/blog/viability-of-js-frameworks-on-mobile

“Hacker News told me I need to do
universal/isomorphic rendering!”

What is “Universal JavaScript”?

Code structured
to run in any
JavaScript runtime

You run a JavaScript
environment on the server

run the same app code
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

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?

Much of the complexity of
server-rendering comes from
trying to do it for each request

Doing it once ahead of time
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

that can generate static
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

Think about what we get

pixels on screen immediately

totally crawlable (SEO)

JS Takes over routing
When loaded

deployment and ops
become as simple as FTP

we get 90% of benefit from
“universal” rendering

Users will end up with primed
cache just by visiting your
marketing pages

ready for:
phonegap/cordova
desktop app

now we have an app
with a singular concern:
presentation

I've started building
all my apps as static
native web apps

totally <3 it!

It's renewed my
love for the web!

For so long the trend
has been toward complexity

Open Source app:
hubtags.com

“What's the next step in the
evolution of the web app?”

Going back to
simple

Going back to
the static web

surge.sh
divshot
Auth0.com
Firebase
Parse

“how can we be sure we're building
with the right tools?”

We can't!

what do we know?

Things will
change

optimize for change
it's the only constant

building modular systems
that strive to be as
simple as they can be

Let' build for the future
of the web, not its past

Thank you very much!

@HenrikJoreteg