Consider the tool the author mentioned, jQuery. It is on the text almost as a museum piece.
The things jQuery did (compatibility, CSS selectors, fetch) became standards or stable almost a decade ago. We don't need a 2024 version of jQuery, what that tool did we can now do vanilla.
And that's about it. Perhaps React would be useful for a large project, with lots of complexity to manage, and assuming that people involved have experience in using it to manage such complexity.
On the other hand, that React project that contains only some forms and page navigation could totally be <form and <a with some small vanilla JS snippets.
Sometimes I choose React because it’s easier for me, despite it adding unnecessary complexity to the project.
For example, I’m terrible at front end, and design. Tailwind has a React library that handles many of the UI requirements and produces a decent-looking front end with minimal effort. I know enough React that the complexity doesn’t scare me, and there’s so much documentation and training available that it’s easy to find answers. It integrates easily with other frameworks. I can reuse components I built for other projects.
React is often not the optimal choice for the project, but can yet still be the right choice.
There are many pure CSS libraries out there that meet varying degrees of UX requirements. Form controls, typography, layout, everything.
MDN has a complete documentation with complete browser support, examples, reference. It's awesome.
On React world, I often have issues with community components. I needed a dynamic table in my last job, there was simply none. You had to pay for a premium component, or use a code that barely passes 3min auditing (material-table-core). It was a nightmare.
A dynamic table qualifies as something I'd rather have a framework do for me. Jesus, YUI did that for free 15 years ago (with tests, with cross browser, with rendering and painting considerations...). However, we ended up rewriting significant portions of the original component we chose (all data handling, all export and import, all menu, all cell rendering, all style).
Exactly. A good designer with a deep knowledge of HTML, CSS and JavaScript will tend to prefer vanilla code, and it makes sense for them to use that. A full stack dev - like me - with a smattering of knowledge across the front end may prefer to use React.
When people argue about whether React is right for a project, they are often trying to optimise for different non-functional requirements. Those against might be considering performance, filesize, and complexity. Those in favour may be optimising maintainability, reusability (with other projects), ease of hiring and onboarding new people. So they can both be right, and what they need to work out is which NFRs matter the most.
"And sure, maybe you don’t need jQuery, and that’s fine. Will you need more lines of code to do the same thing? Of course. But even without jQuery, your complexity doesn’t grow exponentially like it would if you brought in a framework with its build system, linters, compilers, and 700mb of Node Modules ..."
Consider the tool the author mentioned, jQuery. It is on the text almost as a museum piece.
The things jQuery did (compatibility, CSS selectors, fetch) became standards or stable almost a decade ago. We don't need a 2024 version of jQuery, what that tool did we can now do vanilla.
And that's about it. Perhaps React would be useful for a large project, with lots of complexity to manage, and assuming that people involved have experience in using it to manage such complexity.
On the other hand, that React project that contains only some forms and page navigation could totally be <form and <a with some small vanilla JS snippets.