I agree with the article, but think it's poorly written. In a way, it's a bit like the developer work that its criticizing -- overly complex.

One of the linked articles is much better and to the point: https://ericwbailey.website/published/modern-health-framewor...

My 2c: I've seen good experiences, but a lot more poor ones. I've worked on them and they were n times more expensive for very little benefit. I don't think it's by design, but more cynical people might. I think it's just a dogma among developers and management too afraid to step in because developers hold too much power. They want to work on this because everyone else is, and if they can't they will go somewhere else and then you need to find new developers and everyone knows there aren't any available.

We switched to a server side rendered spa stack because the developers said "don't want to be stuck on old fashioned stacks, want to work on cool things". We then needed twice the time and twice the developers to get things done.

So basically the way out of this is for someone to hype up a server side solution and sell it as a shiny new thing. It needs to be logical in a way that makes lights in heads go on, but also somewhat mysterious and new. Deno Islands fit that mold, we'll see if it pans out.

> "why is this market so inefficient?"

I don’t know, but I too have felt this for the last many (10 or so) years. And not necessarily just web.

I think the answer lies in part in this line:

“The complexity merchants…”

With so much free money floating around, software development has grown more bureaucratic than ever.

I’m not sure how effective emphasis on IDEs, processes, or languages really was 10+ years ago. But the fact that “being more efficient, higher productivity for lower inputs” was something people paid money for indicates (to me) that it was a priority more than it is now. When the economic model becomes “throw money at moonshots looking for the next 1000x thing” then inefficiency is going to take a back seat.

One of the truly amazing things to me is the increase in specialties that must exist and cooperate to deliver/maintain products of any size.

    I gave a beautiful lecture, which fell flat on its face. The
    managers were horrified at the suggestion that flawless software
    should be delivered since company derived its stability from the
    subsequent maintenance contracts. The programmers were horrified
    too: they derived their intellectual excitement from not quite
    understanding what they were doing and their professional
    satisfaction from finding weird bugs they had first introduced in
    their daring irresponsibility. Teaching the competence to program
    boils down to the training of misfits.

Does anyone else find this writing style hard to follow and alienating? The clever section titles, verbose passages, inflated vocabulary, and indirect descriptions, make it frustrating to read. Just say things directly.

Every non-SPA that I’ve worked on ended up accreting interactivity to the point that I’d wished we had started with a single, unified, well-structured way for managing the UI that handled interactivity well.

I used to do a lot of native Windows apps in C, VB6, and C#. To me, Preact + TypeScript is as good in many ways, better in some, and worse in others— but it averages out to be just fine from a developer perspective.

I personally don’t miss the old native UI days.

The majority of jank that I see on the web is not due to React or Angular or whatnot. It’s due to ads, trackers, and to product owner’s inability to say “no” to piling a million things into important screens.

It is a misplacement of blame to blame React.

Few jobs ago I was a PM director at a scaleup and at some point our frontend platforms engineering (or something like that) came into my purview.

This team didn't build front end experiences but tried to build out tooling in which other devs would. Which was weird to me given that we didn't do anything extraordinary in terms of experience so off the shelf stuff should have worked.

I think this was some evidence towards the point in this article. Two things were at play:

First, the gross complexity of the available frameworks made it seem like something like this was necessary.

Second, the people involved were excited to further their careers on this, so motivation to call out unneeded complexity was low.

If I had owned this space from the start, I'd have asked the question of "what business outcomes does this enable which we can't achieve at least for a while, with static-ish html, forms, etc" and maybe allow a little complexity where justified. But since it was purely engineering owned for a few years before it got to me, it was way too late to reign the complexity and we ended up doing shit like porting from one framework to another.

My god, this article reads like a non fiction incarnation of "infinite jest" its basically impossible to understand the authors concrete intent and meaning of whole paragraphs without reading the footnotes and the linked articles while reading the post. And if i understand it correctly, it completely misses the point who is to blame. Angular and react solutions were seldom sold from an actor with deep information to a manager or business with less information. In my experience the top 2 situations were a) managers/half-technical founders wanted what they had read about and google or facebook were backing and did not want to hear about a proper evaluation, b) devs and whole dev teams wanted to just use what they knew and read about 100% thinking this was the best solution because of their inexperience and lack of reflection. The first is just your usual ignorance towards the experts by buzz word driven and half-knowledge managers, the latter could be more likened to the brainwashing of cult members than intransparent market situations.

I can't look at an app and tell you that it's written in framework A or B, but so many websites are becoming dogs these days, and not just because they have to run Javascript. I think the scripts actually spend a lot of time blocking on the I/O that would have originally been delivered with the initial page. Server side rendering may be a solution but it seems lots of sites have a rather modular approach to putting components on a page that then load lazily over ridiculous amounts of time.

As an example, the American Express account management website. Lots of banking websites are going this way, where it's taking long enough to finish a request that you worry the logout timer will fire before it's done. They have also lost niceties like the ability to take you back to the same page with the items in the same order, that I had on the Dollar Bank website circa 1998. (Seriously, that bank was ahead of the curve and the website was fast, on 33kbps dial-up and a Pentium MMX 200.)

Other websites are the same. Kaiser. State taxes. Delta airlines. Formerly fast things replaced by janky lazy loads that reflow the page and cause you to click the wrong thing. And so much telemetry! Can you actually process all that data? Because if it's working it must be screaming that people are constantly clicking the wrong thing.

At this point articles like this exhaust me beyond the point of caring. The popular tools are all reasonably good and in my experience the people complaining about the JavaScript ecosystem do so at the expense of getting stuff done.