
Ask HN: What is the draw of React? - peteforde
I&#x27;ve been building database-driven web applications since the days of classic ASP and was an early Rails adopter. While I believe in using the right tool for the job, I&#x27;ve always seen myself as someone open to radical change. That&#x27;s why I am so uncomfortable admitting that after several years of trying to understand why people voluntarily use React, I still don&#x27;t get it.<p>I&#x27;ve concluded that either I&#x27;m officially in my dinosaur years or the current generation of web developers are experiencing a collective hallucination.<p>Sam Stephenson made a really good point in this excellent video introducing Turbolinks 5:<p>https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=SWEts0rlezA&amp;t=3m22s<p>Unless you&#x27;re Facebook or Google, you likely don&#x27;t have the same problems they do. Just because Facebook needs to reimagine the Button doesn&#x27;t mean that you should do that on your MVP. Lest you accuse me of being hyperbolic, there are over a million instances of &quot;button.jsx&quot; on GitHub:<p>https:&#x2F;&#x2F;github.com&#x2F;search?q=button.jsx&amp;type=Code<p>Googling for answers to explain why people use React:<p>- you can build &quot;reusable&quot; components<p>- the virtual DOM is easier to work with and faster to update<p>- you can finally blend all of your HTML, CSS and view logic into one file using a weird JS&#x2F;HTML hybrid that has all sorts of quirks<p>- you no longer have to write CSS... write it as a JS object, it&#x27;ll be awesome<p>- easy to learn in just a few hours<p>I don&#x27;t have any of these problems, and no project I&#x27;ve ever worked on would have benefitted from someone announcing that instead of getting a proof of concept working they would first focus on reimplementing the concept of form elements. As for it being easy to learn... ¯\_(ツ)_&#x2F;¯<p>I genuinely want to be convinced or at least understand why this library is so popular. Give me your best examples of how React made something easier, better, faster. What justified the pain of throwing out 20+ years of accumulated best practices?
======
acemarke
Which specific "best practices" are you referring to?

Ignore the CSS-related discussions for now. React itself doesn't care how you
handle the CSS in your app. You can write standalone stylesheets and match the
classnames in your HTML output, same as you always have, write inline styles,
or use one of the fancy new "CSS-in-JS" libs that have popped up.

Other than that, the aspects of "reusability" and "easier to work with than
hand-written DOM manipulation" are certainly true. "Easy to learn" is just an
observation, not a reason to use it.

In general, React is beneficial if you're doing any kind of interactive
client-side application, regardless of how big your company is. It provides a
consistent mental model for how your app is constructed and updated: given
some set of state values, the resulting UI output will be X, and the data and
updates flow top-down in the tree. This becomes more valuable as the size of
the client-side logic and UI grows.

