16 ms·
How I learned to stop worrying and love React
- gadr90 11y agoWow, author here. Woke up to a lot of unexpected traffic on the blog. I hope you like this article. I took a long time to understand React and, now I do, I hope other people don't take as long as I did!
- speg 11y agoNice work. Hopefully you can write another one about Flux? :)
- gadr90 11y agoThanks! Next one is definitely about Flux :)
- antris 11y agoIt's a really neat article. Thanks for explaining this stuff. I have no patience for it :)
- gadr90 11y agoIt is my pleasure to be of service!
- shill 11y agoI clicked through to a few of your other recommended posts and ended up emailing myself a bunch of links to read later. I particularly enjoyed 'Promises Are Not Optional' (http://firstdoit.com/promises-are-not-optional/ http://firstdoit.com/promises-are-not-optional/) You have a talent for clearly explaining complex abstractions. Nice work!
- gadr90 11y agoI don't know about that, but I'm glad you enjoyed it! Thanks :)
- matrix 11y agoThank you for writing that article. To me, the article is pretty much how an ideal technical article should be: it doesn't assume deep knowledge of the subject matter and uses lots of examples and comparisons to make the case. It takes a lot of work to write that sort of article, I really appreciate that you took the time to do it. Looking forward to seeing the one about Flux!
- gadr90 11y agoThanks for reading! I'm glad you appreciate the effort. I spend an average of eight hours to write one small post (1398 words)!
- DougBTX 11y agoNice overview, I like how the article has the same code demo in Knockout and Angular to show how they both solve the same problem in slightly different ways. Would be nice to see the firstName + lastName demo in React too, I know the onChange stuff can be a little verbose, but would be good to show how it can be used to actually update a single central model.
- ryannevius 11y agoI went through something similar...and then I found Mithril (http://lhorie.github.io/mithril/ http://lhorie.github.io/mithril/). I may be alone on this, but I've enjoyed working with Mithril much more than I ever did React. If you haven't given it a shot, I highly recommend you do.
- tobr 11y agoWhat makes you like Mithril more? I've been looking at it for a while, and it seems very nice and lightweight. All I really want is an easy way to get performant DOM manipulations. With React I have to build the whole view around the component system, which isn't so flexible. Am I right in thinking that Mithril allows you to put the view together any way you want, as long as the end result is an object it can diff into the DOM?
- nwenzel 11y agoD3 can do DOM manipulation a. It's more well known for its charting (SVG) functionality. But I've used it to build tables and other data-based DOM structures. It's not ideal for all use cases. But for updating the DOM based on changes to the data, I find it to be a useful option. Square built and fast library on top of D3 called Crossfilter. Speed is pretty amazing when you see the data source. http://square.github.io/crossfilter/ http://square.github.io/crossfilter/
- pygy_ 11y ago> Am I right in thinking that Mithril allows you to put the view together any way you want, as long as the end result is an object it can diff into the DOM? That's correct. Virtual DOM nodes are plain JS objects with `tag`, `attr` and `children` attributes (the last two being optional). The `m()` helper gives you some sugar on top of that. Idiomatic Mithril view code, however, is more about declaratively generating vDOM nodes based on a model and/or a view model than, say, jQuery-style DOM manipulations...
- nodiscpls 11y agoNext up - how I stopped learning how to be a real developer and accepted what framework farcebook ejected today. Tomorrow - abdicating database decisions in favour of whatever I read about on HN today.
- diminish 11y agoQuestion for experts: why Browsers do not get the idea of updating changes the way react does automatically possibly with a start, stop transaction or better without.
- nathanaldensr 11y agoIt would be wonderful if browsers acted more like game engines. Collect user input and at the beginning of every rendering "frame", allow JavaScript to process the input and modify a virtual DOM. Then, render the virtual DOM. It would be so much easier to reason about web applications this way.
- DennisP 11y agoI'm messing around with ideas for an experimental hypertext engine, now you've got me tempted to try building it on a game engine. Looks like Unity might have halfway-decent text support.
- AgentME 11y agoWhenever a change is made to the raw DOM, the change has to be immediately visible to the code running after it. React sacrifices this. When the DOM is treated as the source-of-truth for the page's information, the synchronously-visible changes are very useful. However, getting away from treating the DOM as the source-of-truth, which React forces you to do, gets you a lot of power as changes to the DOM can be batched more efficiently automatically.
- jawns 11y agoI recently worked on my first React project, after working with Angular code for a while. I'm willing to accept that as an app gets more complex, React/Flux really pays off. But there's something to be said for having a single template file for a single page in Angular, versus having JSX scattered among 20+ components for that same single page in React. When you want to get a 10,000-foot-view of how it all comes together, you can (generally) do that in the code in Angular, but you're better off doing it in the browser with React. Which may not be bad, but it's a difference worth mentioning.
- fensipens 11y ago> But there's something to be said for having a single template file for a single page in Angular, versus having JSX scattered among 20+ components for that same single page in React. Good point; How does one view the resulting react-page anyway? CTRL+U shows <body><script.../></body> no matter what state the SPA is in..
- jawns 11y agoIn Chrome, there's a cool React dev tools extension that shows you the React components. https://chrome.google.com/webstore/detail/react-developer-tools/fmkadmapgofadopljbjfkapdkoienihi?hl=en https://chrome.google.com/webstore/detail/react-developer-to...
- hcarvalhoalves 11y agoThat's actually better than looking at the HTML output, unless you're debugging something really weird. With React you should treat HTML as an implementation detail and work in terms of component trees.
- jkkramer 11y agoThere's a React Dev Tools plugin for Chrome that will show a tree of components instead of the DOM.
- ble 11y ago
- kozlovsky 11y ago> However, all template languages are inherently crippled: they can never achieve the same expressiveness and power as code. Quite simply, {{# each}}, ng-repeat and databind="foreach" are all poor replacements for something that is native and trivial in JavaScript: a for loop. On the other hand, when using a template language I can put `foreach` loops and `if` conditions right into the template itself. And when using JSX I need to calculate the result of a `for` loop before the actual template and it looks much more complex and cumbersome.
- BerislavLopac 11y agoWhich is why I prefer Ractive.js to React.
- coldcode 11y agoI like it too when I read the docs but haven't been able to try it yet for anything real. Have you actually used it for real work?
- BerislavLopac 11y agoI have, and it works great. And the fact that it uses Mustache-like templates makes it much easier to collaborate with the designers.
- rattray 11y agoHave you tried using react without JSX? I find it much nicer. Putting var R = React.createElement at the top of each file will make it more ergonomic.
- escherize 11y agoThis is a great argument for using hiccup[1] and reagent[2] as well. [1] https://github.com/weavejester/hiccup#syntax https://github.com/weavejester/hiccup#syntax [2] http://www.reagent-project.github.io http://www.reagent-project.github.io
- insin 11y ago
- mavdi 11y agoI finally got into React after being told by a friend for months that I need to. I'll be honest the whole thing just looks like premature optimisation to me. I still find the structure of an angular app a lot easier to grasp, it might be that I'm used to it but I remember the first time using Angular that it all made sense to me. I liked it instantly. Coming from Backbone, it certainly was a breath of fresh air. I can't say the same thing about React. Sure it's faster, and if you think your app is going to mutate into something big, consider using it. But I personally wouldn't make it my default choice.
- todd3834 11y agoFor me, it isn't about the optimization, it is about the way it lets you break your app into simple reliable components. There was a moment when building my first React application where it just clicked and I realized how much I was enjoying the reusability and ease of testing all of my components. I have never been able to write such well tested front end code. Also, the reusability of my code has skyrocketed.
- mavdi 11y agoFair enough, I might need to spend more time with it. I certainly like the idea of testing components individually.
- crazy_geek 11y agoIt's the old Unix curses library approach applied to the DOM. Everything old is new again :)
- EugeneOZ 11y agoThere is a lot of good and even awesome things in ReactJS universe, except JSX. Thousands of developers took their lessons in PHP/Perl/Python about mixing logic and representation, and now in nightmares they will generate HTML from logic, especially by parts and in worst case - using conditional cases. Everybody who tried to change design of website, written using something like "if ($birthday) $html .= getBirthdayButton()", will understand me. Maybe JS developers should go through it, through this circle of hell, to avoid it in future, so JSX is necessary evil. //despite of that, I sincerely thankful for people behind React, for their new ideas and how they changed fields of JS frameworks and mobile apps. Big respect!
- dominotw 11y agoThis is the first thing every dev says when he/she first discovers React. Logic and representation are not two unrelated pieces to keep them separate.
- EugeneOZ 11y agoIf you don't know yet reasons to keep them separate, please google about it before arguing without arguments. For example, read about Separation of Concerns: http://en.wikipedia.org/wiki/Separation_of_concerns http://en.wikipedia.org/wiki/Separation_of_concerns //You can use "they" to replace "he/she".
- efdee 11y agoYou are just throwing unrelated links around. Parent's point was that in this case, logic and representation are one and the same concern. What you're doing is similar to using SoC to defend having to split up class definitions into .h and .cpp files.
- EugeneOZ 11y agoDon't put your words into my mouth with "allegories", I hate it. I don't talk about cpp and headers at all, I talk about view templates and view logic.
- logicchains 11y agoI encourage anyone who likes React and doesn't mind lisp to check out Reagent, an awesome Clojurescript library built atop React that manages to completely hide its complexity. It's by far the most fun I've ever had with web development; the way I feel now is like how I imagine people who've had religious epiphanies must feel when trying to show potential converts the proverbial light of god. https://reagent-project.github.io/ https://reagent-project.github.io/
- findjashua 11y agocould you elaborate what specific complexities it abstracts away?
- logicchains 11y agoIt essentially combines all of React into a single component, the Reagent atom. It's used exactly like a normal Clojure atom, but whenever it's updated, Reagent will automatically update all Reagent components that depend on it. I find this quite elegant, as it allows one to write pretty much any reactive ui using only three functions: deref, update and render-component. Reagent atoms can even be passed between Clojurescript async threads, and will still work as expected, which completely eliminates the need for any kind of callback hell. So what it eliminates is the need to learn React. Anyone who understands how Clojure atoms work and how to use Hiccup-style HTML templating will be able to use Reagent with almost zero learning curve.
- findjashua 11y agoSo Reagent is like React + Baobab (https://github.com/Yomguithereal/baobab https://github.com/Yomguithereal/baobab)? Since Clojurescript has to compile to Javascript anyway, I can't think of a reason why Javascript can't have a counterpart to Reagent. I'm not familiar with Clojure, but it seems like atom is the data tree that holds the state of the entire application. If so, could you give an example use case of when you'd pass the data tree between threads, and what advantages it has over promises or es7 async/await. Just to be sure, I'm not questioning the validity of your claims, I'm genuinely curious about how things work in reagent.
- JDDunn9 11y agoThe virtual DOM is nice, although the only time I've seen a noticeable difference from two-way binding in speed is for tables with 1,000's of rows. The whole bit about React being more predictable than two-way binding is just an opinion though. Since any component can emit an event and change data, it's just as prone to loops and unpredictability. It's really just two different ways of thinking through the process. One's not better than the other.
- crimsonalucard 11y agoI've never used react but from what I read it's a more intuitive organization of components. The separation of the view and logic is an arbitrary separation that isn't always efficient. It's like owning a bunch of power tools and organizing by color instead of by function. Templates have components like search bars and login forms and they have logic related to those components. Why should component logic and template code be separated when both the logic and template components serve the same function? Code should be organized by segregating things into widgets. This, to me, makes more sense. I think the only thing missing from React is the ability to incorporate local css styles into the widget. Again like I said if there are styles associated exclusively with a widget, there's no point in segregating styles into some separate css file. Logic, structure, and style should be unified and organized by function, not by category.
- vvpan 11y agoSo, besides the virtual DOM, I feel like it's east to write React-like code in Angular. Just make directives that are real tight, with unidirectional flow of events and get passed only the values they need. Perhaps I'm missing something.
- msie 11y agoUgh, for my sanity as a JS newbie I have to ignore all the other JS frameworks/libs mentioned in this discussion and just master React and JS, perceived warts and all. I recommend the same thing to other newbies who come here.
- vijayr 11y agoFor someone whose strong point is not JS, is it a good idea to ignore all other frameworks (like ember, angular etc) and just go with react? I find it easier to evaluate server side frameworks than JS frameworks.
- gadr90 11y agoHey, "first do it", man :) If you think React could be a good fit, simply use it. Comparing frameworks is very time-consuming and doesn't get you any closer to your goals. Actually, any framework is better than pause-deciding-which! :)