
A response to “An experienced JavaScript dev’s account of learning React” - nachtigall
https://medium.com/@dan_abramov/hey-thanks-for-feedback-bf9502689ca4
======
nevir
A lot of Abramov's responses do refute the original points, but they also
betray how much cognitive overhead is required to play in React's ecosystem.

The guy used Redux, I'm sure, because he knew he needed to manage state
somehow - and the articles he found probably pointed him there (rather than
vanilla component state)

He knew he wanted some sort of routing system, found react router, was got a
bit scared by how quickly it has been moving lately - and also, likely, how
many existing articles about it are somewhat outdated

Etc

~~~
philpee2
I've never understood the whole "Don't use Redux until you need it" idea. If
you're building anything larger than a toy app, component state isn't gonna
cut it, so you're better off structuring your app with Redux or MobX or
something from the start than rewriting stuff to include it later.

~~~
acemarke
There's a difference between "don't try to learn Redux until you understand
React", and "don't use Redux right away when you start building an app".

For most people, trying to learn to "think in React" is a pretty big jump,
especially if they're coming from an imperative, jQuery-style background.
Throwing in Redux's concepts at the same time is usually too much for most
people, especially if they're relatively inexperienced programmers. So, the
standard advice from both the React and Redux teams is to focus on learning
React first. Once you have a good understanding of how React works, you will
better appreciate why a state management library like Redux can be useful, and
you can learn about other tools later.

