DEV Community: Taylor Hunt

Why not React?

Taylor Hunt — Sun, 17 Sep 2023 04:22:50 +0000

This was an internal analysis I wrote when challenged if Kroger.com could do the same MPA speed tricks as my Marko demo, but still using React because, well, you know.¹

It’s from around 2021, so some questions got answered, some predictions got proven wrong or boring-in-retrospect, and React’s official SSR story actually released. I once planned a rewrite, but I’m burnt out and can’t be arsed. (Feel free to tell me what I got wrong in the comments.)

However, I’m publishing it (with some updated hyperlinks) because this post might still be useful to someone:

React’s streaming has interesting flaws, and the official RSC implementation ain’t exactly fast
Low-end devices remain stubbornly stagnant 2 years later
React indeed says it’s changing in unfamiliar ways
The intro became more relevant than I could have possibly known when I wrote it.

Don’t believe me? Well, a WebPageTest is worth a thousand posts:

WebPageTest results for: Simulated 3G, emulated MOTOG4, Los Angeles

	Next.js RSCs + streaming	Marko	HackerNews (control)
URL	next-news-rsc.vercel.sh	marko-hackernews. ryansolid.workers.dev	news.ycombinator.com
WPT link	230717_BiDcVJ_9GN	230717_AiDc35_A1Q	230717_AiDcNY_A0G
JS	94.9 kB	0.3 kB	1.9 kB
HTML	9.5 kB	3.8 kB	5.8 kB
`text/x-component`	111.1 kB	0 kB	0 kB
Waterfall chart

I’m not including timings, since unfortunately WPT seems to have stopped using real Androids, and Chrome’s CPU throttling is way too optimistic for low-end devices. However, note that browsers can’t parse text/x-component natively², so that parsing is blocked behind JS and the parse time is more punishing on low-end devices than usual.

I’m also not sure if I should test next-edge-demo.netlify.app/rsc instead, but its results seemed so inconsistent I wasn’t sure it’s functioning correctly.

Anyway, time for the original analysis.

Can we get React to be as fast as the Kroger Lite demo?

Probably not.

Okay smart guy, why not?

This is not going to be a short answer; bear with me. I’m going to start with an abstract point, then back it up with concrete evidence for my pessimism.

Code struggles to escape why it was created. You can often trace the latest version’s strengths and weaknesses all the way back to the goals of the original authors. Is that because of backwards compatibility? Developer cultures? Feedback loops? Yes, and tons of other reasons. The broader effect is known as path dependence, where the best way to predict a technology’s future is to examine its past.

Front-end frameworks are no exception:

Svelte was invented to embed data visualizations into other web pages.: 💪 Svelte has first-class transitions and fine-grained updates, because those things are very important for good dataviz.; 🤕 Svelte’s streaming nonsupport and iconoclastic “𝑋 components↦bundle size” curve make sense if you consider the code Svelte was invented for didn’t do those things in the first place.
Angular was made to quickly build internal desktop web apps.: 💪 Angular fans are right about how quickly you can make a functional UI.; 🤕 If you think about what big-company workstations are like and the open-in-a-tab-all-day nature of intranet desktop webapps, Angular’s performance tradeoffs are entirely rational — until you try using it for mobile.
React was created to stop Facebook’s org chart from Conway’s Law-ing all over their desktop site’s front-end.: 💪 React has absolutely proven its ability to let teams of any size, any degree of cooperation, and any skill level work together on large codebases.; 🤕 As for React’s original weaknesses… Well, don’t take my word for it, take it from the React team:
So people started playing around with this internally, and everyone had the same reaction. They were like, “Okay, A.) I have no idea how this is going to be performant enough, but B.) it’s so fun to work with.” Right? Everybody was like, “This is so cool, I don’t really care if it’s too slow — somebody will make it faster.”

That quote explains a lot of things, like:

React’s historical promises that new versions will make your app faster for you
The pattern of React websites appointing specialized front-end performance teams
Why big companies like React, since departmentalizing concerns so other departments don’t worry about them is how big companies work

I’m not claiming those things are wrong! I’m saying it’s a consistent philosophy. For once, I’m not even being snide about React’s performance; the React team are very open about their strategy of relieving framework consumers from worrying about performance, by having the framework authors do it for them. I even think that strategy works for (most of) Meta’s websites!

But so far, it has not made websites overall any faster. And the things the React team have resorted to have gotten odder and more involved. Lastly, our site (and indeed, most sites) are not very similar to facebook.com.

🔮 Note from the future
Because it’s the obvious question to ask: Marko got started when eBay devs wanted to use Node.js, and the business said “Okay, but it can’t regress performance”.
💪 Strength: It didn’t. That’s not typical for JS frameworks.
🤕 Weakness: Marko’s early focus on performance instead of outreach/integrations beyond what eBay uses/etc. also explains why most devs haven’t heard of it.

But can React be that fast anyway? It’s all just code; it can be worked with.

It’s code and path dependencies and culture and a support ecosystem, each with their own values, golden paths, and pewter paths. Let’s examine those concretely — we’ll look at how feasible technically it would be to have React perform at the same speed as the Kroger Lite demo.

Starting with what traits are desirable for MPAs:

📃 Streamed HTML: Incrementally flush parts of the page to the HTTP stream, so pages aren’t as slow as their slowest part.
🥾 Fast boot: If JS reboots on every navigation, it should do so quickly.
🥀 Hydration correctness: Like airplane takeoff, hydration is a few moments where any of a hundred tiny things could ruin the rest of the trip.; In MPAs, it’s vital to reconcile DOM updates from user input during load, as that “edge case” becomes a repeat occurrence.
🏸 Fast server runtime: If we’re leaning on the server, it better render efficiently.; Even more important for spinning up distributed datacenter instances, edge rendering, Service Worker rendering, and other near-user processors.
🍂 Tree-shakeable framework: SPAs assume use of all of framework’s features eventually, so they bundle them to get into JS engines’ caches early. MPAs want to remove code from the critical path if it’s not used in it, amortizing framework cost across pages.
🧠 Multi-page mental model: If a component only renders on the server, should you pretend it’s in the DOM?; If you can’t have API parity between server and client, provide clear and obvious boundaries.

📃 Streamed HTML

I consider streaming HTML to be the most important thing for consistently-high-performance server rendering. If you didn’t read the post about it, here’s the difference it makes:

Download video: HTML Streaming vs. Non-streaming Here’s the closed captions, since Forem doesn’t allow <track> elements.

Important facets of incremental HTML streaming

Both explicit and implicit flushes; early <head> for asset loading, around API calls, at TCP window size boundaries…
All flushes, but especially implicit ones, should avoid too much chunking: overeager flushing defeats compression, inflates HTTP encoding overhead, bedevils TCP scheduling/fragmentation, and hitches Node’s event loop.
Nested component flushes help avoid contorting code to expose flush details at the renderer’s top level.
Out-of-order server rendering, for when APIs don’t return in the same order they’re used.
Out-of-order flushes , so inessential components don’t hold up the rest of the page (like Facebook’s old BigPipe).
Controlling render dependencies of nested and out-of-order flushes is important to prevent displaying funky UI states.
Mid-stream render errors should finish cleanly without wasting resources, and emit an error event on the stream so the HTTP layer can properly signal the error state.
Chunked component hydration, so component interactivity matches component visibility.

Marko has been optimizing those important subtleties for almost a decade, and React… hasn’t.

Additionally, we had a brownfield tax. Kroger.com didn’t render its React app to a stream, so that app had many stream incompatibilities of the kind described here:

Generally, any pattern that uses the server render pass to generate markup that needs to be added to the document before the SSR-ed chunk will be fundamentally incompatible with streaming.

—What’s New With Server-Side Rendering in React 16 § Streaming Has Some Gotchas

🥾 Fast boot

SPAs’ core tradeoff: the first page load can be painful in order for fast future interactions. But in MPAs, every page load must be fast.

Costs in JS runtime boot

Download time
Parse time & effort
Compilation: compile time, bytecode memory pressure, and JIT bailouts
Execution (repeats every page, regardless of JIT caching)
Initial memory churn/garbage collection

Only some of those costs can be skipped on future page loads, with the difficulty increasing as you go down:

Downloads are skipped with HTTP caching.
Modern browsers are smart enough to background and cache parses, but not for all <script>s — either from script characteristics or parallelization limits.
Compiler caches intentionally require multiple executions to store an entire script, and compilation bailouts can thrash for a surprisingly long time.
Execution can never be skipped, but warm JIT caches and stored execution contexts can slash properly-planned runtimes.
Memory churn and overhead during load is impossible to avoid — intentionally by the ECMAScript standard, even.

Luckily, v8 moved most parses to background threads. Unfortunately, while that doesn’t block the main thread, parsing still has to finish. This is exacerbated by Android devices’ big.LITTLE architecture, where the available LITTLE cores are much slower than the cores already occupied with core browser tasks in the main, network, and compositor threads.

More on v8’s JS costs and caching, as it’s the primary target for low-spec Androids and JavaScript servers alike:

Does React play nice with JS engines’ boot process?

Remember React’s demos back in the day that got interactive much faster than competing frameworks? React’s lazier one-way data flow was the key, as it didn’t spend time building dependency graphs like most of its peers.

Unfortunately, that’s the only nice thing I found about React and JS engines.

The sheer size of react + react-dom negatively affects every step of JS booting: parse time, going to ZRAM on cheap Androids, and eviction from compiler caches.
React components are functions or classes with big render methods, which defeats eager evaluation, duplicates parse workload via lazy compilation, and frustrates code caching:

One caveat with code caching is that it only caches what’s being eagerly compiled. This is generally only the top-level code that’s run once to setup global values. Function definitions are usually lazily compiled and aren’t always cached.

—JavaScript Start-up Performance

React prioritizes stable in-page performance at the expense of reconciliation and memory churn at boot.
React renders and VDOM results are infamously megamorphic, so JS compilers waste cycles optimizing and bailing out.
React’s synthetic event system slows event listener attachment and makes early user input sluggish each load.

Rehydration performance

Rehydration spans all of the above considerations for JS boot, and was the primary culprit in our performance traces. You can’t ignore rehydration costs for the theoretical ideal React MPA.

Performance metrics collected from real websites using SSR rehydration indicate its use should be heavily discouraged. Ultimately, the reason comes down to User Experience: it’s extremely easy to end up leaving users in an “uncanny valley”.

—Rendering on the Web § A Rehydration Problem: One App for the Price of Two

Thus, faster rehydration is almost as common as incremental HTML in the React ecosystem:

Along with their own caveats, each implementation runs into the same limitations from React itself:

Mandatory [data-reactroot] wrappers hurt DOM size and reflow time.
React listens for events on each render root, which increases memory usage and slows event handling since previous === invariants are no longer guaranteed.
The Virtual DOM imposes a lot of rehydration overhead:
1. Render the entire component tree
2. Read back the existing DOM
3. Diff the two
4. Render the reconciled component tree
That’s a lot of work to show something nigh-identical to when you started!

🥀 Rehydration correctness

Cursory research turns up a lot of folks struggling to hand off SSR’d HTML to React:

No, really, skim those links. The nature of their problems strongly suggests that React was not designed for SSR, and thus uniquely struggles with it. If you think that’s an opinion, consider the following:

React handles intentional differences between client and server render about as ungracefully as possible.
If we use React for regions of more-complex interactivity throughout a page, what’s the best way to handle the rest of the page?
- Is it a pain to share state/props/etc. across multiple React “islands” on a page? Do Hooks behave oddly if you do that?
- Can we use Portals to get around this? (Note Portals don’t SSR.)
React’s error handling when rehydrating is… nonexistent. By default, it rejects showing any errors to the user in favor of flashing content or tearing down entire DOM trees into blank nodes.
React 16 doesn’t fix mismatched SSR-generated HTML attributes

—What’s New with Server-Side Rendering in React 16 § Gotchas

That’s… kind of a big deal.

Loses interaction state like focus, selection, <details>, edited <input>s on hydration. Losing users’ work is maddening in the best case, and this issue is magnified over slow networks/bad reception/low-spec devices.
Has issues with controlled elements when the boot process catches up and event listeners fire all at once. Note the above demo is using future Suspense APIs to solve a problem all React apps can fall into today.

🏸 Fast server runtime

Server-side optimizations for React are more common than anything else in this analysis:

Rax
react-ssr-optimization
ESX
react-ssr-error-boundary
React suspense and server rendering § So what’s the catch?
…and a million others

(The cynical takeaway is that because developers have to pay for React’s inefficiencies on servers, they are directly incentivized to to fix them, as opposed to inefficiences on clients.)

Isomorphic rendering is not a helpful abstraction for tweaking performance between server-side vs. client-side — web applications often end up CPU-bound on arbitrarily-slow user devices, but memory-bound on servers with resources split between connections.
A fast, efficient runtime can double as Service Worker rendering to streams for offline rendering, without needing to ship heavier CSR for things that don’t need it.

Unfortunately, almost all prior art for optimizing React server render involves caching output, which won’t help for Service Workers, EdgeWorkers, cloud functions, etc. So the suggested “trisomorphic rendering” pattern (which the demo bet on for offline) is probably a no-go with React.

🍂 Tree-shakeable runtime

Omitting code saves load time, memory use, and evaluation cost — including on the server! Svelte’s “disappearing framework” philosophy would be the logical conclusion of a tree-shakeable runtime — or maybe its reduction to absurdity, for Svelte’s pathological cases.

Facebook has considered modularizing React, but didn’t conclude it was a win for how they use it. They also experimented with an event system that tree-shook events you didn’t listen for, but abandoned it as well.

In short: nope.

🧠 Multi-page mental model

The most extreme MPA mental model probably belongs to Ruby on Rails. Rails wholly bets on server-side rendering, and even abstracts its JavaScript APIs to resemble its HTTP-invoked Controller/Model/View paradigm.

At the other end, you have React:

JSX prefers properties to HTML attributes
Server-side React pretends to be in a browser
The ecosystem strives to imitate DOM features on the server
Differences between server and browser renders are considered failures of isomorphic JavaScript that should be fixed

Pretending the server is a browser makes sense if you only use HTML as a fancy skeleton screen, and hydration is only a hiccup at the start of long sessions. But that abstraction gets leakier and more annoying the more times the original web page lifecycle occurs. Why bother with the className alias if markup may only ever render as class? Why treat SSR markup as a tree when it’s only ever a stream?

React plus forms (and other DOM-stored state) is annoying, controlled or not — will that be painful when we lean more on native browser features?
- React’s special handling of .defaultValue and .defaultChecked vs. .value and .checked can get very confusing across SSR-only vs. CSR-only vs. both
- React’s onChange pretending to be the input event, and the resulting bugs
Is it more likely we’d persist SPA habits that are MPA antipatterns if we continue with React?
Using another language/template system/whatever for non-React bits seems not ideal, but that’s how it’s been done for years anyway — especially since React straight-up can’t handle the outer scaffold of a web page.
React’s abstractions/features are designed to work at runtime
- Even without a build step, which is an impedance mismatch for apps with build steps. Not an intractable problem, but one with ripple effects that disfavor it.
- Leads to unusual code that JS engines haven’t optimized, such as the infamous thrown Promise, or Hooks populating a call index state graph via multiple closures.
Many new React features don’t currently work on the server, with vacillating or unclear timeframes for support:
- .lazy() and Suspense [EDITOR’S NOTE: yes I know they do now]
- Portals
- Error Boundaries
- How long does it usually take for React to bring client APIs to server parity? That lag may forecast similar problems in the future.

Speaking of problems in the future…

What about where React is going?

As we’ve seen, there’s much prior art of features desirable for fast SSR: incremental HTML streams, in-page patching for out-of-order rendering, omitting JS for components that never rerender on the client, compiling to a more efficient output target for the server, SSRing React APIs that otherwise aren’t, etc.

