Comment by fishtoaster
16 days ago
As someone who lived through all major waves of JS for the last ~16 years, I do love react, in a sense:
React is the worst JS framework except for all the others we've tried.
I'd take React over the Angular 1 days any time. I'd take Angular 1's full-bodied MVC over the "build it yourself from scratch every time" approach of Backbone. I'd take Backbone's minimal MVC structure over the classic JQuery Soup architecture. And I'd take JQuery's dom manipulations and standard-library improvements over the native apis (of that era) in an instant.
React has its tradeoffs, but we got here after a long slog of other things that don't work.
But why over vue? My biggest frustration has been how vue ends up moving in the direction of react. The original component architecture with the html template, JavaScript state and css styles in vue was so nice. Even the data fetching a url in the component was so intuitive.
A bit out of date, but I like the point-of-view of "The single most important factor that differentiates front-end frameworks" : https://mjswensen.com/blog/the-single-most-important-factor-...
> A bit out of date
> article just about to turn three years old
JavaScript community never beating the allegations lol
4 replies →
Fantastic article. It is strange that such important aspects of JS frameworks are so rarely discussed.
Great article. I prefer the react model over the other models. Now it'd be good to know, with every framework, which of these it implements.
Terrific read thanks for digging it up
I was deep in Vue 5-6 years ago, so much that I offered internal training for it and had sessions with more than 20 people attending.
IMHO, React wins because you can just treat templates as variables. You don't need "slots" or other special stuff. It's simply more composable.
Vue doesn't solve problems better than React (and solves them worse if you have to learn all their proprietary files and DSLs instead of JSX), so there's not much of a reason to switch.
The real discussion would be between React's vdom and something like Solid's signals.
It does, if you care about ergonomics. The reactivity model is simpler and arguably less error prone.
It does have its own templating syntax, which is trivial to learn. No more cumbersome to learn than JSX, which is a templating language designed by the React team. Not sure why you chose to make the distinction between JSX and Vue’s DSL as if JSX wasn’t developed for the sole purpose of facilitating React’s virtual DOM.
14 replies →
Vue solve single source of truth much better than react though. The shape of derived data and source data (or even external data) are the same and interchangeable. So you can write an api that works with both without handling implementation quirks at all.
The words borrowed from someone else:
The react is more about view.
The vue is more about reactivity
So JSX is not proprietary?
The company I work for uses Vue. I think the non-backwards-compatible move from Vue 2 to Vue 3 burned a lot of the current devs, so now they're stuck working on Vue 2 apps that are in maintenance mode with no viable case to clean up the mess by moving everything to Vue 3. The experiments to do it with Copilot mostly failed, although that was in the early days so another try today might work better. If we're doing something drastic to improve though, we might as well solve our "Vue devs are hard to find" problem by rebuilding it all in React at the same time.
I am in a process of upgrading fairly big Vue 2 app (technically 2 apps, where one is not traditional and the other uses Inertia) to Vue 3.
It is a fairly painful process - I am using Codex and Claude as a first pass for converting things, but everything has to be checked manually and often fixed or rolled back to try again. Too often instead of "removing" piece of code that is not necessary anymore, AI would try to add a 100 line workaround for it because it would really rather add things than remove them.
It is, however still a faster process than doing manual rewrite. Smaller components are a breeze to convert from older Vue 2 to Vue 3 composition API.
Rewriting entry point app.ts with bunch of custom plugins was a horrendous experience that eventually was done manually. Move from Vuex to Pinia was also 50/50. Some things were easy, some things were not and had to be done manually.
Then there's a process of switching from unsupported packages which is a whole other can of worms.
Overall - if not for AI I'm not sure I'd have gone with an upgrade at this point. Yes it requires careful review and testing, but a ton of trivial stuff was done very quickly.
I led a project to (successfully) migrate a Vue 2 to 3 app and while that was painful and expensive, I still find Vue more pleasant to work with than React once it was done. But TBH depending one team code discipline either could be fine or a nightmare. :)
I definitely sympathize with the feelings about the Composition API. Though I’ve moved past it because looking at React’s visible complexity (useMemo, useEffect - which apparently have changed names again since I last looked) - Vue has clearly chosen a superior API design.
Unless I’m completely missing something, those hooks still have the same names and semantics as always?
1 reply →
I'm using Vue and do not feel it's becoming react
This sentiment only really applies if you’re coming from Vue 1/2 to Vue 3. The Composition API is definitely more like React but makes some better design decisions that make it easier to work with than React. Such as implicit reactivity.
2 replies →
Is Vue still magic, or can you actually write normal typescript?
as long as JSX never becomes default in Vue, vue is still winning
Amen.
Agreed. Like you, I went from hand-written cgi-bin html to jquery to angular v1 to React. I will willingly reach for React as a tool - it does what I want to do.
I remember in 1999 being so psyched about changing a button image on mouseover. Went hard on jquery, little bit of angular and bootstrap. React was big for me because it’s one way data binding solved the kinds of bugs I had spent years dealing with. Vue svelte and others are cool but they are all very similar to me. I always encourage people to work at first without any framework because then you gain an appreciation for why these things exist (or you stay vanilla and constantly blog about it)
I like react over angular and vue over react.
same here thus I'm with vue
Have you used Svelte? I can’t see why anyone would like React more. The only upside I think react has it’s the IBM of frontend. No one has been fired for choosing React.
Currently rewriting nextjs app into sveltekit. It’s going surprisingly smoothly. Don’t know about svelte vs react yet BUT sveltekit is far more straightforward than nextjs has far better DX and is somehow faster
Svelte is cool although I didn't have some big epiphany. I'm not going to use Svelte because "it compiles" and "is faster" when my existing React app performs very well. Plus there are some libraries for my specific use case that didn't exist in Svelte. I know people love things besides React, and I would be happy to see it unseated. Sure I'm part of the problem but it's been good to me and I have bigger fish to fry.
> Plus there are some libraries for my specific use case that didn't exist in Svelte.
A lot of these libraries aren't needed in Svelte because 1) the functionality might already be built into Svelte, and 2) you can use any JavaScript library directly, unlike in React where you often need a React-specific wrapper.
Not saying that applies to your specific use case, but I've seen this argument way too many times.
2 replies →
Just use JS libraries. You don't need wrappers.
More library support for React over any other framework. I also like explicit state change over implicit.
As someone who went through that same journey, agreed.
Compared to previous paradigms, React lets you compose complexity and rich interactivity really, really well. Even for all its flaws.
I've never had the sort of problems I[0] had with React when using Angular (1 or 2), despite the apps having more complexity.
Maybe that's just anecdata, but I hated them a lot less. (I am mostly a Backend dev who also does Frontend, so I don't love any of them.)
[0]: and by that I mean my whole team at the appropriate time, it's not simply me misunderstanding things
React was a major improvement over Backbone + Marionette. Pre-jQuery was a shit-show as they hadn't even standardised the DOM.
Before that was XMLHttpRequest (particularly during my .Net WebForm days) and even had to use the ActiveXObject in IE that predated JSON.
XML, XMLHttpRequest, and XSLT in IE 5 was peak web dev for me. Never been more productive.
This feels like the equivalent of "whatever music you liked at 16 defines your taste"
1 reply →
Back in the days when launching a website was an event, and sometimes included junket trips to attend.
Give me Backbone + anything over React. Backbone was the last time I really felt close to the web page I was creating.
We're still using it for our stuff (via our @beanbag/spina TypeScript wrapper for Backbone that has a few additional niceties), and I feel the same way. We can be as close to the DOM as we need (or let something manage it for our view for us), we can be smart about where data lives and how things interact with it/listen for changes, and we get a decent little object model that doesn't dictate how we think about everything.
Very happy still with the Backbone way of building webapps.
Oh boy the ActiveXObject brings back some ~~ptsd~~ fond memories.
What about Angular 2+?
After the disaster of AngularJS that we are still paying external EOL support on, I will never trust another Google led framework.
Angular 2+ is equally horrible. Having spent 6 years on various versions of Angular, their migration story time and again has been an incredible pain.
These days I use web components for component writing and frameworks to handle routing, state management, bundling, and so on.
can you compare it to other frameworks?
I migrated from Angular 4 to 18 (including ngrx and material) and didn't find it especially problematic.
Migrating mostly was little effort and consisted of automatic migration and walking through the provided checklist (mostly to ensure I didn't miss anything important), but I don't have any comparison in the JS SPA ecosystem.
1 reply →
I tried Angular 2+ back in the day. I found it frustrating to learn as the API had changed between versions, and when searching for help you would come across a blog post/stackoverflow answer, start implementing it and realise it didn't work in the version of Angular your project was in. Frustrating.
Tried React afterwards, this frustration didn't really exist and it was much easier to pick up.
The frustation is pretty much there under Vercel's stewardship, especially when React comes in the shape of Next.js.
It is apps or pages, which supports what, what new use cases is "use..." now for, ....
Wait, react is a framework now? People used to say that react is just a model binding library. FYI I haven't used react.
"React is actually a library, not a framework" is definitely a thing people have said here and there since its inception. It's a distinction that doesn't seem to buy anything in terms of explanatory power or clarity, so I tend to ignore it.
I think it's a shortcut for saying that react doesn't have an 'official' routing library (like vue-router) and state management library (like vue's pinia). So depending on what you choose to manage routing / state, one react app can be quite different from another.
Maybe nowadays there is a set of popular libraries for react so it becomes framework-y?
1 reply →
Generally the difference between a library and a framework is that you can use bits and pieces of a library to add functionality to your project.
A framework expects most of your project to be shoehorned into it.
Whether something is one or the other depends on which of the two most users are doing. It's not a very interesting argument, though, because debating semantics is the worst use of the limited time you have on this planet.
you can use React like a library, but I have never really seen it done.
Depends on the definition.
jQuery isn’t a “framework” either, at least not like Angular or Vue, though it can be extended with “plugins.”
Both jQuery and React are foundational technologies, so comparison is valid.
jQuery isn’t exactly a “framework” either, at least not like Angular or Vue, though it can be extended with “plugins.”
Both jQuery and React are foundational technologies, and comparison is valid.
Yep, react is indeed a library. Part of the confusion comes from a fact that react community was keen to hijack "react" name and slap it onto their own projects, for example there were react router, react query, react table, etc., so one could have get a feeling that react was like full-fledged framework, while most of these "react" projects were not affiliated with react the library in any way.
That’s right — the outcome is path-dependent. If we knew then what we know now, surely we’d have gotten over the idea that the web is DOM-documents-plus-REST-plus-JS-handlers-everywhere.
A lot of people did and do like that idea — I like it too — but it’s woefully inadequate for making rich web apps that a team of average devs can handle.
We are very far away from Angular 1.0 days, and not every single website needs JavaScript.
Exactly right. And this is why Astro works very well for me.
I enjoy React and I’d take it over all of those other things. I wouldn’t take React over htmx/data-star and server rendering if that’s all I needed, and even if I had a couple of pages that needed a little bit more.
I never wanna use anything but Svelte ever again, honestly.
I was a big Sevelte fan. After writing a sizeable application in Sevelte I realized that React is superior in every way overall speaking and at least you're writing 100% pure JavaScript directly. Or Typescript.
Plus the ecosystem. It's huge. Nothing comes closer.
You might be interested in solid.js. To me, it's easier to work with than React. What I like about it is that the reactivity model is small enough that you can understand it, and even implement a basic version yourself.
It also uses JSX, but since there's no virtual DOM, you can also write 100% JS, but, unlike React, you can do it without any special wrapper. So you don't need to use or write a `react-dnd`, just use any vanilla drag and drop library.
I've tried solid and it's much nicer on small projects. How well does it scale though? Modern React is also 'more functional' (for some definition) but it comes at a cost of cumbersome and leaky abstractions. Classic React walked a fine line of being 'just reactive enough'. You could make code declarative and composable while still micromanaging certain lifecycle and data dependency decisions that can be critical for performance.
5 replies →
> 100% pure JavaScript directly
How did the React community convince so many people of this falsehood? Do that many people just not know what javascript is? It baffles me that one could look at JSX and be like, “that right there is vanilla javascript”.
Yeah man it’s pure JS trust me just add this little transpiler and you’re good to go. What do you mean you don’t have a bundler?
History is important here. React came at a time when so many frameworks used custom template libraries for variable binding, looping, conditionals, etc. Usually it was some HTML/XML-like markup language.
vanila javascript would not be far off, just replace the tags with function calls. In early versions of react, there were people who wrote code like that. For some reason web devs since collectively agreed that the xml syntax is essential to web technologies
What people mean is obviously that you use JS primitives for looping, branching, conditionals, etc. over some DSL. Everybody knows that the tags are added syntax, there is no conspiracy here.
3 replies →
JSX is basically just a subset of E4X.
Could you expand on your experience compared to react?
I had main issue with smaller ecosystem. Very limited components and everything else is geared towards React. Take React Query for example. If you want first class data caching and retry logic etc, then Svelte support was second class at least couple of years ago.
Same goes for component libraries.
>Sevelte
FYI: https://www.merriam-webster.com/dictionary/svelte
Chesterton’s framework.
Curious to see where you'd place Knockout (still my favorite framework to date)
We'll set aside performance because that could be fixed with a renderer rewrite.
The biggest issue when I worked with it was weaving a spiderweb of bindings that eventually trap you. At some point, you wind up spending most of your time fighting weird bugs that show up in places very far removed from the bindings that actually caused the bug.
Unfortunately I never got around to trying it! I remember it being a contender around the time of Backbone, but then Ember and Angular were the main options thereafter.
Where would you put custom elements in your list?
Not comparable because custom elements don't handle rerenders elegantly without extra plumbing.
> React is the worst JS framework except for all the others we've tried.
> React has its tradeoffs, but we got here after a long slog of other things that don't work.
I strongly believe it's because of trying to achieve the wrong goal with the wrong tool. So many websites could just be bare html pages and forms with just a sprinkle of JS for some interactivity, but they want to add JS for whatever reason.
If you can have a complete repo browser without JS (cgit), most web applications can survive without it too.
There are four culprits here and neither is due to JS.
First is the pursuit of polish. Each extra 1% in polish adds tons and tons of lines of code. If you want that level of polish on a non-SPA, you'll still have to add all that code then reload it one page at a time. I see a lot of these "bare HTML pages" and they are lacking important stuff like i18n/a11y/WCAG compliance. Try adding all that back in and you'll see your website bloat right up.
Second is bloated do-everything libraries. Ant, MUI, Mantine, or whatever else is aimed to be a superset of all possible website needs which means that the components you adopt have tons of features and bloat you don't need that slow down loading, parsing, and execution. Simply replacing that <Paper> component with a <div> and a few lines of CSS will get you the same thing you want, but will save you layers of unnecessary React components and sometimes a layer or two of unneeded DOM nodes as well that were added because the <Paper> component had weird interactions with some other component.
Third is manpower/experience. Many/most JS devs today (sad to say) don't actually know how to make that simple <Paper> component on their own. Those that do often skip it because they've got too much to do already. I've lost count of the number of teams I've seen where a bog-standard backend has 25 people working on stuff while the frontend team has 3x as many total lines of code (which are often times handling human-computer interaction issues the backend couldn't even imagin), but only 3-4 people to maintain it all.
Fourth is of course management. Designs on the backend change at a trickle while changes to the frontend arrive in a torrent. Understaffed frontend teams can't keep up with all the things shoved on their plate, so they usually can't optimize things even if they know how (eg, only a small percentage of SPA actually know/take the time to lazy load various parts of their apps to improve load time).
Fix these things and the SPA performance will improve drastically and almost certainly exceed BE templates with some jQuery spaghetti.
>I see a lot of these "bare HTML pages" and they are lacking important stuff like i18n/a11y/WCAG compliance. Try adding all that back in and you'll see your website bloat right up.
having lots of JavaScript tends to make more WCAG problems, because you do interactive stuff that needs to be described. Having bare HTML and the accessibility that is required for that is not tending to bloat in my experience.
3 replies →
Sounds like your argument is with SPAs, not React in particular?
SPAs are a monster that grew and grew; an idea that at first seemed like a clever optimization has generated huge and complex systems that are a nightmare to work with, and are bloated, slow and insecure.
Web components are the next big idea. I hope they have a chance to work.
3 replies →
Exactly, for most websites out there classical webserver rendering does the job pretty well. Even fancy animations can be taken care by pure CSS.