The rise of React | Hacker News Reader

The rise of React

increment.com

220 pointsprostoalex164 comments

Props to the people who have been managing the project. I have done a lot of React in the last 6 years and have never been frustrated with their decisions, which is very rare.

I think beyond the technical aspects, the way React evolved over time was really on point. The roadmap has always been very well designed and the literature around new features and deprecated ones top notch.

The way React is used has changed completely, but at no point did I feel upgrading was too costly and ended up stuck with an old version.

Is “props” a pun? If it is...I appreciate it * snap

Nah, I just wanted to state my appreciation.

Good to know; my uncertainty was mounting

Did it mount ?

We now only useEffect for this kind of events.

This comment rendered me speechless.

If you use hooks it's less verbose, you can just return speechless.

> I have done a lot of React in the last 6 years and have never been frustrated with their decisions, which is very rare.
Same, but this is also why I feel burnt by create-react-app. There's so many important features the team has simply decided it won't support. One of the biggest issues with the React ecosystem is that there's nothing in between training wheels (CRA) and a motorcycle (rolling your own config). Maybe there's an opportunity for a new project there.

to be honest, Id say the next level abstractions(gatsby and next) fill that role. I can’t think of a SPA alternative though

I totally agree. If you need access to one config variable CRA doesn't support out of the box, your only option is to eject. I really wish there were the option of just providing an "overlay" file that only had your changes from the CRA defaults, rather than being forced to eject the whole config.

See sibling comments for solutions to do exactly that.

I think there's a couple repos that provide exactly that - a webpackOverrides.js file or something similar.
I also think that next.js might have some of what the gp is interested in

I can only second what ht85 said in a sibling comment.
I have the same complaint, but this is definitely possible using e.g. react-app-rewired.
Adding custom webpack loader rules is as simple as replacing the calls to react-scripts with calls to react-app-rewired and adding a .js file with your customizations.

There are multiple existing third-party tools in the ecosystem that let you do exactly that:
- https://github.com/gsoft-inc/craco
- https://github.com/harrysolovay/rescripts
- https://github.com/timarney/react-app-rewired
- https://github.com/arackaf/customize-cra
No, they're not "officially" supported, and you basically void the warranty by poking the configs manually, but the tools do what you want them to do.

Thank you, this list is much appreciated.

But I think that is the problem. Since there are many ways to do it, you will have to evaluate each one and hope the one you pick gets upstream updates.

I'd go with `craco`, personally.

Not sure if I understood you correctly, but if I did then you can use react-app-rewired https://github.com/timarney/react-app-rewired

From the official docs: Alternatives to Ejecting.
https://create-react-app.dev/docs/alternatives-to-ejecting/

I've has a lot of success using react-app-rewired to do small changes to the webpack config.
You avoid ejecting and benefit from upgrades to CRA, but you can customize anything you like.
There's a `customize-cra` lib that provides useful helpers that you can use to perform the most common operations.

> to do small changes to the Webpack config
90% of the reason I eject CRA. rewired is essential.

"there's nothing in between training wheels (CRA) and a motorcycle"
AFAIK the "betweens" are Next.js, Blitz.js, Gatsby, Remix, Expo, etc.

I like Next.js quite a bit but I don't need SSR. To expand upon my use case a bit: I need a way to create dozens of small SPAs in an enterprise environment maintained by people who are not front-end experts. CRA fits the bill almost perfectly except it makes certain Webpack/Babel configs unavailable that make my life very difficult. The token response from the CRA team tends to be: we don't think you need this, fork or eject.
Eventually I'll end up maintaining a company fork. It's more work for me but that's life. It's really just the dogmatic attitude of the CRA team that irks me.

CRA focuses on the very basics, so it's probably not suited for your problem.
Can't you switch Next.js to SSG for all routes since v9?

CRA is exactly suited to my problem: these are simple React front-ends. I don't want any sort of server-side rendering. I don't need any of the features from Next.js. I just the ability to modify some of the basic configs that are hard-coded in CRA for unclear reasons.

When there is a clear case of use like this, the usual procedure is to create and publicize your fork.
If enough people start using it, the original maintainers will see the need it covers, and hopefully will get rid of their dogmatic attitude, seeing how real people are adopting the approach they found no value in.

Also, there may very well be forks already that are used by many people that allow to do what they want.

Check out craco, for overriding specific bits of config without ejecting:
https://github.com/gsoft-inc/craco

I've been using craco. I really commend the creators but it's a project that shouldn't exist. I shouldn't have to hack the officially supported solution to do simple things like provide my SSL cert to Webpack or tweak some Babel config.

I tried to start with React 5-6 years ago but got burned with WebPack complex config and scarce docs. Went back to it with Create React App 3-4 years ago and I'm in love, I don't ever want to go back to building complex apps with jQuery.

I feel the same way about React. Out of all of the current choices I feel like React is not only mature but very useful.
The only thing that really ever irked me is the weird LICENCE clause about patents but that was addressed.

I prefer to use it as a rendering library only. That part is good. But much of the ecosystem is a mess. CRA, a fundamental piece, is a trainwreck. If you eject you can see how much focus on local simplicity has been implemented at the expense of global stability...

This article was great…up until the very end when it failed to mention any alternatives to React that already exist.
"Alpert, who helped chart React’s rise, doesn’t see an alternative emerging anytime soon."
This is completely ridiculous. Vue, Svelte, LitElement / Web Components, to name but a few. Maddening to see this level of journalistic malpractice.

