The Market for Lemons

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.

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.

The author spends the bulk of the post (as far as I could tell from the opaque writing style) criticizing React and the React ecosystem.

But when you see the first footnote for their recommended alternatives, many are very similar to React in practice. Notably:

Preact (basically just another implementation of React)

Vue (very similar ecosystem to React in terms of the mentioned SPA SSR etc)

SolidJS

Svelte

Etc.

Then some of the recommended alternatives to the SPA are just as complex or more complex than the things the author had just criticized, including Astro (SSR with islands), Fresh (denos edge based "just in time" SSR), Sveltekit (the same SPA SSR SSG etc complained about for React above).

Not sure how these don't fall under the same opaque criticisms of the JS "lemon market".

The article is a bit too bitter for my taste, but I agree with most of it. Except for the developer experience improvement these frameworks supposedly offer, I don’t even buy that.

For over a decade it seems to me the industry has been enamored with crazy complex solutions to problems that mostly don’t exist. I keep reading their proposals in dismay and basically chugging along with almost the same stack as before. Clients are as happy as ever.

I tried to show (here and elsewhere) that, for instance, PHP/MySQL + HTML/CSS/VanillaJS is faster, easier to read and write than React/Angular/FrameworkDuJour, but we seem to live in different worlds. I still think jQuery was the biggest improvement in frontend development quality of life and hasn’t been matched since.

I’ve mostly resigned to believe that React and friends are maybe great for hiring, being hired, manage teams. Actual coding is another discussion altogether.

I think there’s a bit too much “blaming the tool” going on here. Be reasonable about what you introduce into a software project. If it’s a bunch of CRUD you probably can wait to add a front-end framework. If you find yourself needing it for that one big feature where you have to implement drag-and-drop and a bunch of DOM manipulation, don’t rewrite your whole app, just tailor that one experience.

If you don’t NEED a high level of server communication or data continuation between components, you probably also don’t need any crazy state management. And again, when you build that one wizard experience that really needs something more, tailor the solution local to that one experience.

Not to say that larger and more complex projects don’t exist, but for most things you can get away with a lot less, and there’s balance between performance, developer joy and increasing productive capacity.

TFA is a rant that seems mostly targeted at React, judging from the links/examples. The article is not very clear or easy to follow but it still has a point. All modern frameworks are ridiculously complex, esp. given the fact that modern JavaScript is extremely versatile, with classes, modules, web components, etc.

A new empty Angular project via the Angular CLI copies almost 40,000 files of node modules (350 Mo), which is apparently considered "very little space" by today's standard (actual quote from a SO answer).

It's all quite demoralizing. I actually like SPAs! and I agree that state must be managed on the client somehow; but this is insane. Plain old JS with some Redux, querying a well thought out and simple API on the server will get you a long long way.

People that complain about SPAs are the modern knights tilting at windmills. What are the primary ways people today consume content? Youtube, tiktok, whatsapp, facebook messenger, instagram, discord, etc, etc.

Before someone qualifies my post with "ackshually I do this thing", yes I read blogs too.

That being said, NOBODY READS BLOGS. People don't want static html and css. They want real time updates, they want notifications, they want gamification. They want to play the slot machine.

