Other than being owned by Facebook, I’m not sure how exactly React is a monstrosity. I think people downvote vue fans because it seems they can’t help but tirelessly bring it up any time there’s anything any React and a lot of people clearly don’t feel that vue is “better”, so it gets extremely irritating.

At this point, though, aren't React and Vue more similar than different?

I set out to figure out the answer to this question by writing about it and comparing various performance issues, ease of composition of components, debugging, etc.

I didn’t find any particularly interesting or meaningful differences.

At the template level, JSX exposes more plain old JavaScript than Vue’s templates do. I find defining and using types in JSX land more intuitive. Otherwise they’re fundamentally both excellent and very capable and neither is doing any one thing glaringly wrong.

I ended up scrapping it because the deeper I went, the less interesting it got. I think it really does come down to ergonomics and preferences

Even boring as it may sound, definitely something I would read, since I known React well but don’t feel like bothering to much with vue atm, but would like to understand the difference / nuances.

A few differences between React and Vue, purely off the top of my head. (Caveats: I am deeply involved in the React ecosystem and have never personally _used_ Vue myself, but am generally familiar with it overall.)

Vue: rendering output defined primarily with templates and attributes like `v-for`; Single-File Components structure, lets you define styles as CSS and I _think_ they get scoped automatically; all major libs for routing, state management, etc, are considered "official" Vue packages and have at least some intentional coordination; probably less ecosystem churn overall due to those "official" packages; possibly easier to get started with, since it's easier to drop in one script tag and use it as a small enhancement to an existing page; reactive data UI for updating state (`state.value = 123` auto-triggers UI updates of components that rely on that data).

React: JSX syntax for rendering logic ("It's just JS!"); no official structure for defining component files/folders/logic; React is still "just a rendering lib/framework", so all other capabilities (routing/state management) are filled in with community maintained packages (React Router, Redux, etc); _dozens_ of community packages for any conceivable use case, but plenty of churn as a result; _can_ be used with just a couple script tags, but in practice normally used with a full JS build toolchain; explicit `setState(newValue)` API for triggering re-renders, and renders many components by default - have to intentionally optimize components to avoid unnecessary re-renders.

I might actually revisit it – maybe going a little deeper will eventually point to something interesting. Thanks for the nudge, I’m never sure who will be interested in things and why.

Vue supports JSX as well, and has been doing so for years.

Good point, I didn’t bother taking this route but now that I’m thinking about it, maybe it would have been useful to illustrate differences between features state management.

Anyone know of a good quality comparison out there? A video or blog post?

Read the code, then go and check preact codebase which achieves the same api.

React is the definition of an overcomplicated codebase + its model is wasteful and re-renders too much by default.

It's the least ergonomic framework which became popular I've ever seen in my entire career.

A pure case of resume driven project getting popular in some FANG and then being shoved down the throat of developers everywhere because cargo culting.

As a svelte user, i shake my head on react and vue.

It’s baffling to me how something like Svelte can be so much better in nearly every way for developers, businesses, and end users, yet still fly under so many people’s radars!

Is svelte SEO friendly by default? (SSR)

Yes Sveltekit does SSR by default behind the scenes.

Is Sveltekit to Svelte as Next.js is to React?

Or is it more like create-react-app is to react?

If you want to work for someone else, React is the thing you have to do and have prior, validated, experience in. The only employers not using React but other SPAs (Angular) are the “I want to be cool too” companies pretending to be in the tech sector.

All major SPA’s have had convergent evolution towards the same optimizations implemented in the same ways with similar syntax as well.

If one briefly had an advantage on package size, thats gone now.

If one briefly had an advantage in a DOM manipulation technique, thats gone now.

And thats that

that makes me smile

and I'll have to shift the goalpost toward what I actually think, which is the reality where the theoretical performance of optimizations is undermined by the 100 megabyte analytics package that your users are going to have to load anyway

so while we all played around with page scores to optimize how fast things load to theoretically reduce strain on the server or have less users that bounce, its just so far divorced from the user experience because we'll wind up putting so much extra stuff on our pages anyway

