Evolution of the “Web App”

@HenrikJoreteg
This used to be simple!
  1. Write some HTML
  2. Lay it out with frames or tables
  3. FTP it to a server
  4. 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
  1. Write some PHP/PYTHON/ASP/COLDFUSION
  2. set up a relational database
  3. write some bad SQL
  4. some dynamic data into html
  5. lay it out with CSS (no tables this time)
  6. run it on shared hosting somewhere
Congratulations,
You're a web developer!
Phew!
Then we got “smart”
Use a framework!
  1. Rails
  2. All them php frameworks
  3. django
  4. 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
  1. javascript
  2. html
  3. css
  4. 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
  1. browser requests url
  2. router
  3. 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
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
  1. browser requests url
  2. router
  3. 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:
  1. static content pages
  2. 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
powered by APIs/services
some of which we build
many of which we rent
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