There is no reason to think that these individual upgrades are inherently incompatible with each other — with enough glue code, debugging, and linting, React theoretically could have the rendering tricks I found useful in Marko.

But we’ve already gotten a taste of future compat problems with our React SSR relying on deprecated APIs. What about React’s upcoming APIs? Do we want to redo our SSR optimizations with every major version?

This risk is made more annoying by the upcoming APIs’ expected drawbacks:

In our experience, code that uses idiomatic React patterns and doesn’t rely on external state management solutions is the easiest to get running in the Concurrent Mode.

This makes me worry that the previously-mentioned possibility of a state manager to synchronize multiple React “islands” will be mutually exclusive with Concurrent Mode. Less specifically, I doubt we’d be sticking to “idiomatic React patterns”.

In the words of a Facebook engineer:

Better comparison is to a hard fork where we don’t maintain any backwards compatibility at all. React itself might be the sunk cost fallacy.

Essentially, future React will be different enough to break many of the reasons companies rely on it today:

Knowledge gained from experience with the library
3rd-party libraries (in deep ways)
Established patterns

Potentially worse is how Suspense would affect React’s memory consumption. The VDOM roughly triples the DOM’s memory usage (real DOM + incoming VDOM + diffed-against VDOM), and the “double-buffering” used in Suspense’s examples will worsen that. React also considered slimming its synthetic event system, but Concurrent Mode would break without it.

If you look at how Fiber is written, the architecture truly makes no sense and is unnecessarily complex… except to support Concurrent Mode.

Similar case in design of hooks. If not for concurrency, we woulda just used mutation.

— Andrew Clark

So Concurrent Mode promises smart scheduling about long JavaScript tasks so React’s cost can be interrupted, but the ways React had to change for Concurrent Mode caused other possible issues:

Worse raw performance from frequently yielding the main thread
Garbage collection pressure from Hooks
Memory consumption from multiple simultaneous React trees
Risks “tearing” during hydration
Doubling down on synthetic events instead of omitting them for less bundle size
Existing patterns that didn’t break before, but will — often patterns that libraries needed to eke out performance

What if, instead of trying to be clever about doing a lot of work in the browser, we instead did less work in the browser? That’s why Kroger Lite is fast. It’s not just from box-ticking the features I mentioned, it’s because its technologies were chosen and app code was written in service of that principle.

It may be wise to judge future React not as a migration, but as a completely different framework. Its guarantees, risks, mental model, and benefits are no longer the same. And it really seems to be pushing the depths of framework-level cleverness.

Assume we nail the above; it takes little time to augment React, there are no unforeseen bugs, and teams quickly update components to reap the rewards. We would nevertheless shoulder some drawbacks:

More painful upgrades to React versions with internal or breaking changes
Required linting/CI/etc. to ensure React features aren’t used in ways or contexts that would cause problems
Unknown compatibility issues with ecosystem code like Jest, 3^rd party components, React DevTools, etc.

Open questions:

What new rehydration problems will we see with Concurrent Mode, async rendering, and time-slicing?
Will hook call order remain persistent across React islands, Suspense, deferred updating, different renderers, combinations of all of those, or scenarios I haven’t anticipated?

Conclusion

This analysis is harsh on React’s MPA suitability. But is that so odd?

It was created to client-render non-core bits of Facebook. Its maintainers only recently used it for server rendering, navigation, or delivering traditional web content. In fact, its SSR was a happy accident. And finally, longstanding evidence holds React trends antagonistic towards performance.

Why would React be good at the things we ask it to do?

With the FB5 redesign, Facebook is finally using React in the ways that we are, and they have found it wanting. On the one hand, this means React will surely become much better at desirable SSR features. On the other, when this will happen is unsure, it will heavily change React’s roadmap, and React could change so much that familiarity with how it works today could be a liability rather than a strength.

For the target audience of rural/new/poorly-connected customers, does Facebook even use React to serve them? Did FB5 change anything, or does m.facebook.com still not use React?
If we want a version of Kroger.com as fast as the demo, but using the same framework, processes, management, and developers as the existing site — wouldn’t that just become our existing site? We can’t change our personnel, but we can change the technologies we build on.
Last, but certainly not least: can you make an industry-beating app out of industry-standard parts?

Men would rather ignore 20% of the US than stop using React.³ ↩
Well, one browser can natively parse text/x-component, sorta. I guess RSCs reused the MIME type as an easter egg? ↩
Or 50% of the US, depending on what you count. ↩

Follow-ups to the “Streets” series

Taylor Hunt — Sun, 17 Sep 2023 04:22:40 +0000

The original Streets series was adapted from a bunch of internal writeups I did at Kroger to explain myself and my demo, and there’s plenty of leftovers that didn’t fit into the original “tight five”. Since nothing came of that, and I’ve since given up on my original plan to reuse that knowledge (more on that later), I’m putting the rest onto the Web so that maybe someone can find them useful or interesting.

Answers to some questions

Feel free to ask more questions in the comments!

Why should we trust a framework team member about front-end framework performance?

I was laid off by eBay in February 2023. I am now equally untrustworthy as I was before.

What should you do when a server error happens in the middle of an HTML stream?

There isn’t a perfect solution (yet, the HTTPWG has been thinking about it), but there’s at least something you can do to avoid errors being cached on clients and prevent search engines from indexing pages with mid-stream errors.

You can emulate 5XX error semantics (that is: do not cache and permissible to retry the request to see if error is fixed) by mucking around at the HTTP level:

HTTP version	Error signal
HTTP/1.1	Corrupt the `chunked` `Transfer-Encoding` syntax or never terminate it properly
HTTP/2	Send a `RST_STREAM` frame with a code of `0x2 INTERNAL_ERROR`
HTTP/3	Like h2, but the frame name differs I think?
SPDY	Why are you still using this

Research and further details on doing this correctly:

marko-js/community#1 Handling mid-stream errors (it’s a WIP pull request with an evolving discussion, sorry you’ll have to read the whole thing before the advice becomes clear)
httpwg/http-core#895 Mid-stream error semantics

Why did you think Kroger Lite would work?

I didn’t, but it was worth a shot. And then for a while, it really seemed like it was working. But yeah, big companies historically seem content to let internal efforts to improve speed wither:

Andy Davies on Twitter:
Shortly after I did this talk BazaarVoice demo’d a slimmed down version but don’t think it ever saw the light of day

Amazing really, especially after their internal panic when a customer talked about how disabling BazaarVoice increased revenue by several millions pounds / year

Jason Grigsby on Twitter:
I doubt I’ll be able to publish about it, but I’m not seeing anything different than what @AndyDavies talked about in noti.st/andydavies/dCB… and youtube.com/watch?v=mLzt23…

It’s four years later and BV’s performance is basically the same. It’s depressing.

…and indeed it also happened to me. I’m partial to Baldur Bjarnason’s explanation that software quality and software income are basically uncorrelated:

In most sectors of the software industry, sales performance and product quality are disconnected.

By its nature software has enormous margins which further cushion it from the effect of delivering bad products.

The objective impact of poor software quality on the bottom lines of companies like Microsoft, Google, Apple, Facebook, or the retail side of Amazon is a rounding error. The rest only need to deliver usable early versions, but once you have an established customer base and an experienced sales team, you can coast for a long, long time without improving your product in any meaningful way.

Maybe only a competitor with a really fast site could make big slow React sites get faster?

Was it the choice of Marko that doomed Kroger Lite?

I dunno. Marko at the time had components, syntax, and a VDOM like React; and powered a bigger, more successful ecommerce site; and had an agreeable license thanks to the Open JS Foundation.

If that wasn’t a realistic alternative to React, then what possibly could be?

What’s with the cover images?

I made them. I tried outsourcing because doing it myself took longer than my ADHD liked, but finding an artist open to commissions for this kind of thing took even longer. (This was before popular text-to-image models, but those are gauche anyway.)

I made most of the images by combining photographs in the The GIMP. (Tip: use the hell out of layer masks.) The source images were from DuckDuckGo’s Image Search by License, Wikimedia Commons, and photos by US government personnel that default into the public domain.

I made the train map for Routing: I’m not smart enough for a SPA with Metro Map Maker. (Which, yes, is a SPA. It could be fun to replicate it as an MPA with <input type=image>.)

Why is the series called “Streets”, anyway?

See next question.

Where’s that code you threatened us with?

And by the end, some code I dare you to try.

— Making the world’s fastest website, and other mistakes

That was to be streets, an NPM package to help produce a web thang as fast as the demo site I showed off. (Without using the demo’s site original code, since Kroger owns the copyright on it.)

Why “streets”? Turns out a street is different from a road in some important ways:

A feature universal to all streets is a human-scale design that gives its users the space and security to feel engaged in their surroundings, whatever through traffic may pass. — Street · Wikipedia

(In this analogy, SPAs are stroads.)

That seemed perfect for my design priorities:

🛡 Reliable: respect everyone’s safety and circumstances
- Security features built-in to where your server is in control
- Offline support without SPA overhead
♿️ Accessible: respect the web’s diversity, longevity, and ubiquity
- Fast, accessible-by-default navigations
- Browser support as deep as you need
💨 Fast: respect users’ time and money
- Interactive in 150ms on $20 devices
- Payload small enough for 2G networks
- Avoid jams with streaming

But I burnt out. Yes, I’m seeing a therapist. I also started drawing as a hobby for the first time in ≈10 years.

I’d love to make Streets, but I can’t keep going it alone anymore. I’m also not sure who would really bother using it — my original idea was developers beholden to the public good via government sites, charities, etc., but I realized those organizations probably require certified vendors or something.

Here’s a Rollup config very similar to the demo’s, though. That’ll be handy if you want the kind of speed it had.

Now what?

The next post will be adapted from my original analysis of why I doubted Kroger.com could approach the demo’s speed if it remained wedded to React. It was part of the original Streets posts, but at the time I was afraid of people getting angry at me over it.

The one nice thing about burnout? I don’t care about that sort of thing anymore.

I think I finally “get” JS objects

Taylor Hunt — Tue, 30 May 2023 14:31:53 +0000

While learning JavaScript, at some point I looked up what “object-oriented” meant.

That was a mistake.

The first reason it was a mistake was because I was exposed to way too many unhelpful OOP diagrams. You know the kind:

This diagram from Wikimedia Commons is typical: it models something you’d never code in a real program. (Why is that so common?)

The other reason it was a mistake was because it taught me about Java and C++ programmers’ opinions on objects… but those opinions barely mattered to the language I was learning. I read about “information hiding”, “encapsulation”, and “polymorphism”, but I didn’t understand how they were relevant.

And as it were, they mostly weren’t relevant!

Some jargon was for techniques difficult in other languages, but so easy in JavaScript that you don’t even think about them.
Some jargon was for how low-level languages would optimize performance, in ways that JavaScript is too high-level to care about.
Some jargon described techniques that JavaScript objects can’t even do.
And, lastly, some jargon was for bad ideas — even in the originating languages.

For years, I was dimly aware that it seemed unnecessary to mess with prototypes, classes, constructors, and this for like, 98% of my code — so why was I expected to use them for everything, or I wasn’t doing object-orientation “properly”?

It turns out object-oriented code is great at some things, but not all things

What I’ve since realized is that JavaScript reuses its full-power Objects for many non-OO purposes, most of which are much simpler. I’ve used JS objects for roughly 4 things:

Grouping variables
Namespacing
Typed-ish data
Actual full-power Objects

The first 3 aren’t “real” object-orientation (or whatever that means), but they reuse the object machinery JavaScript already has because it’s convenient.

1. Grouping variables

Sometimes, you want to collect related variables together. Other languages features for that are called dictionaries, hashes, maps, or structs. Perl, being Perl, has 6 ways to do it, with names like “BagHash”.

It’s like prefixing variable names that go together:

var player_x = 0;
var player_y = 0;
var player_health = 100;

// or:
var player = {
 x: 0,
 y: 0,
 health: 100
};

Usually the specifics of how exactly to group variables in other languages is for performance reasons. For example, C’s structs group values together to make them efficient byte-wise, but if you want to look up the properties at runtime by name, you’ll need a hash function/table instead.

These sorts of grouped variables as objects are also used to 1.) return multiple values, 2.) implement optional arguments in a friendly way, and 3.) other places where the language doesn’t support passing around multiple variables at once. As a counterexample, Python has optional keyword function arguments and multiple return values, so it doesn’t use objects for either. But in JavaScript, we use object and object accessories for both:

function getCoordinates (
  target,
  { relativeTo } // Using object destructuring for optional arguments
) {
  let ret = { x: 0, y: 0, relativeTo };
  if (relativeTo) {
    ret.x = getHorizontalOffset(target, relativeTo[0]);
    ret.y = getVerticalOffset(target, relativeTo[1]);
  } else {
    ret.x = getHorizontalOffset(target);
  }

  return ret; // Returning 3 related variables in the same object
}

2. Namespacing

There’s no technical reason that the Math object exists. But there is a human reason: it’s easy to remember math-related stuff lives in this object.

They could be separate identifiers with math_ prefixes — older languages did that all the time. But this seems a little cleaner; contrast the myriad functions in PHP’s global scope.

Modern-day JavaScript now handles namespacing with module imports and exports, but you can still wrap those up into an object, the syntax is similar, and many old browser APIs and libraries still use objects for namespacing.

(This is also known as static properties/methods, which kind of sucks as a name and infected JS from other, less fun programming languages. Go @ TC39 about it.)

3. Typed-ish data objects

Typed-ish data objects (a very rigorous term I just made up) bundle data with ways to read and manipulate said data, like Date, DOMRect, or Array.

Typed-ish data objects are when this and methods become useful — methods that don’t use this are just namespaced functions.
I think this is the level where instanceof would become useful, but JS/DOM design mistakes popularized duck typing in the JavaScript world anyway.

These objects let you change their data in different ways, and the different ways to read that data will update to match your changes:

var d = new Date();
d.toDateString(); // "Sat Apr 11 2020"
d.setMonth(7);
d.toDateString(); // "Tue Aug 11 2020"

These kinds of objects can use (and often do use) information-hiding/internal representations, but it’s not required. For example, a Date only stores one UNIX timestamp as an integer, and it even lets you look at and change that integer directly if you want. And as for TypedArray, well, it’s in the name.

For example, a Color object where the constructor takes any string that CSS can parse as a color, then expands it into an object with R, G, B, and A properties. (This part is left as an exercise to the reader, because it’s surprisingly hard.)

At first, an object shaped like the following:

{
  R: 255,
  G: 40,
  B: 177,
  A: 255
}

…doesn’t seem that much more useful than using hex codes directly in JS like 0xff28b1ff. But by making an actual color Object you can new up, we can add useful features, such as:

We could enforce that R, G, and B never exceed 255 or go lower than 0 with a setter.
It could have tint() and shade() methods that are easier to understand than manual RGB tinkering.
The Color object could return the numeric equivalent of its hexadecimal code for its .valueOf(), output a human-friendly hsla() syntax for its .toString(), or output to an array for data transfer with .toJSON().

4. Full-force capital-O internal state Objects, also known as Art

Finally, you have the full-force objects that act as discrete… well, objects. Like DOM elements, Document, and so on. They use the hell out of this, and need to. (It’s possible to model these sorts of things in functional programming, but it involves trying to avoid this so hard you end up inventing that.¹)

HTMLInputElement.validity.validate(), though, is very good. It uses a bunch of properties on one specific user-visible object, then changes what the element is doing to reflect its calculations. And if you call the .focus() method on one <input>, it changes the properties of others and the activeElement property of the document that owns them all.

For an even more complex example, consider jQuery objects and their seemingly-simple API:

$('.widget').addClass('loaded').fadeIn().on('click', activateWidget);

