> I'm still a bit steamed from being gaslit all throughout the mid-2010s

I get downvoted into oblivion every time I criticize React on HN (I mean, for one, Vue is like 10x better imo, but that's neither here nor there). Just too much money is poured into getting people trained on React and too many folks' livelihoods is directly tied to React for a serious critique of the monstrosity it turned into.

Facebook really did take over the world.

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.

    I'm still a bit steamed from being gaslit all throughout the mid-2010s years when we were told <div id="root"></div> + SPA was The One True Way of building web applications. 

omg. tell me about it. One CTO I remember flat out getting angry that his reason for using React was because Facebook was doing it. that's it

We are going to see more reversion to '05 days, with financials of SaaS as interest rates rise. I remember one CFO getting mad because spending $2 to make $1 doesn't make sense as an enterprise company and that his reason was because we are in a new economy.

Perhaps I'm extrapolating but it seems that the boring, predictable and old is that way because it's been through market manias, both financially and technologically during periods of novelty recycling.

> One CTO I remember flat out getting angry that his reason for using React was because Facebook was doing it

Lol.

I find it ironic that from a developer standpoint, we're quick to jump with the latest FAANG libraries/cult thinking paradigms, but especially here on HN, we're equally quick to show the hate for those very same companies. Personally, I've found that all FAANG software is generally a good reason to not use it! (My solutions are all bricks and mortar sized, rather than oligarchal/massive advertising globalist farms)

I love the smell of ASP.NET and Telerik in the morning...

that's unfair :=) asp.net core is completely different beast compared to asp.net

I think this is a bit disingenuous and misstating (or not understanding) the evolution frontend-focused web development has been through over the past 10 years.

There’s no pendulum swing back to server-rendering, but rather new frameworks and techniques that involve both in unison.

Yeah I feel like every day there's an article on HN about how we're moving back to the old days without client-side frameworks. Except that's not true at all. People are still writing in React/Vue/Svelte, but now there's tooling that allows it to run on the server as well (SSR). Client-side frameworks are playing a bigger role than ever before. And there was no gas-lighting in the 2010's, SPAs are still here and many still use <div id=root>, even with SSR.

We are seeing a bit of reduction in client-side bloat due to bundlers and compilers like Webpack or Svelte, but the value of client-side frameworks was never to add bloat to the client anyways. It was always about making it easier to write complex user features. So they provided things like better composability, better state management, etc. So when tools come along that provide the same benefits, while reducing client-side bloat, then of course the industry starts moving.

I think there's also a slight sampling bias in HN because 90% of the posts here are articles and blog posts, both of which can be written in static html. So of course there's going to be blogs boasting about how they got away without a javascript framework. But the majority of internet users aren't browsing blogs, they're spending time on big web apps like Facebook and Youtube. And those web apps benefit greatly from these frameworks.

Yep. It's very convient to pretend that we jumped from Apache template-includes to React, but there was a messy time in between where client-side rendering with jQuery was extremely popular.

No pendulums are swinging here. What's happening is refinement and variation between two extremes.

Yes.

I remember reading that this latest approach is only really viable because of the use of HTTP2 for the requests and the adoption of that technology.

The swing towards frontend made sense before this step change in latency.

AJAX was originally about speed, but as soon as it changed from fetching and injecting HTML fragments, to fetching data (usually JSON) and performing a bunch of transformations and interpretations of it before finally modifying the DOM, it's been in practice slow as hell compared with traditional server-side rendering.

Totally agree.

Doing everything on the frontend is great for making the UI feel responsive, but once you start grabbing large amounts of data from an API, manipulating it on the frontend while keeping it in sync with the server, you run into some major headaches very fast.

Isn't that how pendulums swing?

Ugh. Even reading this article. There’s always a The One True Way, even though there never really was. The right way always depends on the desired result.

Too pragmatic, you'll never get clicks that way

Pragmatic? I'd call it too generic. It's about as good as "a man's got to do what a man's got to do" as life advice.

Yes, there's no "one size fits all" and there are exotic needs, but there are certain good ways to build web pages that fit a vast majority of the use cases, and on the other hand, there are fads and hype.

>1 Simple Trick To Adjust Your Attitude to the Task

> It's breathtaking to see the pendulum swing so obviously and definitively back in favor towards HTML-first and SSG/SSR-first solutions…

Has it, for you? The pendulum has not begun to swing back from where I sit, and I don't see any indications that it ever will.

>It's breathtaking to see the pendulum swing so obviously and definitively back in favor towards HTML-first and SSG/SSR-first solutions—to the degree that even the JS-framework-hotness-du-jour braintrust is going all-in on SSG/SSR.

The pendulum swings large due to under-educated (and I don't only mean CS degree in school) developers, now days the industry is fill with developer wanna be jumping on the band wagon, many if not most are not really interested in software development. SPA was created to split up front-end/back-end development to cater to these new bee 'front-end' developers. That way the only thing they can screw up is the front end. The way how these Reactive app does thing, makes it easier to split that up. Front end is client/browser, backend API. It make sense from management point of view. It is stupid from a true software developer point of view. SPA also allow to control what user can and can not do. e.g: Link that doesn't allow user to open link in another page. SPA became so popular that w3 even made what so called web components to try to be like React.

However, it is stupid to recreate browser rendering functionality in JS, and try to build desktop like apps in a document based system, even if V8 really made that fast by JIT compiling the JS.

I do like the 2 way binding the vars. And if I'm going to us a reactive app, I would use Solid/Vue/Mithilral before I event touch React/Angular with 10 feet pole.

It's not just that. Making one API that can be consumed by web and mobile was also a big part of it.

The SPA is definitely what you want i building an app like Google Sheets.

The grey area where the pendulum might apply is in more line of businessy kind of apps: email client or online banking are examples.

I think there is no pendulum though, there has just been a lot of choice in the last 10 years on all sides

Email client: Whether or not you wanted JS, your competitor works offline, retries better when connection is not good, persists emails without having to save, live refreshes emails when received, sends notifications, allows drag and drop to organize emails, autocomplete email addresses, works in SSO, have a nice text editor with spellchecking, autocomplete, bold and italic text. You lost.

Banking: your competitor handles nicely dynamic forms, with helpful field validation, asking users just the right amount of questions based on what you entered previously, without changing page, with a go back button just working great. They also live refresh transactions, provide some nice clickable spending graphs, have a nice live dynamic wire confirmation system provide in-website live chat with your advisor. Their session doesn't expire every 15min for security reasons. You lost.

Actually I really love the old fashioned cubemail type interface. Faster to load, more predictable interface where opening in another tab is a thing. I am rarely in a offline situation and if I am I connect a traditional email client that apple provides on my iphone anyway.

Banking - again same kind of argument.

Non JS infused apps have a certain solidness about them. I think it is the predictability. An interactive site will have whatever original UX innovations that team came up with.

Case in point in HN you can paste arbitrary text into a comment without it fucking up. Impossible on Reddit! If I paste there the comment box is now forever fucked until I reload. I need to do the old notepad middleman trick.

Your you lost comments are odd, it is horses for courses always.

Cubemail is 80% tinymce and queryui on the rendering front. We have different sensibility, Having notifications / autorefresh / working on mobile is more important to me that a predictable, static and stale interface.

About the copy and paste situation, having implemented a text editor myself, JS is of great help to handle copy and paste. Just letting the platform do what it does via the text entry of the copy buffer has some underwhelming behavior that are seen as bugs.

Copy and paste in JS is very hard. It is like 2004 style writing code for each browser.

The good thing about scripting it is handling images on the clipboard. But Reddit: please invest in making it work and not regressing!

If you just need plain text then native HTML works fine. Never had issues when the JS is not interfering.

This is admittedly off topic, but how did the term "gaslight/lit" become so common in recent years? I had never heard of it until several years ago when someone close was going through therapy regarding a loved one. Now, it's like I'm shopping for a mattress and I'm being inundated with mattress ads.

That's not to take way from your experience or suggest it's not the appropriate word, I'm quite sure it is. I'm just curious if I was really oblivious of concept before my own exposure to it, or if it was called something else?

The term "gaslighting" derives from the 1944 film Gaslight, in which a husband uses trickery to convince his wife that she is mentally unwell so he can steal from her.

Gaslighting was largely an obscure or esoteric term until the mid-2010s, when it broadly seeped into English lexicon.

https://en.wikipedia.org/wiki/Gaslighting

You might be a fairly 'protected' person. This is one of the ways unscrupulous managers try to get you to do things that are detrimental to you yet beneficial to themselves/the company - to get you into a state of self-doubt and misery so that you'll make the decision yourself.

One way to get around this is recording everything you do and feel on a daily basis. Otherwise it's one claim against the other.

Historically, it's similar to the way women try to control men since they're not as physically competitive - if you've seen chinese dramas featuring an emperor and his wives it always boils down the cliche of 'oh but it's for you, the emperor's sake' or something like that.

I don't want to further derail this thread by bringing politics into it, but let's just say that the term suddenly started being used a lot in news headlines starting in around 2016:

https://www.salon.com/2016/10/16/donald-trump-as-a-gaslighte...

I don't know but Google Trends [1][2] bears out that it's very recently common.

My best guess is that it has come up as part of the Amber Heard / Johnny Depp trial and that has spurred a lot of people searching for it.

[1] Past 5 years, March & earlier - https://trends.google.com/trends/explore?date=2017-03-01%202...

[2] Past 90 days including giant spike - https://trends.google.com/trends/explore?date=today%203-m&ge... (if you go to past year you can see the spike)

"gaslighting" has a steady upward curve the last 10 years.

My personal guess is that it has to do with psychology and mental health awareness going mainstream due to social media and psychology channels on YouTube.

https://trends.google.com/trends/explore?date=all&geo=US&q=g...

I have also noticed this. It feels like gaslighting has become the new "literally".

But "gaslighting" and "literally" fill completely different semantic niches! I feel like you're literally gaslighting me by suggesting that. /s

I used to work on an single page application that was pretty complicated with heavy DOM updates. In the team, we wanted to investigate at the time if React could help us with some performance bottlenecks. However, I remember very much with that buy-in with JSX didn't appeal much to me. As we started to write more code against it, it was okay.

On reflection though, I don't think React would have helped to solve the problems we thought we had. I only tried to see it as a solution to a problem, not seeking to use it to be part of a sub-industry around this library. But, even as I write this, I get a recruiter email asking for React experience. I have not followed it much for a few years, but using React now doesn't seem to fit the exact problem it tried to originally solve anymore (if that problem even matters now) but is a completely separate thing. But I really don't care anymore, because I don't work in any focused frontend web development now.

I wrote something in plain JS a couple of weeks ago, up to a point where it was generally useful for myself for my work. It was wonderful - no crazy complex toolchain, no React to deal with, just html and some JS to do stuff. Doing the simplest thing in a new project (no extraneous toolchains if you can help it specifically) should be the first thing to do. This is not a fad, it's just taking stock in the time you have to make usable programs.

I love that some of us are all having a similar experience at the same time. I'm writing something small and I just include an htmx script tag at the top of the file and get going. It's amazing how fast something is when it's just selecting exactly what it needs from the DB and sending prerendered html to the browser.

> being gaslit throughout the mid-2010s

This is exactly how it felt to me.

“wildly simpler stacks” [citation needed]. With a framework like rails you still have a front-end and you still have to solve for interactivity — unless you’re building a rudimentary CRUD app. There are modern alternatives that attempt to hide the interactivity by baking it into html attributes via a DSL, but JS is still there.

I would argue that a client-side only SPA is very simple from the lens of how it is deployed: drop the files in an S3 bucket. There’s no need for a server and from that perspective, an SPA is actually a simpler stack.

Most of the web is just CRUD apps, be it php, rails, cgi calls, <your favorite language>. And no one is saying get rid of JS front end stuff, it should be used to enrich and not hinder.

> drop the files in an S3 bucket

If you have a completely static site you still shouldn't host of s3, that's a big no no.

S3 isn't a CDN; you want a CloudFront or something else in front of that.

But as soon as you need something more your gonna get lost or locked in.

> Most of the web is just CRUD apps

I disagree, pages for web apps don’t just CRUD one entity, they mix and match many entities in complicated ways. Also, I was referencing rails auto generated crud pages where there’s a single form and a single entity table.

If that’s all that’s required then kudos but rarely has that been true for the companies I work for. I wish it were true.

Mixing and matching a C(reate) or U(pdate) api call into a single request is exactly why its better. Logic can be checked, verified, confirmed, denied and rolled back.

Multiple entities with multiple endpoints are harder, if not impossible to enforce.

> And no one is saying get rid of JS front end stuff, it should be used to enrich and not hinder.

Having separation between the HTML on the server side and the JS on the frontend side is exactly why React become popular.

Personally, I don't want to go back to the PHP+jQuery days. I want one language and one framework to handle both HTML and JS interactivity.

> Having separation between the HTML on the server side and the JS on the frontend side is exactly why React become popular.

But did they really. Cuz now i see .jsx files with sql calls, adding in static js and css, and logic with mixed html in... Its honestly blowing my mind how we got to this point.

We all agreed biz logic, and view should be separated. and that html, css, js should also be in sperate files. and then .jsx or the like came along and merged them all back together in some of the ugliest code ive seen in years.

> Most of the web is just CRUD apps

And most of that doesn't need to be.

Now that the Web Platform as a whole has gained so many amazing features and quality-of-developer-life improvements, I think the pendulum was always going to swing back. <div id="root" /> was the "one true way" in the early-mid 2010s for a reason.

But now we're all thinking in terms of components already, so whole-pages-only is not needed -- serve up partials only, and have your thin JS layer combine them all.

Use the platforms features for as much interactivity as it can get you, for UX/UI reasons, and then use small amounts of JS for those things where you can't.

It's quite nice! Though I still make my bread and butter with the <div id="root" /> as it currently stands. We'll see if that changes.

Hilariously, in 2016 I tried to push a "front-end web server that consumes the API and gives up HTML/HTML partials" idea that was this exact pattern, but could not get enough buy-in at the place I was at. The tools weren't quite there, so we'd have to build a lot of them ourselves.

Now, the tools are built (or being built)!

I've always felt that it was a bit of an odd decision to put all of one's eggs in a basket that you don't own or meaningfully control (the client). The client's basket will need to hold some of your eggs sometimes, that's unavoidable in some cases, but it makes perfect sense to put as many of your eggs in the basket you do control (your back end).

I always felt the opposite was odd. Server side rendering felt like an odd hack due to the limitations of the platform. Imagine all you had was a PDF reader - then it would make sense to construct an application by building PDF files which contain links to other PDF files. But otherwise, why not write an actual client program that maintains its own UI state and have the server take care of what it does best - provide the data?

Would you build a CLI (ncurses style or otherwise) application by fetching the TTY codes to render the current screen from a server for most user interactions?

That makes sense when the client is always a known quantity, but such is not the case with the web. While you can get an idea of what the majority of your target audience is running, there's always going to be some percentage that will be left out when writing client code for the majority browser only. There's always going to be client situations that you can't predict much less write for, and in those cases more server-heavy solutions tend to do better.

Is a traditional desktop client really a better-known quantity than a web browser these days?

The more your app can run client-side, the lower your bills server-side.

And yet all client-side frameworks like next.js, remix and others are literally moving to server again, making you even more tied to serverless stuff.

I think what can make some of the rhetoric around it all seem so surprising and frustrating, is because many of the proponents started their careers with the paradigm already shifted toward frontend SPAs. I started my career with the paradigm shifted toward backend templating frameworks, and when SPAs came around I remember seeing some of the old-hats with the same surprise articles like this exhibit, as we had never experienced GUI frameworks before, where they had.

I have an app which was built 10-ish years ago using C# and which I rewrote using rust - in almost no-JS, fully server-side style. (I somewhat factored out the web framework that I ended up with - https://github.com/ayourtch/rsp10)

After reading this article I sent it to a coworker “hey if I wait for another couple years the style this app is written in will be all the rage again :-)

> I'm still a bit steamed from being gaslit all throughout the mid-2010s years when we were told <div id="root"></div> + SPA was The One True Way of building web applications.

Cult-like behavior with a healthy dash of resume driven development. All it is. They tend to be the loudest people in the room and so then management says, okay, do this.

The One True Way will always rise up and claim its victims, especially the inexperienced and/or naive amongst us.

I sometimes think TOTW is actually an ancient one that thinks Cthulhu is an infant.

SPA has been web's response to native mobile apps.

> The One True Way of building web applications

To which I usually answer: I'm building a website. If I want an actual application, I don't consider hypertext with macros as a viable option.