5 ms·

I don't get what the benefit of using React is, aside from having it on my resume. A virtual DOM? What does that get me? It renders faster? Rendering speed is n

I don't get what the benefit of using React is, aside from having it on my resume. A virtual DOM? What does that get me? It renders faster? Rendering speed is not a problem my CRUD screens have. Etc., etc. Perhaps some UIs are so complex and dynamic that they're easier to build and maintain using React. I'm not saying other people shouldn't use React, but I'm fairly certain it wouldn't give me enough payback to justify the investment it requires.

hamandcheese 8y ago
Even if you don’t need it for its speed, it’s a fine choice if only to use JSX for your templating. Aside from that, it and a handful of other technologies (webpack, maybe redux) seem to be coming out ahead as industry standard for SPAs. So yes, learn it “for your resume”, or as I like to put it, “staying employable”. Edit: this is assuming you already have a SPA based CRUD app. If you are rendering server side then by all means keep doing that.
camdenreslink 8y ago
Its top down `(props) => rendered view` paradigm is a breath of fresh air if you've ever spent a significant amount of time in an Angular 1.x application with a complicated web of watchers and scope sharing all over the place.
- tenaciousDaniel 8y ago
  I'm currently still on Angular 1 at work. We migrated to 1.6, where they introduced Angular.component(). It's actually very nice, since it allows for explicit I/O and enforces isolate scopes. It's actually made Angular 1 enjoyable for me.
diggan 8y ago
Not sure what you're trying to say here. Sounds like you don't need React, and that's perfectly fine. I've had applications like that as well. React becomes useful when you have really complex and dynamic websites, not when you're building basic CRUD todo applications.
- rhapsodic 8y ago
  >React becomes useful when you have really complex and dynamic websites, not when you're building basic CRUD todo applications I realize you're just trying to be dismissive, but in point of fact, my CRUD applications are far more complex than basic todo applications.
  - diggan 8y ago
    Sorry, was not meant to be dismissive, maybe the "basic" and "todo" was too much. Basically, unless you need dynamic elements on a page, you're better off without JavaScript. If you have lots of them, React might help.
  - ben509 8y ago
    You can do a fairly complex system by yourself with a simpler scheme because you have a mental model of how things are organized. It's when you throw more developers into the mix that you run into issues.
    - rhapsodic 8y ago
      >You can do a fairly complex system by yourself with a simpler scheme because you have a mental model of how things are organized. It's when you throw more developers into the mix that you run into issues. I think that's a fair point. And I think others have remarked that it illustrates Conway's Law.[1] For a front end like Facebook's, that has numerous moving parts, developed by different teams scattered all over the world, and those parts have to fit together and work together in combinations that may not even be foreseeable, then a framework like React may be the only possible way it could be successful. [1] https://en.wikipedia.org/wiki/Conway%27s_law https://en.wikipedia.org/wiki/Conway%27s_law
  - swman 8y ago
    Then don't use react if you don't need/want to. However, it certainly makes many things easier for development for complex applications especially on greenfield projects.
ben509 8y ago
> I don't get what the benefit of using React is It's frontend technology that is robust enough to deliver Facebook. If you haven't worked on or aren't working on a complex UI with a team of developers, you might not appreciate how incredibly solid React is. This isn't something that can be explained well through anecdotes, but this comment is getting at it: > Its top down `(props) => rendered view` paradigm is a breath of fresh air if you've ever spent a significant amount of time in an Angular 1.x application with a complicated web of watchers and scope sharing all over the place. The complicated web issue isn't peculiar to Angular. Many UI frameworks are modeled in such a way that they become a rats' nest of objects, events, etc. all firing back and forth. Using React with good practices enable an overall structure that mitigates that tremendously.
- olavgg 8y ago
  Actually, I find the DOM surprisingly structured for reading and manipulation. This button have one or more events? No problem! Want to see the code in that event, no problem. The DOM is the truth, and you are free to read, understand and modify it as you like. What is a problem though, is that there is no consensus in the team about how the code should be structured. So everyone creates their own mess. Oh state management? There is something called observer pattern for that.
