Hacker News new | past | comments | ask | show | jobs | submit login

"React isn't a framework, it's a library!" There I said it!

Jokes aside, React provides a Virtual DOM which isn't available natively. I'm sure sometime in the future browser's DOM tree estimation and computation would be so efficient that you wouldn't need a Virtual DOM anymore. Until then, React is the best way forward. There are plenty of thin VDOM libraries (some even more efficient than React) out there but the joy of working with code written as composable Components outweighs efficiency (I'm sure those libraries would fare far worse in benchmarks if composability is put into the equation). Couple this with a library like Om/Reagent and you get FP (code as data)+immutability handed to you on a silver platter.

Without the "right" libraries you introduce a lot of incidental complexity into your application development lifecycle.




> "React isn't a framework, it's a library!" There I said it!

React is a framework though, for the most part it calls you(r components), you don't call it outside of the original binding. It's not a huge one, but it's still one.

> I'm sure sometime in the future browser's DOM tree estimation and computation would be so efficient that you wouldn't need a Virtual DOM anymore.

Browsers already batch changes and defer recomputations as much as they can. They can't significantly improve the model because it requires a different abstraction which is not available under the existing DOM.

Also, you can use a VDOM without using React and its component, several VDOM-only pure=js libraries have sprouted up e.g. https://github.com/Matt-Esch/virtual-dom (the basis for elm-html, and the Mercury react-like framework)


Well, the virtual DOM is a great concept regardless - storing diff information on JavaScript is a great optimization, even if browsers eventually optimize browser rendering speeds, one will still be able to squeeze more with this & benefitting from that optimization.


"React isn't a framework" but nevertheless includes it's own implementation of classes.


I'm a huge fan of ReactJS, however it isn't a perfect or optimal implementation of it's concepts. Having a purely functional frontend, with immutability is key. ReactJS is leaky in it's mix of imperative and declarative code. FluxJS also suffers from this same issue.

ReactJS is the gateway drug to frontend nirvana. For more info:

http://computationallyendowed.com/blog/2014/07/20/reactive-m... (MVC in a Reactive World) http://elm-lang.org (ELM Language) https://github.com/swannodette/om (Om/Clojurescript)

These will be _the_ technologies and approaches in 2015. ReactJS/FluxJS are great, but imperfect implementations!


But you can also get om in javascript with something like omniscient[1]/immutable[2], or fynx[3] for flux with immutable.

Though I agree both clojurescript and elm look nice, I'd bet you a lot of money they won't be _the_ technologies in 2015.

[1] https://github.com/omniscientjs/omniscient [2] https://github.com/facebook/immutable-js [3] https://github.com/foss-haas/fynx


I can't speak to the others, but Immutable is not in any way sufficient to replace native immutable data structures. The fact that you don't get native notation for initialization or destructuring is a huge deal in practice. Nobody wants to write 'foo.get("a").get("b").get("c")' where "foo.a.b.c" would do. (Likewise for assignment/creation.)




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: