4 ms·
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
by 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 agoThanks 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 8y agoTwo 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 8y agoThanks! 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.
- eschutte2 8y agoAdding 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.