There are alternatives to React indeed, but those you mentioned are conceptually very different.

Vue has also JSX as optional for the template system. you can see react as a subset of Vue.

"journalistic malpractice" - he's merely passing on the sentiment of the main subject of the piece.

Is it really that maddening? This response feels much too political. There are things worth getting mad about, and then there are JavaScript frameworks.

Also, why does everything have to be so radicalized? "Journalistic malpractice"? It's hard to have earnest discourse in 2020 for this reason. People often push everything to the extreme immediately.

Pushing debate to extremes is as old as humanity. I don't see any evidence to suggest that it's gotten worse recently (certain countries recent political increase in extremism notwithstanding).

The writing could be improved, but to me it's clear that the previous paragraph is providing the context for this statement: they're talking about alternatives to using frameworks that provide a higher level of abstraction. Not alternatives to React itself.

I could see that interpretation. It's not very clear to me though…

(Sophie Alpert here.) What I meant is it’s not clear the next thing that will _replace_ React.
Certainly there are plenty of great alternatives, each with their own pros and cons – but at this point, none clearly poised to “take over”.

I appreciate the clarification Sophie. :) Sometimes quotes just don't come through well in translation in finished articles.

As someone who has been in the industry for a dozen years, and been an engineer or managed engineers at companies of different sizes, I love React. Some benefits:
1- It has bridged a previously large gap between FE code and BE code, and hence, made it a lot easier for engineers who aren't FE-specialists to build frontend code. I've found that backend engineers are a lot more willing and able to write React code, since it just feels more like the type of software they're used to writing.
2- It has brought concepts like functional/declarative programming much more center-stage. Prior to React, most developers might get a taste of declarative programming if they used SQL, but not in their day-to-day. They might give something like Scala a try, and either join the cult or turn around and run away screaming. React made these concepts a lot more accessible.

I'd also add that if you don't like React, but haven't tried it in a few years, you should give it another shot. It's still not perfect, but recent additions like hooks have been able to cut out a lot of the pain points it used to have. Even just using React with Typescript makes it easier and more robust (vs the old PropType syntax.. And yes I know you can use both but for 90% of use cases you don't need to).

Peter Hunt, one of the original creators of React, was heavily influenced by David Nolen from the Clojurescript community. So we have Clojure to thank for the return of declarative programming.

Meh, React is great for more reasons than modularity. One way data flow combined with automatic updating and rendering is really really nice. I just wrote a simple UI for a terminal and having to manually call a function to paint to the screen felt rather...quaint. We've had modular templates for years. It's only recently that we've had the ability to think of UI elements as functions that automatically get called when their arguments update.
This article also doesn't delve into why Facebook supports React so much. Or why Twitter, Reddit and the rest are switching to React. The answer being that React lets developers make really smooth, really addictive websites. I wouldn't be surprised if there was some studies showing that any flash of unstyled content, i.e. a server render round trip, lowers conversions by x%. Therefore having a client side app is imperative if you care about having your users on your site. Multiply it by Facebook's revenue and paying the few million to fund a team of developers is a really good deal.

> One way data flow combined with automatic updating and rendering
React did not bring that. Flux, released a few months later, brought the unidirectional data-flow to it; we were already building similar architectures using event buses, though with looser abstractions. The 'automatic rendering' is a bit deceptive. Unless you manually optimize it, React will simply re-render everything all the time which is the same as calling `App.render()` after every data change.
> React lets developers make really smooth, really addictive websites
As someone who has been doing it for a decade, I don't see an inch of a difference. Browsers got more capable, our tools got more sophisticated, but there is nothing really you couldn't do a decade ago. If anything, React leads to bloated and inefficient SPAs.
> any flash of unstyled content, i.e. a server render round trip, lowers conversions by x%. Therefore having a client side app is imperative
There is no 'round trip' for server render, it is the exact opposite - a client-side app will have no content to show in initial render until it boots in the client. Hence you need SSR + hydration to make it faster.

Did Flux really bring one way data flow? Because that's a pretty essential part of React. Even if React adopted it later, it's a core part of React's appeal.
Do you legitimately see no difference in websites from 2012 and 2020? I'm honestly baffled if that's true. Payments are a massive difference that I've noticed. Every decent ecommerce site these days uses quite a lot of slick tricks to make the purchase flow really easy. Whether it's autocomplete based on Google Maps address data or being able to do everything without any obvious page refreshes, payments are significantly slicker. React definitely facilitates this.
> There is no 'round trip' for server render
Uhh there is a round trip. You click on a link, the new page does a request, loads new HTML, new CSS and paints the new page. Sure, an SPA takes longer to load up front, but you can now ensure that everything past that point is seamless. On a site like Facebook where the initial load won't kill conversions (because people are already addicted), you can take a 500ms hit so that stuff like infinite scroll and seamless notifications keep people on the site.

>React will simply re-render everything all the time which is the same as calling `App.render()` after every data change.
My understanding is that react will calculate the diff of your changes and what is already rendered and then only render the difference.

It will diff the virtual dom, but you'll still be running the `render()` method again for every component. That is, unless you replace it with a PureComponent that does shallow diffing, write your own `shouldComponentUpdate` (if still using classes), or use something like Redux that will actually manage updates outside of React's component lifecycle and take advantage of immutable data structures.

The only reason I choose React today is the immense ecosystem around it. With every other framework, even though the core framework is capable enough, it feels like I have to reinvent wheels, axles, and more.

> With every other framework, even though the core framework is capable enough, it feels like I have to reinvent wheels, axles, and more.
Curious, does that apply to Angular/Ember?

Agreed.
As someone unfamiliar with the JS ecosystem I find React to be difficult because it appears just as a UI library. I have to then choose between dozens of competing options for everything (local state management, API calls, forms, URL routing, etc) where as frameworks such as Ember (not sure about Angular) seem to provide those features out of the box using a consistent API as well as some structure.
I guess React is powerful in the sense that it will allow you to do this that wouldn't fit well with the structure and way of doing things of Ember/Angular, but that seems to be a relatively rare problem. In the majority of cases the structure and "batteries included" approach of Ember (and maybe Angular) would be beneficial.
I see a similar problem with server-side Javascript. You can use Express for the HTTP side of things, but then you need to bolt on an ORM (from a dozen competing options), configure it, etc. There is no "batteries included" framework equivalent to Django, Rails or Laravel.

I hear this a lot and it's really missing the forest for the trees. Picking a routing library (if you need one) requires 10 minutes of googling. Picking Ember/Angular will haunt you for the lifetime of your project.

Picking a routing library out of 10 competitors might mean that it becomes unmaintained (in favor of some other competitor) or will have bugs integrating with your other libraries.
With a batteries-included framework, as long as the framework itself is maintained I can be fairly certain that parts of it just won't stop working as long as I follow the release notes when upgrading (there might be minor changes here and there, but nowhere near the amount of work of switching to a totally different library because the first one stops being maintained).

> I guess React is powerful in the sense that it will allow you to do this that wouldn't fit well with the structure and way of doing things of Ember/Angular, but that seems to be a relatively rare problem.
I think that might depend on what you're trying to do. I'm guessing as you say you are unfamiliar with the JS ecosystem, that you were trying to do something relatively simple.
As a full-stack developer who does a lot of front-end dev, my experience has been that hitting against the limitations of Angular/Ember* is exceedingly common. Not "every feature I try to implement common". But "every project has 2 or 3 features that need the flexibility" common. This is enough to make avoiding that pain very appealing.
I haven't had the same problems with Laravel or Django (haven't used Rails). And I think a key part of that is that Laravel/Django are still "just PHP/Python". Angular tries to put the proprietary string templating language in charge of everything. Which is painful.
Also: Picking libraries is a skill you can develop. You learn to google for the N most popular libraries for a given task. Then search for blog posts comparing advantages and disadvantages. And check for recent activity / outstanding issues. It only takes a couple of hours, and you get a library which is more tailored to your use case.
* I haven't actually use Ember. Only Angular.

