Live data from Hacker News

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

news.ycombinator.com

61–70 of 78 posts

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

#61

I like React because it's closer to JavaScript than any other JS library I've used. The public API is tiny; you get better at React by getting better at JavaScript. The only thing I don't like about React is the rapid churn in architecture best-practices (Flux et al). This is in stark contrast to Ember—which nails conventions and tooling but is written far about vanilla JS. We use React because components are a great…

> ...rapid churn...

This is why I'm sticking with Knockout for probably another year or so. It's tiny, safe, easy, stable and it's already been proven to work for large apps.

It also has a beautiful component system and since Knockout simply stays out of your way, you get to focus on Javascript. When the churn dies down in React-land, maybe I'll take another look.

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

#62
I've used it on a few personal projects with a koa powered API on the backend and one smaller project at work. I like it a lot, I've tried angular and jquery as well, both really don't stack up at all.

One thing that I wish was different was the focus on using flux. Flux isn't really for me, I found it really complicated and it made following the data through my app even more complicated than it was with angular.

The solution for me was to use something like Om's cursors (specifically baobab https://github.com/Yomguithereal/baobab). After trying to get a handle on flux for a few days I switched to baobab and the real power of reactjs just clicked for me.

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

#64
post #13
post #11

Earlier quoted context omitted.

Would you mind elaborating on the TypeScript comment? Is anything broken or just suboptimal?

It's suboptimal and obscure. There is barely any up to date resources on it. So far I've managed to get to stuff presented on the window, but as soon as you start messing with references to the DOM components, things start to break down. It's a shame, I really think Typescript and React would be the answer to getting a decent code base. One of the cool parts, is that you get to define what your property is with stati…

Thank you. I'd love to use these together.

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

#65

I love it. The only things that could be improved are: - some components in the ecosystem are more hobby projects and have trouble keeping up with React's API, even though it's small. - Documentation for react-native could be a bit better (but react-native is amazing). - I still haven't found a nontrivial and non-bloated example of react hot loader config, and getting it working on an existing project seems to be a b…

Hi grandalf! Which sections do you think are most lacking in the react native documentation? I've put some time into improving it this week by adding:

- https://facebook.github.io/react-native/docs/animations.html...

- https://facebook.github.io/react-native/docs/direct-manipula...

- https://facebook.github.io/react-native/docs/navigator-compa...

I'd love to hear where you think I should be spending my efforts next.

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

#66
post #7

I tried it for a small project, but end up using Mithril.js for all my new projects instead. JSX, OOP, and Flux may be fine for some people, but I prefer to use plain, functional JavaScript.

I know that React likes to use the ES6 `class` syntax, and `React.createClass` otherwise, but the spirit of React seems very rooted in functional programming to me. Create pure functions that return data, no side-effects; use immutable data structures; minimize state where possible. I'm curious what about React gives off an OOP smell, besides the (admittedly curious) choice of syntax?

You said it: class syntax and React.createClass. In Mithril, a component is a plain JS object with two properties (controller and view).

Functional programming can mean many things, and no side-effects is one of them. However, JavaScript does not support immutable data structures very well, and React suffers by trying to force it, which results in unnecessary boilerplate code for common actions. Mithril does not enforce immutable data (though you can use something like immutable.js if you want to); it embraces JavaScript-the-language better in general.

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

#67

I've used it for multiple apps at this point and it's been a huge win for me in terms of productivity (I'm also quite enjoying Reagent with ClojureScript so far, but I'll withhold judgement on that for now). Trying to apply simple FRP-style abstractions over state changes like Signals becomes infinitely more tractable in React, where components are just functions that return data (as opposed to most frameworks, like…

This might help explain where flux is useful http://briandipalma.github.io/flux-for-components/

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

#68
post #59

I've used it for multiple apps at this point and it's been a huge win for me in terms of productivity (I'm also quite enjoying Reagent with ClojureScript so far, but I'll withhold judgement on that for now). Trying to apply simple FRP-style abstractions over state changes like Signals becomes infinitely more tractable in React, where components are just functions that return data (as opposed to most frameworks, like…

The point of flux is one way data flow. Your data lives in ONE place (the "store"), and then it's fed into your views, which render it in a deterministic fashion. User interaction triggers actions, which circle back around to modify the data in your stores. Data should only be modified by actions, and views should only change when your data does. There's a lot of advantages to this (in terms of performance, but much…

Okay thanks, that actually clears things up a lot. Funnily enough, I found myself using this exact pattern in ClojureScript yesterday, using a ratom as my store and having what I suppose I should call "actions" which (may make HTTP calls and) update the data.

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

#69

I've used it for multiple apps at this point and it's been a huge win for me in terms of productivity (I'm also quite enjoying Reagent with ClojureScript so far, but I'll withhold judgement on that for now). Trying to apply simple FRP-style abstractions over state changes like Signals becomes infinitely more tractable in React, where components are just functions that return data (as opposed to most frameworks, like…

How you liking Reagent? Why did you choose that over Om?

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

#70

I've used it for multiple apps at this point and it's been a huge win for me in terms of productivity (I'm also quite enjoying Reagent with ClojureScript so far, but I'll withhold judgement on that for now). Trying to apply simple FRP-style abstractions over state changes like Signals becomes infinitely more tractable in React, where components are just functions that return data (as opposed to most frameworks, like…

How you liking Reagent? Why did you choose that over Om?

Honest answer? It seemed simpler. I haven't used Om yet so I won't try to compare the two, but Reagent presents very simple interface. Components are just functions which emit Hiccup. Reagent's ratoms are, I'm told, much like Om's Cursors, but different in a way that I haven't investigated enough to understand. Looking at the READMEs for the two projects, Reagent just seemed more approachable to me.

While I've really enjoyed working with Reagent (I haven't encountered any real deficiencies, though that may just indicate I haven't used it enough), I'm totally open to being convinced in favor of Om.

Post reply on HN