There is a great deal going on under the hood there. But because jQuery is doing those object operations under the hood, it turns into a wonderful API that has stood the test of time.

Anyway, I’m not a good enough programmer to really understand or work on level 4 yet.

So what?

My first draft originally tried to tie this all into a lesson for readers, but I suspect this post is too confusing for beginners and also too mundane for advanced devs, so I’m publishing it for me. As a treat.

No, I will not explain what I mean. ↩

How to Succeed in Open Source Without Really Trying (Really)

Taylor Hunt — Wed, 10 May 2023 01:29:00 +0000

≥8 years ago, I wrote about an extremely niche improvement to a very specific use of SVGs. It got enough positive feedback that I turned that knowledge into an NPM package: mini-svg-data-uri.

Today, it’s both one of the most and least important web dev things I’ve ever done.

Somehow, it’s important

As of this writing, NPM says it gets ≈1.7 million downloads/week. That also means NPM foisted 2FA onto my account that I almost never use. (If you compare the dates when the repo accepted a PR to the NPM updates, you’ll probably see exactly when they did that.)
Snyk rates it “Influential”, which means it’s in the top 5% of all NPM packages actually added to a package.json, not just a transitive dependency.
I know with some certainty that lots of people use mini-svg-data-uri solely on RunKit, so both Snyk and NPM don’t see a huge chunk of users. (Never underestimate how meaningful a “try online” feature is.)

Normally, I’d be super smug about this and start being insufferable in developer conversations, but…

It’s also unimportant and ridiculous

Snyk and NPM both have algorithms to rate packages for quality and maintenance, but in this case they should consider letting me submit a rating of “lol i dunno”.

It’s not that effective.: The README points out it optimizes by as much as, uh, 20%. And unlike the README’s example, most websites don’t consist entirely of SVG data: URIs.; Unless you’re using mini-svg-data-uri in an offline build tool, it’s almost certainly not worth the download of its JS. (So all of you importing it to use on the client-side… are you sure you want to do that?)
It has no tests.: I don’t remember where its index.test-d.ts came from, but it’s certainly not clear what it accomplishes.
It rarely updates.: Snyk penalizes this, but honestly it’s kind of a feature. It rarely needs to update.
It’s written in like, ES3½.: Folks wanted to use it untranspiled, or something? In principle that’s terrible and Alex Russell will appear in your mirrors at night chanting “who made this mess”, but in practice it’s ≈3.5kB unminified.
I am objectively kind of a bad maintainer.: I automated nothing, which means I must relearn how to npm publish each update, which means folks’ contributions can get needlessly delayed.; If you look through the issues, you’ll see me say “I don’t know” a lot. Humility’s one thing, but I wouldn’t begrudge anyone not trusting me to do things right.; There’s no code of conduct or contributing guidelines, and it still defaults to master. (Somehow I’ve innovated the cognitive dissonance of believing those things are important, and yet also too important for my rinkydink package.)
The features it accrued are niche.: Its “types”: a function that accepts a string and returns a string. I assume the TypeScript was for autocomplete or purism or something, because it sure doesn’t constrain much.; Its CLI is from a dev who whipped it up for themselves then contributed back on a whim. Sure, without a real shell arguments parser, it might break or be needlessly slow. But if you can identify those problems, you probably already know how to fix them with your own #!/usr/bin/env node.; It sprouted a .toSrcset() method because srcset uses spaces as part of its syntax, so you need %20 escapes. It accomplishes this with zero cleverness whatsoever, so I suspect most of the feature’s worth is from how it emphasizes the srcset pitfall in the README.

To be clear, I appreciate that those devs took the time to add features that scratched their own itch. I know there’s something to be said for refusing features to keep software lean and mean. But even though I don’t use those contributed features myself, it takes up a whopping 10kB uncompressed on disk. So, like, refusing those features would have ruined a lot of peoples’ days for no real reason.

Nobody really gives that much of a shit about it

The code is handy, but if it became even slightly annoying to use — say if I added whatever makes npm fund do its thing — people would just fork or vendor it.
It’s in a sweet spot of usefulness with almost no leverage, so it chugs along without any temptation for me to do anything spicy and/or money-related with it.
Putting its stats on my résumé would be impressive, until anyone looked closer.
It’s somehow avoided getting slapped with the “regular expression denial of service” bullshit that everyone loves, despite having regular expressions I authored in 3 minutes.
I haven’t even had people try to grift me over it, which I assume is automated based on package stats nowadays.

And yet, it’s undeniably popular. I guess it ticks all the boxes for “is this worth using?” — it handles enough annoying details that you’d rather not yourself, it has no dependencies, and you can read the entire source code almost by accident. The UNIX philosophy is a scam, but it’s a nice racket if you can get it.

It’s dying, but not how’d you think

