DEV Community

Taylor Hunt
Taylor Hunt

Posted on

Follow-ups to the “Streets” series

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:

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… and…

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:

  1. 🛡 Reliable: respect everyone’s safety and circumstances
    • Security features built-in to where your server is in control
    • Offline support without SPA overhead
  2. ♿️ Accessible: respect the web’s diversity, longevity, and ubiquity
    • Fast, accessible-by-default navigations
    • Browser support as deep as you need
  3. 💨 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 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)

peerreynders profile image
peerreynders • Edited

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

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 …

  • It's good enough Facebook so it should be great for us

… and turned into …

  • It's popular so it must be the best.

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.

my original idea was developers beholden to the public good via government sites, charities

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.

tigt profile image
Taylor Hunt

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.

citronbrick profile image

Hi, could you please elaborate more? Probably write an artcle.

I'd love to learn about datepicker accesibility.

Thread Thread
tigt profile image
Taylor Hunt

This was years ago and I no longer have access to the original investigation, unfortunately.

Thread Thread
peerreynders profile image
peerreynders • Edited

In 2021 moment.js was 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.