> Picking libraries is a skill you can develop. You learn to google for the N most popular libraries for a given task.
I'm not a js developer, but picking libraries based on popularity seems a dubious idea if a sufficient number of other people are doing the same.

> my experience has been that hitting against the limitations of Angular/Ember* is exceedingly common
In this case, it seems to be a problem with the framework if certain parts can't easily be overridden and implemented with custom code. But this is a problem with one particular framework and not with the whole idea of a "batteries-included" framework.
> Angular tries to put the proprietary string templating language in charge of everything. Which is painful.
Probably yes. I have not used Angular, only skimmed the Ember documentation, and what I'm talking about is mostly its MVC structure and the basics it provides like URL routing, models (which is just a REST API client in the background), templates, etc. I'm assuming most of this can be overridden with custom JS for the areas that don't map to its structure well enough.
> Picking libraries is a skill you can develop.
True but my point is less about the complexity of picking libraries and more that these libraries are at its core still framework-agnostic. They are designed by different people, with different goals, skills and opinions, which means there's potential for interoperability bugs if you are unlucky enough to be using the wrong combination of libraries. In comparison, with a batteries-included framework I am more or less guaranteed that all the "batteries" will play nice together and will have a consistent API.
The Javascript ecosystem also moves very fast so even if you pick your libraries at the beginning you might realize 6 months down the line that some became unmaintained or no longer interoperate as well as they used to.

> There is no "batteries included" framework equivalent to Django, Rails or Laravel.
The closest to those for JavaScript is Nest[0]
[0] https://docs.nestjs.com/

We use Nest. It's great, but it doesn't actually include things like ORM. It has good recipes for TypeORM, but nothing is really included.

Like everything else, start simple. React by itself can do everything you need it to do on the front end.

> local state management, API calls, forms, URL routing, etc
for all of these examples, React offers a vanilla way to do this, or you could use React + ECMAScript & polyfills to do this. there are definitely bolt-on libraries that do more with those but you can be fine with minimal dependencies on other things.
I feel like a lot of pain with React development is self-inflicted.

Agree with this. On a recent React side-project, I decided to try avoiding dependencies as much as practical, and building my own stuff. I've found the libraries often don't do as much as you think, and you'll spend more time customizing them than you would rolling your own. I think often I reach for a library because I don't understand how to solve a problem in react. It's better to first figure out how to solve the problem, then decide if you still want a library for it.
The only libraries I used aside from React itself were react-router (scars from dealing with the history API in a past life) and material-ui (not a designer.) react-router was a breeze, and I did end up spending a lot of time figuring out how to customize material-ui, but I still think it was worth not having to write my own components.
One thing that's key to this approach though is understanding the patterns your would-be dependencies use. For example, I did implement unidirectional state flow like in Redux. I just didn't use Redux. I also considered using a form library, but ended up just stealing some of its ideas.
Now where I do think libraries shine is on larger teams. Once you have a larger team, having documented ways of doing things, and the possibility of hiring people that already know them outweighs a lot of the costs of using libraries.