svg-mini-data-uri will probably become obsolete as evergreen browsers completely take over, since their parsing is loose enough that "data:image/svg+xml," + str.replace(/#/g, '%23') gets you 80% there.

Honestly, it’s kind of nice that it’ll die with the problem it helped solve. It was there when needed, but not a moment longer.

So what?

Maybe the system worked this time? I wrote code for me, then shared it, and now tons of people benefit without me suffering the usual problems of being a popular open-source maintainer. The software does what it says, boringly, and is small enough that it doesn’t make developers or users suffer even when it’s not used “right”.

And it happened without me writing tests, doing any outreach, being good at code, or even using this correctly.

When I put it that way, it sounds like a pretty good trick.

Marking up colors, revisited with GitHub’s color swatches

Taylor Hunt — Thu, 05 Jan 2023 23:21:14 +0000

I wrote about semantic HTML for colors 5 years ago, for when a color’s appearance is important content, not just style:

Design systems’ available color palettes
Choosing what color of clothing you would like to buy
Preview swatches for sites about paint
Probably lots more — colors are pretty important!

My original post suggested a labeled <input type=color readonly>, but since then I’ve thought about how that falls short:

Can’t display wide-gamut colors, or managed color in general
Can’t display semitransparency, gradients, patterns, or other fancy swatches
Can’t nest inside <a>, <button>, another form field’s <label>, etc.
readonly still isn’t allowed on <input type=color>… and the color picker/inspection popup isn’t accessible yet anyway

So, my original conclusion’s <svg> is probably a better idea. (I’d use my Edit button on that post… if I had one.)

Now, those issues are important, but the real reason I’m writing this is much pettier: I used Inspect Element on github.com and got mad about it.

GitHub’s hex code swatches

GitHub has a feature where if you type a 6-digit hex code in Markdown files/comments/whatever, it displays a color dot of that hex in RRGGBB format:

For example, GitHub’s HTML output if you type `#aa4400` looks like:

<code>#aa4400
  <span
    class="ml-1 d-inline-block border circle color-border-subtle"
    style="background-color: #aa4400; height: 8px; width: 8px;"
  ></span>
</code>

This has problems:

Not exposed accessibly: Forget text alternatives, right now it’s completely nonexistent to assistive technology
Too easily overridden: By Dark/Light Mode browser extensions, builtin Dark Mode browser support, user styles, etc.
Invisible under forced colors: forced-colors is the standardized name for features like Windows High-Contrast Mode, which turn off background-color altogether

We can fix most of those problems with inline SVG:

<code>#aa4400
  <svg width="8" height="8"
    fill="#aa4400"
    class="ml-1 border circle color-border-subtle"
  >
    <rect width="100%" height="100%"/>
  </svg>
</code>

A few notes on the above markup:

I haven’t exposed it accessibly yet, because that turned out to be a whole section’s worth of considerations
No longer needs the d-inline-block class (<svg> is inline-block by default)
No style attribute lets it play nice with strict Content-Security Policies

But why stop there when we could be perfectionist

GitHub’s current implementation also has what I presume is a bug, where it looks silly inside larger text:

Inside an <h1>, for example.

SVG’s width and height attributes can use ems to scale the dot with the font size:

<code>#aa4400
  <svg width=".667em" height=".667em"
    fill="#aa4400"
    class="ml-1 border circle color-border-subtle"
  >
    <rect width="100%" height="100%"/>
  </svg>
</code>

Heck, you could even replace GitHub Primer’s utility classes with SVG’s builtins:

<code>#aa4400
  <svg width=".667em" height=".667em"
    fill="#aa4400"
    viewBox="-9 -8 17 16" stroke="var(--border-subtle)"
  >
    <circle radius="16"/>
  </svg>
</code>

GitHub probably won’t, since once you choose utility classes for something you need to use them everywhere or their core performance promise falls apart¹, but maybe you might?

By the way, GitLab does this too

And as usual, GitLab implemented the feature more thoughtfully than GitHub did². They support more color syntaxes and transparency, it doesn’t have the font-size scaling bug, and the markup is refreshingly simple:

<code>HSLA(540,70%,50%,0.3)
  <span class="gfm-color_chip">
    <span style="background-color: HSLA(540,70%,50%,0.3);"></span>
  </span>
</code>

It still breaks with forced colors and dark mode, so maybe the GitLab peeps would be interested in this article anyway. (I also refactored theirs to be shorter, simpler, and with one less <span>, because I’m insufferable.)

Speaking of accessibility, there’s something I haven’t addressed…

Accessibly exposing the color

So, that <svg>. What’s its role? Its accessible name? Should it be announced at all?

For this specific case, it has a text equivalent right alongside it, and GitHub’s audience is tech-savvier than usual — I can imagine that GitHub may have decided announcing the color dot separately was superfluous.

…but I disagree. Displaying the color adds information for sighted users, hence why the feature exists at all; for the ideal of information parity across disability boundaries, we should try to be equitable.

Since the hex code is already there, a proper text alternative would be the information equivalent of displaying the color dot. Maybe a color name via something like the ISCC–NBS system?³

Trying to explain colors to people who can’t see them isn’t the goal — but naming a color consistently can be quite useful by itself. Not to mention, blind people may want to know for its own sake!

<code>#aa4400
  <svg role="img" aria-labelledby="_Z5jdHi6">
    <title id="_Z5jdHi6">Color: “firebrick”</title>
    …
  </svg>
</code>

I’m not 100% sure you need the role — the state of the art with inline SVG accessibility has changed a lot recently, as this StackOverflow question, answer, and interspersed comments show.
Using <title> shows up on hover, which helps colorblind folks disambiguate when they need to.
I’m using aria-labelledby because aria-label still isn’t machine translated. (Then again, I’m not sure Google/Bing translate inline SVG yet either.)

I don’t have a real conclusion but here’s a fun fact

When I first started learning about color accessibility, the explanations of what each colorblindness variety sees instead of the “real” colors bothered me — how could they be so sure? While normally I’m happy to leave “do you and I see the same red” to the philosophers, this was too important for a hand-wavy justification to satisfy me.

Days later, lost and confused from scientific papers about human retinas, the occipital lobe, signal processing, and other complexities around one of the first skills babies learn, I found an answer that was so prosaic it made me laugh: some people are colorblind in only one eye.

Any feature you have to “earn” by adhering to a technology and you shall have no technologies before it is one I distrust. Migrating away from something like Tailwind is suspiciously difficult. (This is my footnote and I can be crankety if I want to.) ↩
Using GitHub Actions after working in GitLab CI is like disassembling a perfectly good sandwich and making it into sushi. It all eventually goes where you need, but nobody’s happy. ↩
There’s a bunch of color naming systems and even more color naming NPM packages, and I’m not qualified to recommend any of them. ↩

So what?

Taylor Hunt — Wed, 08 Jun 2022 14:20:26 +0000

Last time, I promised to write about “getting the benefits that SPAs enjoy, without suffering the consequences they extremely don’t enjoy”. And then Nolan Lawson wrote basically that, and then the madlad did it again. He included almost everything I would’ve:

MPA pageloads are surprisingly tough to beat nowadays: Paint holding, streaming HTML, cross-page code caching, back/forward caching, etc.
Service Worker rendering: Also see Jeremy Wagner on why offline-first MPAs are cool
In theory, MPA page transitions are Real Soon Now: In practice, Kroger.com had none and our native app barely had any, so I didn’t care
And his main point:: If the only reason you’re using an SPA is because “it makes navigations faster,” then maybe it’s time to re-evaluate that.

(I don’t think he talked about how edge rendering and MPAs are good buds, but I mentioned it so here’s ticking that box.)

Since Nolan said what I would’ve (in less words!), I’ll cut to the chase: did my opinions in this series make a meaningfully fast site? This is the part where I put my money where my mouth was:

Proving that speed mattered wasn’t enough: we also had to convince people emotionally. To show everyone, god dammit, how much better our site would be if it were fast.

The best way to get humans to feel something is to have them experience it. Is our website painful on the phones we sell? Time to inflict some pain.

The demo

I planned to demonstrate the importance of speed at our monthly product meeting. It went a little something like this:

Buy enough Poblano phones for attendees.
On those phones and a throttled connection, try using Kroger.com:
1. Log in
2. Search for “eggs”
3. Add some to cart
4. Try to check out
Repeat those steps on the demo.
Note how performance is the bedrock feature: without it, no other features exist.

Near the laptop with the horrible pun are 10 of the original 15 demo phones. (The KaiOS flip phone helped stop me from overspecializing for Chrome or the Poblano VLE5 specs.)

A nice thing about targeting wimpy phones is that the demo hardware cost me relatively little. Each Poblano was ≈$35, and a sale at the time knocked some down to $25.

How fast was it?

Sadly, I can’t give you a demo, so this video will have to suffice:

The browser UI differs because each video was recorded at different times. (Also, guess walmart.com’s framework.) Text description of video

Me racing to get the demo, kroger.com, Kroger’s native app, amazon.com, and walmart.com all to the start of checkout as fast as possible. In order of how long each took:

The demo, in 20 seconds
amazon.com, in 59 seconds
The Kroger native app, in 1 minute 21 seconds
walmart.com, in 2 minutes 14 seconds
kroger.com, in 3 minutes 44 seconds

If you want to improve dev.to’s video accessibility, consider voting for my feature request for the <track> element.

For a bit, our CDN contact got it semi-public on the real Internet. I was beyond excited to see this in @AmeliaBR’s Firefox devtools:

That’s Cincinnati, Ohio → Edmonton, Canada. 293 milliseconds ain’t bad for a network response, but I was so happy because I knew we could get much faster…

About 50–100ms was from geographical distance, which can be improved by edge rendering/caching/etc.
PCF’s gorouters have a 50ms delay. Luckily, we were dropping PCF.
40ms from Nagle’s algorithm, maybe even 80ms from both Node.js and the reverse proxy. This is what TCP_NODELAY is for.
Tweaked gzip/brotli compression, like their buffer sizes and flushing behavior
Lower-latency HTTPS configuration, such as smaller TLS record sizes

Let’s say that averages out to 200ms in the real world. Based on the numbers in the first post, that’s $40 million/year based on kroger.com’s 1.2 TTFB today. Or, ~5% of company profit at the time. (The actual number would probably be higher. With a difference this large, latency→revenue stops being linear.)

So… how’d it go?

Or as Jason Grigsby put it:

The burning questions are related to how it performed and what the organization thought about it? How much was adopted? Etc.

What did the organization think of it?

The immediate reaction exceeded even my most indulgent expectations. Only the sternest Dad Voice in the room could get enough quiet to finish the presentation. Important people stood up to say they’d like to see more bottom-up initiative like it. VIPs who didn’t attend requested demos. Even some developers who disagreed with me on React and web performance admitted they were intrigued.

Which was nice, but kroger.com was still butt-slow. As far as how to learn anything from the demo, I think these were the options:

Adapt new principles to existing code
Rewrite (incremental or not)
Separate MVP

Adapt new principles to kroger.com’s existing code?

Naturally, folks asked how to get our current React SSR architecture to be fast like the demo. And that’s fine! Why not React? Why not compromise and improve the existing site?

We tried it. Developers toiled in the Webpack mines for smaller bundles. We dropped IE11 to polyfill less. We changed the footer to static HTML. After months of effort, we shrank our JS bundle by ≈10%.

One month later, we were back where we started.

Does that mean fast websites are too hard in React? C’mon, that’s a clickbait question impossible to answer. But it was evidence that we as a company couldn’t handle ongoing development in a React SPA architecture without constant site speed casualties. Maybe it was for management reasons, or education reasons, but after this cycle repeated a few times, a fair conclusion was we couldn’t hack it. When every new feature adds client-side JS, it felt like we were set up to lose before we even started. (Try telling a business that each new feature must replace an existing one. See how far you get.)

At some point, I was asked to write a cost/benefit analysis for the MPA architecture that made the demo fast, but in React. It’s long enough I can’t repeat it here, so instead I’ll do a Classic Internet Move™: gloss a nuanced topic into controversial points.

Reasons not to use React for Multi-Page Apps

React server-renders HTML slower than many other frameworks/languages

If you’re server rendering much more frequently, even small differences add up. And the differences aren’t that small.

React is kind of bad at page loads

react + react-dom are bigger than many frameworks, and its growth trendline is disheartening.

In theory, React pages can be fast. In practice, they rarely are.

VDOM is not the architecture you’d design if you wanted fast loads.

Its rehydration annoys users, does lots of work at the worst possible time, and is fragile and hard to reason about. Do you want those risks on each page? ℹ️ Okay, I feel like I have to back this one up, at least.

Performance metrics collected from real websites using SSR rehydration indicate its use should be heavily discouraged. Ultimately, the reason comes down to User Experience: it's extremely easy to end up leaving users in an “uncanny valley”.

— Rendering on the Web § A Rehydration Problem: One App for the Price of Two

The Virtual DOM approach inflicts a lot of overhead at page load:

Render the entire component tree
Read back the existing DOM
Diff the two
Render the reconciled component tree

That’s a lot of unnecessary work if you’re going to show something mostly-identical to the initial text/html response!

Forget the performance for a second. Even rehydrating correctly in React is tricky, so using it for an MPA risks breakage on every page:

No, really, skim those links. The nature of their problems is more important than the specifics.

React fights the multi-page mental model

It prefers JS properties to HTML attributes (you know, the class vs. className thing). That’s not a dealbreaker, but it’s symptomatic.

Server-side React and its ecosystem strive to pretend they’re in a browser. Differences between server and browser renders are considered isomorphic failures that should be fixed.

React promises upcoming ways to address these problems, but testing, benching, and speculating on them would be a whole other post. (They also extremely didn’t exist two years ago.) I’m not thrilled about how React’s upcoming streaming and partial hydration seem to be implemented — I should test for due diligence, but a separate HTTP connection for a not-quite-JSON stream doesn’t seem like it would play nice during page load.

Taking it back to my goals, does Facebook even use React for its rural/low-spec/poorly-connected customers? There is one data point of the almost-no-JS mbasic.facebook.com.

Rewrite kroger.com, incrementally or not?

Software rewrites are the Forever Joke. Developers say this will be the last rewrite, because finally we know how to do it right. Businesses, meanwhile, knowingly estimate how long each codebase will last based on how wrong the developers were in the past.

Therefore, the natural question: should our next inevitable rewrite be Marko?

I was able to pitch my approach vs. another for internal R&D. I can’t publish specifics, but I did make this inscrutable poster for it:

And because I’m an incorrigible web developer, I made it with HTML & CSS.

That bakeoff’s official conclusion: “performance is an application concern, not the platform’s fault”. It was decided to target Developer Experience™ for the long-term, not site speed.

I was secretly relieved: how likely will a new architecture actually be faster if it’s put through the same people, processes, and culture as the last architecture?

With the grand big-bang rewrite successfully avoided, we could instead try small incremental improvements — speed A/B tests. If successful, that’s reason enough to try further improvements, and if those were successful…

The simplest thing that could possibly work seemed to be streaming static asset <script> and <link> elements before the rest of the HTML. We’d rewrite the outer scaffolding HTML in Marko, then embed React into the dynamic parts of the page. Here’s a simplified example of what I mean:

import {
  renderReactRoot,
  fetchDataDependencies
} from './react-app'

<!doctype html>
<html lang="en-us">
<head>
  <meta charset="utf-8">
  <meta name="viewport" content="width=device-width,initial-scale=1">
  <for|{ url }| of=input.webpackStaticAssets>
    <if(url.endsWith('.js')>
      <script defer src=url></script>
    </if>
    <if(url.endsWith('.css')>
      <link rel="stylesheet" href=url>
    </if>
  </for>

  <PageMetadata ...input.request />
</head>
<body>
  <await(fetchDataDependencies(input.request, input.response)>
    <@then|data|>
      $!{renderReactRoot(data)}
    </@then>
  </await>
</body>
</html>

This had a number of improvements:

Browsers could download and parse our static assets while the server waited on dynamic data and React SSR.
Since Marko only serializes components with state, the outer HTML didn’t add to our JS bundle. (This had more impact than the above example suggests; our HTML scaffolding was more complicated because it was a Real Codebase.)
If successful, we could rewrite components from the outside-in, shrinking the bundle with each step.
Marko also paid for itself with more efficient SSR and smaller HTML output (quote stripping, tag omission, etc.), so we didn’t regress server metrics unless we wanted to.

This almost worked! But we were thwarted by our Redux code. Our Reducers ‘n’ Friends contained enough redirect/page metadata/analytics/business logic that assumed the entire page would be sent all at once, where any code could walk back up the DOM at its leisure and change previously-generated HTML… like the <head>.

We tried to get dev time to overcome this problem, since we’d have to make Redux stream-friendly in a React 18 world anyway. Unfortunately, Redux and its ecosystem weren’t designed with streaming in mind, so assigning enough dev time to overcome those obstacles was deemed “not product-led enough”.

Launch a separate, faster version of kroger.com?

While the “make React do this” attempts and the Streaming A/B test were, you know, fine, they weren’t my favorite options. I favored launching a separate low-spec site with respectful redirects — let’s call it https://kroger.but.fast/. I liked this approach because…

Minimum time it took for real people to benefit from a significant speedup
Helped with the culture paradox: your existing culture gave you the current site. Pushing a new approach through that culture will change your current culture or the result, and the likelihood of which depends on how many people it has to go through. A small team with its own goals can incubate its own culture to achieve those goals.
If it’s a big enough success, it can run on its own results while accruing features, until the question “should we swap over?” becomes an obvious yes/no.

How much was adopted?

Well… that’s a long story.

The Performance team got rolled into the Web Platform team. That had good intentions, but in retrospect a platform team’s high-urgency deploys, monitoring, and incident responses inevitably crowd out important-but-low-urgency speed improvement work.

Many folks were also taken with the idea of a separate faster site. They volunteered skills and time to estimate the budget, set up CI/CD, and other favors. Their effort, kindness, and optimism amazed me. It seemed inevitable that something would happen — at least, we’d get a concrete rejection that could inform what we tried next.

The good news: something did happen.

The bad news: it was the USA Spring 2020 lockdown.

After the initial shock, I realized I was in a unique position:

COVID-19 made it extremely dangerous to enter supermarkets.
The pandemic was disproportionately hurting blue-collar jobs, high-risk folks, and the homeless.
I had a proof-of-concept where even cheap and/or badly-connected devices can quickly browse, buy, and order groceries online.

People won’t stop buying food or medicine, even with stay-at-home orders. If we had a website that let even the poorest shop without stepping in our stores, it would save lives. Even if they could only browse, it would still cut down on in-store time.

With a certainty of purpose I’ve never felt before or since, I threw myself into making a kroger.but.fast MVP. I knew it was asking for burnout, but I also knew I’d regret any halfheartedness for the rest of my life — it would have been morally wrong not to try.

We had the demo running in a prod bucket, agonizingly almost-public, only one secret login away. We tried to get anyone internally to use it to buy groceries.

I’m not sure anyone bothered.

I don’t know what exactly happened. My experience was very similar to Zack Argyle’s with Pinterest Lite, without the happy ending. (It took him 5 years, so maybe I’m just impatient.) I was a contractor, not a “real employee”, so I wasn’t privy to internal decisions — this also meant I couldn’t hear why any of the proposals sent up the chain got lost or rejected.

Once it filtered through the grapevine that Bridge maybe was competing for resources with a project like this… that was when I decided I was doing nothing but speedrunning hypertension by staying.

When bad things happen to fast code

On the one hand, the complete lack of real change is obvious. The demo intentionally rejected much of our design, development, and even management decisions to get the speed it needed. Some sort of skunkworks to insulate from ambient organizational pressures is often the only way a drastic improvement like this can work, and it’s hard getting clearance for that.

Another reason: is that to make a drastic improvement on an existing product, there’s an inherent paradox: a lot of folks’ jobs depend on that product, and you can’t get someone to believe something they’re paid not to believe. Especially when the existing architecture was sold as faster than the even-more-previous one. (And isn’t that always the case?)

It took me a while to understand how people could be personally enthusiastic, but professionally could do nothing. One thing that helped was Quotes from Moral Mazes. Or, if you want a link less likely to depress you, I was trying to make a Level 4 project happen in an org that could charitably be described as Level 0.5.

But enough about me. What about you?

Maybe you’re making a website that needs to be fast. The first thing you gotta do is get real hardware that represents your users. Set the right benchmarks for the people you serve. Your technology choices must be informed on that or you’re just posturing.

If you’re targeting cheap phones, though, I can tell you what I’d look at today.

For the closest performance to my demo, try Marko. ~~Yes, I’m paid to work on Marko now~~, [EDIT: not anymore] but what technology would better match my demo’s speed than the same technology? (Specifically, I used @marko/rollup.)

But, it’s gauche to only recommend my employer’s thing. What else, what else… If your site doesn’t need JS to work, then absolutely go for a static site. But for something with even sprinkles of interactivity like e-commerce — well, there’s a reason my demo didn’t run JAMstack.

My checklist of requirements are…

Streaming HTML. (See part #2 for why.)
Minimum framework JS — at least half of react + react-dom.
The ability to only hydrate some components, so your users only download JavaScript that actually provides dynamic functionality.
Can render in CDN edge servers. This unfortunately is hard to do for languages other than JavaScript, unless you do something like Fly.io’s One Weird Trick.

Solid is the closest runner-up to Marko; the only requirement it lacks is partial hydration.

Svelte doesn’t stream, or have partial hydration, but tackles the too-much-app-JS problem via its culture discouraging it. If Svelte implemented streaming HTML, I’d recommend it. Maybe someday.

If Preact had partial hydration and streaming, I’d recommend it too; even though Preact’s goals don’t always match mine, I can’t argue with Jason Miller’s consistent results. Preact probably will have equivalents of React’s streaming and Server Components, right?

Remix is almost a recommend; its philosophies are 🧑‍🍳💋. Its progressive enhancement approach is exactly what I want, as of React 18 it can stream HTML, and they’re doing invaluable work successfully convincing React devs that those things are important. This kind of stuff has me shaking my fists in agreement:

Wouldn’t it be great, if we could just move all of that code out of the browser and onto the server? Isn’t it annoying to have to write a serverless function any time you need to talk to a database or hit an API that needs your private key? (yes it is). These are the sorts of things React Server Components promise to do for us, and we can definitely look forward to that for data loading, but they don’t do anything for mutations and it’d be cool to move that code out of the browser as well.

— Remix: The Yang to React’s Yin

We’ve learned that fetching in components is the quickest way to the slowest UX (not to mention all the content layout shift that usually follows).

It’s not just the UX that suffers either. The developer experience gets complex with all the context plumbing, global state management solutions (that are often little more than a client-side cache of server-side state), and every component with data needing to own its own loading, error, and success states.

— Remixing React Router

Really, the only thing I don’t like about Remix is… React. Check this perf trace:

Sample from this remix-ecommerce.fly.dev WebPageTest trace

Sure, the main thread’s only blocked for 0.8 seconds total, but I don’t want to do that to users on every page navigation. That’s a good argument for why Remix progressively enhances to client-side navigation… but I’ve already made my case on that.

Ideally, Remix would let you use other frameworks, and I’d shove Marko in there. They’ve discussed the possibility, so who knows?

Routing: I’m not smart enough for a SPA

Taylor Hunt — Tue, 19 Apr 2022 11:30:39 +0000

In part 2, I glossed over a lot when I wrote…

I decided this called for an MPA. (aka a traditional web app. Site. Thang. Not-SPA. Whatever.)

Okay, but why did I decide that? To demo the fastest possible Kroger.com, I should consider all options — why not a Single-Page App?

Alright, let’s try a SPA

While React was ≈2× too big, surely I could fit a SPA of some kind in my 20kB budget. I’ve seen it done: the PROXX game’s initial load fits in 20kB, and it’s smooth on wimpier phones than the Poblano.

So, rough estimate off the top of my head…

Source | Parse size | gzip size ------------------------|-----------:|---------: `preact` 10.6.6 | 10.2kB | 4kB `preact-router` 4.0.1 | 4.5kB | 1.9kB `react-redux` 7.2.6 | 15.4kB | 5kB `redux` 4.1.2 | 4.3kB | 1.6kB My components[^2] | 5.9kB | 2.1kB **Total** | 40.3kB | ≈14.6kB

The HTML is little else than <script>s, so its size is negligible.
The remaining 5.4kB is plenty for some hand-tuned CSS.
This total is pessimistic: Bundlephobia’s estimate notes “Actual sizes might be smaller if only parts of the package are used or if packages share common dependencies.”

Seems doable.

…But is that really all the code a SPA needs?

Some code I knew I’d need eventually:

Translation between UI elements and API request/response formats
Updates in the <head>
Instead of fullsize image links, a lightbox script to avoid unloading the SPA
Checking and reloading outdated SPA versions
Code splitting to fit in the 20kB first load (my components estimate was only for the homepage), which means dynamic resource-loading code
Reimplementing beforeunload warnings for unsaved user input
Analytics need extra code for SPAs. Consider two particularly relevant to our site:
- A “simple diagram” of SPAs in Adobe’s tracker
- Dynatrace’s “Capturing > Async web requests and SPAs”

Buuuuuut I don’t have concrete numbers to back these up — I abandoned the SPA approach before grappling with them.

Why?

It’s not always about the performance

I didn’t want to demo a toy site that was fast only because it ignored the responsibilities of the real site. To me, those responsibilities (of grocery ecommerce) are…

🛡 Security even over accessibility: Downgrading HTTPS ciphers for old browsers isn’t worth letting credit cards be stolen.; You must protect data customers trust you with before you can use it.
♿ Accessibility even over speed: A fast site for only the able creates inequality, but a slower site for everyone creates equality.; Note that speed doubles as accessibility.
🏎️ Speed even over slickness: Delight requires showing up on time.; Users think fast sites are more easy-to-use, well-designed, trustworthy, and pleasant.

Accordingly, I refused to compromise on security or accessibility. A speedup was worthless to me if it conflicted with those two.

Security

MPAs and SPAs share most security concerns; they both care about XSS/CSRF/other alphabet soups, and ultimately some code performs the defenses. The interesting differences are where that code lives and what that means for ongoing maintenance.

(Unless the stateless ideal of SPA endpoints leads to something like JWT, in which case now you have worse problems.)

Where security code lives

Take CSRF protection: in MPAs, it manifests in-browser as <input type=hidden> in <form>s and/or samesite=strict cookies; a small overhead added to the normal HTTP lifecycle of a website.

SPAs have that same overhead¹, and also…

JS to get and refresh anti-CSRF tokens
JS to check which requests need those tokens, then attach them
JS to handle problems in protected responses; to repair or surface them to the user somehow

Repeat for authentication, escaping, session revocation, and all the other titchy bits of a robust, secure app.

Additionally, the deeper and more useful your security, the more the SPA approach penalizes all users. That rare-but-crucial warning to immediately contact support? It (or the code to dynamically load it) can either live in everyone’s SPA bundle, or only burden an MPA’s HTML when that stress-case happens.

What that means for security maintenance

With multiple exposed APIs, you must pentest/fuzz/monitor/etc. each of them. In theory that’s no different than the same for each POSTable URL in an MPA, but…

Sure, 8 out of 9 teams jumped on updating that vulnerable input-parsing library. Unfortunately, Team 9’s senior dev was out this week and the juniors struggled with a dependency conflict and now an Icelandic teenage hacker ring threatens to release the records of anyone who bought laxatives and cake mix together.²

This problem is usually tackled with a unified gateway, which can inflict SPAs with request chains and more script kB to contact it. But for MPAs, they already are that unified gateway.

Accessibility

Unlike security, SPAs have accessibility problems exclusive to them. (Ditto any client-side routing, like Hotwire’s Turbo Drive.)

I’d need code to restore standard page navigation accessibility:

Remember and restore scroll positions across navigations.
Focus last-used element on back navigations (accounting for autofocus, tabindex, JS-driven .focus(), other complications…)
Focus a page-representative element on forward navigation, even if it’s not normally focusable. Which is filled with gotchas.

And do all that while correctly handling the other hard parts of client-side routing:

Back/forward buttons
Timeouts, retries, and error handling
User cancellations and double-clicks
History API footguns — see its proposed replacement’s reasoning
Only use SPA navigation if a link is same-origin, not an in-page #fragment, the same target, needs authentication…
Check for Ctrl/⌘/Alt/Shift/right/middle-click, keyboard shortcuts to open in new tabs/windows, or non-standard shortcuts configured by assistive tech (good luck with that last one)
Reimplement browsers’ load/error UIs, and yours can’t be as good: they can report proxy misconfiguration, DNS failure, what part of the network stack they’re waiting on, etc.

In theory, community libraries should help avoid these problems…

The majority of routers for React, and other SPA frameworks, do this out of the box. This has been a solved problem for half a decade at least. A website has to go out of its way to mess this up.

— warning: HackerNews

We use those libraries at work, and let me tell you: we still accidentally mess it up all the time. I asked a maintainer of a popular React router for his take:

We can tell you when and where in the UI you should focus something, but we won’t be focusing anything for you. You also have to consider scroll positions not getting messed up, which is very app-specific and depends on the screen size, UI, padding around the header, etc. It’s incredibly difficult to abstract and generalize.

Even worse, some SPA accessibility problems are currently impossible to fix:

For example, screen readers can produce a summary of a new page when it’s loaded, however it’s not possible to trigger that with JavaScript.

— Why Gatsby is better with JavaScript § Accessibility

Also, remember how speed doubles as accessibility?

For accessibility as well as performance, you should limit costly lookups and operations all the time, but especially when a page is loading.

— Accessibility and Performance · Marcy Sutton

Emphasis mine — if you should avoid heavy processing during page load, then SPAs have an obvious disadvantage.

I needed something to break up the text.

Let’s say I do all that, though. Sure, it sounds difficult and error-prone, but theoretically it can be done… by adding client-side JS. And thus we’re back to my original problem.

Sometimes it is about the performance

You probably don’t have my 20kB budget, but 30–50kB budgets are a thing I didn’t invent. And remember: anything added to a page only makes it slower.

Beyond budget constraints, seemingly-small JS downloads have real, measurable costs on cheap devices:

Code	Startup delay
React	~163ms
Preact	~43ms
Bare event listeners	~7ms

Details in Jeremy’s follow-up post. Note these figures are from a Nokia 2, which is more powerful than my target device.

I see you with that “premature optimization” comment

The usual advice for not worrying about front-end frameworks goes like this:

Popular frameworks power some sites that are fast, so which one doesn’t matter — they all can be fast.

Once you have a performance problem, your framework provides ways to optimize it.

Don’t avoid libraries, patterns, or APIs until they cause problems — or that’s how you get premature optimization.

The idea of “premature optimization” has always been more nuanced than that, but this logic seems sound.

However… if you add a library to make future updates faster at the expense of a slower first load… isn’t that already a choice of what to optimize for? By that logic, you should only opt for a SPA once you’ve proven the MPA approach is too slow for your use.

Even 10ms of high memory spikes can cause ZRAM kicking in (suuuuper slow) or even app kills. The amount of JS sent to P99 sites is bad news

ZRAM impact is system wide. Keyboard may not show up quickly because the page used too much.

Having less code can make everything faster.

— Alex Russell

I had performance devtools open and dogfooded my own code as I made my demo. Each time I tested a heavier JS approach, I had tangible evidence that avoiding it was not prematurely optimizing.

It’s not just bundle size

Beyond their inexorable gravity of client-side JavaScript, SPAs have other non-obvious performance downsides.

In-page updates buffer the Web’s streaming, resulting in JSON that renders slower than HTML for lack of incremental rendering. Even if you don’t intentionally stream, browsers incrementally render bytes streaming in from the network.
Memory leaks are inevitable, but they rarely matter in MPAs. In SPAs, one team’s leak ruins the rest of the session.
JS and fetch() have lower network priority than “main resources” (<a> and <form>). This even affects how the OS prioritizes your app over other programs.
Lastly, and most importantly: server code can be measured, scaled, and optimized until you know you can stop worrying about performance. But clients are unboundedly bad, with decade-old chips and miserly RAM in new phones. The Web’s size and diversity makes client-side “fast enough” impossible to judge. And if your usage statistics come from JS-driven analytics that must download, parse, and upload to record a user… can you be certain of low-end usage?

Fresh loads happen more than you think

The core SPA tradeoff: the first load is slower, but it sets up extra code to make future interactions snappier.

But there are situations where we can’t control when fresh loads happen, making that one-time payment more like compounding debt:

Page freezing/eviction: Mobile browsers aggressively background, freeze, and discard pages.; Switching apps/tabs unloads the first annoyingly often — ask any iOS user.
Browser/OS updates and crashes: Many devices auto-update while charging.; I’m sure you can guess whether SPAs or MPAs crash more often.
Deeplinks and new tabs: Users open things in new tabs whether we like it or not.; Outside links must do a fresh boot, weakening email/ad campaigns, search engine visits, and shared links.; Multi-device usage really doesn’t help.; In-app browsers share almost nothing with the default browser cache, which turns what users think are return visits into fresh load→parse→execute.
Intentional page refreshes: Users frequently refresh upon real/perceived issues, especially during support. The world considers Refresh ↻ the fixit button, and they’re not wrong.; SPAs often refresh themselves for logins, error-handling, etc.; A related problem; you know those “This site has updated. Please refresh” messages? They bother the user, invoke a refresh, and replicate a part of native apps nobody likes.

But when fresh pageloads are fast, you can cheat: who cares about reloading when it’s near-instant?

SPAs are more fragile

While “rebooting” on every navigation can seem wasteful, it might be the best survival mechanism we have for the Web:

These errors come, in large part, from users running odd niche or out-of-date browsers with broken Javascript or DOM implementations, users with buggy browser extensions injecting themselves into your scope, adblockers blocking one of your <script> tags, broken browser caches or middleboxes, and other weirder and more exotic failure modes.

— Systems that defy detailed understanding § Client-side JavaScript

A typical Datadog error summary.

Given that most bugs are transient³, simply restarting processes back to a state known to be stable when encountering an error can be a surprisingly good strategy.

³ 131 out of 132 bugs are transient bugs (they’re non-deterministic and go away when you look at them, and trying again may solve the problem entirely), according to Jim Gray in Why Do Computers Stop and What Can Be Done About It?

— Erlang in Anger § On Running Software

We control our servers’ features and known bugs, and can monitor them more thoroughly than browsers.
Client error monitoring must download, run, and upload to be recorded, which is much flakier and adds its own fun drawbacks.
Relying on client JS is a hard known-unknown:
- JavaScript isn’t always available and it’s not the user’s fault.
- Why availability matters
- Dan Abramov’s warning against React roots on <body>.
- User-Agent Interventions are when browsers intentionally mess with your JS.

Overall, SPAs’ reliance on client JS makes them fail unpredictably at the seams: the places we don’t control, the contexts we didn’t plan for. Enough edge-cases added up are the sum total of humanity.

When a SPA is a good choice

Remember PROXX from earlier? It did fit in 20kB, but it also doesn’t worry about a lot of things:

Its content is procedurally generated, with only a few simple interactions.
It has few views, a single URL, and doesn’t load further data from a server.
It doesn’t care about security: it’s a game without logins or multiplayer.
If it weren’t accessible³ or broke from client-side fragility… so what? It’s a game. Nobody’s missing out on useful information or services.

PROXX is perfect as a SPA. You could make a Minesweeper clone with <form> and a server, but it would probably not feel as fun. Games often should maximize fun at the expense of other qualities.

Similarly, the Squoosh SPA makes sense: the overhead of uploading unoptimized images probably outweighs the overhead of expensive client-side processing, plus offline and privacy benefits. But even then, there are many server-side image processors, like ezgif or ImageOptim online, so clearly there’s nuance.

You don’t have to choose extremes! You can quarantine JS-heavy interactivity to individual pages when it makes sense: SPAs can easily embed in an MPA. (The reverse, though… if it’s even possible, it sounds like it’d inherit the weaknesses of both without any of their strengths.)

But if SPAs only bring ☹️, why would they exist?

We’re seeing the pendulum finally swing away from SPAs for everything, and maybe you’ll be in a position someday where you can choose. On the one hand, I’d be delighted to hand you more literature:

On the other hand…

Please beat offline-first ServiceWorker-cached application shells or even static HTML+JS on a local CDN with a cgi page halfway across the globe.

— Mihail Malo

This is true. It’s not enough for me to say “don’t use client-side navigation” — those things are important for any site, whether MPA or SPA:

Offline-first reliability and speed
Serving as near end-users as possible
Not using CGI (it’s 2022! at least use FastCGI)

So, next time: can we get the benefits that SPAs enjoy, without suffering the consequences they extremely don’t enjoy?

Some say that instead of CSRF tokens, SPAs may only need to fetch data from subdomains to guarantee an origin header. Maybe, but the added DNS lookup has its own performance tax, and more often than you’d think. ↩
No, this was not an incident we had. For starters, the teenagers were Luxembourgian. ↩
PROXX actually did put a lot of effort into accessibility, and that’s cool. ↩

Speed Needs Design, or: You can’t delight users you’ve annoyed

Taylor Hunt — Thu, 24 Mar 2022 12:31:17 +0000

To really sell streamed HTML’s impact, I should have shown the existing site’s design, but with streaming’s speed.

The demo’s design deviations

Unfortunately, it was impossible to have the existing design and the speed I needed. This post is about some of the differences.

If I were a good scientist, I’d have before/after traces for each deviation. Unfortunately, I do not — I was hastily testing and retesting on real hardware and a packet-throttled connection. If something felt slower, I tossed it.

If I’m wrong about something, I’ll happily accept corrections with a good source.

Design goals

Look, I’m jealous of native devs too. They get 60–120fps fullscreen animations with builtin platform support and minimum overhead.

But this is a website that sells food: I will relentlessly sacrifice delight for easier access. I can never truly catch up to native apps’ interaction richness, platform fidelity, and SFX flaunting. But I can beat native apps at the Web’s strength of getting things done, easily, with little fuss. I wasn’t just trying to outrace our existing site — I aimed at our native app too.¹

I figured I could add flourishes and rise to meet interesting challenges after finishing the usable, accessible bones.

My amateur login page	The professional login page

Which design looks better, 10 seconds in?

That said, I’m no designer. A real designer could probably make these tradeoffs with better results.

Fonts

Kroger.com’s Nunito .woff2 files are ≈14kB each, totaling 55.3kB.

If I found a smaller lookalike font, subset aggressively, and applied more arcane font optimizations, that could probably shrink to ~12kB total.² But remember the 20kB budget? 60% of that for a decorative font is hard to justify.

System fonts also spend less time on the main thread: each webfont src causes a reflow (they can batch together, but don’t count on it). Usually the reflow isn’t awful, but you know who’s not too good for free performance? 👉 This dork! 👈

So, no webfonts.

But that was an easy decision: avoiding custom fonts is negative work. How about something harder?

Product carousels

Displaying products is ecommerce’s most important job. Which is why it was a problem that our scrolling product lists didn’t fit on the phone we sell:

I know whitespace is an important part of design, but this is probably not what they meant.

That was the obvious reason to change, but there’s also subtler drawbacks:

Memory pressure and increased layout cost

Scroll panes use RAM and VRAM for hardware-accelerated scrolling — but we need those for fast <body> scrolling, too!

Current homepage in Chrome DevTools’ Layers view. It only rasterizes the non-blank parts, but still calculates layout for all areas.

Remember how iOS Safari needed opting-in for accelerated scrolling with -webkit-overflow-scrolling: touch? Now you know why.

Scroll trap on touchscreens

The lists take up so much vertical space that they become infuriating scroll traps on the demo phones, like mobile map embeds. (It doesn’t help that cheap touchscreens often get swipe direction confused at the beginning of a gesture.)

Reflow and pop-in

As new cards load on scroll, they all resize their height to match the tallest. Even when the shift is minimal, the necessary layout calculations still hiccuped on the demo phones.

Poor use of small viewport

The Poblano wasn’t the smallest screen I targeted. I wanted to preserve legibility down to the Apple Watch.

Instead, I displayed products like this:

No, it’s not very attractive. But it works a hell of a lot better.

You can probably spot several tricks to save space in the above screenshot: product sizes inline with the names, relying on text’s horizontal nature for more wrapping compactness, etc.

⌛ Other things I wanted to do, but ran out of time

I wanted to use shape-outside to flow text into the empty spaces of non-rectangular products, so I could make the image larger. (I had a burning desire to maximize how many onscreen pixels could be image pixels without sacrificing too much information density.) I might post how to do this, someday.

Later, the “stickiness” of scrolling lists was cited to me as an important quality. I wanted to recoup some of that by decorating the “See more” links at the end of each product list with thumbnails of what more was on that list, but ran out of time before the demo. C’est la vie.

`box-shadow` more like `bourgeois-shadow`

I know, I know. Shadows are fashionable. If used correctly they make interfaces more understandable. The interplay of light and shadow is the sum total of visual art itself.

But even from a strict design perspective, shadows aren’t all-upside:

The area needed to spread/blur shadows requires space around elements, which comes at a premium on the small screens I targeted.
Current popular use is subtle, which means they can never be the workhorse of a design. (Unless you make shadows the only design element, and that’s terrible.)
An affordance that doesn’t meet contrast requirements is questionably useful for the people who need it most. Or even most people: glaring sunlight, tired eyes, distracted attention, etc. need strong affordances, not minimal ones. (I’m not even sure how many people can notice trendy shadows, from a visual accessibility perspective.)

And from not a strict design perspective…

Historically, box-shadow is a career performance criminal. Probably not as much nowadays, unless some combination of inset, blur radius, border-radius, transparency, shadowed element size, screen resolution, browser, OS, or hardware falls off browsers’ fast paths.

Modern advice mostly warns about transitioning or animating around shadows — especially since scrolling under them also counts, as Facebook learned.

(Yes, Google’s Material Design went all-in on blurring and animating lots of shadows. Have you seen how much effort they spend because of that?)

There are ways to work around shadows’ performance risks, which might even be worth the effort.

But… man, these box-shadows just don’t seem that worth it. They’re subtle! Intentionally! If I have to plan how to protect users from them, there needs to be way more of a payoff. At least skeuomorphism was in-your-face.

If a design effect is only noticeable to young people with good vision, and it can unpredictably penalize people with cheap or overworked devices… then I don’t care how delightful it is. The risks conflicted with my goals and this was my stupid passion project, dammit. I didn’t trust them and I didn’t need them.

So, I dropped the shadows. …but not like that.

Homepage promotions

Carousel	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…)

But the demo didn’t use tiles either

Encoding each promotion as one big image has problems:

Scaled-down text becomes unreadable small viewports
Doesn’t work with High-Contrast Mode or other forced-colors
Takes too long to display anything on the target connection, which meant it was as good as not having it
Costs users more than I was comfortable with. Especially since I couldn’t aggressively compress the images without making their text look crusty.

So the demo went even further beyond, with an approach I’m calling “ribbons” just now. Here’s how those load over the target connection:

The text and colored backgrounds are visible instantly, even though the images take a few seconds. (A media query rejiggers them into tiles on larger viewports.)

No modals, tooltips, toasts, etc.

Unlike the parts of this post where it felt like I was compromising, this was a user experience improvement. Do you like dealing with modals and pop-up banners and all their annoying friends? Me neither.

That’s an opinion, though. Some more objective reasons I eschewed widgets for boring alternatives:

Their JavaScript and CSS eat away at the performance budget
They make less sense on small/touch screens — in particular, modals take up nearly the entire page anyway
They’re hard to make accessible (modals in particular have been called “the final boss of web accessibility”)

More on that last one… Even if I did succeed in making widgets accessible, the JavaScript required to do so really adds up. Check out the sizes of some popular modules, each a reasonable choice for tooltips, modals, and toasts respectively:

JS cost according to Bundlephobia

Module	Minified	.min.gz	Slow 3G download
`@popperjs/core` 2.11.4	20.5 kB	7.2 kB	144 ms
`@reach/dialog` 0.16.2	27.3 kB	9.4 kB	188 ms
`notistack` 2.0.3	18.8 kB	6.4 kB	128 ms
Total	66.7 kB	23 kB	~½ second!

✏️ Note: this table doesn’t include parse/execute time, which scales with minified kB.

(Yes, there are more efficient ways to script these widgets. I just grabbed whatever looked well-maintained and popular, like the vast majority of devs.)

Finally, implementing complex interactivity would have taken a lot out of me. Check out what it took for Pedro Duarte to make an accessible dropdown:

Source: Headless components in React and why I stopped using a UI library for our design system

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.

More on alternatives to these known user-aggravators:

Better design via speed

Unlike the other sections where design was in service to speed, this section is about how fast page loads can enable better design!

Our existing checkout flow had expanding/contracting accordions, intertwingled error constraints, and tricky .focus() management because of the first two. I wanted to avoid all that, so I broke up checkout into a series of small, quick pages:

If you’ve heard of One Thing Per Page, that’s what I did. It didn’t take long to code, and was surprisingly easy.

But wait! There’s more!

low-confidence users find them easier to use

they work well on mobile devices

they’re better at handling things like errors, branches, loops and saving progress

— One thing per page · Design in government

I didn’t implement them for the demo, but functionality like user’s Account info and settings would also be well-served by this pattern.

[W]hen we started user research with the general public, we saw a very positive response to the simple step by step approach, even on large screens. Though it added more clicks, people said it made the process feel simple and easy - there wasn’t too much to take in and process at any one time. So we stuck with the simpler screens for everyone.

— GOV.UK: Things we learnt designing ‘Register to vote’

And thanks to Paint Holding these page sequences looked and felt as seamless as SPA navigation. (Lots more on that in the next post.)

So what?

Like how woodworking involves sculpting along the grain, web design needs an understanding of what’s easy and natural, to save effort for things that really need it.

Our current practices of pushing designers away from HTML & CSS thwarts an intuitive understanding of what’s easy vs. what’s hard on the Web. More cooperation and faster feedback loops could help — because I was designing and developing myself, the loop was as tight as possible as I switched hats on the fly.

But, uh, it’s also true my designs won’t win any beauty contests. So don’t trust me, listen to some actual designers:

In the next post, I reveal that while I may be a twentysomething paid to work in React, I’m secretly a filthy progressive enhancement liker.

Native has much improved since Gruber wrote that post. It’s time web devs also stepped up our game, and not by playing catch-up: “What I missed when I dismissed them a decade ago is that web apps don’t need to beat desktop apps on the same terms.” ↩
Based on results with Poppins from an earlier design. ↩

The weirdly obscure art of Streamed HTML

Taylor Hunt — Tue, 15 Mar 2022 15:30:58 +0000

My goal from last time: reuse our existing APIs in a demo of the fastest possible version of our ecommerce website… and keep it under 20 kilobytes.

I decided this called for an MPA. (aka a traditional web app. Site. Thang. Not-SPA. Whatever.)

And with that decision, I doomed the site to feel slow and clunky

In theory, there’s no reason MPA interactions need be as slow as commonly encountered. But in practice, there are many reasons.

Here’s an example. At Kroger, product searches take two steps:

Send user’s query to an API to get matching product codes
Send those product codes to an API to get product names, prices, etc.

Using those APIs to generate a search results page would look something like this:

const resultsData = fetch(`/api/search?${new URLSearchParams({
    query: usersSearchString
  })}`)
  .then(r => r.json())
  .then(({ upcs }) =>
    fetch(`/api/products/details?${new URLSearchParams({ upcs })}`
  )
  .then(r => r.json())

res.writeHead(resultsData.success ? 200 : 500, {
  'content-type': 'text/html;charset=utf-8'
})

const htmlResponse = searchPageTemplate.render({
    searchedQuery: usersSearchString,
    results: resultsData
  })

res.write(htmlResponse)
res.end()

Each fetch takes time, and /api/products/details only happens after /api/search finishes. Plus, those requests traveled from my computer to the datacenter and back. A real server making those calls would sit next to the others for very fast requests.

But on my demo machine, the calls usually took ~200 milliseconds, sometimes spiking as high as 800ms. Combined with the target 3G network, server processing time, and other inconvenient realities, I was frequently flouting the 100–1000ms limit for “natural and continuous progression of tasks”.

So the problem is high Time to First Byte, huh?

No worries! High Time to First Byte (TTFB) is a known performance culprit. Browser devtools, Lighthouse, and other speed utensils all warn about it, so there’s lots of advice for fixing it!

Except, none of the easily-found advice for improving TTFB helps:

Optimize the server application to prepare pages faster: Node.js spent 30ms or less handling the request and sending HTML. Very little to be gained there.
Optimize database queries or migrate to faster database systems: I was not allowed to touch our databases or API servers.
Upgrade server hardware to have more memory or CPU: This ran on a MacBook Pro with plenty of unused RAM and CPU.
Cache the expensive lookups: Caching can’t help the first requests, unless I precache all known endpoints or something. Even then, that wouldn’t work for search: users can and will search for strings never seen before.

The problem: web performance is other people

If only two API calls were a struggle, I was in for ruination. Here are some data sources our homepage uses:

Authentication and user info
Items in shopping cart
Selected store, pickup vs. delivery, etc.
Recommended products
Products on sale
Previous purchases
Sponsored products
Location-specific promotions
Recommended coupons
A/B tests
Subscription to Kroger Boost
…and so on. You get it, there’s a lot — and that’s only the stuff you can see.

Like many large companies, each data source may be owned by different teams. With their own schedules, SLAs, and bugs.

After you see real API charts, Krazam’s satirical microservices diagram gets either more or less funny. Still figuring out which.

Let’s say the 10 data sources I listed are each one API call. What are the odds my server can respond quickly enough?

Let’s say 1 client request creates 10 downstream requests to a longtail-latency affected subsystem. And assume it has a 1% probability of responding slowly to a single request. Then the probability that at least 1 of the 10 downstream requests are affected by the longtail latencies is equivalent to the complement of all downstream requests responding fast (99% probability of responding fast to any single request) which is:

$1 - (0.99)^{10} = 0.095$
That’s 9.5 percent! This means that the 1 client request has an almost 10 percent chance of being affected by a slow response. That is equivalent to expecting 100,000 client requests being affected out of 1 million client requests. That’s a lot of members!

—Who moved my 99th percentile latency?

And since users visit multiple pages in MPAs, the chances of suffering a high TTFB approaches “guaranteed”:

Gil walks through a simple, hypothetical example: a typical user session involves five page loads, averaging 40 resources per page. How many users will not experience something worse than the 95th percentile? 0.003%.

—Everything You Know About Latency Is Wrong

I believe this is why Kroger.com used a SPA in the first place — if disparate teams’ APIs can’t be trusted, at least they won’t affect other teams’ code. (Similar insulation from other teams’ components is probably one reason for React’s industry adoption.)

The solution: streamed HTML

It’s easier to show than to explain:

Download video: HTML Streaming vs. Non-streaming

Both pages show search results in 2.5 seconds. But they sure don’t feel the same.

Not all sites have my API bottlenecking issue, but many have its cousins: database queries and reading files. Showing pieces of a page as data sources finish is useful for almost any dynamic site. For example…

Showing the header before potentially-slow main content
Showing main content before sidebars, related posts, comments, and other non-critical information
Streaming paginated or batched queries as they progress instead of big expensive database queries

Beyond the obvious visual speedup, streamed HTML has other benefits:

Interactive ASAP: If a user visits the homepage and immediately tries searching, they don’t have to wait for anything but the header to submit their query.
Optimized asset delivery: Even with no <body> to show, you can stream the <head>. That lets browsers download and parse styles, scripts, and other assets while waiting for the rest of the HTML.
Less server effort: Streamed HTML uses less memory. Instead of building the full response in RAM, it sends generated bytes immediately.
More robust and faster than incremental updates via JavaScript: Fewer roundtrips, happens before/while JS boots, immune to JS errors and the other reasons 1% of visits have broken JavaScript…; And because it’s more efficient, that leaves more CPU and RAM for the JavaScript we do run, not to mention painting, layout, and user interactions.

But don’t take my word for it:

Hopefully, you see why I considered HTML streaming a must.

And that’s why not Svelte

Previously…

Maybe if I sprinkled the HTML with just enough CSS to look good… and if I had any room left, some laser-focused JavaScript for the pieces that benefit most from complex interactivity.

That’s exactly what Svelte excels at. So why didn’t I use it?

Because Svelte does not stream HTML. (I hope it does someday.)

If not Svelte, then what?

I found only 2 things on NPM that could stream HTML:

Dust, a template language that seems to have died twice.
Marko, some library with an ungoogleable name and a rainbow logo… oh, and JSX-like syntax? And a client-side virtual DOM that fit in my budget? And eBay has battle-tested it for its ecommerce websites? And it only uses client-side JS for stateful components? You don’t say.

It’s nice when a decision makes itself.

Marko’s `<await>` made streaming easy

Marko streams HTML with its <await> tag. I was pleasantly surprised at how easily it could optimize browser rendering, with all the control I wanted over HTTP, HTML, and JavaScript.

Disclaimer
I now work for eBay, but I didn’t yet when I wrote this post.

Source: markojs.com/#streaming

As seen in Skeleton screens, but fast:

<SiteHead />

<h1>Search for “${searchQuery}”</h1>

<div.SearchSkeletons>
  <await(searchResultsFetch)> <!-- stalls the HTML stream until the API returns search results -->
    <@then|result|>
      <for|product| of=result.products>
        <ProductCard product=product />
      </for>
    </@then>
  </await>
</div>

`<await>` for nice-to-haves

Imagine a component that displays recommended products. Fetching the recommendations is usually fast, but every once in a while, the API hiccups. <await>’s got your back:

<await(productRecommendations)
    timeout=50> <!-- wait up to 50ms -->
  <@then|recs|>
    <RecommendedProductList of=recs />
  </@then>

  <@catch>
    <!-- don’t render anything; no big deal if this fails -->
  </@catch>
</await>

If you know how much money product recommendations make, you can fine-tune the timeout so the cost of the performance hit never exceeds that revenue.

And that’s not all!

<await(productRecommendations) client-reorder>
  <@placeholder>
    <!-- immediately render placeholder to prevent content jumping around -->
    <RecommendedProductsPlaceholder /> 
  </@placeholder>

  <@then|recs|>
    <RecommendedProductList of=recs />
  </@then>
</await>

The client-reorder attribute turns the <await> into an HTML fragment that doesn’t delay the rest of the page behind it, but asynchronously renders when ready. client-reorder requires JavaScript, so you can weigh the tradeoffs of using it vs. a timeout with no fallback. (I think you can even combine them.)

That’s how Facebook’s BigPipe renderer worked, which once lived on the same page as React. Wouldn’t it be nice to have the best of both?

Let me tell you: it is nice.

Marko’s `<await>` is awesome

Best of all, these <await> techniques are Marko’s golden path — heck, its very reason for being. Marko has stream control no other renderer makes easy, a way to automatically upgrade streamed HTML with JavaScript, and 8+ years of experience with the inevitable bugs and edge cases.

(Yes, I was quite taken with Marko. Let me have my fun.)

However, the fact that Marko was apparently my one option does raise a certain question…

Why is HTML streaming not common?

Or in the words of another developer after my demo: “if Chunked Transfer-Encoding is so useful, how come I’ve never heard of it?”

That is a very fair question. It’s not because it’s poorly-supported — HTML rendered progressively in Netscape 1.0. Beta Netscape 1.0. And it’s not because the technique is barely-used — Google search results stream after the top navbar, for instance.

I think one reason is the inconsistent name

Steve Souders called it “early flushing”, which is not… the best name.
“Chunked transfer-encoding” is the most unique, but it’s only in HTTP/1.1. HTTP/2, HTTP/3, and even HTTP/0.9 stream differently.
It was known as “HTTP streaming” before HLS, DASH, and other forms of video-over-HTTP took up that mindspace.
The catch-all term is “progressive rendering”, but that applies to many other things: interlaced images, visualizing large datsets, video game engine optimizations, etc.

Many languages/frameworks don’t care for streaming

Older languages/frameworks have long been able to stream HTML, but were never really good at it. Some examples:

PHP 🐘

Requires calling inscrutable output-buffering functions in a finicky order.

Ruby on Rails 🛤

ActionController::Streaming has a lot of caveats. In particular:

This approach was introduced in Rails 3.1 and is still improving. Several Rack middlewares may not work and you need to be careful when streaming. Those points are going to be addressed soon.

Rails hit 3.1 in 2011. There was clearly not much demand to address those points.

(Rails’ modern way is Turbo Streams, but those need JS to render, so not the same thing.)

Django 🐍

Django really doesn’t like streaming at all:

StreamingHttpResponse should only be used in situations where it is absolutely required that the whole content isn’t iterated before transferring the data to the client.

Perl 🐪

Perl’s autostream behavior is controlled by a $| variable (yes, that’s a pipe), but that sort of nonsense is normal for it. God I love Perl.

Because streaming was never their default happy path, languages/frameworks considered it a last resort where you gained performance at the expense of the “real” render features. Here’s a telling quote:

You can still write ASP.NET pages that properly stream data to the browser using Response.Write and Response.Flush. But you can’t do it within the normal ASP.NET page lifecycle. Maybe this is a natural consequence of the ASP.NET abstraction layer.

Regardless, it still sucks for users.

—The Lost Art of Progressive HTML Rendering

Node.js is a happy exception. As proudly described on Node’s About page:

HTTP is a first-class citizen in Node.js, designed with streaming and low latency in mind.

Despite that, the “new” hot JavaScript frameworks have been struggling to stream for a while:

React’s had renderToNodeStream since 2016, but using it was tricky. Ergonomic streaming is the focus of a lot of upcoming React SSR work.
Ember’s Glimmer can stream HTML, but it’s been “experimental” since 2016, too.
Vue can stream, but with caveats and incompatibilities since it’s not the default.

These frameworks have the staff, funding, and incentives to make streaming work, so the holdup must be something else. Maybe it’s hard to retrofit streaming onto their abstractions, especially without ruining established third-party integrations.

Streaming rarely mentioned as a TTFB fix

As mentioned near the beginning, when high TTFB is detected, streaming is almost never suggested as a fix.

I think that’s the biggest problem. A Web API with a bad name can become popular if it’s mentioned enough.

Personally, I’ve only seen streaming HTML recommended for TTFB once, and it’s in chapter 10 of High-Performance Browser Networking. In an aside. At the bottom.

(Inside a <details> labeled “Beware of The Leopard”.)

So that’s one silver bullet down

I had streaming HTML, but that was no substitute for the other 999 lead bullets to back it up. Now I had to… make the website.

You know, write the components, style the design, build the features. How hard could that be? (Hint: people are paid to do those things.)

Making the world’s fastest website, and other mistakes

Taylor Hunt — Tue, 15 Mar 2022 15:30:47 +0000

This is a story about a lot of things:

Fitting a Fortune 20 site in 20kB
Diving into site speed so deep we’ll see fangly fish
React thwarting my goal of serving users as they are
Burning out trying to do the right thing
And by the end, some code I dare you to try.

The situation: frustratingly typical

I work on Kroger’s ecommerce sites for their regional chains, most of which share a codebase. You’d probably guess the front-end stack: React, Redux, and their usual symptoms of too much JavaScript.

The facts:

React/Redux packages used totaled 44.7 kB before any feature code.
Our WebPageTest results spoke for themselves.
This was after investing in Server-Side Rendering (SSR), a performance team, and automated regression testing.

In particular, React SSR was one of those changes that looks faster, but looks can be deceiving. In retrospect, I’m amazed developers get away with considering SSR+rehydration an improvement at all.

Make your code faster… by running it twice!

—how React SSR works, apparently

The backstory: developer bitten by a radioactive WebPageTest

I used to ask other developers to stop writing slow code.¹ Such as…

“Please cut down on the <div>s, they make our DOM big and slow.”
“Please avoid CSS like .Component > * + *, it combines with our big DOM into noticeable lag.”
“Please don’t use React for everything, it caps how fast we can be.” (Especially if it renders big DOMs with complex styles…)

Nobody listened. But, honestly, why would they?

This carried on, and it was cool/cool/depressing/cool. But a new design system inflicted enough Tailwind to hurt desktop Time to First Paint by 0.5 seconds, and that was enough to negotiate for a dedicated Web Performance team.

Which went well, until it didn’t. Behold, the industry-standard life of a speed optimization team:

Success with uncontroversial changes like better build configuration, deduplicating libraries, and deleting dead code
Auditing other teams’ code and suggesting improvements
Doing the improvements ourselves after said suggestions never escaped backlogs
Trying to make the improvements stick with bundle size monitoring, Lighthouse checks in PRs, and other new layers of process
Hearing wailing and gnashing of teeth about having to obey said layers of process
Realizing we need to justify why we were annoying everyone else before we were considered a net negative to the bottom line

The thing was, WebPageTest frowning at our speed didn’t translate into bad mobile traffic — in fact, most users were on iPhone.² From a business perspective, when graphs go up and to the right, who cares if the site could be faster?

To prove we weren’t wasting everyone’s time, we used WPO Stats and internal data to calculate that each kB of client-side JavaScript cost us ≈$100,000 per year, and every millisecond until Time to Interactive at least $40,000.³

But proving speed = money only moved us from Anger to the Bargaining stage of performance grief: hoarding improvements to use later, empty promises to fix massive regressions after a deadline, and protesting numbers with appeals to “developer experience”.

The 5 Stages of Performance Grief

Denial	It’s fast enough. You’ve seen those M1 benchmarks, right?
Anger	You mean I have to care about this, too!? We just got done having to care about accessibility!
Bargaining	I promise we will eventually consolidate on just three tooltip libraries if you let us skip the bundle check
Sadness	I should have realized the dark path I was going down when I tried to see if `npm install *` worked.
Acceptance	I love my slow website.

Proving that speed mattered wasn’t enough: we also had to convince people emotionally. To show everyone, god dammit, how much better our site would be if it were fast.

So I decided to make a demo site that reused our APIs, but in a way that was as fast as possible.

Spoiler: surprising myself, I succeeded. And then things got weird. But before I can tell you that story, I have to tell you this story…

The goal: how fast is possible?

HTTP/1.1 204 No Content
Cache-Control: max-age=999999999,immutable

This is the fastest web page. You may not like it, but this is what peak performance looks like.

That may seem unhelpful — of course a useful page is slower than literally nothing! — but anything added to a frontend can only slow it down. The further something pushes you from the Web’s natural speed, the more work needed to claw it back.

That said, some leeway is required, or I’d waste time micro-optimizing every little facet. You do want to know when your content, design, or development choices start impacting your users. For everything added, you should balance its benefits with its costs. That’s why performance budgets exist.

But to figure out my budget, I first needed some sort of higher-level goal.

Some sort of higher-level goal

🎯 Be so fast it’s fun on the worst devices and networks our customers use.

Target device: bestselling phone at a local Kroger: Hot Pepper’s Poblano VLE5; $35 ($15 on sale); Specs: 1 GB RAM, 8 GB total disk storage, and a 1.1 GHz processor.
Target connection: “slow 3G”: 400kbps bandwidth; 400ms round-trip time latency; At the time, what Google urged to test on and what WebPageTest’s “easy” configuration & Lighthouse used

Unfortunately, connections get worse than the “slow 3G” preset, and one example is cellular data inside said Kroger. Big-box store architectures double as Faraday cages, losing enough packets to sap bandwidth and latency.

Ultimately, I went with “slow 3G” because it balanced the USA’s mostly-faster speeds with the signal interference inside stores. Alex Russell also mentioned “we still see latency like that in rural areas” when I had him fact-check this post.

(These device and connection targets are highly specific to this project: I walked inside stores with a network analyzer, asked the front desk which phone was the most popular, etc. I would not consider them a “normal” baseline.)

(Wait, don’t spotty connections mean you should reach for a Service Worker?)

Yes, when networks are so bad you must treat them as optional, that’s a job for Service Workers.

I will write about special SW sauce (teaser: offline streams, navigation preload cache digests, and the frontier of critical CSS), but even the best service worker is irrelevant for a site’s first load.

Although I knew what specs I was aiming for, I didn’t know what they meant for my budget. Luckily, someone else did.

Google’s suggestions to be fast on mobile

Google seems to know their way around web performance, but they never officially endorse a specific budget, since it can’t be one-size-fits-all.

But while Google is cagey about an specific budget, Alex Russell — their former chief performance mugwump — isn’t. He’s written vital information showing how much the Web needs to speed up to stay relevant, and this post was exactly what I needed:

Putting it all together, under ideal conditions, our rough budget for critical-path resources (CSS, JS, HTML, and data) at:

170KB for sites without much JS

130KB for sites built with JS frameworks

—Can You Afford It? Real-world Performance Budgets

(Alex has since updated these numbers, but they were the ones I used at the time. Please read both if you’re at all interested — Alex accounts for those worse-than-usual networks I mentioned, shows his work behind the numbers, and makes no bones about what exactly slows down web pages.)

Unfortunately, the hardware Alex cited clocks 2GHz to the Poblano’s 1.1GHz. That means the budget should lower to 100kB or so, but I couldn’t commit to that. Why?

Engineering around analytics

As usual, third-parties ruin everything. You can see the 2022 site’s cross-origin bytes situation, and it doesn’t include same-origin third-parties like Dynatrace.

from The Physics Of: Clown Cars · Car and Driver

I can’t publish exact figures, but at the time it was scarcely better. Barring discovery of the anti-kilobyte, I needed to figure out which third-parties had to go. Sure, most of them made $, but I was out to show that dropping them could make $$$.

After lots of rationalizing, I ended with ≈138kB of third-party JS I figured the business wouldn’t let me live without. Like the story of filling a jar with rocks, pebbles, and sand, I figured engineering around those boulders would be easier than starting with a “fast enough” site and having it ruined later.

Some desperate lazy-loading experiments later, I found my code couldn’t exceed 20kB (after compression) to heed Alex’s advice.

Okay, 20kB. Now what?

20 kilobytes ain’t much. react + react-dom are nearly twice that. An obvious alternative is the 4kB Preact, but that wouldn’t help the component code or the Redux disaster — and I still needed HTML and CSS! I had to look beyond the obvious choices.

What does a website truly need? If I answered that, I could omit everything else.

Well, what can’t a website omit, even if you tried?

You can make a real site with only HTML — people did it all the time, before CSS and JS existed.

Maybe if I sprinkled the HTML with just enough CSS to look good… and if I had any room left, some laser-focused JavaScript for the pieces that benefit most from complex interactivity.

(Yes, I see you with the Svelte.js shirt in the back. I talk about it in the next post.)

Amazon serves basically what I just described if you visit with a really bad User-Agent:

What Amazon shows for Opera/9.80 (J2ME/MIDP; Opera Mini/5.1.21214/28.2725; U; ru) Presto/2.8.119 Version/11.10.

And this is the lowest-fidelity version of Amazon, which appears with a skin=noskin cookie.

So my plan seemed possible, and apparently profitable enough that Amazon does it. Seemed good enough to try.

But everyone knows classic page navigation is slow!

Are you sure about that? The way I figured…

If you inline CSS and generate HTML efficiently, their overhead is negligible compared to the network round-trip.
A SPA still requests JSON data to render, yeah? Even if you inline that JSON into the initial response, JSON→JavaScript→HTML cannot possibly be faster than skipping straight to the HTML part.
Concatenating strings on a server should not be a huge bottleneck. And if it were, how does React SSR justify concatenating those strings twice into both HTML and hydration data?

But don’t take my word for it — we’ll find out how that stacks up next time. In particular, I first need to solve a problem: how do you send a page before all its slow data sources finish?

I still ask other developers to stop writing slow code, but I used to, too. ↩
That does not count as insider information. Any US website with a similar front-end payload will tell you the same. ↩
Those numbers were very loose, conservative estimates. They’re also no longer accurate — they’re much higher now — but they still work as a bare minimum. ↩

That Dang Material Design Spinner in One Element

Taylor Hunt — Sat, 12 Feb 2022 21:11:20 +0000

You know the one, looks like this:

material.io/components/progress-indicators#circular-progress-indicators

I was going to show it animated, but dev.to removes the controls attribute on <video> so you can’t pause it, and that’s terrible.

I want the markup to be as simple as:

<progress></progress>

…because that’s the right tool for the job, dangit. It’s easy, accessible, and semantic.

CSS is powerful enough to style <progress> into all sorts of fancy loading indicators, so it should also be able to animate Google’s funny looping circle.

Existing implementations

The first thing I did was look for code to steal. You know, like a developer does.

Material Design Lite

Surely Google has its own spinner for its sites, right? Who better to rip off than the inventor?

Material Design Lite’s Spinner component… was the worst. But, sadly, also the most official. I expected an abundance of <div>s because but not this many:

<div class="mdl-spinner mdl-spinner--single-color mdl-js-spinner is-active is-upgraded"
  data-upgraded=",MaterialSpinner">
  <div class="mdl-spinner__layer mdl-spinner__layer-1">
    <div class="mdl-spinner__circle-clipper mdl-spinner__left">
      <div class="mdl-spinner__circle"></div>
    </div>
    <div class="mdl-spinner__gap-patch">
      <div class="mdl-spinner__circle"></div>
    </div>
    <div class="mdl-spinner__circle-clipper mdl-spinner__right">
      <div class="mdl-spinner__circle"></div>
    </div>
  </div>
  <div class="mdl-spinner__layer mdl-spinner__layer-2">
    <div class="mdl-spinner__circle-clipper mdl-spinner__left">
      <div class="mdl-spinner__circle"></div>
    </div>
    <div class="mdl-spinner__gap-patch">
      <div class="mdl-spinner__circle"></div>
    </div>
    <div class="mdl-spinner__circle-clipper mdl-spinner__right">
      <div class="mdl-spinner__circle"></div>
    </div>
  </div>
  <div class="mdl-spinner__layer mdl-spinner__layer-3">
    <div class="mdl-spinner__circle-clipper mdl-spinner__left">
      <div class="mdl-spinner__circle"></div>
    </div>
    <div class="mdl-spinner__gap-patch">
      <div class="mdl-spinner__circle"></div>
    </div>
    <div class="mdl-spinner__circle-clipper mdl-spinner__right">
      <div class="mdl-spinner__circle"></div>
    </div>
  </div>
  <div class="mdl-spinner__layer mdl-spinner__layer-4">
    <div class="mdl-spinner__circle-clipper mdl-spinner__left">
      <div class="mdl-spinner__circle"></div>
    </div>
    <div class="mdl-spinner__gap-patch">
      <div class="mdl-spinner__circle"></div>
    </div>
    <div class="mdl-spinner__circle-clipper mdl-spinner__right">
      <div class="mdl-spinner__circle"></div>
    </div>
  </div>
</div>

That’s 29 — count ‘em, twenty-nine — <div>s.

I was able to steal some variables like animation timings from this implementation, but mostly it made me wonder how Google can bang the performance drum and also suggest we use code like this.

Polymer’s <paper-spinner-lite> gets it done with only 7 elements and allows customization, so I don’t think the inherent design is something inexpressible in CSS. Its <paper-spinner> is still 22 <div>s, though, and its only difference is it doesn’t cycle through colors:

The default spinner cycles between four layers of colors; by default they are blue, red, yellow and green. It can be customized to cycle between four different colors. Use <paper-spinner-lite> for single color spinners.

To be fair, MDL/Polymer’s spinners probably had some requirements I don’t:

They date from at least 2015, so the techniques I use may have had spottier browser support back then. (In particular, it looks like Safari did not animate ::after pseudo-elements inside shadow roots.)
Google probably had to match their official design specs perfectly — which I don’t much care to. As far as I’m concerned, if my users stare at a spinner long enough to notice animation inconsistency, the page has a bigger problem.
I think the reason the 4-color version has quadruple the <div>s is because they animate opacity for hardware-accelerated color changes, because changing colors on the Web triggers paint invalidation, which can hiccup animations.

SVG?

Okay, so the official implementations were out. The next best place to steal front-end code? CodePen.

And thanks to Fran Pérez's Material Design Spinner pen, I had a starting point that I forked and rewrote to fit my harebrained sensibilities. I then embedded the SVG as a data: URI, in order to style my lone <progress> element with it:

I almost went with this, but it had problems:

Annoying to update — tweaking the code involves decoding the URI, understanding the SVG, then re-encoding to a mini SVG data URI
Risks desyncs and sputtery animation in browsers that don’t hardware-accelerate SVG animations — which used to be everything but Firefox and IE, but thankfully I believe Chrome might have that fix in the works.
Nothing shows if High-Contrast Mode is on or images are turned off, because it’s a background-image.

The `clip-path` one I ultimately riffed on

I then found a spinner by Adam “acronamy” Crockett which used clip-path. It didn’t quite match the shape and timing needed, but it showed it could be done with only one element and a single @keyframes rule:

Final result

Features

Tweak the thickness by changing the border-width
Tweak the color with the color property. You can even animate color changes that way!
Tweak the size with the font-size property
Builtin accessible name/caption via <label>
Bonus: backdrop circle that matches the top one

But should you use it?

Not if what you’re loading behind the spinner runs on the main thread, like React or another JS-heavy thing. If it’s only a fetch that inserts some HTML, like Hotwire’s Turbo, then yeah, go ahead.

Since this was originally code I wrote for work almost three years ago, I thought I wouldn’t need this section anymore, because in the meantime Chrome shipped hardware acceleration for clip-path! 🎉

Unfortunately, the world isn’t just Chrome. If the animated clip-path (and color if you want the fancy color-shifting one too) run on the main thread, you can run into a heap of problems:

Any JS work/re-layouts/etc. can make the animation stutter and hitch.
If it can’t run on the accelerated compositor thread, it chews up more battery life.
Since spinners show while the main thread is busy with whatever you needed a loading animation for, a spinner running on the main thread delays whatever’s behind it!

So be careful, and make sure you’re being responsible to your users before reusing code from some dork’s blog post. You know what’s better than a spinner? Showing content faster.

(Was it irresponsible of me to publish this? Yes, probably.)

Failing to math for “fun” and “profit”

I may have gotten a 4 in AP Calculus, but I managed to forget all of it because I couldn’t even express a circular rotation animation the “right” way. Ultimately, I hacked it by dividing the element into quadrants, and sweeping a side of each polygon() as part of the animation.

That probably didn’t make any sense, did it? Here’s the code:

// (x,y) points expressed in %, for use in CSS’s `clip-path`
const center = ['50%', '50%']
var top = ['50%', '-50%']
var right = ['150%', '50%']
var bottom = ['50%', '150%']
var left = ['-50%', '50%']

// These four are used once each for the final “sliver” in the 4 different orientations
const topLeft = ['0%', '-50%']
const bottomLeft = ['-50%', '100%']
const bottomRight = ['100%', '150%']
const topRight = ['150%', '0%']

// Edit these if you want to change the animation.
// It’s a list of `clip-path` coordinates that the animation uses as keyframes.
const keyFrames = [
  [bottom, left, left, top],
  [left, left, left, top],
  [topLeft, topLeft, topLeft, top],

  [top, top, top, right],
  [top, top, right, bottom],
  [top, right, bottom, left],

  [right, right, bottom, left],
  [bottom, bottom, bottom, left],
  [bottomLeft, bottomLeft, bottomLeft, left],

  [left, left, left, top],
  [left, left, top, right],
  [left, top, right, bottom],

  [top, right, right, bottom],
  [right, right, right, bottom],
  [bottomRight, bottomRight, bottomRight, bottom],

  [bottom, bottom, bottom, left],
  [bottom, bottom, left, top],
  [bottom, left, top, right],

  [left, left, top, right],
  [top, top, top, right],
  [topRight, topRight, topRight, right],

  [right, right, right, bottom],
  [right, right, bottom, left],
  [right, bottom, left, top]
]

var cssText = `/* <generated-keyframes> */
@keyframes inchworm {
${keyFrames
    .map((f, i) => {
      const isLastFrame = i === keyFrames.length - 1
      const interval = 1 / keyFrames.length
      const percent = toPercent((i + 1) * interval)
      return `  ${isLastFrame ? '0%,' : ''}${percent} { clip-path: ${polygon(f)} }`
    })
    .join('\n')}
}
/* </generated-keyframes> */`

function polygon (points) {
  const cssPoints = points.map(point => point.join(' ')).join(', ')
  return `polygon(${cssPoints}, ${center.join(' ')});` // final point is always the center
}

function toPercent (num) {
  const percent = num * 100
  const decimalPlaces = Number.isInteger(percent) ? 0 : 3
  return parseFloat(percent.toFixed(decimalPlaces)) + '%'
}

If that didn’t make sense to you either, well… yeah, me too. It’s been a while since I wrote it.

(I tried writing that in Sass, but couldn’t manage it.)

Skeleton screens, but fast

Taylor Hunt — Wed, 28 Apr 2021 17:18:05 +0000

Here’s a fun HTTP+HTML+CSS technique for skeleton screens that works in almost* any stack, and some small but important details we need to do right by it.

Most importantly, it involves no client-side JavaScript, because adding JS to make a website feel faster usually is counter-productive. In fact, Zach Leatherman inspired this post by saying:

// Detect dark theme var iframe = document.getElementById('tweet-1352314419343052800-605'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1352314419343052800&theme=dark" }

// Detect dark theme var iframe = document.getElementById('tweet-1352317811285237761-845'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1352317811285237761&theme=dark" }

* The newer isomorphic ones like React struggle mightily to stream over HTTP, with one exception — I’ll get to it later.

Skeleton screens?

Or indicators/placeholders/whatever. The “new” design hotness for when computers aren’t ready to show you something: skeleton screens!

No, not nearly that entertaining.

Instead of a spinner or progress bar, show something shaped like the eventual content — it orients the user faster, hints at what to expect, and avoids the page jumping around as it loads:

The loading process of Polar, one of the first apps to popularize the concept of skeleton screens.

Demo

We can’t avoid the time it takes to call a search results API — we can cache its responses, but how can you cache all possible search queries ahead of time?

Here’s what these search skeletons look like with an artificial search API response delay of 5 seconds:

And here’s some code for how they work:

<SiteHead />

<h1>Search for “${searchQuery}”</h1>

<div.SearchSkeletons>
  <await(searchResultsFetch)> <!-- stalls the HTML stream until the API returns search results -->
    <@then|result|>
      <for|product| of=result.products>
        <ProductCard product=product />
      </for>
    </@then>
  </await>
</div>

This is that “one exception” I mentioned earlier. Marko is a JS component framework similar to React, but is actually good at server-side rendering — in particular, built-in support for HTTP streaming. (And last I checked, it’s nearly the only thing in Node that does. RIP Dust)

If you’re more familiar with other languages/frameworks, here’s how they accomplish something similar to Marko’s <await>:

PHP: flush() and ob_flush()
Ruby on Rails: ActionController::Streaming
Spring: StreamingResponseBody
ASP.net: I recommend searching for ASP’s .BufferOutput and .Flush() yourself, because it’ll also turn up results warning about possible footguns.
Django: There’s a StreamingResponseBody, but Django really doesn’t care for it. You may need to get creative.
Others not listed here: Try searching for them plus “http stream” or “chunked transfer-encoding”.

By not waiting on search results before sending HTML, browsers get a head start downloading assets, booting JS, calculating styles, and showing the <SiteHeader> and <h1>.

.SearchSkeletons:empty {
  height: 110vh; /* Skeletons take up at least the full viewport */
  background-image: …/* Assume this is an image of the skeletons for now */…;
}

.SearchSkeletons::before { /* This is the faded white bar that scrubs across the skeletons */
  content: "";
  position: absolute;
  height: 100%;
  width: 3rem;
  background: linear-gradient(rgba(white, 0) 10%, rgba(white, 0.5), …);
  animation: shimmer 2.5s linear infinite;
}

@keyframes shimmer {
  0% { transform: translateX(-100%) }
  100% { transform: translateX(100vw) }
}

The :empty pseudo-class is the key:

While waiting for the search API, the opening <div class="SearchSkeletons"> is streamed to browsers, without children or a closing tag.
:empty only selects elements without children, such as the aforementioned <div>.
As soon as the HTML resumes streaming and fills .SearchSkeletons with results, :empty no longer applies.
The skeleton styles disappear at the same time the <ProductCard> components display, reanimating the product skeletons into real products.

A nice thing about this approach is that if the search endpoint responds quickly, :empty never matches and browsers waste no resources styling or displaying the product skeletons.

Avoiding style recalculation

Do we need :empty? Couldn’t this also work?

<SiteHead />

<h1>Search for “${searchQuery}”</h1>

<style>
  .SearchSkeletons {
    …
  }
</style>
<div.SearchSkeletons></div>

<await(searchResultsFetch)>
  <@then|result|>
    <style>
      .SearchSkeletons { display: none }
    </style>

    <for|product| of=result.products>
      <ProductCard product=product />
    </for>
  </@then>
</await>

Yes, that does work. But it’s slower: appending new CSS to a document triggers “style recalc”, where browsers update their selector buckets, invalidate and re-match elements, etc.

We can’t avoid browsers performing reflow, as that always happens when new HTML streams in. But by avoiding additional style recalc:

Browsers show the new HTML sooner
User interaction doesn’t hitch as much
There’s more CPU time left over to run JavaScript

Using :empty vs. additional <style> elements is a subtle decision, but it impacts user experience just the same.

Hopefully, this illustrates why a strong understanding of HTML and CSS is important for making a site fast.

Hardware-accelerated animation or bust

And if that didn’t illustrate why a strong understanding of HTML and CSS is important for making a site fast, this sure as hell will.

A predefined @keyframes that only changes the transform property is one way to ensure that an animation is hardware-accelerated on the GPU. That means it frees up the CPU for all the other responsibilities of the main thread: parsing, JavaScript, user interaction, reflow…

Skeleton animations that run on the main thread have a raft of complications:

The shimmer animation will hiccup and stall whenever JavaScript executes, the document reflows, style recalculates, or JSON is parsed.
The time the CPU spends running the animation makes the above tasks take longer.
The loading indicator delays the content it’s a placeholder for!

At my job, I changed a similar loading animation from using background-position to transform. The page FPS went from 49 to 55 on a powerful developer MacBook — imagine how much more on mobile!

But wait, there’s more!

Remember this from the earlier code sample?

background-image: …/* Assume this is an image of the skeletons for now */…;

The TL;DR is the background image is made of CSS gradients and so that the skeleton is shown ASAP. It makes no sense to have your loading indicator wait on an HTTP request, does it?

I implemented the background images with Sass variables to prevent the skeletons from drifting out of sync with the product cards if any changes were made. For example, if I tweaked the padding of the actual product cards, the following code would also update the spacing of the skeletons:

$skeleton-color: #dfe1e1;

$card-padding: 0.5rem;
$card-height: 8.125rem;

$img-height: 70%;
$img-width: 45%;
$img-position: right $card-padding top 0;
$img-skeleton: linear-gradient(
  transparent 15%,
  $skeleton-color 15%,
  $skeleton-color ($img-height + 15%),
  transparent ($img-height + 15%)
);

$name-line-size: 0.844rem;
$name-line-1-width: 13ch;
$name-line-1-offset: $card-padding;
$name-line-1-position: $card-padding 0;
$name-line-1-skeleton: linear-gradient(
  transparent $name-line-1-offset,
  $skeleton-color $name-line-1-offset,
  $skeleton-color ($name-line-1-offset + $name-line-size),
  transparent ($name-line-1-offset + $name-line-size)
);
$name-line-2-width: 10ch;
$name-line-2-offset: $card-padding + $name-line-size + 0.2rem;
$name-line-2-position: $card-padding 0;
$name-line-2-skeleton: linear-gradient(
  transparent $name-line-2-offset,
  $skeleton-color $name-line-2-offset,
  $skeleton-color ($name-line-2-offset + $name-line-size),
  transparent ($name-line-2-offset + $name-line-size)
);

$price-height: 1.5rem;
$price-width: 4ch;
$price-offset: $name-line-2-offset + 1.3rem;
$price-position: $card-padding 0;
$price-skeleton: linear-gradient(
  transparent $price-offset,
  $skeleton-color $price-offset,
  $skeleton-color ($price-offset + $price-height),
  transparent ($price-offset + $price-height)
);

.SearchSkeletons:empty {
  background-repeat: repeat-y;
  background-image:
    $img-skeleton,
    $name-line-1-skeleton,
    $name-line-2-skeleton,
    $price-skeleton
  ;

  background-size:
    $img-width $card-height,
    $name-line-1-width $card-height,
    $name-line-2-width $card-height,
    $price-width $card-height
  ;

  background-position:
    $img-position,
    $name-line-1-position,
    $name-line-2-position,
    $price-position
  ;
}

@media (min-width: 30rem) {
  .SearchSkeletons {
    display: grid;
    grid-template-columns: repeat(auto-fill, minmax(20rem, 0.75fr));
    grid-gap: 1rem 2rem;
    justify-content: center;

    &:empty { /* TODO show how to use `background-repeat-x: round` to make skeletons responsive */
      height: auto;
      background: none;
    }
  }
}

Here’s what that Sass compiles to:

.SearchSkeletons:empty {
  background-repeat: repeat-y;
  background-image:
    linear-gradient(transparent 15%, #dfe1e1 0, #dfe1e1 85%, transparent 0),
    linear-gradient(transparent .5rem, #dfe1e1 0, #dfe1e1 1.344rem, transparent 0),
    linear-gradient(transparent 1.544rem, #dfe1e1 0, #dfe1e1 2.388rem, transparent 0),
    linear-gradient(transparent 2.844rem, #dfe1e1 0, #dfe1e1 4.344rem, transparent 0);
  background-size:
    45% 8.125rem,
    13ch 8.125rem,
    10ch 8.125rem,
    4ch 8.125rem;
  background-position:
    right .5rem top 0,
    .5rem 0,
    .5rem 0,
    .5rem 0;
}

I was going to finish this post with how to make these mobile-first styles responsive using background-repeat, but it was making me put off publishing this altogether, and that’s terrible. If you’re interested, let me know and I’ll write a followup.

Update

I haven’t written that followup yet, but Jason “scurker” shared that the AXE browser extension does this too, and was able to share some code for how they do repeating skeleton backgrounds:

DEV Community: Taylor Hunt

Why not React?

Can we get React to be as fast as the Kroger Lite demo?

Okay smart guy, why not?

But can React be that fast anyway? It’s all just code; it can be worked with.

📃 Streamed HTML

Important facets of incremental HTML streaming

🥾 Fast boot

Costs in JS runtime boot

Does React play nice with JS engines’ boot process?

Rehydration performance

🥀 Rehydration correctness

🏸 Fast server runtime

🍂 Tree-shakeable runtime

🧠 Multi-page mental model

What about where React is going?

Conclusion

Follow-ups to the “Streets” series

Answers to some questions

Why should we trust a framework team member about front-end framework performance?

What should you do when a server error happens in the middle of an HTML stream?

Why did you think Kroger Lite would work?

Was it the choice of Marko that doomed Kroger Lite?

What’s with the cover images?

Why is the series called “Streets”, anyway?

Where’s that code you threatened us with?

Now what?

I think I finally “get” JS objects

It turns out object-oriented code is great at some things, but not all things

1. Grouping variables

2. Namespacing

3. Typed-ish data objects

4. Full-force capital-O internal state Objects, also known as Art

So what?

How to Succeed in Open Source Without Really Trying (Really)

Somehow, it’s important

It’s also unimportant and ridiculous

Nobody really gives that much of a shit about it

It’s dying, but not how’d you think

So what?

Marking up colors, revisited with GitHub’s color swatches

GitHub’s hex code swatches

But why stop there when we could be perfectionist

By the way, GitLab does this too

Accessibly exposing the color

I don’t have a real conclusion but here’s a fun fact

So what?

The demo

How fast was it?

So… how’d it go?

What did the organization think of it?

Adapt new principles to kroger.com’s existing code?

Reasons not to use React for Multi-Page Apps

Rewrite kroger.com, incrementally or not?

Launch a separate, faster version of kroger.com?

How much was adopted?

When bad things happen to fast code

But enough about me. What about you?

Routing: I’m not smart enough for a SPA

Alright, let’s try a SPA

…But is that really all the code a SPA needs?

It’s not always about the performance

Security

Where security code lives

What that means for security maintenance

Accessibility

Sometimes it is about the performance

I see you with that “premature optimization” comment

It’s not just bundle size

Fresh loads happen more than you think

SPAs are more fragile

When a SPA is a good choice

But if SPAs only bring ☹️, why would they exist?

Speed Needs Design, or: You can’t delight users you’ve annoyed

The demo’s design deviations

Design goals

Fonts

Product carousels

box-shadow more like bourgeois-shadow

Homepage promotions

`box-shadow` more like `bourgeois-shadow`

Marko’s `<await>` made streaming easy

`<await>` for nice-to-haves

Marko’s `<await>` is awesome

The `clip-path` one I ultimately riffed on