I enjoyed reading this. But I thought this was more than funny:

1. The author says:

So, I don’t think talking is working. But one thing that static site generators showed is that examples work.

2. The author says:

I’m hard-pressed to name more than a handful of web apps that I would say are genuinely good with no major flaw.

…

But web apps? There are a ton that I tolerate because they are marginally more useful than they are flawed but very few are what I’d say were genuinely good.

3. The author goes into a digression about good native apps made by small teams and names several examples.

4. The author claims:

But a single person making a decent web app seems to be a fantastical notion. Hell, you rarely even see big teams making decent web apps these days. I would like to see that change. And there are two ways to make that change happen.

5. One of the two good ways the author feels we can make that happen is to talk more about those good web apps that are already out there.

The author spills nearly 3000 words about how examples improve the field, admits to knowing a few good examples, and concludes that one way we can improve things is to talk about the good examples that are out there.

And nowhere in those 3000 words does the author discuss examples of what they consider a “genuinely good” web app.

I found that funny. In a way that was a little frustrating after reading the whole piece.

Unfortunately, none of this is going to happen until we’ve suffered more churn in the tooling, because:

1. The people consuming the tooling demand to pick and choose parts of the stack piecemeal, which means there can be no meaningful integration across the various divides within your app’s platform, and all the interface points between these actors are lowest-common-denominator, throwing away and re-creating slightly-different metadata each time.
2. The people driving the major players at the moment aren’t concerned with the user-visible quality of the output so much as they are being able to avoid whatever part of Javascript or the DOM they don’t like.
3. Far too much uninspectable runtime magic instead of build-time work, which dovetails nicely with:
4. Dev-time and end-user run-time execution environments are wildly inconsistent even within individual projects, and:
5. Individual parts of your stack, having being chosen piecemeal, each embedding slightly different stacks of magic for their particular dev-time experience, and constant weird behaviour caused by this (say, nextJS vs Storybooks bundling and dev-server behaviour)

More holistic tooling options could address a lot of the technical challenges of current web-dev, but I have no idea how to go from zero to one with a new, more complete toolkit. Web app developers are loathe to adopt complete tools because it means giving up whichever part of their stack they’re currently happy with. And this means if you want your OSS web dev platform to gain the necessary hype required to sustain it, you need to cater to these demands.

I can picture better tools, but I have NFI how to evolve from where we are to that point without tool teams having the funding to just work furiously for a year or two to build an experience so good that people can’t ignore it.

Edit: Just to clarify: None of the people involved are acting in bad faith, it is an emergent system problem. The people writing frameworks are doing it to support their existing needs, and trying to juggle the outside needs of external users is fuckloads of hard thankless unpaid work. Adopting a complete-stack framework is a huge risk, and without believable promises of unicorns and order-of-magnitude improvements they are rightly a tough sell.

Post the excellent web apps that you know.

I’ll start with https://www.photopea.com/