Pete Hunt: React: Rethinking best practices -- JSConf EU

If you’re not sure of the “why” of react, I’ve found that Pete Hunt’s talk “Rethinking Best Practices” gives a great overview of the reasoning behind react. Especially from about 15:15. [VIDEO]

How far back can we go? insin/DOMBuilder was initially based on a 2006 library of the same - but differently-cased - name by Dan Webb ( [LINK] ) and the earliest variant I can recall was Mochikit.DOM ( [LINK] ) By the end of DOMBuilder's life it could generate DOM or HTML from the same code and I'd tried unsuccessfully to implement a way to rehydrate HTML by hooking up events using the same code on the client. Not long after, I happened to be in the audience for Pete Hunt's React: Rethinking best practices talk at JSConf EU ( [VIDEO] ) and I was totally floored; they'd solved everything I had been trying to do with UI as code and much more, and JSX was the icing on the cake, as using nested object/array syntax has always been rife with comma-management hell when you're maintaining UI code.

Totally agree and also recommend to look at React. While Angular is just way too much of everything React is pretty much thought-out: Here a quick comparison of both: [LINK] Here a pretty good video of React's founder pointing on some weakness of Angular: [VIDEO]

#1 -- Separating by concerns is much preferable to me, organizing by controllers/directives/services/... is a separation of technology, not the high level concept. There's a great React video on this concept, as well as some other good stuff! [1] [1] [VIDEO]

You're definitely not the only one. [LINK] as well as other HN comment threads. Check out [LINK] or this JSConf talk [VIDEO]

Separation of concerns and separation of technologies are a different thing. It would appear you haven't done your research. See Pete Hunt's famous talk: [VIDEO]

This is a very useful walkthrough. Some links for those who are also interested in "Thinking in React" in a more conceptual way (#4 is a presentation from the same person who wrote the walkthrough): 1) React — Basic Theoretical Concepts: “A description of the conceptual model of React without implementation burden.” [LINK] 2) Pure UI: “A lot has been written about the merits of React as a framework. Today I’m compelled to write about the benefits of a programming model it enables and its implications to the design and creation workflow." [LINK] 3) Removing User Interface Complexity, or Why React is Awesome: “I’m mostly concerned with the core problems of data binding and componentizing UIs. After much research and usage of the technologies mentioned above, I found React to provide the best solution.” [LINK] 4) Pete Hunt: React: Rethinking best practices (youtube): “building views with JavaScript, ‘re-​rendering’ your entire application when your data changes, and a lightweight implementation of the DOM and events.” [VIDEO] 5) Nothing new in React and Flux except one thing: “What is it that makes React so innovative and compelling?… The Virtual DOM allows us to convert a mutable retained mode graphics API to an immutable functional immediate mode API.” [LINK] (I collected them to go along with something I wrote in the same vein: [LINK] )

I was very intrigued by the title: Things nobody will tell you about React.js Immediately had high hopes that someone is going to try and give a well researched, novel critique that maybe can spur out some constructive conversation. And then, sadly, the author goes on to write exactly what countless other articles have already covered and discussed to the death for years now. "HTML in JS", "JSX is bad", "Redux is complicated", "The tooling is too much". And then here we are again in the front page of HN for some reason. To me, this is, again, an extremely common case of "trying to learn everything at once". Still, a couple of points I'd like to try to mention: JSX: Has been argued about so much it's pretty much useless to try and add anything to this discussion at this point honestly. For whomever likes it, fine, for those who don't, thankfully the JavaScript ecosystem provides with a multitude of alternatives. For new-comers still trying to reason about it, this talk by Pete Hunt is a good start [VIDEO] Redux: > Anytime I work with redux I need to go back to its documentation because its core concepts are so complicate that my mind struggles retrieving them back puking them out as soon as I stop working with it. While I agree that working with Redux at scale can be complicated, the core concepts are extremely simple: Async Action -> Action -> Reducer -> Connect data to your components -> Display -> Async Action -> enter an extremely simple data flow paradigm (flux). (state,