On the other hand, if you are familiar with Redux, it does make a lot of sense
to set it up from the beginning. I've been writing a tutorial series called
"Practical Redux" ( [http://blog.isquaredsoftware.com/series/practical-
redux/](http://blog.isquaredsoftware.com/series/practical-redux/) ) , which is
intended to demonstrate a variety of useful React and Redux techniques in the
context of a sample app. In that series, I create a new project using Create-
React-App, and then immediately add Redux into it as a baseline.

Overall, what Dan is trying to push back against is the perception that you
_must_ use Redux with React, or that you _must_ learn them both at the same
time. Neither is true.

~~~
vbezhenar
Honestly many developers don't have freedom to experiment with new things on
their own. I got web project, I'm thinking, well, it's a good time to try out
React, I've heard it's cool. I'm convincing my manager, if necessary and I'm
starting to build production project without any prior React or Redux or
whatever knowledge. I'm not going to do it step by step, no. I'm grabbing
everything and trying to bundle it all together. I know, that my app will need
state, so I'm using Redux. I know, that my app will need routing, so I'm using
router. And my experience is similar to author's, I had a lot of troubles to
even get build setup working. I guess, it's more about javascript development
tools, not specifically about React, but point stands still. And if I'm
understanding, that I just got buried under pile of things, I'll throw it out,
rewrite everything on Angular I know and love and forget about it for a few
years, until it matures and I could try it again, hopefully with less
troubles.

If you've got a lot of free time and want to tinker a lot, that's a good
advice. Pick simple project, make it with simplest setup, introduce additional
dependencies, rewrite the project, and so on. But not everyone wants to learn
without being paid for it.

~~~
davidjnelson
I'd recommend pitching it to your manager as a one week spike, and if that
goes well do a presentation on it and sell technical leadership on it from
what you learned. Then you can add proper tooling. Make a few trade offs to
save time as needed. That strategy worked for me.

------
jannotti
Impressive job replying to what seems like a hatchet job, without losing his
cool.

But my favorite part: The next React will allow returning an array of
components without a div wrapper. Small change, but it annoyed me to no end
that it wasn't already possible.

~~~
STRML
It will also allow returning raw strings (TextNodes), which will allow for
some very light i18n libraries.

~~~
samtho
IMO, this really shows the maturity of React as a project and gives me a lot
of confidence that working on React apps wont be in vein after another few
years. They are able to see pain points and provide solutions to solve them
without sacrificing backwards compatibility.

------
AustinG08
I didn't see the original article, but he was tossed a softball. The issues
quoted in his response are so cliché.

React is great, and judging by the growing ecosystem, many people agree. If
you don't like it because it requires you to learn a workflow you are
unfamiliar with, don't use it.

~~~
eganist
> If you don't like it because it requires you to learn a workflow you are
> unfamiliar with, don't use it.

Unrelated to the technical side (which I haven't investigated in much depth
yet as a third party to this discussion), I don't like it because of the
patent license, which AFAICR is a valid concern for a non-trivial number of
large firms.

[https://github.com/facebook/react/blob/master/PATENTS](https://github.com/facebook/react/blob/master/PATENTS)

~~~
acemarke
You might want to look at the official Facebook FAQ regarding that PATENTS
clause (
[https://code.facebook.com/pages/850928938376556](https://code.facebook.com/pages/850928938376556)
), as well as this legal analysis: [http://lu.is/blog/2016/10/31/reacts-
license-necessary-and-op...](http://lu.is/blog/2016/10/31/reacts-license-
necessary-and-open/) . I also have links to further discussion on the PATENTS
clause in my React links list: [https://github.com/markerikson/react-redux-
links/blob/master...](https://github.com/markerikson/react-redux-
links/blob/master/pros-cons-discussion.md#reacts-patents-license) .

~~~
yladiz
The problem with the patents clause is that it's too broad wrt patents. If you
have a valid patent that Facebook is infringing upon, no matter if it relates
to React, Facebook revokes your right to use React. That's their prerogative,
but it is generally too broad to allow some companies to actually use the
library.

~~~
davidjnelson
That would be awful. Has this ever been used by Facebook, where a company had
to strip react out?

~~~
spicyj
No.

~~~
davidjnelson
Cool, thanks for the info!

------
julianmarq
I'm having trouble understanding what this accomplished, other than making the
react (or I guess redux in this case) team look petty.

I agreed with the original post and this reply didn't sway me. I see in this
thread that people who had already disagreed with the original post agreed
with this, as expected.

Seriously, nobody not called Linus Torvalds should be writing direct replies
to criticism of their technology in blog posts (and he's the only exception
because reading his replies is very entertaining).

Yes, people like their technology and like how it is, it makes sense for
_them_ but, that's not universal; so addressing criticism (even as an attempt
of countering the criticism) only legitimizes it.

If one doesn't want to acknowledge that one's technology is not for
everyone... one is better off _not acknowledging it_ , in any way; doing
otherwise puts that shortsightedness in evidence.

~~~
danabramov
Thanks for feedback, I just edited to include the reason I wrote this:

 _> Your post includes a lot of misconceptions commonly held in the React
community, so I wanted to take a moment to clarify them for everyone else who
has the same concerns._

I didn't reply to many similar posts before, but I felt like this is a good
opportunity to jump in and provide some clarifications because there are some
factual misconceptions in the post. When unaddressed, these tend to keep
spreading and get a life of their own.

Also, we _do_ take this feedback to the heart. In fact we spent time
developing Create React App precisely thanks to feedback like this.

 _> If one doesn't want to acknowledge that one's technology is not for
everyone._

We totally acknowledge React is not for everyone! I touched on this in the
last paragraph, but it wasn’t the focus of my article. I do try to stress it
when comparing React to other libraries in general, but this seemed like a
React-specific post.

~~~
dentemple
Thank you for your efforts!

As a React developer, I also raised an eyebrow at the misconceptions given in
the original article. (The worst, IMO, was definitely the part regarding
Create React App and the overall toolchain).

I appreciate your take on the article and felt that you did a good job
focusing on these issues, whereas someone like myself would've been a bit more
biting in my response.

------
hising
Maybe I read this with the wrong glasses, but I find some of the answers a bit
high-horse? "How many components do you have" etc.

~~~
spicyj
I'm on the React team and momentarily read this the same way you did. It
probably could have been clearer, but I think I don't think number of
components here is meant to be an accomplishment. Rather, it just means that
we've done the work of testing compatibility already on a gigantic codebase so
there's a good chance that most other apps will work out of the box.

~~~
hising
My point being, you are doing a great job, if a person is frustrated over some
tech and writes a blog post or whatever about it, maybe you should just leave
it with that? Coming out defending design decisions etc just leaves a foul
taste. React is awesome, but maybe it is not for everyone?

~~~
acemarke
It's definitely not for everyone, but it would be nice for people to make that
decision based on accurate information.

There is unfortunately a lot of FUD that has been spread around React in
general, the React ecosystem, and the upcoming React Fiber rewrite. It's a
combination of longstanding complaints like "HTML in my JS? EWW!", concerns
about build tools like Babel and Webpack, badly written articles and headlines
like the recent TechCrunch post that claimed "React Fiber is a complete change
that Facebook has never talked about", and of course lots of arguments in
comment sections.

If someone has taken time to evaluate React and determined that it's not for
them, that's totally fine. But, when poor articles get upvoted and spread
widely, it doesn't help anyone.

------
finchisko
Hat off for Dan, I wouldn't have that patience to explain and basically refute
every claim from the former post. No framework/lib is perfect (for every job),
that is the reason, we have so many. Critique is fine and necessary, but you
should have quite a lot experience with the subject, or you might look
"rookish" (as in this case). Sorry, but that guy did a really poor job
criticizing react.

------
samtho
> Create React App is a thin layer on top of Webpack and Babel. It doesn’t
> generate the project code for you, but it configures those tools in the
> recommended way.

TIL. I've been manually setting up my own configs for years now, and never
touched this tool because I thought it was literally creating a
sample/boilerplate app for you much like the express.js cli generator.

~~~
acemarke
Yeah, CRA really isn't a "boilerplate". It's a prepackaged build system that
can be upgraded. It doesn't come with dozens of app-level dependencies already
installed and custom-configured, like most boilerplates do.

Dan Abramov commented a while back on how CRA differs from boilerplates:
[https://www.reddit.com/r/reactjs/comments/5gt2c4/you_dont_ne...](https://www.reddit.com/r/reactjs/comments/5gt2c4/you_dont_need_a_boilerplate/)
.

Also, I commented with some additional thoughts on why CRA is a better choice
than "boilerplates" for someone who's trying to learn:
[https://www.reddit.com/r/reactjs/comments/5oem3g/recommended...](https://www.reddit.com/r/reactjs/comments/5oem3g/recommended_reactredux_starter_kits/)
.

Overall, CRA serves three primary purposes: it allows React learners to set up
an environment without having to learn Webpack and Babel first; it allows
experienced React devs to spin up a project without having to do all the
configuration work (or copy and paste it from somewhere); and it also provides
a common starting point for instructions and tutorials. For example, my recent
blog post on using the Cesium.js 3D globe library with Webpack and React (
[http://blog.isquaredsoftware.com/2017/03/declarative-
earth-p...](http://blog.isquaredsoftware.com/2017/03/declarative-earth-p...))
was able to start by just saying "Create a CRA project, eject, and modify
these two config values".

------
NoGravitas
Off-topic, but can anyone explain why the comment system on Medium is so
terrible? It always takes at least two clicks (and corresponding slow loads)
to read a comment that you want to read.

------
jaequery
"you must use className instead of class to define the DOM css classes" \- op

"You are completely right it’s annoying. It’s one of those early design
decisions to align better with the DOM APIs that has proved to be confusing.
We might change this in the future." \- dan

i appreciate dan's honesty here. it was little things like this made the
framework look a bit immature and rushed but glad to know these are in the
horizon to be improved on.

------
blurrywh
OT: When I tried Inferno as a drop-in replacement for React few months ago
everything kept working fine. Inferno's author was hired by Facebook and some
of his work might have been reused. Inferno was insanely fast and for me super
compatible though missing some of the API.

I like Dan's answer and it shows that many are not really familiar with React
and its trivial concept (like me before I tried). React is good and manageable
even after a rewrite because it has a tiny API (compared to other
frameworks/libs in this space).

------
whitefish
Those who think React + ReactRouter + Redux is too complex -- you're right.
But there is an easier way to use React: MVC. React is the V in MVC.

[https://github.com/Rajeev-K/mvc-router](https://github.com/Rajeev-K/mvc-
router)

Note that using MVC does not imply 2-way binding!

~~~
hising
I don't understand Redux, I have almost 20 years of coding (I probably suck at
it though). I once asked a developer at an interview if he could explain the
redux stuff he had used in an assignment. He couldn't and I really tried to
understand all the boilerplate and inner designs of the library, but I found
it really hard to get into. Mobx though, 2 minutes and you get it AND you get
more efficient in building complex UI:s.

~~~
ashark
It's two event/message dispatchers slapped together. One for "reducers" that
take an event/message and apply it to state, one that automagically applies
the resulting state-change event to do stuff to your views. You mostly don't
need to worry about the second one.

As far as I can tell, that's it.

For bad reasons they've decided to stick with the terrible "action" name for
their events/messages, which has made the whole thing super confusing (turning
"actionCreator" into "eventCreator" immediately makes things much clearer, for
instance).

There's also a ton of convention/process taught on top of it for some reason
that's IMO not that great, and makes it really hard to see what's actually
part of Redux and what's cruft on top of it that you can skip/modify. Redux-
as-typically-presented is mostly _you_ doing stuff to follow a (kinda painful)
pattern, not the Redux library helping you do stuff.

[EDIT] I'd add that the communication pattern of the docs and various attempts
to help people understand Redux seems to largely be "oh, you didn't get it?
Let me say the same thing again but louder". Which is why there's SO MUCH
documentation and chatter for something fairly simple, I think. Which just
compounds the problem.

~~~
acemarke
A lot of the naming of stuff goes back to Redux's Flux heritage. The Flux
architecture labeled those objects as "actions", so Redux (since it was
intended as a "Flux implementation") kept that naming.

You are right that the majority of usage is really at the user level, than the
library level. I'm actually working on a blog post that will try to clarify
and discuss what actual technical limitations Redux requires of you, vs how
you are _encouraged_ to use Redux, vs how it's _possible_ to use Redux. Been
busy with other stuff, but hoping to make progress on that post this week. If
you're interested, keep an eye on my blog at
[http://blog.isquaredsoftware.com](http://blog.isquaredsoftware.com) .

If you have concerns with the docs, I'd appreciate any specific suggestions or
ideas you might have for improving them. Docs issues and PRs are absolutely
welcome, from you or anyone else who wants to help improve them.

Finally, I recently opened up an issue to discuss possible future improvements
and "ease-of-use" layers that could be built on top of the Redux core:
[https://github.com/reactjs/redux/issues/2295](https://github.com/reactjs/redux/issues/2295)
. Would be happy for any feedback you could offer.

(edit: just noted I replied to you a couple different times in this thread,
and repeated myself a bit. Offer of discussion absolutely still stands :) )

------
_greim_
> React 16 (work in progress) is a rewrite, but it has the same public API,
> and works with more than 30,000 (!) components at Facebook, so it will most
> likely work with your code too

This is uninformative without more context. Is he saying Facebook only had 30K
components, and all of them worked with the new React? Or does FB have, say,
60K components and only 30K worked seamlessly on the upgrade?

~~~
spicyj
30k+ is the number of total components we have. Almost all of them worked
without changes; most of the dozen or so components that needed changes were
relying on unsupported, undocumented behaviors. About 99.9% of our components
(literally) worked out of the box.

~~~
danabramov
Thanks for writing this clarification. Edited the post to include it.

------
yladiz
Am I wrong to feel that this response is written a bit flippantly? Of course,
it's his personal blog, but considering he's writing as a member of the React
team (and seemingly writing on their behalf as he includes the word "we" in
the second sentence) it really feels a bit unpolished and disrespectful. The
use of emojis is really strange, and reading phrases like, "How many
components do you have," and quoting "skeptical" and "doing your job," reads
defensively and sarcastically, not something I want to see in a public post
from a React dev member.

~~~
danabramov
Thanks for feedback. I agree I got too defensive, so I edited the post to be
less flippant. (Didn’t expect it to jump to HN in an hour.)

I do use emojis all the time in personal communication but I guess it doesn't
read very well so I removed them.

The question about components wasn’t meant to be an insult but I can
understand how one could see it that way, so I removed it.

Sorry!

~~~
throwawaymaroon
A bigger concern for me is the grating cheerfulness in what is a very critical
article.

Don't pretend you're not fighting fire with fire with this article. You're mad
and you're showing it. When you say stuff like...

>>To sum up, I love that you brought up these concerns in an article.

I don't believe you! Disingenuous.

(You should also think about whether or not the Riot.js author is worth
responding to. Just because he's a framework author doesn't mean that
framework has ever been held in high regard.)

~~~
danabramov
My motivation was to address common misconceptions around React ecosystem. I'm
genuinely happy people bring them up (since that's how we learn about the
issues).

To me, reading posts filled with frustration serves as a motivation to improve
things. I didn't reply to "fight with fire": I see these kinds of posts every
week or two. But I replied this time because I think it was also important to
separate real issues from the factual inaccuracies (that get a life of their
own once somebody writes an article).

Some bitterness did come through, and I removed it. But I'm not lying when I
tell you I'm happy people are sharing their concerns with React. It's all for
the best. :-)

------
andrethegiant
If anyone isn't aware, you can use babel-plugin-react-html-attrs[1] to address
the class/className issue addressed in the author's last point.

[1] [https://github.com/insin/babel-plugin-react-html-
attrs](https://github.com/insin/babel-plugin-react-html-attrs)

------
ed_balls
What React is missing is a set of idioms and patterns. When you inherit
Angular or Django project it's quite easy to understand it and be productive
if someone follows the philosophy.

Create-React-App is a great step, but what next? How to handle AJAX and state
if I have a simple app and don't really need Redux. How to structure it so it
would be easy to add it.

~~~
acemarke
There _are_ many patterns that exist already, and have been widely discussed
in the React world (such as "Higher Order Components" for code reuse).

You may be interested in several of the sections in my React/Redux links list
at [https://github.com/markerikson/react-redux-
links](https://github.com/markerikson/react-redux-links) . In particular,
check out the "React Architecture", "React Component Patterns", "React State
Management", "React and AJAX", "Redux Architecture", and "Project Structure"
sections.

To pick out a few specific links related to your questions:

\- [http://reactpatterns.com/](http://reactpatterns.com/)

\- [https://github.com/vasanthk/react-bits](https://github.com/vasanthk/react-
bits)

\- [https://medium.com/@dan_abramov/smart-and-dumb-
components-7c...](https://medium.com/@dan_abramov/smart-and-dumb-
components-7ca2f9a7c7d0)

\- [https://daveceddia.com/ajax-requests-in-
react/](https://daveceddia.com/ajax-requests-in-react/)

\- [https://daveceddia.com/visual-guide-to-state-in-
react/](https://daveceddia.com/visual-guide-to-state-in-react/)

\- [https://hackernoon.com/redux-step-by-step-a-simple-and-
robus...](https://hackernoon.com/redux-step-by-step-a-simple-and-robust-
workflow-for-real-life-apps-1fdf7df46092)

~~~
ed_balls
Thanks for that. Really helpful.

Is there a great mid-size open-source project that was created with Create
React App? Any input on UI frameworks? I'm currently using React-Bootstrap,
but I'm thinking about using Material-UI.

~~~
acemarke
Mmm... not sure about apps specifically built with CRA. I do have a list of a
few selected interesting-looking apps built with Redux (and React) in my Redux
ecosystem catalog [0] . Haven't updated that section in a while, though, and
it's definitely not comprehensive, but there's a useful variety of apps to
look at.

I personally am using Semantic-UI-React [1] in a work project, as well as in
the sample app for my "Practical Redux" tutorial series [2] [3]. I also
frequently recommend a tutorial series called "Building a Simple CRUD App with
React + Redux" [4] as another "real-world" tutorial/example. That tutorial
doesn't use CRA, but my "Practical Redux" sample app does.

[0] [https://github.com/markerikson/redux-ecosystem-
links/blob/ma...](https://github.com/markerikson/redux-ecosystem-
links/blob/master/apps-and-examples.md)

[1] [http://react.semantic-ui.com/](http://react.semantic-ui.com/)

[2] [https://github.com/markerikson/project-
minimek](https://github.com/markerikson/project-minimek)

[3] [http://blog.isquaredsoftware.com/series/practical-
redux/](http://blog.isquaredsoftware.com/series/practical-redux/)

[4] [http://www.thegreatcodeadventure.com/building-a-simple-
crud-...](http://www.thegreatcodeadventure.com/building-a-simple-crud-app-
with-react-redux-part-1/)

------
nickbauman
The core of React is the VirtualDOM and how it simplifies interaction with the
hypermedia. React has gone way past that original simplification toward curing
cancer or solving the faster-than-light-speed problem (take your pick). This
shazz should have been a separate effort.

Most of the original criticisms centers around NPM, which belies the hell that
is JavaScript. Since everyone compiles JS anyway, we should stop writing in it
altogether. Pick some other language ecosystem that transpiles to JS. _Delenda
Est NPM._

------
philmander
It's often seen as an advantage of React that it's just a view library and not
a framework. But if you want to build any reasonable kind of modern web app,
you'll need those extra elements like routing and state management. You
effectively must piece together your own framework and the cognitive overhead
of this is huge. At least for the first time anyway.

------
noshbrinken
I love reading Dan Abramov's writing because I always learn two things at the
same time:

1\. something about programming;

2\. something about communicating with people.

------
smdz
There are a few things in React ecosystem that need to be abstracted.

1\. Redux

2\. React Router

3\. Smart components

4\. Dumb components

5\. Services (This is combination of Redux, redux-thunk and axios(or
whatever))

6\. Webpack (CSS loader, SCSS, fonts, html, etc...)

7\. And hopefully, everything with TypeScript if they can get over Flow.

Having worked on quite a few React projects, I have a boilerplate that mashes
up the above combination and makes it work. With new project, I upgrade the
dependencies.

But each time I start a new project in 3-4 months, something would have
changed. Either its TS type defs or something in core React.

And as I discovered recently few days back - Webpack2, Router4 broke my
boilerplate setup. Well, they actually improved react-router, and that made me
remove some workarounds.

Every time I start, I end up spending at least half-to-one day setting up the
same "Hello world" page and making sure the wiring works okay before I proceed
to add functionality. That is just a waste of time. React core is cool, but I
hope they had one highly-opinionated version of React that works out of the
box.

~~~
asdfgadsfgasfdg
create-react-app

~~~
smdz
I get thrown that a lot, but unfortunately create-react-app is not the
solution. It simply summarizes all the complexities in one place, it doesn't
abstract those out.

For starters - yes, definitely. They should start with it

~~~
spicyj
If there are areas where create-react-app is a leaky abstraction, please file
bugs. My understanding is that the maintainers aspire to have it completely
shield you from configuring the underlying tools.

------
darth_mastah
> Don’t use Redux if you don’t need it, as it is intentionally verbose.

Yeah... People say that, but is it true? Lifting the state gets very messy
very quickly and you end up with a spaghetti code before you know it, with the
separation of concerns dying short yet painful death. For that reason I use
Redux even in small projects, guarding myself against unnecessary verbosity
with redux-actions. It's really that simple. I understand the need to prove
that React can stand on its own without Redux, but the truth is, without Redux
it's limping.

------
bigato
Here's the article this one is meant to answer:

[https://medium.com/@gianluca.guarini/things-nobody-will-
tell...](https://medium.com/@gianluca.guarini/things-nobody-will-tell-you-
about-react-js-3a373c1b03b4)

~~~
lucaspiller
It is actually linked at the top of this article, although Medium's minimal
design doesn't make that very clear.

------
spion
Here is what is missing now in the React ecosystem

[http://guides.rubyonrails.org/](http://guides.rubyonrails.org/)

Thats it. A central place with an organised list of guides. Not a blog though.
Also must cover things such as redux, mobx and routers, and how it all fits
together.

~~~
acemarke
I already have something pretty close to that :)

I keep a big list of links to high-quality tutorials and articles on React,
Redux, and related topics, at [https://github.com/markerikson/react-redux-
links](https://github.com/markerikson/react-redux-links) . Specifically
intended to be a great starting point for anyone trying to learn the
ecosystem, as well as a solid source of good info on more advanced topics.

(The entire list has just been me working it by myself with the occasional
"add a link" PR from random other people, but I'd certainly appreciate any
actual offers to help improve it, especially since my own knowledge is rather
limited in a number of areas.)

~~~
lucaspiller
The work you have done here is useful, but as pointed out in the original
article, articles very quickly become outdated in the Javascript ecosystem.
It's not just how libraries work (I haven't looked through the list too much,
but I'm sure there are plenty of articles suggesting a Webpack 1.x
configuration) but also the recommended way of doing things and what tools to
use that changes.

I guess this is one of the advantages Rails has being a monolith - as it
provides nearly everything, it's very easy for them to keep up to date
documentation of the 'Rails way' to do things. React and Redux have been
relatively stable, but it's everything else that goes along with it that is
the issue.

~~~
acemarke
True, but it's also worth noting that the existence of a newer version of a
lib doesn't completely invalidate the older version. For example, Webpack 2
_is_ out, but a Webpack 1 config and setup will still keep working just fine.
Ditto for, say, React-Router v3 vs v4.

------
beefman
This post does a great job refuting minor points while completely ignoring the
central arguments of the original.[1][2] The React TodoMVC weighs some 451
lines -- more than vanilla JS, jQuery, and over twice as much as Vue.

There are weird incentives in software ecosystems. Companies benefit by
controlling one because they can hire easily, and ensure their code & tools
will not become obsolete. And the more complex ecosystems become, the harder
it is for devs to compare them or switch. I think there were similar forces at
work in the UIs of large GUI applications like DAWs. Once you get through the
painful learning process, you find you love it, and find it impossible to
switch -- a phenomenon that has attracted comparisons to Stockholm syndrome.

[1]
[https://gist.github.com/GianlucaGuarini/b9238a187ef13897b71e...](https://gist.github.com/GianlucaGuarini/b9238a187ef13897b71e15e4906e4499)

[2]
[https://news.ycombinator.com/item?id=14184666](https://news.ycombinator.com/item?id=14184666)

~~~
acemarke
React's benefits come through more at scale. If you just want to add a bit of
interactivity to a page, sure, jQuery is going to be fewer LOC and KB. If
you're trying to write a large full-blown application that's 10K, 50K, 100K
LOC, with tons of views and lots of data to manage, jQuery won't cut it. React
helps you build the UI in manageable, understandable, reusable pieces.

~~~
beefman
A valid point, but TodoMVC is enough of an app that I feel we shouldn't be
multiplying jQuery by 2. No larger benchmarks exist, but I'm reasonably
confident React would still be substantially larger than e.g. Riot, Vue, or
Svelte. And yes, conventions have value, but it's a zero-sum kind of value
that comes at the expense of all other possible conventions.

------
mswift42
While Abramov's points sound reasonable, his post could do with a less
patronising tone.

~~~
danabramov
Sorry. Fixed. :-)

~~~
spicyj
You're doing it again with the smiley faces Dan.

(As someone who knows Dan, I'd bet money that this smiley face is genuine.
Still, easy to misread.)

~~~
danabramov
I'll attach webcam photos next time. :-)

------
mcguire
To quote Doc Martin, that sounds appalling.

------
sksixk
i find the passive-aggresive emojis in these "response" blog posts amusing.

~~~
danabramov
Thanks for feedback! I use them all the time on Twitter, and didn't mean to do
it in a passive aggressive way. I removed them.

------
metehe
Facebook rewrites gonna scare whole lot users.. react projects seems to be
very fragile in versioning process..

I would prefer Riot.js instead.. a much less headaches

~~~
haukur
The React API _is_ stable. There haven't been any major changes to its public-
facing API in a long time. Third-party projects that you might also depend on
are not always as stable but the React team has no control over that (and
third-party dependencies don't have anything to do with React itself or
fiber).

------
plandis
This is a failure in obsessing over your customers. Rather than refuting a
noobs comments, perhaps that is a great time to learn what exactly is painful
for new people and fixing it?

~~~
aeze
The comments are being mostly refuted because they're mostly misconceptions.

------
bigato
I'd love to read an answer to this:

"what do you expect from a framework with more than 1000 issues on github that
will let you install alpha dependencies by default (React@16.0.0-alpha.6) to
develop your native app?!?"

~~~
scrollaway
I'll answer it: When you become popular and have a lot of momentum, the Github
issue tracker becomes extremely hard to manage. This is partly Github's fault
as well (the tracker is optimized for small repositories and throwaway issues,
which is also why I like it a lot).

This is aggravated in the JS world which is extremely Github-centric.

NodeJS: 730 open issues, 4323 closed issues, 324 open pull requests, 7201
closed pull requests:
[https://github.com/nodejs/node](https://github.com/nodejs/node)

Ansible: 1863 open issues, 9204 closed issues, 1084 pull requests, 11762
closed pull requests:
[https://github.com/ansible/ansible/issues](https://github.com/ansible/ansible/issues)

~~~
julianmarq
So (much like the OP), your non-answer is moving the goalpost and blaming
something else, and even that only partially "addresses" the issue brought up?
Seems appropriate.

~~~
scrollaway
I answered the matter of open issues, and I have enough experience in open
source to back that up. There's not _one_ issue brought up in the original
post scriptum, there's two stitched together into a big fat strawman. Please
voice your concerns about me only "partially" addressing anything to
noreply@devnull.com.

~~~
spicyj
(For clarity – this person does not work at Facebook despite that convincing
noreply@facebook.com email.)

~~~
scrollaway
Sorry, I tried making a joke, and upon re-reading I see how it could have been
misread :) Edited out.

~~~
spicyj
No worries.

