I’m not a fangirl of any single framework. For me, frameworks are tools. Just like I prefer a good, sturdy hammer over a rusty one with holes... I ...
For further actions, you may consider blocking this person and/or reporting abuse
We could talk about "React in spaghetti cosplay", the same as "jQuery in spaghetti cosplay".
Both are UI libraries, not architectural frameworks, which are separate, orthogonal concerns.
We shouldn't even expect React or jQuery to have a say in an application architecture.
What we should have instead is a formal architecture declared in a project, like in a sort of
architecture.ymlfile that declares architectural decisions, constraints, structure, etc. Some sort of "architectural linters" could assume the role of checking whether code, components, services, adapters etc exist and are created and connected according to the rules... that would bring order to chaos and we would stop blaming the wrong libraries for the wrong problems.Angular does behave more like a framework: it does define structure, architectural elements and their relationships, but those are only defined "anecdotally", rather through a formal system. This is the reason why we can still create spaghetti with it...
Architecture linters (or any kind of formal, enforceable architectural rules) would honestly be an amazing solution and probably the best possible outcome long-term.
At the same time, I don’t think the fact that React is “just a UI library” automatically frees us from thinking about structure, responsibility, and patterns. Treating React purely as a rendering layer for imperative DOM logic misses the point of why many of us choose it in the first place. Even without hard enforcement, there is a “React way” of thinking about UI, state, and effects - and it’s worth trying to follow it.
In practice, that often comes down to things like better code reviews, shared conventions, and calling out patterns that clearly fight the React mental model. These may not be perfect substitutes for formal architectural tooling, but they still help reduce entropy over time.
And of course, reality often intervenes: many projects are inherited, shaped by past decisions, deadlines, and constraints, and the code is simply there already. In those cases it’s less about blame and more about awareness and gradual improvement.
Thanks a lot for the thoughtful comment - I really appreciate it and the broader architectural perspective you’re bringing to the discussion.
Hi Sylwia,
Thanks for this post.
To be frank, DOM manipulation inside useEffects are like a haunting ghost, visiting from old times. I am not very experienced in non-framework web development but mixing two approaches (DOM manipulation with vanilla JS inside a react comp) seems really something to be avoided.
But regardless of oldschool JS coding, the examples showcase how the code can turn to spaghetti or over-complex. I wonder how it would affect the performance, especially in a big codebase.
The "How it should be" parts are of great value.
Best regards
Thanks a lot for the comment - I’m glad you found the post useful.
And yes, performance can definitely suffer, especially in larger codebases. Mixing imperative DOM manipulation with React often leads to unnecessary work and effects that are hard to reason about or optimize. Unfortunately, this pattern isn’t that rare in practice, and it shows up quite often in React projects - likely because of its flexibility and the scale at which it’s commonly used.
We loved your post so we shared it on social.
Keep up the great work!
I also prefer React.
Good choice 😀
A framework is architected in ways that makes using it a guarantee of consistency across developers, teams and companies.
React is none of these, and from seeing their trend in about ten years, then do not care to become. They seem pretty happy with this multitude of malpractices.
You’re touching on a very important - and quite sensitive - point here.
Very often, when you tell React fanboys that React is “just a library”, the immediate reaction is outrage: “That’s not true, it’s a huge ecosystem!” And yes, the ecosystem is massive. But in practice, the lack of strong guarantees around consistency, integration, and architectural direction is very real.
I remember jumping into a React project after several years of working with Angular and being genuinely surprised that one of the most popular UI libraries in the React world was not fully compatible with another extremely popular form library. You had to write custom helpers just to make validation behave correctly. In Angular, a situation like that would be almost unthinkable, because the framework provides stronger, shared abstractions and contracts.
Things have definitely improved over the years - but your point still stands. React seems comfortable embracing flexibility over consistency, and that choice has consequences. It’s powerful, but it also means that a lot of discipline has to come from teams themselves, not from the tool.
This hit a little too close 😅
“jQuery with JSX” is exactly the smell — especially the giant useEffect doing document-ready cosplay.
Loved how you framed it as habits + history, not “bad devs”. React really shines when state → UI is respected.
Great reminder to pause and refactor before the god-component becomes folklore 👏
And yes, exactly that was my intention: it’s rarely about “bad devs”, much more about habits, history, and pressure piling up over time. React really does shine once the state → UI mental model is respected.
Glad it resonated - and hopefully helped stop at least one god-component before it turned into project folklore 👏
One big reason for me to write code in a certain way is maintainability. I know that I have to go the mess I may have created multiple times in the future, and so do my colleagues.
Efforts we spend in creating beautiful code should have the goal in mind to create something an average, hung-over developer would find possible to reason about in an emergency.
Linters, static code analysis and, if possible, code reviews are proven tools to raise the quality bar of a code base.
"I don't want to touch this because it may break" is a huge alarm sign you can get from a developer that the code is crap.
I completely agree with this. For me, maintainability is one of the main reasons to care about how code is written in the first place.
I’m also a strong believer in keeping things as simple as possible and avoiding unnecessary layers of abstraction. If a new developer joins the project, they should be able to understand the code without fear and extend it with confidence - not treat it like a fragile artifact no one dares to touch.
nice!
Thanks Ben 😊
No problem :)
or everything is a custom hook!
Haha, yes! I completely forgot about that architectural gem 😄