For most applications on most consumer devices, benchmarks comparing the time it takes to update thousands of rows are not really relevant, other considerations will have a stronger impact.

However, the lighter frameworks (where most of the work is done at compile-time and the result is highly optimized vanilla JS) really shine in specialized usecases like underpowered embedded devices, where the more popular frameworks introduce too much latency (>0.5s) for a smooth user experience.[0]

[0] - https://twitter.com/sveltejs/status/1088500539640418304

(That being said, it is kind of hilarious to me the world we live in where we're running an entire web browser on an embedded device just so we can use JavaScript to program it.)

I won't. And for analytics I will proxy via my server

> The only employers not using React but other SPAs (Angular) are the “I want to be cool too” companies pretending to be in the tech sector.

I guess that depends on where you are. Here in France Angular usually indicates companies that are a bit more "enterprise" and a bit less "startup". It will often go with a backend in Java or C#. On the other hand, React users tend to have their backend in Python, JS or Ruby. This is not a hard rule of course, but Angular is more like the opposite of cool.

> All major SPA’s have had convergent evolution towards the same optimizations ... If one briefly had an advantage ... thats gone now.

There's quite some room for disagreement wrt. this claim, depending on what exactly counts as "major" at any given time.

Okay, what about when comparing React, Vue and Angular

I'm a CTO and I mark resumés down for having React on them. If you fell for that, what other rubbish are you going to fall for?

That's the dumbest thing I've ever heard. You sound like a really inexperienced engineer, let alone CTO, that has never seen technology trends come and go, and sometimes you bet on the wrong horse.

I'd rather hire an junior React developer than someone with such hubris.

Really funny seeing you got downvoted. Not surprising. People can't get alternative opinion is ridiculous.

The downvotes are because it's so incredibly stupid that one must hope it is a trolling attempt, or intended as a deadpan joke of some kind.

This seems like an outrageous statement on its face. They probably have React on their resume because that is where the job market has drifted. No one is getting hired these days, even at old-school Fortune 500 type companies, for listing "Java-Server-Pages" or "Jinja SSR templates" on their resume for a frontend position.

That was my initial reaction too. Then I realized that every web UI re-write I've seen was lead by developer evangelism, never by management. Developers update their resumes and HR updates hiring reqs accordingly.

This makes it harder to see this as something other than a developer-inflicted problem but for the fact that there are probably three groups of developers affected by this:

a) true-believer evangelists

b) resume-builders

c) innocent bystanders

There's no way to tell from the presence of "Framework X" on a resume where the developer falls between bystander and evangelist. Probably the CTO's point is that they do not like "Framework X", and cases of c) lack judgement and decisiveness for putting up with it?!

Anyway, funny to think about, especially in comparison to the playbook for changing the back-end frameworks.

You need some oversight on your candidate evaluation practices, for the sake of that organization.

Very few of your frontend candidates will be privileged enough to optimize for what you think is relevant. They exchange time for money, you know? Or do you know that.

What is your tech stack?

I'm mostly a backend engineer, but I've worked with react and Vue a bit and, back in the day, jquery. React is definitely way harder to grok than the other two - for someone who doesn't work on front-end full time. It feels like a different language of its own, while jquery and Vue seem to complement JS.

TBH that's part of its appeal. JS is a mess, React is a relatively clean tiny little playpen inside a hoarder's house. If you're used to the stacks of newspapers and pizza boxes, it's a shock.

It's interesting how history rhymes with itself.

This pretty much sums up how I felt about Java in 2000. There had been a healthy evolution and interchange between different language ecosystems up until the late 90's. And then Java took over. One pundit opined "In 20 years, we will not talk about Java for any groundbreaking technical choices, but business schools will talk about how it was the first widely marketed programming language and the effect it had."

I'm sure this will rhyme again.

He/she turned out to be somewhat right, though the JVM is still quite a marvel of engineering, not to mention Truffle. And today Java is a far more capable language than in 2000.

