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

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 ( ▶ this 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.

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. ▶ this video

I actually much prefer how react handles this, I think this very early react talk makes a very good point ▶ this video

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 ▶ this 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,

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.” ▶ this 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 )

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: ▶ this video

You're definitely not the only one. link as well as other HN comment threads. Check out link or this JSConf talk ▶ this 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] ▶ this video

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: ▶ this video

I understand the sentiment, but disregarding the nuance does the situation a disservice. HTML/CSS serves two separate but related use cases: a document layout and display language, and as a display layer for applications. I remember Pete Hunt's talk "React: Rethinking best practices" [1] explaining in 2013 why the styling separation of concerns for document display doesn't make sense for applications. Has opinion on best practice se-sawed back and forth? No, we've merely gone from web content being document centered to being massively application centered, and the discourse on best practices follows that proportional shift. Would it be better if there was a different web application display technology, not retrofitted on top of HTML/CSS? Like maybe, but HTML/CSS is... fine. Even separated from the success of Javascript, it's an archetypal example of "worse is better" [2] leading to market success. [1] ▶ this video [2] link

Your quote doesn't state anything to support what the OP said. It doesn't even say what you said it says. Here's Pete Hunt talking about static webpages with React, in a best practices talk from 2013: ▶ this video There is no need to imbue meaning into quotes or history when there is a clear, well defined timeline with striking examples of how React was used to generate static website all the way from its initial release.

It seems like you're conflating a few different concerns here: - JSX as a paradigm for defining component display output - Drag and drop capability for UI design - How web apps are built tooling-wise - The actual display layer being used (HTML, canvas, etc, or at least that's what I think I'm reading) - Whether the browser is where these apps run at all (?) Those are all entirely different questions and concerns. Which of these are you actually asking about? JSX has been argued about since React was first introduced [0]. It exists because React tries to stay "just JS" and use JS logic for flow control, rather than having a completely separate templating layer. Some people love that, some people hate it. Drag and drop for laying out an app exists - there's multiple projects out there that allow a very VB-like GUI design experience for React components. Modern JS build tooling exists to solve the multiple problems I listed earlier: insufficient standard library, building full-size apps with tens of thousands of SLOC and large teams, and optimizing deployment bundle and asset sizes. HTML and CSS are the native language of browsers. You can certainly use canvas/WebGL to draw pixels on screen (and that's what "compile-native-desktop-to-WASM" demos do), but you lose all the built-in accessibility of HTML, and still have to reinvent all the widgets from scratch. As for "breaking free of browser constraints and web fundamentals"... well, we _are_ talking about still delivering code t