Live data from Hacker News

Ask HN: ReactJS – Do you use it? Do you like it?

news.ycombinator.com

41–50 of 78 posts

Re: Ask HN: ReactJS – Do you use it? Do you like it?

#41
Yes, I use it at work. Yes, I'm happy with it. My thoughts are:

The core idea behind React is that it makes a ton of sense to think about views as being composed of pure functions which transform (immutable) data into a DOM. It's a very good idea, and React is a good (and certainly the most popular) implementation of it.

It's not hard to implement in a way which is performant (which is nice), but much more importantly it lends itself to code which is easy to test and reason about.

In addition, it also works well with a flux architecture. It's not the easiest way to write a web app, but there's simply large classes of bugs or potential issues that simply don't apply if you embrace one way data flow and immutable data.

There's nothing magical about React, and there's certainly some alternatives floating around. And you can certainly write terrible React code. But it's still a pretty good starting place, and the more serious you are about the app the better. If it's large, complex, needs full test coverage, and will be maintained by a team of people for the indefinite future, React is pretty good. If it's a weekend hack project, it might be overkill.

As for particular issues I've had:

1) The React team is trying to embrace ES6 syntax (and for good reason) but it's not quite ready for prime time. Some core React functionality relies on mixins, but ES6 classes don't really support mixins. So either you write hideous ES5 code (ewww), or find weird workarounds for the not-yet-ES6 ready bits.

2) Facebook also pushes the testing library Jest, and a lot of React projects use it. Jest is so slow that many people will give up before ever seriously using it, but if you do persevere it you'll find that it's actually a steaming pile of buggy crap. A modern mocha/chai/sinon testing stack will be 100 times faster (I wish that was hyperbole), much more stable, and much better supported.

3) There's a lot of, well, flux, when it comes to flux implementations. I like Marty and Alt, which are both really good (and apparently might be merging soon), but there's several more excellent ones. Which is kind of a problem; it'll be good when things settle down.

4) React doesn't enforce immutable data, probably because it's not a mainstream concept yet, but everything works so much better when you use it. And it's a lot easier to use if you're using it from the start.

Re: Ask HN: ReactJS – Do you use it? Do you like it?

#43
I adore react. I've moved two companies to it, one on my own and one with a team, from angular and template toolkit respectively. It's been an enormous boon to each team, who have both found that it rapidly leads to clearer shorter code.

There's a dip. Your team will briefly get really screwed up, because the mind change is big, and since it's just part of the stack, after that you'll have some library support choices to make.

Try it on a side project. Once you have a gut feel for it, you'll know.

----

Edit: splelang si hrad

Re: Ask HN: ReactJS – Do you use it? Do you like it?

#44
post #20

I've moved from angular to react and i'm happy. Simple, really simple!!! interface. All you need is to remember just few methods of one (ONE!!!) class. It's fast enough to create interfaces with a lot of objects. With react and react-native i start publish my projects on github, because they has a simple structure and can be easily supported. I almost forget jQuery, it's really rare situation when i need to access re…

