
The rise of React - prostoalex
https://increment.com/frontend/the-rise-of-react/
======
ht85
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.

~~~
ng12
> 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.

~~~
hn_throwaway_99
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.

~~~
acemarke
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/gsoft-inc/craco)

\-
[https://github.com/harrysolovay/rescripts](https://github.com/harrysolovay/rescripts)

\- [https://github.com/timarney/react-app-
rewired](https://github.com/timarney/react-app-rewired)

\- [https://github.com/arackaf/customize-
cra](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.

~~~
arvinsim
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.

~~~
acemarke
I'd go with `craco`, personally.

------
jaredcwhite
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.

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

~~~
hombre_fatal
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.

~~~
esperent
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).

------
Ozzie_osman
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.

~~~
Ozzie_osman
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).

------
_hardwaregeek
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.

~~~
ricardobeat
> 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.

~~~
jjeaff
>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.

~~~
ricardobeat
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.

------
satya71
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.

~~~
Ididntdothis
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.

~~~
RussianCow
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).

------
Marazan
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.

~~~
MaxBarraclough
> two way data binding is the fucking devil

You mean in terms of performance, or something else?

~~~
hajile
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.

~~~
MaxBarraclough
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?

------
Swizec
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.

~~~
toshk
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.

~~~
Swizec
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.

~~~
toshk
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.

~~~
dgb23
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”.

~~~
rimliu
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.

~~~
dgb23
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.

------
pier25
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-...](https://npm-
stat.com/charts.html?package=react&from=2013-05-30&to=2020-05-30)

~~~
srg0
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.

~~~
pier25
> 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?

~~~
srg0
> 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.

~~~
pier25
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.

------
pmlnr
> 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.

~~~
hombre_fatal
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.

~~~
hoorayimhelping
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.

~~~
ulisesrmzroche
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

~~~
ramraj07
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.

~~~
ulisesrmzroche
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

------
skrebbel
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 :-)

~~~
tempodox
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](https://www.lingscars.com)

------
bsaul
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 ?

~~~
manigandham
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.

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

~~~
manigandham
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.

------
cutler
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.

~~~
XCSme
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?

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

------
loosetypes
I’ll see your Ling’s Cars[0], and raise you Camacho Auto[1] (requires flash).

[0] [https://m.lingscars.com/](https://m.lingscars.com/)

[1]
[http://web.archive.org/web/20171205085043/https://www.camach...](http://web.archive.org/web/20171205085043/https://www.camachoauto.com/)

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

------
cateye
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.

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

------
marvindanig
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. ;-)

~~~
mcav
> The intent of React is to drive new developers away from the building blocks
> of the web.

That’s not React’s intent.

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

