GOTO notes: Frontend Architectures


GOTO notes: Frontend Architectures

Frontend Architectures: From the Prehistoric to the Post-Modern
Pamela Fox (with Coursera - online training)

Bello walnut green tea - recommended.

Multiple architectures can make training new engineers difficult.

Picking an architecture is hard. Users and developers have different needs.
Users: Usability, searchability, etc.
Developers: Productivity, testability, etc.
Both: Performance

Prototypes become real products. Even then, make good decisions.

3 Architectures

1. Server-side HTML (classic, templates, form submission, PHP, etc.)
Usability generally poor
  Wait for page reload
  Easy to lose your place
Search- and share-ability generally good (but doesn’t matter if page is private)
Linkability good
Performance has pros & cons - predictable and optimizable, but can take a long time to load everything
Productivity pretty poor - developers can get away with mixing markup and code
  Not API-driven, not modular, encourages copy & paste
  Bringing in JavaScript can lead to spaghetti
  Tied to your server-side language (PHP, etc.)
Testability is so-so - predictable, but may have to test data & presentation layers together; often end up with lots of untested code

2. JavaScript-generated HTML (server outputs minimal HTML with script tag)
(Coursera uses Require.js, backbone.js, jade on frontend)
(They like jade for templates - auto-closes tags, enforces HTML prettiness, designers can use directly without knowing JavaScript)
(Backend doesn’t matter much - can be swapped out)
“I scoped it out to two weeks; it was two months…”
Usability is both good and bad.
  Can do quite a few actions (even simultaneously) in a short period of time without waiting for page reloads.
  Have to use loading indicators well to avoid confusing users.
  (May want to enforce indicators in Ajax.)
  Pages may be partially broken (parts work), which can confuse users.
Search- and share-ability is poor. You have to have an alternative view for bots.
  Coursera uses a just-in-time renderer uses Selenium to render page to the cloud and serve it to the bot - but only to bots. This can be cached.
Performance is generally good.
  Content can be loaded incrementally (even based on what’s onscreen).
  Fast pagination.
  Infinite scrolling (which does have usability features - Ctrl+F, Jump to Bottom)
  However, JavaScript can be slow to process.
Dev productivity is typically very high.
  Separates presentation from data.
  Reusable (even in mobile apps).
  Can expose an external API. (API-centric architecture.)
  Does require learning JavaScript and multiple frameworks. (There’s more than one way to do it.)
Testability is so-so.
  Can test presentation separately from API.
  (Coursera uses Mocha and jsdom, and Chai? for mocking)
  Many more cases to test; may have to wait for bug reports.

3. Single-page webapps (JavaScript is also controlling the routes)
(Coursera uses Backbone History API and hash trick)
Similar to #2.
Usability is similar; navigation is fast. REALLY need loading indicators.
Linkability - internal anchors are hard to use because of double hash.
Performance is similar; only need new resources.
  However may need to come up with multiple bundles if one is too big.
Dev productivity is similar; there’s no more window load/unload, though (bad).
  Have to come up with a way to keep users from losing their data.
  Does the current view have an unsaved model? (Mark as dirty.)
    (Coursera’s technique.)
  There aren’t as many people doing #3, so there’s less info on it.
Testability is similar, but it gets even harder. Now there’s state across your web views. You have to test state across routes. Combinatorial.

None of the approaches are perfect.
The presenter prefers #2 - but there’s no one right answer.
It Depends on what’s important to you.
#2 and #3 should get easier and easier.
Pick your battles.

Coursera serves many things off Cloudfront.

Your Host:
Copyright © 2000-2013 by William Sorensen. All rights reserved.