The advantage of frameworks is to have a "common language" to achieve some goals together with a team. A good framework hides some of the stupid mistakes you would do when you would try to develop that "language" from scratch.

When you do a project from scratch, if you work enough on it, you end up wishing you would have started differently and you refactor pieces of it. While using a framework I sometimes have moments where I suddenly get the underlying reasons and advantages of doing things in a certain way, but that comes once you become more of a power user, than at start, and only if you put the effort to question. And other times the framework is just bad and you have to switch...

React is a weird beast. I've been using it for years. I think I like it? I use it for new projects too, probably somewhat as a matter of familiarity. I'm not entirely convinced it's a great way to code, though.

My experience with it is that functional components always grow and end up with a lot of useEffect calls. Those useEffects make components extremely brittle and hard to reason about. Essentially it's very hard to know what parts of your code are going to run, and when.

I'm sure someone will argue, just refactor your components to be small, avoid useEffect as much as possible. I try! But I can't control for other engineers. And in my experience, nobody wants to refactor large components, because they're too hard to reason about! And the automated IDE tools aren't really built well to handle refactoring these things, so either you ask AI to do it or it's kind of clunky by-hand. (WebStorm is better than VSCode at this, but they're both not great)

The other big problem with it is it's just not very efficient. I don't know why people think the virtual DOM is a performance boost. It's a performance hack to get around this being a really inefficient model. Yes, I know computers are fast, but they'd be a lot faster if we were writing with better abstractions..

You could walk through the framework so you then understand it. There are several "let's create react from scratch" articles

https://pomb.us/build-your-own-react/

Certain frameworks were so useful they arguably caused an explosion the productivity. Rails seems like one. React might be too.

I get the sentiment, but "I don’t like magic" feels like a luxury belief.

Electricity is magic. TCP is magic. Browsers are hall-of-mirrors magic. You’ll never understand 1% of what Chromium does, and yet we all ship code on top of it every day without reading the source.

Drawing the line at React or LLMs feels arbitrary. The world keeps moving up the abstraction ladder because that’s how progress works; we stand on layers we don’t fully understand so we can build the next ones. And yes LLM outputs are probabilistic, but that's how random CSS rendering bugs felt to me before React took care of them

The cost isn’t magic; the cost is using magic you don’t document or operationalize.

I feel like a lot of the comments here are from people who either weren't around for, or didn't grow up in, the era where adactio and the wider web dev scene (Zeldman, etc) were the driving force of things on the web.

If you've only been in a world with React & co, you will probably have a more difficult time understanding the point they're contrasting against.

(I'm not even saying that they're right)

So you don’t like compilers? Or do you really full understand how they are working? How they are transforming your logic and your asynchronous code into machine code etc.

If you have this attitude I hope you write everything in assembly. Except assembly is compiled into micro-ops, so hopefully you avoid that by using an 8080 (according to a quick search, the last Intel CPU to not have micro-ops.)

In other words, why is one particular abstraction (e.g. Javscript, or the web browser) ok, but another abstraction (e.g. React) not? This attitude doesn't make sense to me.

The AI pilled view is coding is knitting and AI is an automated loom.

But it is not quite the case. The hand coded solution may be quicker than AI at reaching the business goal.

If there is an elegant crafted solution that stays in prod 10 years and just works it is better than an initially quicker AI coded solution that needs more maintenance and demands a team to maintain it.

If AI (and especially bad operators of AI) codes you a city tower when you need a shed, the tower works and looks great but now you have 500k/y in maintaining it.

> And so now we have these “magic words” in our codebases. Spells, essentially. Spells that work sometimes. Spells that we cast with no practical way to measure their effectiveness. They are prayers as much as they are instructions.

Autovectorization is not a programming model. This still rings true day after day.

What I cannot build. I do not understand

I've used React on projects and understand its usefulness, but also React has killed my love of frontend development. And now that everyone is using it to build huge, clunky SPAs instead of normal websites that just work, React has all but killed my love of using the web, too.

