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 dayAmazing 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.
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.
Top comments (5)
I think at this point "the industry" is just too far gone.
Take Shopify.
In the interest of their customers how could they choose a React based solution like Hydrogen with all the evidence that React is too slow for Amazon on mission critical parts of their store front?
Primarily because their customers need to have access to a prevalent (and perhaps these days “cheap”) supply of developers to build and maintain these storefronts—a technically “better” non-React solution could make it a lot more difficult to hire for, commercially invalidating Shopify's product.
And pre-RSC Remix saw this “hole” in the Market that Next.js left. However they didn't dare leave React's market clout behind even though their “mission” would have been served a lot better with Preact but there's always:
(Though now with Remix and Jason Miller under the same roof who knows what will happen).
It started with …
… and turned into …
Meanwhile nobody seems to have taken the circumstances of React's development within Facebook into account.
It was always about (initially) building web solutions fast, not building fast web solutions.
And with Facebook's positioning the web solution just had to be good enough to hook a potential new user to motivate them to download a more performant (and invasive) native client (as Facebook had plenty of motivation and resources to create those). I seem to remember that in some countries Facebook had arrangements with some cellular carriers to incentivize users to access the internet via a Facebook app.
And lets not forget that in 2013 web access via desktop was still prevalent and that the (back-end) Developers are expensive, runtime is not (and “free” on the client device) attitude is still common today.
And at least since July 2013 React became solely about React and not the web. The siren song of cross platform reuse was just too hard to resist (OO reuse anyone?).
Which raises the question: if you aren't using React Native why are you using React on the web at all?
Essentially you are making trade offs you are not reaping the benefits of (i.e. RN reuse). inferno is dedicated to the web and enables declarative UI but doesn't push trade offs downstream to the user the way React does.
… but the ecosystem.
I think the GOV.UK Design System is a good example of this. It makes their content first orientation pretty clear, while interactivity is mindfully introduced. While marko would have been a pretty good fit, their resource pool is probably more amenable to nunjucks partials.
The funny part about the ecosystem is that we found it rarely helped when we set our standards high enough. Our design system tried to find a React datepicker that passed basic accessibility audits and didn’t bundle all of
moment.js— and failed.Hi, could you please elaborate more? Probably write an artcle.
I'd love to learn about datepicker accesibility.
This was years ago and I no longer have access to the original investigation, unfortunately.
In 2021
moment.jswas at the core of the lighthouse alternate library recommendation controversy due to the fact that it wasn't conducive to tree-shaking (Early RxJS had similar issues due operators being methods rather than independent functions).The Web Accessibility Evaluation Tool (WAVE) can help find lots of accessibility problems.