I think the major difference between them and now for developers is that MIT/BSD/Apache-licensed, non-marketed languages and toolsets have gone mainstream.

In other words, developers today no longer are paying through the nose for the tools they use, unless those tools are cloud-based.

> though the JVM is still quite a marvel of engineering

I'm aware that some of those "marvels" were technologies harvested from Self/Smalltalk. But I suspect that there have been some innovations in the JVM that I just have not kept up with. When you say it's a "marvel of engineering", which types of things are you thinking of?

I'm thinking specifically of the runtime performance optimizations. Hotspot is incredibly good at JIT generation of fast machine code.

You can add C++ to that list. It seems the pattern goes like this (with examples for C++, Java, Javascript)

1) There is an unmet need in the current technology ( e.g. C can't organize huge complexity, native app crashing is not tolerable on the web, web 2.0 is incompatible with full server side html generation).

2) A current techical powerhouse withbopen enough culture has a solution fixing it, while leaving current knowledge mostly intact ( C++ is C with classes, Java is safe C++, javascript is webified Java)

3) The powerhouse tech is used everywhere because it's voice is heard louder than the small playser, and also everyone wants to feel like a big player.( at&t, sun, google/facebook)

4) A cambrian explosion pops up full of components and frameworks. Most of them dies, nobody knows what tobbet on long term. The new good tech is both used and abused on every possible problem.

5) Things settle down, we learn what to use the tech for.

6) Circumstances change, we start fighting our tools, and the cycle starts again. The new group will not understand why the old guard is still loving their old klunkers (C illegal behaviour, Java XML), even if they have to construct a strawman first.

In fact, both Cobol and C might be exampled of this, but they were before my time. There are plenty of smaller examples out there.

Redux is the only thing (sort of) from the React ecosystem that I'd save from a fire. But mine seems to be a minority opinion.

Redux is largely responsible for turning me away from React sending me straight into Vue and Vuex.

I'm sorry to hear that :(

For what it's worth, we've changed Redux usage drastically in the last three years. "Modern Redux" with Redux Toolkit and React-Redux hooks is drastically simpler to learn and use than the older-style patterns, and we get feedback from users on a daily basis telling us how much they enjoy using RTK.

If you're curious to see what that looks like, I did a video discussing the changes and cooperatively live-coding an example app:

https://redux.js.org/tutorials/index#learn-modern-redux-live...

and the "Redux Essentials" tutorial in our docs shows how we want people to learn and use Redux today:

https://redux.js.org/tutorials/essentials/part-2-app-structu...

For what it's worth, I gave RTK a go after a rushed, failed attempt at using redux. Initially started as a POC for some internal tooling within the company. Due to its simplicity, it was a breeze to set up. Two years later, it's still great, and things like RTK Query[0] have made it even better, by removing the need to write custom data fetching logic, and adding other perks like caching.

Thank a lot for your hard work!

[0] https://redux-toolkit.js.org/rtk-query/overview

Thank you! Great to hear that it's working well for you.

Your second link briefly got my hopes up that I’d finally be able to learn a little about Redux today.

Nope, the tutorial tells me I better get good first in:

> React terminology: JSX, State, Function Components, Props, and Hooks

Does that imply you can’t use Redux without React at all? Or does it just use part of React’s concepts?

I’d totally love to learn to manage my application state better. Do I really have to pull React in with that? I use vanilla JS as much as I can because I want my apps to have a decent chance to still be working a decade from now.

Redux is 100% UI-agnostic. You can use it with any UI framework (React, Vue, Angular, Svelte, jQuery, web components, vanilla JS). This is also true with our official Redux Toolkit package, which is the standard way to write Redux logic today.

However, in practice, probably 90-95% of Redux users _do_ use it with React. So, yes, all of our tutorials are written under the assumption that you are using it with React.

