Frontend Architectures



@pamelafox



What's a frontend architecture?



Coursera

...a modern webapp?

So many architectures

...after just a year of existence

The optimal number

Picking an architecture

...what matters?

3 Architectures

The good, the bad, the ugly





*Not necessarily in that order

#1: Server-side HTML

Server-side HTML @ Coursera



In Action!

Usability

Good

  • Users are used to it?
  • Once it loads, it works

Bad

  • Users wait for page reloads between trivial actions
  • Users often lose their place
  • No way to deliver instant updates or realtime changes

Search+Share-ability

Good

  • Google/Facebook bots understand HTML Facebook debugger

*This doesnt matter if the page is private

Linkability

Good

  • Usually a 1-to-1 mapping of URLs to views
    forum/list?id=12
  • In-page anchors work
    admin/forum/edit#forum-27

Performance

Good

  • When the page is done loading, its done. Optimization is more straightforward.
  • More predictable across users/inputs.

Bad

  • Every page view is potentially a full load of HTTP requests (depending on browser cache)
  • Long content can take a long time to load or must be paginated

Productivity

Good

  • Maybe developers are more familiar with server-side than JS? Google Trends

Bad

  • Often not API-driven, hard to extract data and re-use elsewhere
  • Often not built in modular, reusable way
  • Hard to bring JS into it, quickly becomes spaghetti
  • Tied to your server-side language, hard to change backends

Testability

Good

  • Predictable inputs and outputs, its easy to know what to test

Bad

  • May have to test data layer and presentation together, if they haven't been separated PHP Coverage

#2: JS-Generated HTML



At Coursera


Frontend:

RequireJS logo

Backbone logo

Jade logo

Backend(s):

PHP logo
or
Scala logo + Play logo
or
Python logo + Django logo

In Action!

Usability

Good

  • Users can quickly do many actions on the same page.
  • Users do not lose their place.
  • Users can get realtime updates.

Bad

  • If loading indicators aren't used well, user can be confused
  • Your site breaks in more unexpected ways Borked Facebook
  • Users still wait on true page reloads (but they are less often)

Search+Share-ability

Bad

  • Bots aren't good at JS, have to have an alternate view for them

Performance

Good

  • Can incrementally load in content to avoid extra HTTP/API calls or DOM overload
    • only show if (almost) visible
    • start images with placeholders
    • infinite scroll
    • fast pagination

Bad

  • JS can sometimes be slow to process. Backbone pull request

Dev Productivity

Good

  • Often API-centric, API can be re-used by other views/mobile
  • Can be written in a more modular way

Bad

  • There's not one way to write them, have to learn JS, frameworks, conventions.

Testability

Good

  • Can test presentation *separately* from API

Bad

  • There are many more cases to test, its not as obvious what to test, e.g.
    1. Start with template first
    2. Then test events
    3. Then test sequences of events
    4. Then wait for bug reports...

#3: Single-Page Webapps

In Action!

Usability

Same as before, plus...

Good

  • Users don't have to wait for page reloads anymore, fast navigation.

Bad

  • Loading indicators *really* need to be properly used

Linkability

Bad

  • Harder to use internal anchors because of double hash (/#terms#privacy)

Performance

Same as before, plus...

Good

  • Users only have to download newly needed resources on page navigation

Bad

  • JS Bundle might be too big for whole site, have to come up with multiple bundles, figure out how to serve them.

Dev Productivity:

Same as before plus...

Bad

  • There is no more window load or unload.

Testability

Same as before plus...

Bad

  • Now there is state across your web views, so you have to test state across routes. Strange things happen!

A Recap

Server HTML JS-Generated Single-page JS
Usability Bad Good Good
Search/share Good Hard Hard
Linkability Good Good Hard
Performance Depends Depends Depends
Productivity Low High High
Testability Depends Hard Hard


Picking your architecture

= Picking your battles