When life gives you lemons, make a framework

February 10, 2023

I need to write something about The market for lemons. It is a long, well-written, and rather refreshingly angry article about the state of web development, and it touches on a lot of things I have had floating around in my head but have felt unsure of how to start a good conversation about.

The rest of this text may not make much sense unless you have read the article.

(Or even if you have read it.)

I do not believe that there has been a lot of malice involved in the current spread of big frameworks, but rather some kind of mass expert beginner syndrome where we have all found some exciting tools and try to push them ever further, instead of taking a step or ten back and ask whether they really solve any problems for us. React had some exciting ideas, and despite initial confusion and backlash, so many of us picked it up and used it for so many things, or took the ideas and built similar frameworks. Frameworks around and on top of Ract exploded in numbers, and React itself also kept evolving to try and solve more things in different ways.

And the React ecosystem is only one part of one stack. But let me try to not get stuck in my usual track of complaining about tech stack sizes. I always feel like less of everything would be a good thing.

I wonder what the alternatives are, and whether they are being seriously attempted somewhere. I am not even sure how to look for them, or which questions to ask. I guess web software built with fewer large frameworks - perhaps using more standard HTML and CSS? Perhaps using home-grown smaller frameworks to solve the specific things in need of solving in the particular application?

It almost feels like asking if anyone is solving their website problems by not building a website. Very, very foreign. I have only really played with the thoughts of other options myself, but it is very hard to set up a side universe with anything nearing the complexity of, typically, things I build at work but on top of some other base.

A fun possibly unexpected twist is that I am actually a fan of base React in itself. We tried other solutions before settling on React for my main work project, and it fit our problems shockingly well. But has it helped us with everything else? Is it worth all the tooling in the long run? What would the code base and user experience look like if we had applied the ideas from React, rather than the framework itself?

We kind of did that when it came to data management in the app, simply because Redux and its likes did not exist yet. The result is Redux-like if you squint, it solves our problems to a degree where we never even touch it, and the heart of it is 250 lines of airy code.

React itself is so much more entangled in everything. I have sat down and tried to figure out what would be needed to get by without it, and that becomes confusing and tiring rather quickly. But I doubt it would be impossible, or even all that difficult. More of a slog than a journey into unknown lands. But that is higly coloured by the optimism you get from not having thought deeply about a problem for a while. That enganglement itself is also interesting to me, because we use that in itself to motivate staying with what we have. We have React and all that comes with it, so adding this part which also depends on React is easy. And that makes React more entangled. Then, we have the whole build system. Originally it was there to get that React code massaged and packaged so we could deploy it. Then we hang linters and tests and prettifiers and who knows what else on top of that structure. We already have it, so why not hang one more thing on it? Oh look, we can not think about replacing React, look at all those dependencies! Simplify the build system? Oh sure, but what are all these things for? What if that really old package pulled in halfway through happens to be essential to something else?

So many words, and I still have no idea where I am going.