Ask HN: What is the draw of React? | Hacker News Reader

Ask HN: What is the draw of React?

4 pointspeteforde8 comments

I'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've always seen myself as someone open to radical change. That's why I am so uncomfortable admitting that after several years of trying to understand why people voluntarily use React, I still don't get it.

I've concluded that either I'm officially in my dinosaur years or the current generation of web developers are experiencing a collective hallucination.

Sam Stephenson made a really good point in this excellent video introducing Turbolinks 5:

https://www.youtube.com/watch?v=SWEts0rlezA&t=3m22s

Unless you're Facebook or Google, you likely don't have the same problems they do. Just because Facebook needs to reimagine the Button doesn't mean that you should do that on your MVP. Lest you accuse me of being hyperbolic, there are over a million instances of "button.jsx" on GitHub:

https://github.com/search?q=button.jsx&type=Code

Googling for answers to explain why people use React:

- you can build "reusable" components

- the virtual DOM is easier to work with and faster to update

- you can finally blend all of your HTML, CSS and view logic into one file using a weird JS/HTML hybrid that has all sorts of quirks

- you no longer have to write CSS... write it as a JS object, it'll be awesome

- easy to learn in just a few hours

I don't have any of these problems, and no project I'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... ¯\_(ツ)_/¯

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?

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

My React/Redux links list:

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 .

Thank you! I look forward to going through the links.

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.

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.

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.

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

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.

Adding on to what acemarke said, with which I agree:

Defining a mapping of your table data elements to virtual DOM elements allows React to update only the rows that changed, automatically (from your perspective), which is much faster than messing with the DOM for all rows. Yes, you can do the diffing yourself, at which point you would have rewritten a lot of React.

You mentioned the button example a few times. A normal button in React shouldn't be any more code than doing it in vanilla JavaScript. All those projects with Button.jsx are doing that because they've decided they want to add behavior to a normal HTML button, and they want it consistent throughout their app.

W.r.t. debugging, I meant just reading code, but yes the tooling is very nice too.

Reply on news.ycombinator.com