5 ms·

Ask HN: What is the draw of React?

• acemarke 8y ago
  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-learn-react/ http://blog.isquaredsoftware.com/2017/12/blogged-answers-lea... 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 8y ago
    Thank you! I look forward to going through the links.
  • peteforde 8y ago
    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 8y ago
  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 8y ago
    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.