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.
Feel free to ask more questions in the comments!
I was laid off by eBay in February 2023. I am now equally untrustworthy as I was before.
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/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
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
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?
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?
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.
See next question.
- And by the end, some code I dare you to try.
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.
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.