I'd suggest taking some time to actually try out React and get a feel for how
it works in practice. The easiest way to do it is to open up
[https://codesandbox.io](https://codesandbox.io) and start a new React
project.

Here's a couple meta-links that may be helpful for learning more.

My suggested list of resources for getting started with React:

[http://blog.isquaredsoftware.com/2017/12/blogged-answers-
lea...](http://blog.isquaredsoftware.com/2017/12/blogged-answers-learn-react/)

My React/Redux links list:

[https://github.com/markerikson/react-redux-
links](https://github.com/markerikson/react-redux-links)

If you've got any further questions I can help with, ping me @acemarke on
Twitter. Also, come by the Reactiflux chat channels on Discord. The invite
link is at [https://www.reactiflux.com](https://www.reactiflux.com) .

~~~
peteforde
Also, to actually answer your question, the best practices I'm referring to
include:

\- server-side generated pages on demand

\- a mature set of CSS-stylable HTML elements and form interactions that
behave in a predictable manner without having to write code

\- templates that include little or in some cases no logic

\- the ability to View Source

I've actually worked with React, in small bits. I've done several tutorials
and they each required extensive Stack Overflow troubleshooting because
something evolved.

Code reuse can devolve into a holy war. I guess I find myself working on
projects where you have your site templates - which is more of a visual/design
language concern that isn't going to translate to other sites - and then you
have your application functionalities that do the important things that people
want to pay you for, and they too aren't going to be endlessly repeated. So I
see a lot of journeyman devs putting energy into reusable components that
don't make sense to reuse - and the ones that did ended up getting forked
anyhow.

What I have fallen in love with is Stimulus. It feels like the right amount of
structure and interaction/event handling, with no attempt made to reinvent
what HTML is. I don't understand why it's not more popular.

When I look at what's actually in those button.jsx files, I'm floored by the
idea that this is either easy to learn or simpler than just using <input
type=button>.

We also might have to agree to disagree about what constitutes easier to work
with the DOM. I just don't find working with a hierarchy of nodes with
properties to be anywhere close to the hard part of building a web
application. And I've never built anything that needs to be updated in such a
way that it strains a modern device to render it. Maybe if I was building
GMail or a spreadsheet, but most people are not building that. People are
starting new projects asking which JS framework they will use and not
questioning whether they need one at all.

------
eschutte2
Hmm... I'll go ahead and give you my opinion since I might have a similar
background to you (I worked in classic ASP too) and I love React.

1\. It's small. You could implement it in 100 lines of code if you wanted to.

As an example of an alternative that I skipped, Angular was very popular a few
years ago, but it never appealed to me. I didn't like the dependency
injection, magic variable names, etc. that seemed heavily influenced by Java.
React does only one thing (take some data and render a view of it) and does it
exactly right, IMO. I was on a team in 2006 where we were trying to achieve
basically this on top of ASP.NET but never got it right. So when I saw React I
thought: finally! I never really liked Rails either, so your opinion might
differ here.

2\. Having your UI defined declaratively as an unambiguous projection of your
data is extremely powerful. It makes it vastly easier to reason about what
you're seeing in the app and how a change will affect it. I actually liked
this in WPF as well when I worked with it briefly long ago. It felt like some
web people had snuck into Microsoft and managed to ship a framework before
being discovered.

3\. Following naturally from #2 but not strictly part of React, encapsulating
state transitions and then replaying them, rewinding them, etc., all fall out
automatically. Making a change to your SPA and having the browser hot-reload
all the code and put you back in exactly the same state was a great feeling
the first time it happened for me. Maybe Rails or whatever does this too, I
don't know.

I don't like mixing styles and code either. I still favor CSS outside JS.
That's not part of React.

Oh yeah, you asked for examples. Well, it was trivial to implement undo/redo
on a recent project. Debugging is much easier. Testing is easy to automate.
There are so many times I've thought "that was easier than it should have
been" that I can't remember specifics at the moment.

~~~
peteforde
Thanks for this. I grinned when you described WPF as feeling like it snuck in
under the door. Too bad that they caught on.

Feel free to describe how React makes debugging easier. Is it the Inspector
plugin for object interrogation, or something more intrinsic to the style of
development? I am genuinely surprised to see this offered because it seems
like there's so much more code surface to go over for things I currently
consider simple like handling an event on a button.

At any rate, the reason I asked the question in the first place is because I
genuinely want to feel the enlightenment of understanding WTF you mean when
you say that a declarative, ambiguous projection of your data is easier to
reason about than, say, iterating through a table and writing out the values.
I feel like everyone has the good dope but me.

~~~
acemarke
Two things:

\- The data flow is predictable. Something wrong with a portion of the UI?
Look at the render method. Something wrong with the data? Look at its state,
or follow the data flow back up the tree. Related to that, it mostly
eliminates a lot of issues you'd see in jQuery-type apps, where you'd see
logic like `if($someElement.is(":visible"))`, because you don't have to write
the logic that handles all those transitions manually - you just specify what
you want the UI to look like _now_, and React takes care of it for you.

\- Yes, the React DevTools browser plugin is a huge benefit to debugging (and
ditto for the Redux DevTools plugin, although that's for a separate library).

~~~
peteforde
Thanks!

For what it's worth, I can definitely appreciate how stateful components can
make implementing command pattern concepts a lot easier. One thing I really
don't appreciate about the web is that we kind of forgot about Undo... much
less Photoshop Undo.