Your google maps component looks awesome. I'm looking at a few frameworks for my company and react is the one that I'm leaning towards (I've used angular before but react feels more performant out of the gate). We use google maps a lot so having this would be awesome!

Re: Ask HN: ReactJS – Do you use it? Do you like it?

#46
For me, the most significant benefit of using React is the community around it. Rightly or wrongly, React had been crowned as the darling of "modern front end" and that has attracted huge amounts of criticism, debates, and exploration into how we build complex UIs. Over the last year the cumulative output of those people plus the related projects such as Babel and Webpack have collectively taught me a smarter way of developing complex dynamic interfaces for the web. The highest praise I can offer is that for the first time in 15 years I feel like I can bring the same level of engineering to the frontend that has been available to us the backend - code that is predictable, reliable, testable, maintainable, and understandable by others.

Having said that, such frantic activity is a double-edged sword. React universe is a rapidly shifting beast - a particular tactic can be the recommended way today, then quickly superseded and discouraged by tomorrow. Some examples include: React's initial createClass() guidance, react-router's "final, final2, final3" API surface, react-dnd's complete and incompatible rewrite between 0.9.8 and 1.0, the many phases of the flux store evolution (from 'just arrays of data', to 'maybe ajax reads', to 'not data at all') etc. In every such case I get annoyed at first, then shortly after I become grateful for the change because the new way _is_ significantly better and it _does_ lead to my app code being appreciably better in structure/flexibility/agility etc. This is great for continuously evolving products - our quality increases with each such iteration. But this can be difficult to budget for, or I do not enjoy going back to the rest of the team with the news that what I asked them to do before should now be avoided. We all learn and our core product benefits, but these quality and engineering efforts are a cost that not every team can maintain indefinitely.

Lastly, React is relatively unopinionated itself which means everyone has a different way to consume it. The freedom is there, and I see many teams using it to shoot themselves in the foot. Take the concept of Flux for example - for clean and maintainable code, very few components should ever have the word 'flux' or 'action' or 'store' in them. The overwhelming majority (>80%) of components should be ridiculously stupid, have no state, and certainly know nothing of flux. But the temptation is there - "oh I'll just drop flux inside and boom I have this power to do anything I want from my ProductSummary component"). This leads to the project having way too many moving parts, overpowered components acting at will, unauthorised data access points which cause subtle bugs, and the project ends up being the same unpredictable mess as we'd' have with jQuery. Yes, the rendering is done with React, but that's a hollow gain if the app is still unwieldy.

Using React demands discipline and focus to have hard boundaries between components, creating clear and predictable data/action flows, removing as much state as possible, and obsessively guarding and layering app's building blocks. Incidentally, if you do it the 'right' way, React itself will be the most inconsequential part of the system that you can swipe away with ease when a better way to write reliable interface will be inevitably discovered.

Re: Ask HN: ReactJS – Do you use it? Do you like it?

#47
post #12

I migrated nearly all of troupeit.com over to ReactJS. I really love it, but my biggest complaint has to be the mixing of logic and views together, and the duplication of security checks. Although I'm not entirely sure I can blame react for that, I blame my moving from CGI to Ajax/RESTFul interfaces for most of that pain. We had about 90% of our codebase in RoR. In retrospect, I wish I had used Flux instead of React-…

I'm using ReactJS with a rails app, and are doing so without needing the security checks on the client side.

Re: Ask HN: ReactJS – Do you use it? Do you like it?

#48
I've been using React and Flux for a few enterprise projects, and although I don't have tons of experience with browser applications it is the most helpful and pleasant JavaScript technology I've ever used (aside from maybe jQuery, but that solves a very different problem).

I agree with the people saying that "stock" Flux has a lot of boilerplate. The upside is that when you're looking to add or change code, you know exactly where to go even as the UI and business logic get complex. Some of the newer Flux implementations look like they reduce the boilerplate, but I'd like to get more comfortable with the concepts before choosing another opinionated abstraction.

Re: Ask HN: ReactJS – Do you use it? Do you like it?

#49
post #28
post #24

We recently developed a large application using Ember. It works very well, but I get the feeling it would have been a bit more maintainable had we done it with React using Flux architecture. My only gripe: React doesn't play nice with things like Emblem.js ( http://emblemjs.com/ )

You won't be needing Emblem if you use CoffeeScript and React.Dom instead of JSX. Something like... import {Div, P} from React.Dom render -> Div P {color :"blue}, "Hey"

That's actually quite helpful. Thanks!

Re: Ask HN: ReactJS – Do you use it? Do you like it?

#50

React is a pain to use with web components. The event handling in React blows up when it is rendered under shadow DOM, so building chrome extension through React can be a bit of pain. They are aware of the issue, but too slow in responding to pull requests and mostly reject them for being 'not good enough'

When we accept a pull request, we have to support that code forever, so I hope you'll excuse us for being a little bit picky in what we accept.

Shadow DOM event support should be in 0.14.

Post reply on HN