Comment by dwg | Hacker News Reader

Comment by dwg | Hacker News Reader

I recently finished building a small-ish web app for a major federal Government customer in react.js. They are very happy with responsiveness and quality of the product. I'm very happy with how easy and cost-effective it was to build.

To get an idea of the size of the app, it has about 20 components. However, some of the components could (and probably should) be broken down. My hunch is that with refactoring the final number would probably be around 30 to 40.

Other frameworks that I have used professionally include Backbone.js, Knockout.js, and Angular.js. My subjective (i.e. non-scientifically-measured) experience with React.js was that it took less time to build a comparatively sized application, and there were fewer bugs. All frameworks have a learning curve, but I felt React.js was pretty easy to get into. There are not a lot of "things" you have to learn about. In this project I didn't have to train anyone else to use React.js, but I believe it would have been relatively easier to do than training for other frameworks, which I have also done in the past.

The bottom line is that my experience was very positive and I will definitely use React.js again on future projects, should a suitable one come my way. I'm sure react.js could be better, but the authors recommendation not to use it based on not being pure enough is total bs.

As is covered ad naseum else where, ReactJS is just a way to do Views.

What did you use to manage state, data flow, communication to servers, etc?

You can actually do a lot of that stuff with JavaScript, it turns out.

yeah, let's be cool guys to the end and use VanillaJS only.

So you end up with an unmaintainable pile of javascript?

Or are advocating reinventing the wheel and writing a bunch of boiler plate javascript to marshal data, update state, etc?

----

One major reason to use a JS framework is to enforce good design and coding practices to allow for more maintainable code.

You can certainly implement these patterns yourself in Javascript, but you are reinventing the wheel, which is an antipattern in pretty much all but the edgiest cases.

React abstracts away the stuff that usually makes JS complicated, like DOM manipulation, or dealing with observables. What you're left with is view components that you can just stick a regular JSON tree into. For instance, updating state is something that you don't really need to do in React. Just update your JSON tree, and your interface will match. And JS is really good at monkeying around with JSON.

There is some stuff like routers etc. that you might not want to write yourself. Luckily there is a universe of components you can choose from, instead of one that some guy at google thought was good.

Used refluxjs for data flow. Inside the stores, superagent is used for request handling. React-router was used for routing.

Once I finally grok'd the implementations of Flux, I found the it to be a decent layer ontop of ReactJS.

Of the implementations of Flux, Reflux is pretty good, with less hassle of a centralized dispatcher, and extra boilerplate.

What I don't get is that the `trigger` is essentially a store created action, which goes against the unidirectional data flow model.

I definitely found Reflux to be more understandable and easier to put into practice than Flux in general. They trade-off some purity and flexibility for simplicity.

That said the stores and trigger method are definitely one of the rougher areas in the app. Thinking back, the stores were probably the largest source of bugs, but they also contain more logic so it's reasonable to assume they would have higher bug density.

Reflux was a great stepping stone, but this is the area I would most like to refactor and/or spend more time on in future projects. Fortunately there's a lot of interesting work going on in this area right now.

It's worth mentioning that this was not an issue the author even brought up, I assume since React doesn't claim to handle any of these other concerns in an application. Saying React doesn't handle these functions is like complaining about a screwdriver not being able to hammer a nail very well.

It's also worth noting that this sub-thread is in response to another commenter, not the original article.

"Other frameworks", but React is not a framework, just UI lib :) Sorry to be pedantic, but framework gives much more often.

Quite alright—I'm usually very precise on these matters as well.

Nonetheless I disagree with the point. My opinion after actually having used React.js is that it is more than a UI library. I've used other UI libraries and React.js is more "comprehensive." I do grant, however, that React.js alone will not suit most needs. You will generally want to add a few other pieces. In my case I also used refluxjs and react-router. I also used store.js as an abstraction for browser storage.

Reply on news.ycombinator.com