A fascinating series looking into how to turn a modern React eCommerce front end into as fast a page as possible. The conclusions are not what I had expected.
In particular, the concept of streamed HTML using "chunked Transfer-Encoding" is a neat one. It basically chunks the page up and delivers bits as they are made available (similar to rehydration, but on the server), giving you a much more meaningful page load where non-dynamic data appears almost instantly, and dynamic data is loaded as the API calls are completed (including with skeleton or loading states, if necessary).
Showing pieces of a page as data sources finish is useful for almost any dynamic site.
Taylor points that this is a very old, extremely well supported technique, that almost no one uses, mainly because the native APIs are clunky and no dev tooling really exists. Well, none except Marko, which looks incredibly interesting:
And [Marko] only uses client-side JS for stateful components? You don’t say.
It has an <await> component that enables this exact "chunked" page/asynchronous HTML effect. Very cool!
The articles also take a critical look at heavy UI patterns, like carousels and dropdowns.
On carousels versus tiles:
Think about what code the carousel needs that tiles don’t:
- Next/previous swiping vs. buttons, and switching between them
- Position indicator
- Pause/Play (required for accessibility)
- (prefers-reduced-motion) check and mitigation
- Accessibly hiding offscreen slides
- Autoforwarding
- Animation timing
- Repositioning slides to the left when wrapping
- Tab ↹ handling
No matter how efficiently those features are implemented, they’re still code users must download. (If users actually liked carousels that could be worth it, but, uh…)
On why problematic UI patterns are so common:
But if these UI patterns are annoying, not very accessible, and costly, why do so many sites use them?
- I think they’re easier to design, since they don’t have to care about the underlying page.
- I suspect analytics falsely report increased “engagement” because they need more interaction than less intrusive designs. Even if said interaction is, say, users trying to get the damn carousel to hold still.
- Sometimes, they can be the best solution for a problem — but as soon as you have that component, it’s tempting to reuse it for other, less-suited problems.