pests 8y ago
The virtual DOM is an implementation detail and is codified as separate packages react and react-dom. React gets you a consistent UI paradigm (state->ui) that scales well as your app gets more complex or as more members are added to your team.
jwr 8y ago
Let me add a different point of view. The adoption of React in the world of ClojureScript was pretty much instantaneous and total. I don't think anybody writes ClojureScript webapps in any other way these days. But the way React is used is different: it's used as a smarter mapping from application state to DOM. Clojure and ClojureScript programmers already know how to manage state and limit its spread, React (plus the usually tiny adapter libs) was just a way to efficiently produce DOM renderings of that state. It fits like a glove. And while it's not all roses, there are fewer friction points it seems than in JavaScript (but then I think JavaScript programmers don't have it easy anyway). Plus, because of the nature of ClojureScript, most articles I read about optimizing React performance do not apply to me, because all the hard work has already been done for me (for example, immutable data structures mean that you can efficiently prevent re-rendering if data hasn't changed). Anyway, to sum this up with an example that I'm basing my opinion on: PartsBox (https://partsbox.io/ https://partsbox.io/) is something I wrote, using React.
- pknopf 8y ago
  Do you have any links/resources for using React with ClojureScript?
  - l_t 8y ago
    There are a couple Clojurescript interfaces to React: Om (https://github.com/omcljs/om https://github.com/omcljs/om) and Reagent (https://reagent-project.github.io/ https://reagent-project.github.io/) are two I'm familiar with. For an example of how a Clojurescript project would be built using these libraries, I'd recommend checking out re-frame: https://github.com/Day8/re-frame https://github.com/Day8/re-frame
  - ilikehurdles 8y ago
    Easy 3 step process: 1. Assuming you have leiningen installed, run `lein new figwheel hello-world -- --reagent` and follow the instructions in the output 2. Follow along with https://reagent-project.github.io/ https://reagent-project.github.io/ 3. Enjoy a nice, refreshing beverage.
  - 8y ago
bitL 8y ago
But you can display likes and notifications realtime on top of your screen with no effort! Can't you see the immediate benefit? /s

hamandcheese 8y ago

Even if you don’t need it for its speed, it’s a fine choice if only to use JSX for your templating. Aside from that, it and a handful of other technologies (webpack, maybe redux) seem to be coming out ahead as industry standard for SPAs. So yes, learn it “for your resume”, or as I like to put it, “staying employable”. Edit: this is assuming you already have a SPA based CRUD app. If you are rendering server side then by all means keep doing that.

camdenreslink 8y ago

Its top down `(props) => rendered view` paradigm is a breath of fresh air if you've ever spent a significant amount of time in an Angular 1.x application with a complicated web of watchers and scope sharing all over the place.

tenaciousDaniel 8y ago
I'm currently still on Angular 1 at work. We migrated to 1.6, where they introduced Angular.component(). It's actually very nice, since it allows for explicit I/O and enforces isolate scopes. It's actually made Angular 1 enjoyable for me.

diggan 8y ago

Not sure what you're trying to say here. Sounds like you don't need React, and that's perfectly fine. I've had applications like that as well. React becomes useful when you have really complex and dynamic websites, not when you're building basic CRUD todo applications.

rhapsodic 8y ago
>React becomes useful when you have really complex and dynamic websites, not when you're building basic CRUD todo applications I realize you're just trying to be dismissive, but in point of fact, my CRUD applications are far more complex than basic todo applications.
- diggan 8y ago
  Sorry, was not meant to be dismissive, maybe the "basic" and "todo" was too much. Basically, unless you need dynamic elements on a page, you're better off without JavaScript. If you have lots of them, React might help.
- ben509 8y ago
  You can do a fairly complex system by yourself with a simpler scheme because you have a mental model of how things are organized. It's when you throw more developers into the mix that you run into issues.
  - rhapsodic 8y ago
    >You can do a fairly complex system by yourself with a simpler scheme because you have a mental model of how things are organized. It's when you throw more developers into the mix that you run into issues. I think that's a fair point. And I think others have remarked that it illustrates Conway's Law.[1] For a front end like Facebook's, that has numerous moving parts, developed by different teams scattered all over the world, and those parts have to fit together and work together in combinations that may not even be foreseeable, then a framework like React may be the only possible way it could be successful. [1] https://en.wikipedia.org/wiki/Conway%27s_law https://en.wikipedia.org/wiki/Conway%27s_law
- swman 8y ago
  Then don't use react if you don't need/want to. However, it certainly makes many things easier for development for complex applications especially on greenfield projects.

ben509 8y ago

> I don't get what the benefit of using React is It's frontend technology that is robust enough to deliver Facebook. If you haven't worked on or aren't working on a complex UI with a team of developers, you might not appreciate how incredibly solid React is. This isn't something that can be explained well through anecdotes, but this comment is getting at it: > Its top down `(props) => rendered view` paradigm is a breath of fresh air if you've ever spent a significant amount of time in an Angular 1.x application with a complicated web of watchers and scope sharing all over the place. The complicated web issue isn't peculiar to Angular. Many UI frameworks are modeled in such a way that they become a rats' nest of objects, events, etc. all firing back and forth. Using React with good practices enable an overall structure that mitigates that tremendously.

olavgg 8y ago
Actually, I find the DOM surprisingly structured for reading and manipulation. This button have one or more events? No problem! Want to see the code in that event, no problem. The DOM is the truth, and you are free to read, understand and modify it as you like. What is a problem though, is that there is no consensus in the team about how the code should be structured. So everyone creates their own mess. Oh state management? There is something called observer pattern for that.

pests 8y ago

The virtual DOM is an implementation detail and is codified as separate packages react and react-dom. React gets you a consistent UI paradigm (state->ui) that scales well as your app gets more complex or as more members are added to your team.

jwr 8y ago

Let me add a different point of view. The adoption of React in the world of ClojureScript was pretty much instantaneous and total. I don't think anybody writes ClojureScript webapps in any other way these days. But the way React is used is different: it's used as a smarter mapping from application state to DOM. Clojure and ClojureScript programmers already know how to manage state and limit its spread, React (plus the usually tiny adapter libs) was just a way to efficiently produce DOM renderings of that state. It fits like a glove. And while it's not all roses, there are fewer friction points it seems than in JavaScript (but then I think JavaScript programmers don't have it easy anyway). Plus, because of the nature of ClojureScript, most articles I read about optimizing React performance do not apply to me, because all the hard work has already been done for me (for example, immutable data structures mean that you can efficiently prevent re-rendering if data hasn't changed). Anyway, to sum this up with an example that I'm basing my opinion on: PartsBox (https://partsbox.io/ https://partsbox.io/) is something I wrote, using React.

pknopf 8y ago
Do you have any links/resources for using React with ClojureScript?
- l_t 8y ago
  There are a couple Clojurescript interfaces to React: Om (https://github.com/omcljs/om https://github.com/omcljs/om) and Reagent (https://reagent-project.github.io/ https://reagent-project.github.io/) are two I'm familiar with. For an example of how a Clojurescript project would be built using these libraries, I'd recommend checking out re-frame: https://github.com/Day8/re-frame https://github.com/Day8/re-frame
- ilikehurdles 8y ago
  Easy 3 step process: 1. Assuming you have leiningen installed, run `lein new figwheel hello-world -- --reagent` and follow the instructions in the output 2. Follow along with https://reagent-project.github.io/ https://reagent-project.github.io/ 3. Enjoy a nice, refreshing beverage.
- 8y ago

bitL 8y ago

But you can display likes and notifications realtime on top of your screen with no effort! Can't you see the immediate benefit? /s