Additionally, we see lots of people trying to learn Redux too early in their journey. It's bad enough that bootcamps throw people through "4 weeks of JS, 4 weeks of React, 4 weeks of Redux, GO!", and we can't do anything to stop that. We do want people to learn Redux, but we've found that it's best if most people are already comfortable with JS and a UI framework (which, again, is normally React), before they try to dive into Redux. That way there's fewer new terms and concepts to learn at once, and it's more clear what benefits Redux can add and how it fits into the UI layer.

If you'd like to focus on just the Redux core concepts, I'd recommend going through our "Redux Fundamentals" tutorial. It explains the underlying principles and techniques, and how Redux works:

https://redux.js.org/tutorials/fundamentals/part-1-overview

There is content in the middle of that tutorial that explains how to use it with React, and if you want to use it with vanilla JS you'll have to recreate equivalents to some of those APIs yourself. But, the rest of the material should be directly relevant.

Also, please come by the Reactiflux Discord and ping us over in the #redux channel - we're happy to help answer questions!

Thanks for the pointers! Really helped clear things up.

> Does that imply you can’t use Redux without React at all?

Yikes, I hope not. One of my favorite things about Redux (last time I used it, maybe three years ago) was that it was easy, and even natural, to build an API client library around it that could be used almost anywhere that JS will run, because it wasn't tied to React.

No worries :) Non-React usage is still the minority use case, but it's one that we take seriously. Per my comment above, Redux and Redux Toolkit are still 100% UI-agnostic at their core. Even our new "RTK Query" data fetching API in RTK works with (or without!) any UI, which is why users have adapted it to run alongside NgRx, Vue, and Svelte.

If you ever have to go back to react, take a look at mobx

It is very uncomplicated

IMO mobx has better DX than redux, not sure why it's less popular. Probably because react community prefer FP over OOP?

Some graphQL clients can eliminate the need for these state management tools. Everything becomes just graphQL queries and mutations with very sophisticated caching. When you mutate some resource, other components that have queries that are affected by the mutation will re render with the new state.

I don't get why most projects need Redux when React has the context API already. Most people just need a place to store data shared across different components, and plain contexts do that easily.

Because Redux and Context are different tools that solve different problems, with some overlap.

Context is a Dependency Injection tool for a single value. Note that it doesn't "manage" or "store" anything - it's just a tube that you can pass something through. Any actual "storage" is normally done with React's own `useState/useReducer` hooks, which actually _do_ store and update values.

Redux, meanwhile, is a tool for predictable state management outside React. Very different kind of tool, for a different purpose.

More details:

https://blog.isquaredsoftware.com/2021/01/context-redux-diff...

They can, but for any reasonable sized application, you're basically recreating bare redux. If someone is good with both, it can architect and choses the correct one based on the needs of your software. But if you find that your global state needs are not small, you just chose redux - add a library like rematch on top to reduce boilerplate - so it's straightforward for your junior.

Out of curiosity, any particular reason you'd suggest Rematch instead of our official Redux Toolkit package?

If you're familiar with both already, are there any parts of Rematch's API you prefer over RTK's, that we should consider looking at for inspiration?

because context re-renders everything all the time

Redux historically had a pretty terrible API. Next stop: Boilerplate-ville.

But it's based on a sound model. Go and check out elm, the project redux copied its structure from and you'll see what that model is capable of achieving in a decent language.

Today with hooks Redux is not too bad but still subpar. I used for years my own simplified store, these days I just use zustand.

it is not about the tech but the tooling. for example i cant use vue with nx because there is obly a 3rd party integration and it is broken.

Taking over the world is not the worst part, it's where it's steering it to.

> the monstrosity it turned into

Literally what? React is responsible for infinitely scaling frontend features and career growth I never could have imagined.

Most websites built as SPAs using React are slower, buggier and more expensive to maintain than if they had been built using mostly server-side rendered pages, like we did in the 90s.

The problem there isn't with React, it's with people who build websites out of a tool that's designed for huge applications.

Most websites shouldn't be built with React. Most single-story buildings shouldn't be built out of steel I beams. That doesn't make them a bad material, it just means you shouldn't use them if a simpler material will do.

> Most single-story buildings shouldn't be built out of steel I beams.

