Apologies to Chesty Puller for appropriating his quote, “Pain is weakness leaving the body.”
It’s 2024, and you are about to start a new project. ...
For further actions, you may consider blocking this person and/or reporting abuse
Let me play the devil's advocate here. React is merely another framework. It has its strengths and weaknesses. It has seen many changes, but so have Angular(JS), Vue and more, while others have vanished altogether (remember Knockout or Durandal?).
Web Components require a lot of boilerplate and are difficult to debug. Lit eases a few of those problems, but it's not a silver bullet either.
At some point, even the most future-proof code becomes legacy code. So if you want to be really future-proof, have an exit strategy from whatever you are using now - even if those are web components already.
It doesn't hurt to separate view from logic, as tight coupling reduces portability. Also, you should be able to move to a new solution without a big bang approach. Pragmatic solutions go a long way.
Does anyone use ember.js still?
LinkedIn uses it.
React isn't a framework.
That shipped has long sailed dude. You're late to the party, React is a framework 😂
Is jQuery a framework too?
React is like an engine, jQuery is like a wrench. An application may run on react, but it could merely utilize jQuery. Only one of them enforces certain patterns.
I agree and disagree. React team calling it library so we should stick with it. However I agree with you it’s somewhere in between. I believe react team is working hard to change it to metaframework as once react-forget is out it’s not going to be just a library
This is still the same argument from authority fallacy. Just because they wrote a single framework they get to decide the definitions of libraries and frameworks for all of them? I certainly disagree.
In my book, a framework is something that shapes the code run within it. By this definition, React is certainly a framework, despite its community may claim otherwise.
However, none of them could give me a convincing definition that would exclude React. Let's hear yours.
React is a Library, not a framework. React is essentially a collection of classes and functions that make things somewhat easier/quicker to get development off the ground. A framework is more a platform that provides a foundation for building applications, providing structure etc.
There’s a lot of good write up's on this topic!
In those write-ups, the distinction point is inversion of control. But even so React takes up a large chunk of control over the DOM and even over fetch, which fulfills the definition more than e.g. AlpineJS, so I think you're still wrong calling React a library.
I'm really not sure what the whole "it's not a framework, it's a library" posse should bring. Should it look like it's less opinionated? Or less constrained? That would be rather amusing, I guess.
You are trying to make subjective opinion into fact - React is a library and this is the official description of it from the devs own mouth. End of story.
I'm making an argument here, not stating an opinion. If you can't make that distinction and address the argument with valid criticism, you're not adding anything of value to the discussion.
Also, if the devs officially declared that it was a chocolate cake, I still wouldn't eat it. This is an appeal to authority fallacy, not a valid argument.
React isn't just a framework, its an ecosystem ..it long outgrew the boundaries of frameworks
Other frameworks have an ecosystem, too. As a member of the Solid.js ecosystem team, I should certainly know.
Nice try, but you get no extra points for attempts to confuse the matter.
yeah yeah
I like these kinds of posts because they make me think, but at the same time I don't think they provide too much value beyond provoking discussion. Let me go point by point.
JSS is completely optional and you can use any other styling solution with React, including CSS modules and Tailwind, which also collocate styles with components. This is nothing React specific.
Saying React has a Shiny object syndrome and comparing it to new kids on the block like Astro doesn't make sense to me.
I agree with the Rule of Least Power, and one should avoid using JS where HTML/CSS suffices. That said, JavaScript is indispensable to create and manage non-trivial UIs. It's insincere to blame React for "JS first" and compare it to Svelte or Web Components which themselves wouldn't fly one bit without JS. In the end, all content that's not directly returned from the server has to be JS generated/incorporated so your criticism of React is actually complaining about how the web platform works. However, debating which content has to be generated on the client and which doesn't is always a valid discussion.
About new versions of React breaking apps, well not really. React is not Python, it maintains a great level of compatibility with the older versions. If you have used
React.Component6 years ago, you can still use it today and avoid hooks altogether. Of course React's APIs changed a lot in its 10 years existence, but I'd rather highlight how astonishing it is that it remained relevant to this day. If you compare it to other established frameworks like Angular or Vue, which had their fair share of big changes too, maybe it says something about the nature of people and projects evolving, and I think you are complaining here about "not getting things right the 1st time" which is a classic mistake to make.Your frustration with React that you linked is in reality a frustration with engineering teams not caring about bundle size. You can't blame React for that, bloat can be created even out of Vanilla.
I think your criticism of React is mostly invalid and recommending Web Components as an alternative seems counter productive to me. They have quite many unexpected pitfalls, are quite clunky to write without a framework and again, they are JS first regardless of how shiny they might look at first glance.
I agree that it's good to think critically about which libraries get used for a project. However, I think there's a couple things to point out here:
That's really what I'm trying to get at with my somewhat inflammatory post. It would be great for folks to evaluate or re-evaluate the frameworks they are using since a lot has changed in the past five years.
Not sure if there's anything particularly unique to be honest. Migrated a vanilla js project to React 15.3.2 in 2016 and use 18.2 in projects now.
As far as I know, class components stayed pretty much fully backwards compatible throughout that time. The only real pain point moving to hooks was some event listener & canvas/DOM cleanup that used to be in
componentWillUnmountand didn't translate perfectly as a return function inuseEffect.Outside of React, ran into some limitations/frustrations with react-router and switched to using Next.js for new projects last fall. Overall very content with that choice so far, but it was a bit of a hassle to adjust to at first.
In terms of structuring projects, I've typically aimed to keep the scope limited (e.g. split a large platform into its constituent parts) and made private
utilsanduiNPM packages to share between them. Keeps things lean & centralized overall I think.I definitely get what you're saying, but if you leave the Vercel question aside, what you wrote is just as applicable to Astro, Svelte, Vue, etc. In fact it's also applicable to Web Components which are written in JavaScript.
It is much less likely with web components since they are part of the platform and their API's are stable. There will only be additive changes to the API's, no breaking changes. A web component you write today will work unchanged in 2039.
I don't think that's necessarily true. Firstly, you can still run React code from 2015 - it works just fine in nearly all cases. And I don't believe they plan on deprecating the class-based API.
And secondly, most people building with web components are doing so with lit, which has exactly the same issues. It's currently on version 3, which in theory means three sets of breaking changes. You can build web components without lit, but it is a MASSIVE pain to get anything resembling a functioning component-based UI.
So the only bit about the post that is a practical difference is the affiliation with Vercel, which I agree is very awkward and a valid reason not to use React.
The difference being, web components will probably never be legacy tech, but React definitely will be.
It depends on how you build your web components. As I said, most people still build web components with a framework like lit or stencil, and those could absolutely become legacy tech. There are not many people building plain web components - at least not for whole applications or complex reactive components - it's just very fiddly.
Great article.
There are more issues with the modern React which I mentioned here: dev.to/arturampilogov/react-is-not...
Today we do not have a good alternative. Only HTMX heavily fighting the whole concept and JS app architecture approaches.
Ideally Web development should include:
1) New version of HTML with concepts from HTMX, so that there is no need in JS for most cases.
2) CSS already provides many cool UI features ✅
3) A new modern language that compiles to WebAssembly as close a possible. It will allow to write server-side logic (supported by any platform) and extra dynamic front-end code.
In my opinion, the problem lies in the frozen front-lines of the Browser Wars. JS is a flawed language, with many quirks that waste so much time for every new learner.
CSS was built for styling documents, not for richly animated, interactive UIs.
A truly big paradigm shift would be to repurpose the browser to be it's own heavily sandboxed OS maybe where you can bring your own language to.
Whole HTML ecosystem is going from simple document to a ( maybe richly animated ) interacive UI. In greater perspective no mather which technical solutions reach this goal. If you are against JS then HTMX is your way. In my perspective the react give a great frame for interaction/animation heavy solution on FE side, where I can combine classic HTML with SVG, WEBGL, Streams interaction/animation elements, for a performance optimal result. If I care so much of amount of JS then I will use
qwik.See my answer to Joshu Amaju please.
lol, let's throw away the language because you have a very niche use case.
I feel you and Peter Vivo think about this emotionally. I had the chance to use a couple of programming languages professionally. JS has objectively a lot of quirks like an absolutely inconsistent "array" of array methods like
sortis mutating the array whilemapis not. And so on.Many would have been happier to use their choice of language, but unlike in an OS like MacOS or Windows, in the browser you can only use JS or things that compile to JS. For example for the mission critical performance tasks you have now things like Rust and Zig and not just C++ or C. These are recent, modern languages. They can exist, because the platforms they are on are not stuck like the browser world.
Regarding interactivity: CSS has similar problems: during its long life it got repurposed many times. I bet some big money on it that if people had to create a new UI engine with a new language it would be a lot different than what we have currently.
This does not mean that either language is garbage, but we are at the point when people don't even consider anything else. We have learnt a lot about what works and what not in programming languages and yet we are stuck at JS for better or worse.
Coming at your interlocutor saying their statement is one derived from emotion is a great way to pass your point across...said no one ever.
I bet you can't come up with one valid reason we should ditch CSS, my observation is that most people that complain about CSS just don't know it, rather than try to understand it they complain. But you can prove me wrong.
JavaScript has issues, but most of the critics are just "I can't put in the work to understand this thing so I'll just complain about it". I've never had issues with anything you've mentioned.
And you do realise that some languages these days are following in the foot steps of CSS and Javascript? There goes your bet.
And if you really want to avoid using Javascript on the web, you can actually go build your own browser that supports different languages. You can also use compile to Javascript languages, you have options. So I don't get the issue. Or is your issue that you don't want Javascript to exist?
Sorry man, your reply is very combative, again, coming from emotional attachment.
I should not do it, but I do reply on your claim about CSS.
Name a cutting edge AAA video game that uses CSS. None. CSS was built for styling documents. It's excellent for that. Many people are forcing their CSS-in-JS way through it avoiding using the defaults that makes CSS very lean (when understood well).
However the problems with CSS will arise when you have to quickly rerender many things at scale. CSS was not designed for very fast rerendering. In fact, being a code JS engineer is to know enough about the DOM and how CSS works to avoid rerendering. But with different languages, rerendering is not an issue at all (unless you do something very stupid).
Nowadays you can do things on top of the current engine that allows you to do run effective and optimized animations in the browser, as an afterthought.
Please show me a AAA video game which is running on browser. I think this is does not tightly belong to HTML/CSS/JS architecture. If you would like to making a smooth and really GPU intensive graphic then you would go to WEBGL. But show me AAA video game which social platform is not on the web. Because HTML/CSS is much more related to document, social platform - like this one or discord.
But in my use case - reall industial one - it is also great ( including react ) to make a high frequency scientict realtime data handling application building. Which is of course use WEBGL, interactive SVG animation, CSS, HTML. Everything which need to use scientist at daily work. So I think this technick is not so slow as you imagine.
At this point I don't take you seriously cause your arguments are based on emotion.
I think you'd like Alex Russel's article The Market for Lemons.
We are big fans of HTML-first approaches and server-side rendered web components that lean on the light DOM. Here is a shameless plug for Enhance, an open source project I work on.
This is unlikely, 25 years ago people would use framesets and other ancient stuff, which modern browsers won't even support.
True, but a lot has changed for the better. I still use paddings, margins, classes, methods to name classes and so on.
We're talking about a slow incremental replacement of the dumb stuff with smart stuff.
For the past nearly three decades if not longer, browsers have understood three languages: HTML, CSS, and JavaScript. Everything that runs in the browser is written in one or more of those languages.
Now we have WASM and a few other languages, but the vast majority of the Web remains HTML, CSS, and JS. TypeScript adds static types and inferencing, but does not (currently) run natively in the browser.
So React, Svelte, Solid, Angular, etc. are just HTML, CSS, and JS. Seventeen years ago I was building websites using Scala to generate HTML, CSS, and even JS. Before that it was Ruby on Rails. Before that PHP and before that CFScript.
But in the end it was all just HTML, CSS, and JS.
So everything we add on top of those three languages is just baggage. It slows things down. It adds complexity. Just as Eric Elliot mentions the "TypeScript tax", there is a "React tax", an "Angular tax" (quite steep), even a "Svelte tax".
What I want is easy re-usability and a component architecture. Simple routing is nice, too. And static types.
Astro with TypeScript provides all that. I don't need or care about the "islands" feature. I use no client-side dependencies except the occasional polyfill.
But Astro let's me write components and reuse them without having to resort to Web Components, which remain difficult to use and, IMO, overly complex. I may eventually use them, but not until I must. Meanwhile, I look for easy ways to abandon Astro, too.
I was an early adopter of React. I taught the first React class at Codementor (now Arc). I pushed my employer at the time toward functional React, then FRP (redux-observable), then hooks. I taught state-of-the-art React to hundreds of people.
But I abandoned React five years ago (except when forced to use it by contract). And when forced to use it, I stripped away all the bloated ecosystem cruft.
I describe this process on my website, Craft Code, for anyone who is interested. The site itself is vanilla HTML/CSS/JS built with Astro and TypeScript (and some Vercel serverless functions).
A great many devs have invested heavily in React and its ecosystem. It remains to be seen how many even remember much HTML, CSS, and JS. They will not easily surrender their investment. But beware the sunk cost fallacy. For the vast majority of sites/apps, React and most other frameworks are overkill.
And your HTML/CSS/JS is unlikely to need to be rewritten every 2.5 years. CSS and JS improve yearly, but there is no need to rush to embrace those new features. So we're talking serious shelf life. But I guess if you prefer refactoring to writing new things ...
I'm reasonably happy with this state – perhaps for the first time in decades.
You can build a React application and not touch it for 10 years and it will be just fine... In my experience though, most enterprise apps don't live longer than 3 years before getting complete replaced or rewritten. So your argument that is somehow weird seems really weird to me. The web is fast paced. Nobody ever said it wasn't. Also, you don't have to rewrite your application to use React server components. What you do need is a full stack framework that supports them though. There are no breaking changes in the way React works since v16.8 and infact it still remains backwards compatible with react code written before that so... Show me another framework that is backwards compatible with code written nearly 10 years ago.
I'm so frustrated with relearning every 3-4 years a new paradigm. Only my CSS and SQL skills seem to be long-lasting.
But then you have people making sure you can't use either because here's instead a framework with religious followers "simplifying" these languages that are going to be gone in 3-4 years again (I'm looking at you
TailwindandPrisma).I´m not sure that your are right about page rendering:
Before any element is processed, the page is scanned for external references, so they can be fetched while the page is being processed.
But all Elements on a HTML page are just processed in the order they appear. A ascript placed somewhere in the middle of your HTML-code will not be able to access any DOM element, that is defined by HTML somewhere below. So, HTML and JS on the same page are executed in the order they appear. They both will build the DOM-tree.
Building the DOM and rendering the DOM to the screen are two different things. Before any part of the page can be shown, CSS needs to be fully loaded and read. If it is an external CSS-file, this might be after the DOM is ready.
Things get much worse if not all external files are referenced in your main page. Then you might get a chain of files, each needing to be fully loaded and executed before you can start to fetch the next file. This can end up with a reasonable delay.
There are different things that can delay your page. It is more the order and structure of the different modules you need than just about a single reason. If you say: "avoid Javascript, it makes your page slow" this is might be a bit misleading.
I like the "Rule of Least Power" reference, I haven't heard of it before but it does make sense...
Btw. for the presentational part of react, JSX that is, I saw that you mentioned that it adds a layer of abstraction which is true, but in a way it actually makes the presentation part of react less powerful, which in turn makes it more reusable / portable...
Thank you for writing this article.
Been doing this for 20+ years. Glad I'm not the only one who feels this way.
"Today we do not have a good alternative. Only HTMX heavily fighting the whole concept and JS app architecture approaches."
Of course we have alternatives.
It's just if they are tolerable or not. (Willing to learn CSS?)
As the article implies (or maybe I read it in there myself) the logical consequence of "Least Power" is "Separation of Concerns" - becoming framework independent thus agnostic.
Decouple GUI logic from data/business logic.
GUI logic defined as - HTML/CSS to manage states - open/close, hide/show, expand/collapse, elements etc.
Data/business logic defined as - whatever framework and or other solutions you and or your team sees fit to "wrangle data".
Semantic HTML - for intuitive, lightweight, minimally nested, structure, interactive elements, and baked-in accessibility.
Modern CSS - for themes, layouts, and to passively watch for and react (so to speak) to dynamic data changes in the DOM through
:has()and other features that have recently achieved majority support status.Buttons need do nothing but CRUD operations on the data itself. When the data changes, the GUI natively reacts (without scripting).
This intrinsic approach (I believe) would lead to better defined swim-lanes, decoupled resources, and less security vulnerabilities. It would realign project required skillsets with developer areas of expertise. It would allow for both design and development to flourish independently for a more enjoyable SDLC experience for all.
(Don’t even need to learn CSS.)
I’m a bit new to web development, and I’ve been told learning React is good since it’s so popular in the job market. I’ve been using it for a couple months now. Do you think it’s still a good idea to master it for the purpose of making yourself more hireable at this moment?
In my private, subjective experience, this is a good combination:
It happened to me a couple of times that the new hire from school was familiar with the Next Thing. For example when they knew already about React, but the tech stack was still on Angular. You could ask the new hire questions about the new tech, while you could bring them up to speed on the old tech.
At this point, we all are looking at escape hatches.
Thanks for the response! That makes a lot of sense.
One more thing: even with emergent new tech, old React applications will need support for many-many years. So my idea works for this scenario, because, eventually people will walk away from the previous tech.
"The Shiny Object Syndrome" - my favorite part of this article! very useful and quite simple language.
Thank you
To me rewriting a codebase every time an API is introduced sounds like terrible software engineering practices, it seems to me that every time a new API comes out then all developers immediately assume that the new API is better than what was previous but is simply not the case, everything has tradeoffs and failure points it just takes time for those things to surface. If you rewrite your codebase every time then it is just a signal to me of lack of maturity in the development team as you tend to react to what is coming out.
Principle of least power, progressive enhancement, robustness, perfmatters, cross-device accessibility, we have known and said for years. So why are the "shiny gems" still so appealing?
Great point of view. Even though it doesn't solve a lot of the issues you mentioned, I'm happy I choose to specialize more in Vue.js rather than React. There are less "big api changes" over time and structure seems more robust.
React is great but it is definitely worth exploring alternatives.
en.wikipedia.org/wiki/No_Silver_Bu...