> everything (local state management, API calls, forms, URL routing, etc)
hooks, axios, html, reach-router.
my point is that if you start with the assumption that browser APIs are sufficient, there is a natural progression to your project and «taste» in supporting libraries to react

just curious, what does axios provide over basic browser "fetch"?

Browser compatibility

My experience with react with different: you have to spend a large amount of time upfront in order to get the basic features of a single page app. You burn a lot of mental energy figuring out which forms library, router library, etc to use. When it's time to upgrade, you have no guarantees that your libraries will continue to play together nicely. And quality and standards between libraries can vary dramatically.
I prefer the Angular approach. The initial learning curve is steep, but once you get over that, it becomes a rapid development framework, as all the pieces work together cohesively. The Angular CLI makes creating components, services, updating, etc a breeze, and helps maintain structure as your scale your app up. The core libraries (like routing, forms) are developed and maintained by Google, so you can expect a solid level of quality. The typescript-first approach means that your IDE can help you explore APIs, auto import, and work with third party libraries just as well. And the strong foundation provided by the core framework means that third party libraries have a better starting point upon which to supplement/extend.

I dont know how much has changed in the two years since I last touched it, but Angular's blessed packages and ecosystem were more of a time sink than anything else- the flex layout package in particular was substantially buggier than simply using postcss with what was at the time css-next (I think it is preset-env now?)
Additionally, baking in rx-js felt like a serious mistake- not only was there the roller coaster ramp up of learning angular, but helping others on the team learn rx-js on top of it while trying to be productive probably cut our output in half.
It didnt help that we had a mix of junior developers and experienced .net devs all learning at the same time- half the battle was explaining which feature came from ES2015, typescript, angular or rx-js.
Hindsight may be 20/20, but I am reasonably confident that we could have been significantly better off with react. Ember was never an option because they are only just now getting features react and angular developers have been taking for granted for years.

Yeah when I first started learning Angular I had similar thoughts "Why did they make this so hard?!?!?!" regarding RxJS. To be fair regarding Typescript & ES2015, you'd get that with React too (since in my mind you;d be insane to start something new in raw Javascript these days when Typescript has made our lives so much so much so much better).
Now though I find RxJS to be a really elegant mental model for dealing with asynchronous stuff. I wish there was more Reactive/Rx* stuff around in the things I work with. Its really nice.

I've had the opposite experience regarding RxJava. I really think "reactive" is an anti-pattern. Its made my companies code base much harder to reason about.

I never used the flex layout package. That's a third party library, and I think sticking with CSS grid + flex makes more sense. (Alternatively, you can just use bootstrap or tailwind or whatever.)
RxJS is actually one of my favorite parts to Angular, but it _does_ lengthen the learning curve quite a bit. Once you get past that, you can have amazingly reactive apps. One of my beefs with ReactJS is that it doesn't play as well with RxJS. Now that I think of it, you're not actually required to use RxJS with Angular: you can convert observables to promises (`toPromise()`).
I could see how having junior/new developers could make things a lot harder. I remember first learning typescript and having to keep the TS playground open at all times to see how it compiled to ES5.

> You burn a lot of mental energy figuring out which forms library, router library, etc to use
Why do you need a specific forms or router library? Those are both things you can do with vanilla ES2015+ and React.
The library problem is self-inflicted, but it doesn't help that search engines tend to boost a lot of half-baked Medium posts about why you should use slightly-nicer flavor-of-the-month library to wrap something really basic like the fetch browser API.

Same experience here with Angular - I have heard it described as "batteries included". It has basically everything you need to do 99% of all projects right out of the box (notable missing thing is something cohesive to properly manage application state in a nice way).
Takes a bit of effort to learn, but once you are up and running with Angular things are pretty fast to put together.

I think using managing state with an observable data service is a pretty good option w/o resorting to 3rd party libraries: https://blog.angular-university.io/how-to-build-angular2-app...
Alternatively, you could use Akita, which is built on top of this basic model, but offers a ton of additional functionality and the ability to use Redux Dev Tools.
Finally, you also have NgRX, which is based on Redux--but also adds a ton of overhead and boilerplate. I actually opted for Akita since it is way more ergonomic and offers most everything I need.

Yeah the "inject a state service into everything you need" is one way of doing it, but it gets messy and it tightly binds your components with that particular state handling approach (e.g. re-using components across projects might get difficult if you have a bespoke state service for Project A and you want to use A's components also in Project B & C etc). We also found that there are big concerns about which components are allowed to access and update which state - e.g. why does a tiny inconsequential GUI control used to copy something to a clipboard potentially get access to read and mutate the entire application's state? You can start sharding it up and put in "ACLs" of sorts ... but that is some of the messyness I mentioned :)
Not seen Akita previously - will take a look. Thanks!

But react did "reinvent the wheel", and it did it so well that it changed the way frontend development is done. When I look at what we had before, it feels even more innovative because it offered a simple interface to DOM manipulation and it took away all the struggles of doing that with jQuery or vanilla JS. To me it feels like such a simple concept that I'm amazed it took us so long to discover.