This person's distinction between "library" and "framework" is frankly insane.

React, which just is functions to make DOM trees and render them is a framework? There is a reason there are hundreds of actual frameworks that exist to make structure about using these functions.

At this point, he should stop using any high level language! Java/python are just a big frameworks calling his bytecode, what magical frameworks!

Predicated upon the definition of "magic" provided in the article: What is it, if anything, about magic that draws people to it? Is there a process wherein people build tolerance and acceptance to opaque abstractions through learning? Or, is it acceptance that "this is the way things are done", upheld by cargo cult development, tutorials, examples, and the like, for the sake of commercial expediency? I can certainly understand that seldom is time afforded to building a deep understanding of the intent, purpose, and effect of magic abstractions under such conditions.

Granted, there are limits to how deep one should need to go in understanding their ecosystem of abstractions to produce meaningful work on a viable timescale. What effect does it have on the trade to, on the other hand, have no limit to the upward growth of the stack of tomes of magical frameworks and abstractions?

If you are the only person who ever touches your code, fine, otherwise I despise this attitude and would insta-reject any candidate who said this. In a team setting, "I don't like magic" and "I don't want to learn a framework" means: "I want you to learn my bespoke framework I'm inevitably going to write."

> I’ve always avoided client-side React because of its direct harm to end users (over-engineered bloated sites that take way longer to load than they need to).

A couple of megabytes of JavaScript is not the "big bloated" application in 2026 that is was in 1990.

Most of us have phones in our pockets capable of 500Mbps.

The payload of an single page app is trivial compared to the bandwidth available to our devices.

I'd much rather optimise for engineer ergonomics than shave a couple of milliseconds off the initial page load.

I also don't like magic, but React is the wrong definition of magic in this case. It's an abstraction layer for UI and one that is pretty simple when you think about it conceptually. The complexity is by third party library that are building on top of it, but proposing complex machineries instead of simple ones. Then you have a culture of complexity around simple technology.

But it does seems that culture of complexity is more pervasive lately. Things that could have been a simple gist or a config change is a whole program that pulls tens of dependencies from who knows who.

This reads like a transcript of a therapy session. He never gives any real reasons. It's mostly a collection of assertions. This guy must never have worked on anything substantial. He also must underestimate the difficulty of writing software as well as his reliance on the work of others.

> I don’t like using code that I haven’t written and understood myself.

Why stop with code? Why not refine beach sand to grow your own silicon crystal to make your own processor wafers?

Division of labor is unavoidable. An individual human being cannot accomplish all that much.

> If you’re not writing in binary, you don’t get to complain about an extra layer of abstraction making you uncomfortable.

This already demonstrates a common misconception in the field. The physical computer is incidental to computer science and software engineering per se. It is an important incidental tool, but conceptually, it is incidental. Binary is not some "base reality" for computation, nor do physical computers even realize binary in any objective sense. Abstractions are not over something "lower level" and "more real". They are the language of the domain, and we may simulate them using other languages. In this case, physical computer architectures provide assembly languages as languages in which we may simulate our abstractions.

Heck, even physical hardware like "processors" are abstractions; objectively, you cannot really say that a particular physical unit is objectively a processor. The physical unit simulates a processor model, its operations correspond to an abstract model, but it is not identical with the model.

> My control freakery is not typical. It’s also not a very commercial or pragmatic attitude.

No kidding. It's irrational. It's one thing to wish to implement some range of technology yourself to get a better understanding of the governing principles, but it's another thing to suffer from a weird compulsion to want to implement everything yourself in practice...which he obviously isn't doing.

> Abstractions often really do speed up production, but you pay the price in maintenance later on.

What? I don't know what this means. Good abstractions allow us to better maintain code. Maintaining something that hasn't been structured into appropriate abstractions is a nightmare.

[dead]