But many are! This is the issue. 10-50x the effort, complexity, hours, expense. Lots and lots of steel, everywhere, because managers heard that Megacorp uses steel and now insist on it.

Steel beams everywhere.

Time to develop a low-JS vanilla SPA framework called "Jet Fuel"

Hey actually React has nothing to do with Megacorp at all. We adopted React in 2015 on a small team (less than 10 engineers) as did many other small startups at that time. The decision to use React on a small team is the same as it would be on a large team: It dramatically changes frontend development. It makes this career worth while. I did 5 years before React, and now still using React 7 years after with no competitor in sight.

I don't use React because I'm being forced to. We chose React!

Depends on the problem that small team is solving. I've used SPAs on several "small" teams (Angular*, Backbone.js) and they are very effective for solving the kind of problems that are otherwise solved by native applications (winforms and the like). When you have hundreds or thousands of forms / screens in a system then SPAs provide a large reduction in complexity.

For websites: we all like to dump on PHP but it was literally designed to build websites with relatively limited features / large reach - which covers a large swathe of the web.

So SPA: good for ERPs, CRMs etc but bad for webshops, social networks, TODO apps, news sites, Streaming sites, blogs etc.

[Why Angular? React is technically interesting, especially that it's build around the Rx pattern popularized in dotnet, however I have a deep-seated hate for Facebook for their key part in making Brexit happen which trumps any technical merit. Vue wasn't a thing back then]

This 1000x. Every nail looks like a React app. Most frameworks are overkill for most sites/apps. There are definitely ones that need that level of architecture, but that isn't most of the time.

Steel is superior to wood in almost every way. Currently they are almost the same price as LVL beams with out the 4+ back order wait.

Thank you sir, for you sir comment of sanity

I think it's using the right tool for the job. I thoroughly regret not using Vue or other major JS framework 5-6 years ago when building out our new application. While the server-side is solid the client-side is sort of a mess. A mix of a ton of different things, underscore templates, jquery, etc. It's not an SPA but any modern web application requires a ton of javascript.

We are slowly incorporating Vue into some aspects of the application and the code is just so much cleaner and legible, with better performance in a lot of cases.

SPA loading performance can be improved by splitting React app into multiple SPAs each rendered by its own smaller bundle. Additionally, for many websites, the landing/index page of a SPA can be prerendered at the build time. The result is the best performance ever achievable for many (but not all) websites.

Once SPA has been loaded, it switches to SPA internal pages faster than "like we did in the 90s" because for static pages there is no network round trip and no delay called TTFB. For dynamic pages, making API call and fetching API data (to use it for CSR) likely takes less network bandwidth than fetching HTML generated on the server (as a part of SSR).

Also server rendering uses server CPU and it's never totally free. Especially if server side needs to be scalable.

is there ANY evidence for that. because i work since two decades in the industry, saw both worlds , and am much much happier now than ever before?

> infinitely scaling frontend features

Front-end features can "infinitely scale" without React. Career growth is great, but, in my experience, after a while (maybe ~Senior Engineer), it becomes technology-agnostic.

We wrote enterprise applications with jQuery and Backbone. It didn't scale. React fixed everything. There is no post-React.

I'm not "technology-agnostic"- I only use React, and will only work for companies that use React. React is the best.

Also, XML is the pinnacle of communication. How many conferences have I been to on it? I'm going to be using XMLSpy til I die!

- you, if you'd been born 20 years earlier

> There is no post-React

Oh, you sweet summer child.

This is quite a reactionary comment.

I imagine the career growth would have happened regardless of which framework became the new hotness. That is, any framework with similar usage/growth would have done the same. I've just seen the pattern too many times.

Maybe, it's hard to say. Whether or not it caused it significantly or how it was involved, the "react era" has coincided with a huge increase in demand, pay and respect for front-end specialists.

A whole webdev cohort came up on and with these technologies, were taken seriously because of their mastery of them, and have moved into areas of tech and engineering that would have been absolutely off-limits to "mere" html/css developers.

