Hacker News Reader

Comment by rhapsodic | Hacker News Reader

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.

View on HN

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/) is something I wrote, using React.

Do you have any links/resources for using React with ClojureScript?

There are a couple Clojurescript interfaces to React: Om (https://github.com/omcljs/om) and Reagent (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

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/

3. Enjoy a nice, refreshing beverage.

One point about libraries: I would recommend starting up with Reagent, as it has a simple and fairly intuitive model, and then moving on to Rum, which allows you to do anything, while being small and elegant.

I do not recommend Om for starting.

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.

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.

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

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.

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.

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.

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

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.

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.

>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

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.

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.

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

Reply on news.ycombinator.com