3 ms·

Can you dumb this down slightly for an "early" developer with a real world example by any chance? I'm not grokking the significance of why changing everything

• orthoganol 11y ago
  It's just nicer to use if you have complex UI. OP's response was poor IMO, just because something follows some abstract principles doesn't necessarily give it value for us. I'll give you examples of things I've worked on where React made sense & where it didn't: -E.g. use React (or Backbone, Angular, etc.): A real-time document editor, with many interacting components, with lots of real time updating of the UI. Definitely needed a framework like that, and it was great. -E.g. don't use React, because in these cases it's a total Rube Goldberg machine (extra steps to achieve the exact same outcome): Basic web app with some ajax submissions, adding results to DOM type of stuff. Maybe small html fragments cloned, inserted by jQuery. No extra fancy client interactivity. ^If people claim you should use React for the latter (undoubtedly some will), they are very likely just people who follow trends to follow trends, or maybe don't have a ton of web experience and it's one of the few things they've learned and are sticking to. It's just so unnecessary (not to mention 100kb+ of overhead, & in my experience comes out to about x3 the amount of code). But yeah, absolutely use React if it's anything like the first use case.
  • hodwik 11y ago
    What technologies would you prefer for the latter case?
    • meestaahjoshee 11y ago
      "Basic web app with some ajax submissions, adding results to DOM type of stuff. Maybe small html fragments cloned, inserted by jQuery." regular old html and jQuery + ajax.
  • xixixao 11y ago
    1) React does not make simple apps overly complex. It might feel like more work if you are more used to jQuery. If you are used to React instead, it really won't have a huge negative impact on a small app. 2) React will scale. It will be a much better vehicle for future development (as you admit, it is more suited for more complex cases than jQuery). I was not making a judgement on the value of the approach, although I personally believe that this paradigm shift has a huge positive impact and is applicable in lots of cases. If I can choose between lots of computation intertwined with state mutation and a declarative approach where the mutation happens on the smallest scale, up the call stack, I will always choose the latter (of course, unless you have to mutate to gain performance).
    • orthoganol 11y ago
      I didn't say it's more complex, I just said more steps. Yes, if app is planning on being more complex, sure use Angular or Backbone or Ember or React. Otherwise, don't. Your pet projects sure, use it; if my team is billing clients, I've learned from experience, you're screwing them if you're not just using basic jQuery or even raw JavaScript which is a lot better to work with these days. If your reasons are only rooted in your abstract preference of design ideals w/o looking pragmatically at the situations, you're likely doubly screwing them. Fyi this "paradigm shift" is like 8 years old, React is not disruptive, it's just another variation.
• thedufer 11y ago
  Pre-React, you would often duplicate every bit of logic. You end up with "here's what you do on first render" and then for each mutable bit you have "here's how you change the DOM to get it back to the right state". With React, you only write the first one, and just re-render all the time. The interesting part of React is how it keeps that performant.
• grayrest 11y ago
  Have you done Backbone? The idea is that you define everything in terms of models and that when one of those models change you call render() to run it through your templates and you're done. This is a simple conceptual model, the framework needed to execute it is simple (and well written in the case of Backbone), and it works really well for simple applications. The problem arises when you can't just call render: when you have input fields, when your rendered DOM has event listeners, when you're using a component with it's own internal state (e.g. a jQuery datepicker), or when you're doing something like a grid and generating too many DOM nodes. Unless you know this is coming and have a plan for dealing with it (e.g. the many Backbone addons), this is a complexity land mine since it does not show up in the small apps you build while testing out the framework. You can (and I do) view the React render as an idempotent projection from state to DOM, otherwise known as a template. React is a very fancy template system. You build your fragments (components) up into views, pass in your data, and render the entire page as if you're rendering it from scratch. It handles or provides hooks for all the situations I mentioned in the previous paragraph and React's internals ensure that it's reasonably performant by default. Having everything conceptually fully render from scratch every change means there's no separate handling for the initial render versus updates to the initial render (e.g. you have an accordion, render it with an ejs template but toggle it open/close by toggling classes). It makes the Backbone model work in a way that's easy to reason about. A real world example: I've implemented (B2B, not something I can link) a drag and drop layout builder as a contract. The workalike they wanted, which I had also worked on but didn't design, was ~6k lines of node/class manipulation and mousenter/leave hit testing while my React version worked out to be around 600 lines, most of which were generating virtual screen position hitboxes for the various drop zones. Hovering/dropping in a zone changes attributes in a list of JS objects and the visual feedback is handled by the rendering code you'd need to draw the layout anyway plus another 20% for the drop previewing/hovering. Most savings aren't as dramatic but in general you wind up spending less effort getting your views right. The LoC isn't always that much lower but it's template code instead of manipulation code. There are other benefits like component composition just working, server side rendering, putting all your app state in one place lets you do session recording and time travelling debugging but this post is long enough as is.
• xixixao 11y ago
  This is a more general declarative vs imperative question so if you search for "declarative programming", you should find lots of examples. But here is one, taken from Bret Victor[0]: Consider a classic drawing API: // stem fill('green') rect(146, 60, 8, 200) // flower fill('red') circle(120, 30, 50) // leaves ellipse(173, 120, 40, 20) ellipse(123, 130, 40, 20) Now, imagine we first wrote the code for stem and leaves, than later added the code for the flower (in the reference, copied it from elsewhere). The code has a bug in it - the leaves are red. This is just one example: once you have a "hidden" state, you have to manage it. You always have to be aware of the effects that every line makes on the state and how the state affects the other lines. A "React"-like (simply declarative) API would look more like: stem = filled('green', rect(146, 60, 8, 200)) flower = filled('red', circle(120, 30, 50)) leaves = [ filled('green', ellipse(173, 120, 40, 20)) filled('green', ellipse(123, 130, 40, 20)) ] plant = [stem, flower].concat(leaves) ... draw(plant) The code is now referentially transparent, I could replace uses of variables by their values and nothing would change, since the functions have no effects. The effects are pushed to the edge of the code, in this case the call to draw which actually performs the drawing, or when React updates the DOM with the results obtained from a render method. http://worrydream.com/#!/LearnableProgramming http://worrydream.com/#!/LearnableProgramming