Hacker News Reader

Comment by mietek | Hacker News Reader

I've just gone through a similar process of reviewing and discarding a number of JavaScript frameworks. I've settled on React, and I can't recommend it enough!

React handles mostly the V in MVC, and does an admirable job of it. It even provides a cross-platform event abstraction, which would've saved the author some trouble.

http://facebook.github.io/react/

http://facebook.github.io/react/blog/2013/06/05/why-react.ht...

http://facebook.github.io/react/blog/2013/11/05/thinking-in-...

Now, how about CSS? So far, I've reluctantly chosen Bourbon + Neat + Bitters, which are nice, but not ideal. I appreciate the Sass and semanticism (semanticness, semanticitivity) of it all — no more Bootstrap-like class names in my HTML! However, there aren't enough examples of real pages built with these tools.

Thoughtbot, if you're listening, why not publish at least the Sass sources of these webpages?

http://bourbon.io

http://neat.bourbon.io

http://bitters.bourbon.io

View on HN

Hey, we're listening. The source code to all of those sites is actually already public, in the gh-pages branch of each of their respective repos:

https://github.com/thoughtbot/bourbon/tree/gh-pages

https://github.com/thoughtbot/neat/tree/gh-pages

https://github.com/thoughtbot/bitters/tree/gh-pages

I hope that helps! -Chad

The biggest cause of bugs before we used React is the fact that the "state" of the app is leaking all over the place. Symptoms were things like looking for dom nodes that didn't exist, events that triggered on code that was no longer active, bugs due to the app being in a state extremely complex to reproduce with crazy conditions all over the place, race conditions...

React does many things to mitigate those problems and those classes of bugs nearly dropped to 0.

- The code you write is declarative: you say how you want the dom to look like. This means that you no longer have two pieces: creation and retrieval that need to be kept in sync.

- React manages the life cycle of the components. When the component is no longer being rendered, it is properly destroyed, all the listeners are destroyed ...

- The render function is pure. This means that it is easier to write and unit test.

- The code is organized into small, composable and unit testable modules. By having a lot of small components it makes writing complex bug-free code easier.

- Each component has a very well defined interface. It cannot use anything else without it being obvious. This prevents the creation of big chunks of interdependent modules that are impossible to separate.

- There is a single point for state update. This makes the high risk pieces of code stand out.

In the end, we found that React actually helped us write more reliable app compared to framework-less Javascript code.

Mutable state can be a huge time sink. It's why I'm putting more and more time into functional programming, since I think that Haskell (and Clojure) is closer to what programming in the future will be like.

I think many programmers don't respect how much complexity is reduced when state isn't leaking all over the place.

Of course there will always be times when you need state, but many times its worth jumping through a few hoops to make things work without state.

EDIT: If programmers learn C so they can think lower level, they should learn Haskell so they can think in terms of side effects, composability, and the advantages of pure functions. Just a reminder, pure functions can be created in any language though some (Clojure, Haskell) enforce purity.

I had the same thought while reading the article. React seems great for people who don't need many libraries to develop complex web apps.

What do you use for the models and routing?

I haven't decided yet. I'm looking at using just the necessary parts of Backbone. Spine was also promising, but seems abandoned.

So you are basically saying that something is great without having worked with it on a production-grade project... Not saying React is a bad library, quite frankly it's the opposite, but your reasoning is surprising. In the future, avoid advising things you have not played extensively with.

+1 react, I also believe it would satisfy OP's need. React is going to take over the world in the next 5 years

React is a view + template, not a framework.

From the React site: "React as the V in MVC".

It's perfectly normal to combine react with something like Backbone as more complete solution.

React components are controllers too. "componentDidMount" == controller event. They are lightweight controllers, though.

@Touche True. It's perfectly reasonable to add a model/data layer to React as a final/complete solution. In such a situation a heavy weight controller can be skipped.

I would recommend http://enyojs.com/

Reply on news.ycombinator.com