|Home||Back to Index|
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.
Prototypes become real products. Even then, make good decisions.
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)
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
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
(Coursera uses Require.js, backbone.js, jade on frontend)
(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).
Infinite scrolling (which does have usability features - Ctrl+F, Jump to Bottom)
Dev productivity is typically very high.
Separates presentation from data.
Reusable (even in mobile apps).
Can expose an external API. (API-centric architecture.)
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.
(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.)
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.