Isn't that a failure of the framework developers that not more stuff is in reusable libraries? When I did some Angular I thought that at 70% of the framework should be in libraries that are independent of the framework and reusable.

I think the idea was to keep it as a library rather than a complete all-in-one framework. It has it pros and cons

You need framework integration at some point; otherwise, you end up writing glue code for every single library you use, which is a huge waste of time. The issue is when some library authors don't separate the "core" part of the library from the framework integration, but that's understandable because 1) it's less work to only support a single framework, and 2) you can design your API around that framework specifically, as opposed to trying to make something generic (which often doesn't translate well to some frameworks anyway).

Yea, I'm a big fan of mithril.js, but I've moved over to React as my preferred framework primarily for this reason. The fact that the Clojurescript community has embraced it via reagent is a big factor as well.

Clojurescript with reagent and re-frame (or keechma, hoplon and others) outlasted two generations of Javascript technical churn. Nothing comes close.

Not really. Remember when people used Om for React bindings in Clojurescript? Clojurescript changes too. React has been around the whole time though.
Also, along the topic in this thread, I've never met someone who used Clojure/script. It's why I ended up just using Node/Javascript in the end. It gets lonely in the Clojure cave.

Om was the first attempt by David Nolen, to see if it could be done. There were probably some ideas in Om that helped create Reagent and Fulcro.I haven't used it myself, but I heard it influenced libraries that came after. It's also not fair to compare longevity of a binding library that needs to be kept up to date to the lib it binds to, but Reagent has been around for 7 years, with all the changes happening in React itself. Sure there are changes in Clojurescript ecosystem, but certainly not as frequent and tiresome as in Javascript land.
I am sure you could find someone doing Clojure stuff if you searched for Clojure on meetup.com

Me too. I love programming with Clojure[script] but Clojure jobs here in London are very thin on the ground.

Same, when I had to choose the front-end framework for my neweset project I first looked at the UI libraries available at that time and went with React just because MaterialUI was so much better developed than all the Vue UI frameworks. The React ecosystem just feels a lot more robust and well maintained than the ones of Vue, Angular or Svelte for example.

React made a lot of sense to escape Angular, Ember, Backbone and jQuery in 2013-2014, but then it took 4-5 years to become wildly popular [1]. I've never understood its popularity despite the fact that during those years there were already better options out there by any metric you can think of (except popularity and hype).
- Inferno and Preact: similar API but so much faster and smaller.
- Mithril: vdom based with components, faster than React and includes http client + router in 10kB gzipped.
- Vue: faster and smaller and has official batteries (unlike react-router which is a third party)
Etc.
[1] https://npm-stat.com/charts.html?package=react&from=2013-05-...

Probably because none of those advantages of other solutions matter for small-to-medium scale business. It's about getting things done _fast_, not getting the fastest thing. And for that purpose, a popular tool is usually better (more people, more information, bigger ecosystem).
As for the technical merits of the alternatives, they fail to manifest in most situations:
"Faster" - any framework is fast enough for most of the common tasks; and even if a popular framework is not the fastest, it is not necessarily a bottleneck in the real life applications.
"Smaller" - it is just "faster" download. Irrelevant in many usage scenarios. It might be important in some applications, but shaving milliseconds vs man-months is a tough sale.
"Official batteries" - bundling of the dependencies is completely irrelevant from the business perspective. It's something that the developers are paid to figure out.

> but shaving milliseconds vs man-months is a tough sale
It's not really one or the other. Both Preact and Inferno can be used with React libraries with a compat layer.
> bundling of the dependencies is completely irrelevant from the business perspective.
It's not irrelevant. Vue is used by major corps in China.
> It's something that the developers are paid to figure out.
Didn't you just argue that the advantage of React is that developers get "things done _fast_"? How come this is not an advantage in the case of Vue?

> Vue is used by major corps in China
It might be the case that in China Vue is the default and the most popular choice. And still my point holds: Vue is not the fastest, and is not the smallest framework. Technical merits alone ("faster", "smaller") are not enough to drive adoption.
On bundling/unbundling. I think it's a preference thing. "Batteries included" vs "modular" are both viable designs.

Since you're claiming the answer is not technical, why would Vue be more popular in China than React and why isn't Vue more popular in the Western world?
> I think it's a preference thing. "Batteries included" vs "modular" are both viable designs.
Again, it's not one or the other.
Vue in itself is just a simple rendering engine much like React, Inferno, etc. There are official libraries (router, state, etc) but those are separate projects which you can choose to use or not. It's not a framework like Angular, Ember, etc.

One-way data binding is what made React successful. Angular took a long time playing catch-up and with Vue it was optional.

I was a Flex developer.
No JS framework felt anywhere close to the ease and power of Flex until I saw React.
React is Flex done right. React is Flex but armed with the knowledge that two way data binding is the fucking devil.

> two way data binding is the fucking devil
You mean in terms of performance, or something else?

In terms of reasoning about your code, I expect.

Reasoning about code. Creation of inscrutable bugs. Forcing to create convoluted hierarchy of data structures to work round the problems this convenient 'feature' created.
The kicker for me is it is perfectly possible to use Flex in a one-way data binding manner. Just wish I'd worked that out 13 years ago!

Ah, the 'spooky action at a distance' aspect. Doesn't much of that apply to data-binding in general though?