So while you want to shit on javascript (it's fun to bundle in the shit language javascript when going on these tirades because everyone fucking hates javascript). The problem is not javascript. The problem is, we want real fucking apps, with interactivity, and we want them instantly, over an internet connection.

I want to play chess in my browser over an internet connection. And when chess 2.0. comes out I better have that shit in my browser in under 100ms.

Oh, and sure JS is shit. But if we were using Rust for our UIs we'd have the same problem. The most prominent Rust web UI frameworks are literal React and SolidJs clones.

And JS will be replaced, but we don't have a good enough garbage collected language for it yet.

edit: Can you even think of a modern business that could be just served by just html and css. Like what? A restaurant? Is that what we really think the average software engineer is working on? Restaurant websites?

Has this author been on the other side of the fence? I have encountered, for every bloated javascript problem child, an equally burdensome python monolith, or sprawling maze of go microservices. I suspect the root cause is something to do with human error, but I digress.

The benefit of much-derided React code when I can onboard new developers from 3 different countries and backgrounds and have them all writing DRY, tested, idiomatic code within a few days. They can then ship a feature that then provides more values to the end user, who probably doesn't care a fig what HTML is. Or, like a patient senior developer, they understand that shipping is preferable to not shipping, and that perfect performance, accessibility, and usability are all asymptotic to us mere mortals.

> We lost a decade to smooth talkers and hollow marketeering

To eliminate lemon markets somebody has to be tasked (and rewarded) for doing the slog work that will reduce the information asymmetry. This would normally be trusted experts (tech journalism, academia etc).

Despite all this NextJS has brought me a lot of joy using it. Probably the most joy of all front end experiences web or even desktop (and I quite liked WPF!)

That said I get it: it can be annoying for the user when the site does unpredictable shit which it can sometimes do with a SPA. For example shit appearing just before you click an area of the screen so you end up clicking the wrong thing.

The complexity is a problem too, there is a lot of shit to learn these days to get the app working. NextJS is like autopilot most of the time but you still gonna drop down and troubleshoot NPM dependencies etc. sometimes so there is a lot to know.

People tried different things for many years and web apps won simply because they did what people want without the trouble of native apps.

Installing, maintaining, and securing native apps is too much trouble.

I wish I knew what the author was fulminating about.

This article is in dire need of examples and case studies but instead, the author says that it is hard to summarise a “decade” of JS/SPA bloat into one article.

Anyway, to his point about the market for JS frameworks shrinking, I’ve moved my projects to HTMX + AlpineJS. Couldn’t be happier though the entire apparatus seems to be holding together with wire and spit and prayers.

Is the author talking about information websites, websites with limited interactivity, or web applications that would feel more at home as desktop applications?

I honestly believe that many of the complaints about SPAs as a bad paradigm don't solve themselves with progressive enhancement; they solve themselves with a better cross-OS development environment and safe, sandboxed modern applets. (Alternatively, your company needs to be homogeneous, and third-party vendors need to develop for both Mac and Windows, and hope Wine is good enough for any other option.)

That leaves websites with limited interactivity. If the author is speaking about these, I can understand the frustration. I'd love to see solutions like liveview or htmx take over. Maybe other solutions will be good enough. However, for us to get beyond talking past each other on these conversations I think we need to always be considering the context and detail the use cases.

the author recommends in the first footnote to use other frameworks like vue, svelte, lit/polymer etc., which makes this seem more like an argument against react, when the entire article is about how javascript-driven spa/ssr stacks are bad. there are a couple clarifications next to it to soften that blow but react also "start[s] with simple output" in the same way these tools do. why act like react is the only lemon merchant? i say this as an active user of vue, so maybe im simply at the most complex of them but from my perspective the other tools are about as complex

Similar article: https://biggestfish.substack.com/p/information-asymmetry-par...

Setting aside the FA for a second and considering just the market for lemons itself. Imagine being George Akerlof. You coined one of the most famous things in economics (the market for lemons), for which you won the Nobel Frikkin' Prize[1] and your spouse[2] is still a more famous economist than you.

[1] Nobel Memorial Prize if you're a Taleb-inspired pointless hair splitter

[2] Janet Yellen

Its interesting as a theme to spot check things these days with: "is what I think is normal really a zirp/vc-bubble anomaly?"

For me the biggest source of unnecessary complexity is Kubernetes.

If you use envelope math, you rarely need more than one reasonably sized instance, and your key performance bottleneck is database and external apis.

Lots of people can get away with single machine running on Heroku/ec2, until their product logic becomes too complicated for a single dev team to maintain.

Hilarious. The page isn't rendering as (I think) it was intended - half of the screen literally sticks to the top. Maybe the author went too far with his point %) Otherwise, I generally agree. )

SPAs were a zero interest rate phenomenon :’DDD I laughed so hard

In the author's footnote #1, he praises Svelte and Vue. So the whole article boils down to "Don't use React, use Svelte/Vue instead."

Yesterday there was a post for Patterns, an AI framework. Deja vu.

Pretty soon everyone and his school buddies are going to be putting out frameworks for building an AI-enabled application, if they aren't already.

And eventually Microsoft and Apple will incorporate one into their developer products, and maybe some of those VC startups will get acquired.

I disagree that JS frameworks are in any way a problem. React is not substantially different from developing a Rails frontend using um... what do the kids use these days? HAML? Hamlet! No, that's not right. Anyway...

The real trouble comes when you think that "switching to <hot new framework>" will solve all of your problems. This is equivalent to thinking that giving your troops Scottish-made swords (when they've been using German-made swords) will somehow make them fight better.

Armed with this disinformation, teams march blindly into the meat grinder of reality. "We need to do auth... again? Didn't we just do that in Django? And then Angular? Arghhhh". If your auth implementation in django was bad, and you rewrote it in angular and introduced problems, rewriting it in react is not going to magically make your developers do it right this time.

This is a pompously written puff piece. Moving logic to the client is the right choice for an application, and the wrong choice for mostly non-interactive content. Know what you're building and choose the right tools/use the right techniques.

Javascript has been (and kind of continues to be) a mess, but thankfully you can compile almost anything to WebASM these days, and 95% of people have browsers that support WebASM, so if you want to build your app in Rust with QT have at it.

> Those who dared speak up were branded "negative" and "haters", no matter how much data they lugged in tow.

I'd argue the rot goes beyond JS frontends and into a lot of webdev infrastructure, including libraries and full-stack frameworks. And that lemons tend to cluster with other lemons.

Did I miss it, or did the author not state what the better solution is?