I'm not willing to claim that react alone made that happen, but it's not at all clear to me that it would have without react having the timing, momentum, and cachet that it has.

No, the career growth happened in 2015 when we adopted React and stopped endlessly inserting JS and CSS tags from jQuery plugins. Backbone made things worse. Angular made things worse. React objectively changed my life and allowed me to work several remote jobs at once. I watched half a dozen startups adopt React for the better. There is no similar growth or usage to React. React is the king.

Sounds like a religious experience.

Exactly. The first time I observed this it was some Perl/CGI framework who's name I've forgotten. Then ColdFusion, then COM, PHP (Cake, Zend) and on the front there was that hotness before jQuery (which I've forgot), jQuery, that other one for a spell and now React.

Loads of people board the train at the most recent stop and are amazed how "fast" it's going.

At least with surfing all the waves are different - in web-tech it feels like the same wave over and over.

Just wait (shakes cane) it'll happen to you too.

> there was that hotness before jQuery (which I've forgot)

Prototype and Script.aculo.us? I remembered being in Prototype camp because I deemed jQuery to be too different (and in a hindsight, that was one of my worst decision in tech)

There's also YUI, MooTools, etc.

> Script.aculo.us

Yes. Thank you!

What does one have to do with the other? React may have helped you with your career but that doesn't mean it can't be a monstruosity

Yes. Winess Java.

> Vue is like 10x better imo

That's very much here and there, and ridiculous. Vue offers an interface that is extremely heavily transpiled and modified before it actually resembles code that can run on the browser, and uses an entirely magic (read: opaque) rendering system, making performance analysis quite difficult. React offers a thin layer on top of JavaScript - look up what JSX actually does if you feel the need to contest this - and offers clear semantics on how a component will evolve over its lifecycle. Plus the TypeScript integration is way better.

So now back to your point: what are you criticizing about React? That you want the batteries included? That you think the vDOM is too heavy? If you're praising vue, I can't imagine you have a single legit criticism

> too many folks' livelihoods is directly tied to React for a serious critique of the monstrosity it turned into

If other libraries were actually as good, they would take over developer mindshare. They're too thick and with too much magic you can't control, React is on the exact opposite end of that spectrum with being thin and unopinionated outside of its core semantics. Which is the right end to be on, and the reason it is winning the developer mindshare war. Not because of sunk cost fallacy.

> React offers a thin layer on top of JavaScript

I think you've completely missed how much "magic" react really does behind the scenes. I guess the most recent example being strict mode and confusion about why console logs are appearing twice in the console when a component only appears to have rendered once.

> If other libraries were actually as good, they would take over developer mindshare.

History shows us that out of two options, the early option usually trumps the more thought-out option.

> I think you've completely missed how much "magic" react really does behind the scenes. I guess the most recent example being strict mode and confusion about why console logs are appearing twice in the console when a component only appears to have rendered once.

Though that decision was wound back, as it was the wrong one to make. The idea of "modes" in general was wrong-headed, according to the React team themselves.

Oh no, they rendered your component twice to make sure it’s idempotent, how magical!

Tell me where react uses magic instead of well defined semantics and maybe I’ll agree

> the early option

Angular and React were around at virtually the same time. A million JSX using libraries promising performance or DX have tried and failed to gain meaningful traction. Early adoption has nothing to do with it - React is the right abstraction for UI dev and is more terse and easier to reason about than any other framework today.

> Oh no, they rendered your component twice to make sure it’s idempotent, how magical!

The problem with trying to check if the component is idempotent is that React can't actually verify that the component is idempotent.

It could have a simple inconsequential non-idempotency like a console.log statement, a larger non-idempotency like pushing a request, or a complete non-idempotency like relying on non-deterministic behaviour and just happening to get the same result during the idempotency check (what's worse is that sometimes this is caused by invisible data races leading to heisenbugs).

Trying to check for idempotency in a language that has no language features for verifying pure functions is bound to failure right from the start.

> Angular and React were around at virtually the same time. A million JSX using libraries promising performance or DX have tried and failed to gain meaningful traction. Early adoption has nothing to do with it

Angular does not use JSX. AngularJS lost because it fell out of support. Angular lost because only enterprise developers trusted Google after the burnt bridge of AngularJS. While I would agree that React is mostly better than Angular/AngularJS, it didn't become popular based purely on its quality relative to Angular/AngularJS.

> React is the right abstraction for UI dev and is more terse and easier to reason about than any other framework today.

Terseness does not equate to readability nor comprehensibility. Speaking of alternatives with better DX, Vue looked at the successes and failures of React's Hooks implementation and DX and improved on the model with it's own form of magic: Vue 3's Composition Api, meanwhile SolidJS removed the magic all together while making the code function how developers expected it to.

> If other libraries were actually as good, they would take over developer mindshare.

I don’t think that is true. We’ve seen plenty of examples of superior technologies not being adopted for various reasons.

> Vue offers an interface that is extremely heavily transpiled and modified before it actually resembles code that can run on the browser, and uses an entirely magic (read: opaque) rendering system

Not entirely true. If you're looking to code that "resembles code that can run in the browser" without that much "magic", Vue has an interface for directly declaring render functions, also for the possibility of using JSX.

See doc here: https://vuejs.org/guide/extras/render-function.html

I don't want to get in a whole Vue vs. React thing here, and I'm no megafan of Vue, either, but I just think it's a lot better designed than React. In fact, I mostly still use React because, hey, just about everyone knows it.

> If other libraries were actually as good, they would take over developer mindshare

This is incredibly naive. React's sole success relies on Facebook heavily pushing it in the conference circuit. "How React Saved my Life" was the go-to talk title in the 2010s.

> This is incredibly naive. React's sole success relies on Facebook heavily pushing it in the conference circuit. "How React Saved my Life" was the go-to talk title in the 2010s.

I was around when React took off. People may have been aware of it because of marketing, but every web developer I know wanted to immediately switch to it, even before class components, because it represented a fundamental paradigm shift in how web applications would be built, and it was self-evidently better than anything else anyone had thought to suggest.

The was a popular talk because _it was true_. React changed frontend web development from a tedious chore offloaded to the junior-most members of your team and elevated it to something everyone takes seriously.

It was a very, very long time before there was anything useful competing with React. Nothing really started to compete with the sheer volume of people who wanted to work with it until JSX proliferated across the frameworks. Just JSX alone was enough to convince people to switch to React.

FWIW, my initial interest in React had _nothing_ to do with Facebook at all :)

My first web app was built with Google Web Toolkit (GWT) back in 2011-12. GWT was a Java->JS compiler framework, and I used an additional library called SmartGWT that provided desktop-style widgets. It all did work, and let me use my existing desktop dev skills to build a web app. But, it also had a lot of pain points.

From 2013-15, I built a JS app using Backbone. Backbone's flexibility was great. On the other hand, it _also_ had a lot of weaknesses that I ran into over time. Nesting child views was really hard. There were a dozen ways to trigger events. You could use plugins to add functionality, but many were incompatible with each other. It had no rendering capability out of the box - you usually had to use something like Handlebars to generate HTML from templates (although in my case I used an addon called Epoxy for data binding). It had no lifecycle methods built in, although Marionette added that.

I started looking at React in 2015 because I wanted to rewrite that GWT app's client (no one else on my team by then knew GWT). I heard about React, started going through the docs and some blog posts... and saw something that solved basically all the Backbone pain points I was experienced. Natural composition of any components by passing props to children, children notifying parents via callbacks, automatic UI updates just by re-rendering, lifecycle methods... it was clearly just an infinitely better UI development paradigm than Backbone or GWT, and switching was a blindingly obvious choice to make.

For me at least, Facebook never even entered into it.

> React's sole success relies on Facebook heavily pushing it in the conference circuit.

LOL, yes, I started using React because I spend all my time at conferences, just like 100% of the millions of people that develop in React. I'm the naive one, eh?

> LOL, yes, I started using React because I spend all my time at conferences, just like 100% of the millions of people that develop in React. I'm the naive one, eh?

You're using it because you probably Googled "good javascript library" and got sent to a blog, you saw it in a talk on YouTube, or because your coworkers/friends are using it. And React has a lot of content because it was heavily pushed in the conference circuit, where people live blogged, tweeted, and so on.

I don't even think my point is particularly controversial, companies literally do this all the time (Angular was pushed almost as hard). Facebook just happened to also be a very developer-friendly and hip company last decade, so folks really drank the Kool-Aid.

I actually have developed web UIs for 9 years professionally and remember evaluating Angular1 vs React. In angular I built an app with tons of great features, but React was far more terse and honest about how things work because there were not really big DSLs or magic features, instead you built trees of JS objects that used the pretty thin JSX syntax to accomplish this. I admit JSX was of course exactly a DSL in some small ways but primarily it was just more terse and semantic.

When you think about major UI frameworks, the fundamental concept of composition is clearly key. State is the other idea at play, and their interrelation needs to have obvious life cycles to be predictable. React accomplished this as well in a very intuitive fashion that is also exactly as performant as you can wire a VDOM based approach to be. The react team’s foresight and rule based approach continues to be cutting edge with hooks, as they are more honest and terse than class-based components.

Finally, wiring up my favorite state library mobx gave me free render optimization and incredibly smooth code authoring capabilities all for one. This was around long before hooks, but still remains top tier as well.

Kool aid is both a poor drink and a poor representation of why I chose React and continue to enjoy building applications with it.

You chose to evaluate Angular1 vs React. But the information about React came to you based on Facebook's marketing of React...

The man wrote that koolaid was the decision maker, but I had literally built a high quality SPA in its main competitor before evaluating it and seeing for myself it was better. The “marketing” was being done by others like me on sites like this who had made the same decision because it was a simpler, better conceptual mode than the other web frameworks offered. Can’t believe your takeaway from “I professionally evaluated it” was “the marketing got you”, but that’s shockingly the level non UI engineers talk at thru thinly veiled superiority on threads like this.

I’m in disbelief you think a decade of one front end framework dominating software engineering of all fields is due to advertising, and not because it presents an incredibly powerful abstraction with a terse interface requiring far less magic than any other major web front end library. Pure disbelief.

I think the OP means both quality and promotion are important to a frameworks adoption.

Promotion helps it to be known, tried, given feedback, improved and loop to grow.

There is no discussion of quality. The claim is nakedly that React isn’t at the top tier and it owes its success entirely to marketing and not at all to quality. Developers have been drinking koolaid for years.

Show me where they said otherwise and I’ll walk back my tone; I don’t expect to

I would walk it back because we're talking about JavaScript, not anything important enough to get worked up about with someone.

I will plainly speak however I wish to non web engineers telling me I drank koolaid in my selection of libraries, and that marketing is the only driver of the general decision making around such libraries

It’s just plainly absurd. In front end, it went from Java -> JS transpilers to vanilla JS and jQuery to ideas to Knockback and then finally to React and that generation of frameworks. Somewhere in here TS became non negotiable and so we write strictly typed front end code on top of high quality libraries.

Meanwhile, backend guys come in and act like they know about how this went, it was just Facebook and Koolaid - those web guys don’t think for themselves. They were dictated to.

What a joke.

> backend guys come in and act like they know about how this went

I'm getting the impression you think this is West Side Story: Software Edition, and that you think other people are aware of this. It's just some individuals talking about a very abstract topic. Nothing to get upset about.

I get very upset at the idea that Koolaid dictates front end development. It’s the same backwards superiority from backend devs as I saw a decade ago, except their languages and frameworks have barely meaningfully progressed and they still like to shit on UI dev, like their work is somehow more valuable than it.

> the same backwards superiority from backend devs as I saw a decade ago

Again, even from observing you in this thread you've decided one comment represents all backend developers. You probably made the same mistake a decade ago. It's not us vs them. It's just some individuals talking.