I have found that the difference between one-way and two-way to be quite profound when it comes to the complexity of bugs produced.
Race conditions become an almost permanent fixture with two-way and the 'chains of causality' are exponentially more complex in a two-way situation.
One-way simplifies things in quite a profound way. I remeber when watching Dan Abromov's excellent Redux tutorial physically laughing and muttering "of course" as every single two-way bug I had ever worked on flashed before my eyes.

Switching to one-way-binding is really just replacing upward propagation with events, right? Aren't both approaches vulnerable to data-change cycles, just by different means?

Maybe the difference is that you keep control with events, i.e. you can filter, retarget, cancel or otherwise reason in general about the way they propagate?
I'm no expert, but the essence of the "reactive functional programming" programming paradigm is that you have composable high level abstractions about the streams of events (e.g. marble diagrams).[1]
[1] https://blog.danlew.net/2017/07/27/an-introduction-to-functi...

Mobx is a great example. It works well for small projects, but as they grow, you get bugs. One thing winds up depending on another that depends on yet another and before you know it, you've got all sorts of unexpected updates happening. These bugs often require digging into and though the mobx implementation details as you try to step your way to the problem.
You can greatly reduce this issue, but you do so by refusing to use most of the 2-way binding features. At that point, you're going to basically be doing one-way data flow anyway and might as well go all-in with a library tailored to do that.

To mirror my other reply:
This is the 'spooky action at a distance' aspect of data-binding. Doesn't it apply to data-binding in general?

I think React’s biggest win is that it appeals to the programmers, not just the web developers. For the first time everything you need to make a website or webapp — html, css, etc – is just data. You have direct control, direct access, you can do what you want.
There’s a beauty and simplicity in that. React is to web frontend what Lisp is to systems programming.

The downside to that is that I've seen a lot of old school frontenders who 5-7 years ago were able to just dus html/css and sass haven't been able to keep up, it just got too complex. In that regard the old situation had better seperation of concerns.

In my experience that separation of concerns was fake. 15+ years of webdev and I ain’t ever seen a redesign that doesn’t fundamentally change the layout and business logic. Never seen a spec update to logic that doesn’t also change how things look.
The coupling is super tight and always has been.

I meant more in the sense that different people could do different jobs.
Non-developers/designers were able to do a lot of the frontend stuff. With the "new" complexity of frontend development that's mostly gone.
I've seen it a few times with my own eyes that in teams the 1-5 frontenders specialised in html/css had a really hard time switching to react, at the same time more seasoned developers felt like fish in the water.
Considering the scarcity of developers that's actual a big deal, more work for developers while at the same time less work for traditional frontenders.

In my experience those different people couldn’t do different jobs. Designers could write css, but I hd to set up magic id/class incantations for them. They could write html, but changes kept breaking business logic.
Css zen gardens was a fantastic idea that I’ve never seen realized in a real project with business needs. Maybe I’ve just been unlucky.

I've seen few organisations where there was a group of frontenders specialised in html/css. Even integrated in continious development. It's a fine line, but with backbone.js and sass they could manage, but with react and postcss the line between templates and logic disappeared.
But it's less specific then that. When 6 years ago hiring a frontender they needed to just know html and css, now they need to be full blown devs.

I’m currently training/mentoring a designer in using React, Tailwind, Markdown and basic CLI tooling (git and yarn). She appreciates the power and expression shes given and is learning quickly and steadily. No prior coding knowledge.
Most of this comes down to getting past the fear of coding/programming. And it is a powerful enabler, even reshapes thinking. She recently came up to me with saying “why should I write this in Word? We have markdown and I bet there is a tool where I can style this and generate a PDF”.

Some people just get development. I had one close person who was able to learn webdev and become and highly skilled freelance developer in 0.5 to 1.5 year (having played with computers his whole life), I had another friend who after 3 to 4 years still struggles to do a simple loop, let alone grasp a recursive function, at the same time he makes great designs and has good skills to implement them frontend wise. Different minds, different talents.

That's really the main reason React got popular. Somehow it lets the people who do not know what they are doing get by. At the expense of the users.

Mind you in my case the designer just really does JSX templating with it and styling. The wiring, plumbing, state and so on is not her business.
The reason I use React is mostly its composable, simple templating abstraction and the fact that it works both on the server and the client.
UX is generally improved. If a site/app is done well, it will work w/o JS enabled, loads fast and transitions even faster.
JS typically makes things better, not worse. What makes sites slow is putting in external and/or heavyweight stuff: ads, analytics, tracking, fonts, images and so on.

FWIW enabling designers is one reason I like Vue a lot (as compared to react). With single file components[0], it's quite possible to contribute knowing just html+css.
In fact the scoped CSS makes Vue files superior to plain html+css for non CSS experts -- organizing large stylesheets is hard to get right!
[0] https://vuejs.org/v2/guide/single-file-components.html

>Non-developers/designers were able to do a lot of the frontend stuff.
This always smells like "nobody could possibly do what we do" developer hubris.
The designers I've worked with on my last three large React projects could edit .jsx/.scss files. I don't really buy the idea that someone can learn web client design but it's jsx or whatever that's too much.

This is true. The MVC idea of separation of concerns on the surface seems like a good idea, but the reality is that I've never been on a team that was disciplined enough to actually keep things separated.
As a mostly back-end developer, I am not a fan of the complexity and magical bullshit you have to know about to use React properly. I am also disgusted when a stopwatch app that can be done in 500kb of native code turns into 25 MB of cruft when implemented with React Native. The fact that it completely disregards MVC, which maybe never really worked anyway, is the least of its problems.

> I am also disgusted when a stopwatch app that can be done in 500kb of native code turns into 25 MB of cruft when implemented with React Native.
On the other hand, the time saved from using React Native versus having 2 separate codebases for iOS and Android is the difference between having a product and not having a product for many teams and solo developers. The issue there is not React Native being bloated, but cross-platform development being such a pain.

> The MVC idea of separation of concerns on the surface seems like a good idea, but the reality is that I've never been on a team that was disciplined enough to actually keep things separated.
on the native app side, ive seen this too with mvc, mvvm, mpv apps: people just arent very good at deciding what goes where in many specific cases
im not sure, but my guess is, the more layers you have to maintain, the higher the cognitive load that one has to implement so many parts, they start to tire and without knowing it, smear things across layers, making a huge mess over time

The idea that HTML was meant to be a pure data format, styled by CSS classes that also were somehow part of that pure data format was always silly, but it became much more silly once REST apis became popular.

maybe its "ivory-tower thinking" in the end... that idea alwasy appealed to me to he honest... i guess the thing is its only one small facet of web development, not the whole thing

Same here, I spent so much time making semantic html that felt great but in the end was never consumed semantically by anyone or anything.

Only benefit I get out of keeping my HTML semantic these days is that using 1 div instead of 10 has a big impact on UI performance. Draw fewer DOM nodes is still one of the best bang for buck optimisations you can do.

Semantic HTML is a pretty important part of making your site accessible. Screen readers have likely consumed that HTML plenty of times.

What REST has to do with it?

So in your 15+ years you never saw a project done right. Sad, really. CSSZengarden is mostly forgotten. True, it is just a demo project, but there were some prominent redesigns, and some people even had fun doing "CSS Swaps".

That's the luddite take.
You probably shouldn't take up a career in technology if you're not willing to continually learn new things to keep up with advancements.

React may be an improvement on what came before, but it's still too complex for "draw a UI on the most-widely used platform."
It's definitely not helping to democratize programming the way that the personal computer did when it simplified the world of computers down to a BASIC interpreter that a child could understand.
The "advancements" are necessary, but let's be honest - they are far from ideal, overcomplicated messes that exist solely to paper over the fact that the main software delivery platform is still just a hacked-up document viewer. They make professional programmers' lives easier, but the act of programming becomes generally less accessible with each iteration.

Don't really buy this.
React is a lot simpler than all of the other frameworks/APIs/SDKs I've used like Cocoa/UIKit that draw a UI on a client that only a fraction of people can use. You'd expect it to be simpler, not more complicated, if you get to target a
Also, unlike iOS dev (for example), the web still has a trivial `echo "<div>hello world</div>" > index.html` you can use when you want it.
I always wonder how many web-client dev critics have done much work building clients on other platforms. Spoiler: it never was simple nor easy. And people's favorite hey day examples only worked for a specific platform.

Unclear why React has to service that need. jQuery still exists, is still supported and maintained, and serves that need much more effectively I wager.
And taking a step back I think many people in frontend confuse React for a jQuery alternative, the thing you whip up a web project with by default, but it really isn't. That there is a component ecosystem might suggest its a jQuery alternative, but they really are for different scales of application programming.
I think it's this idea most harmful about React adoption and to be fair React marketing hasn't exactly said otherwise. So we get web pages with massive JS deps cause most people are probably using React for a productive developer experience rather than a fitting use case that actually justifies resorting to a virtual DOM model for applying view state, and yet React sold itself on "we probably know better than you about efficient DOM updates". That's true if you have lots of Juniors hanging around.

I think that depends on how you use react. When I first started using it to replace jQuery, it resulted in different use patterns than when making a greenfield SPA. I just wanted something easier to maintain and it did that in spades.
React was an easy drop-in replacement. No state library or whatever else (there weren't a ton of libraries at that time). Just add React CDN, code up some simple components and add them to the page (they'd get a list of elements with the correct classname and inject one copy for each element).
Today, I still take a similar approach for the occasional CRUD site I work with. The only change is that now I use the much smaller pReact and use functional components with hooks instead of the old React.createClass() from the early days.

Maybe we don't have to move certain things, like "design", into the area of technology :).
Frontenders at the the time didn't see themselves as engineers.

They could always look into a minimalist framework like Svelte, which is intentionally the most minimal step up from plain JS/HTML in terms of coding, yet gives you the power to make React-level websites.
I recently wanted to throw up some minimal stuff on S3 without building, just a HTML file, and was surprised at how small the difference was, for simple enough pages - almost 0.

This is exactly what drew me into React.
I used to _hate_ front-end programming, everything was a huge framework of magic dust and unicorns. Stuff Just Worked - if you knew the name of the magic incantations (variables and functions) you had to cast to make it work. Never mind that the whole front-end landscape seemed to do a complete pivot and invent new stuff every other week.
With React + Typescript it's just components that produce fragments of HTML and are entirely or at least mostly self-contained with a clear interface.

Yes, as a programmer I love react. It fits into my mental models of composability and state management.

Funny for me state management was pretty simple until React came along and made it asynchronous.

Async never bothered me because I was using it ever since I first started working.

Compared to the updating/rerendering hassle that it solves, this is non-issue.

Exactly. React morphed front-end development into front-end engineering.

> What differentiates websites from one another today isn’t their underlying architecture but their content, design, and editorial.
This is bad, this will kill the quirky, fun internet. Monoculture is not good.

No one seems to complain that all of the quirky websites use three.js. That doesn't seem so different to me.

And while there were complaints, Bootstrap was the big behemoth before React. It’s not new to want to standardize on one front end design standard.

I don't get it unless you interpreted that statement inversely. It's the content, not the underlying architecture of a website, that makes in quirky and fun.

React and the tools used to build React applications (mainly webpack) strongly incentivize engineers to create single page applications, but don't provide good routing and back-button support out of the box. To make a React SPA behave like a traditional web page, you need to add a third party routing library, and that has traditionally been a dumpster fire in React.
That's a quick example of the way the React monoculture is bad for users of the web from a structural, not content point of view.
I say this as someone who has been using React professionally for 5+ years, and who was initially incredibly excited about React's potential. I'm less convinced it's actually good, after seeing how it's used in day to day work with regular engineers working on regular software that isn't Facebook scale.

But then as soon you click the back button you lose all the state and have to do a lot of craziness to keep it in sync with the server. That’s the problem you’re trying to solve, trying to keep the server-client data reliably in sync.
And no one wants to wait around for all that state to load, that’s why those websites were so slow. Plus, then there’s the challenge of scale and traffic
It’s just not about the back button. It’s not about fashion, there are real problems that an SPA fixes. Sure it’s more complex, but the problem is more complex
It looks like you and a lot of people in HN work on super small websites that don’t require React or any SPA but yall don’t have to shit all over it and people who choose an SPA to build their web apps. In fact, more often than not, it’s the right choice

I come from the never-react side, but I see the benefits as well.
However, the issue is that an SPA is fundamentally something that doesn't fully integrate with what browsers were designed to do, which is show independent webpages.
An SPA makes sense if your site is exactly that, an app in the form of a site. Gmail can be an SPA, Google Docs can be _another_ SPA, they shouldn't be in the same SPA. The question is if your particular problem is fully encapsulated as one app or not, and whether you even need any real interactivity in it at all.
The other issue is that practically react tends to make people think they understand what they're doing but they do not really. This happened in the php days as well, but at least the sphagetti code was still interpretable without fully breaking your head, it was much more linear. With react, if the code is written by someone who doesn't share the same ideas of state and data flow as you, it's a huge headache to figure out what they have done.

But it’s been such a long since browsers were first invented and they have changed to accommodate for web apps. Chrome, safari, Firefox et al today are far more capable than the browsers of old, and they do so because the overwhelming majority of users, virtually all of them want web applications.
As for the spaghetti code yes, it can be, but it doesn’t have to. I’m not gonna say it’s beginner friendly, but the software React is meant to be used for it’s not for beginners either

Not sure if this is what GP meant, but I guess it can be understood as "since what matters is the content, just use React".

Totally off topic, and very much a nitpick, but Ling's Cars isn't a used car dealership, it's a car leasing firm. I care because I'm a fan :-)

That site is entertainingly funny and the background paisley is just lovely. If anyone feels the need for a virus-free laugh, I recommend a visit: https://www.lingscars.com

sidenote : i find it funny nobody in the comments mentions vue.js. i find mentions of ember and angular, but i had the impression vue was the one that got all the love recently. Has something bad happened to this framework ?

Not that I can tell. I recently stumbled upon Quasar/Vue and was very impressed. The ecosystem seems to be flourishing.

No, might just be the timing of this submission. Vue is doing great and is about to release version 3 which will be another big leap forward.

Vue 3 looks very much like they're just taking one more step closer to just being react, but made by a different company.

How so? The functional paradigm of data -> view model -> events -> mutation is the same in every framework and state management library but there are lots of differences in other features. Vue has a lot that sets it apart.

Battery drain is a metric often left out of the equation when assessing front-end frameworks. Download size is usually given priority but why? Your poor phone now has to run all that code you so zealously zipped.

That's interesting, are you also suggesting that serving non-gzipped content might lead to less battery usage than serving gzipped content? There will be less data downloaded, but mull CPU time to unzip the files. Isn't network a lot more costly (battery-wise) than CPU?

Sorry, I was refering to the CPU requirements of just running SPA code regardless of unzipping.

I’ll see your Ling’s Cars[0], and raise you Camacho Auto[1] (requires flash).
[0] https://m.lingscars.com/
[1] http://web.archive.org/web/20171205085043/https://www.camach...

increment looks super great just picked up a couple of copies of the mag thanks for sharing

Wild conspiracy theory: Facebook, Dropbox, Netflix, Reddit made React popular so that web developers can't develop a competing service because of the complexity that it introduces.

Or maybe there's genuinely good people working at Facebook who want to help others and help them succeed at their job.

Agreed!
The intent of React is to drive new developers away from the building blocks of the web. And it has definitely succeeded at that. The way its ecosystem has grown all over the place, I find very passionate developers that swear by it.
But you never know, every technology at some point of time becomes a luddite’s take and then it’d become hard to even consider React. Someday may be near as well, given that it’s already more than 10 years old now… but then that would also be a good day for open web standards and simplicity. ;-)

> The intent of React is to drive new developers away from the building blocks of the web.
That’s not React’s intent.

not overtly, yes, but it is, you just don’t know it yet.

Reply on news.ycombinator.com