20 Hacker News comments link this video. Each one links back to its thread.
insinMay 2020Strongly recommends
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.
in “What if we'd had better HTML-in-JS syntax all along?” · View on HN
vmastoApr 2017Recommends
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,
in “An experienced Javascript developer’s account of learning React” · View on HN
firasdMay 2016Recommends
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] )
in “Thinking in React” · View on HN
Show 14 more comments
paulshenDec 2014Recommends
You're definitely not the only one. [link] as well as other HN comment threads. Check out [link] or this JSConf talk ▶ this video
in “Build with React – ReactJS articles and tutorials” · View on HN
munroOct 2014Recommends
#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
in “Mistakes AngularJS Developers Make” · View on HN
versusdotcomMar 2014Recommends
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
in “Angular 2.0” · View on HN
code_biologistMay 2025Cites it
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]
in “All four major web browsers are about to lose 80% of their funding” · View on HN
whoknowsidontApr 2024Cites it
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.
in “Interview with Senior JavaScript Developer 2024 [video]” · View on HN
acemarkeNov 2021Cites it
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
in “Remix – A framework focused on web fundamentals and modern UX” · View on HN
smhgFeb 2021Cites it
> There is also another way of making GUIs called Immediate Mode that is commonly used for drawing user interfaces in games. In this mode the GUI components are no longer subscribing and waiting for events to come, but are instead a part of the main loop that runs at 60 fps and re-render themselves based on the current “global” state. > Immediate Mode GUIs somehow never reached the critical mass and you are probably not going to find it outside of the games industry. Isn't this what React is built on? I think this was part of the 'original' selling point by Pete Hunt: ▶ this video (2013). Around 20:00 in that video he compares React with the Doom3 engine.
in “The complexity that lives in the GUI” · View on HN
antrisNov 2020Cites it
Yes I agree, React broke that mould and web apps are better for it. But it was controversial. The React team even got ridiculed early on: ▶ this video And the person who wrote that tweet wasn't alone. It's perhaps easy to forget how much opposition there was to React. Facebook was quite a bit further than many in the industry, and Pete Hunt from Facebook admits that "we weren't communicating what we were doing". It was a bit much to swallow for many at first, but in the end, the VDOM was such a powerful idea that React was destined to take off sooner or later.
in “React Fundamentals: What I’m Learning” · View on HN
hombre_fatalMay 2020Cites it
Link? You might be misremembering Pete Hunt's talk about React's design decisions: ▶ this video where he makes the case against the "separation of concerns" cargo cult.
in “What if we'd had better HTML-in-JS syntax all along?” · View on HN
PKopOct 2019Cites it
Rethinking best practices absolutely addressed misapplication of separation of concerns. ▶ this video Components have always had JSX markup along with data manipulation logic. CSS in JS and styling co-located with component extended this consolidation of cross-cutting concerns. These, along with not manually updating DOM state as you mention, all fall under declarative aspects of React.. which concurrent rendering and Suspense are consistent with and essentially an extension of.
in “React Concurrent Mode” · View on HN
DougBTXJul 2018Cites it
React was advertised from the start as the V in MV-whatever, so that seems like an overly restrictive definition of "idiomatic". > At which point, JSX is basically just another fancy HTML templating library. JSX is optional syntax sugar; my team uses React and Redux heavily, but we've opted not to use it. HTML templating is great actually, all the rendering is data -> UI. If you go back to the early Rethinking Best Practices presentation[0], it boils down to asking why client side development isn't like like HTML templating. The answer is that updating the entire page DOM on every change is unworkable, there needs to be support for partial updates. That's what React offers, a return to the data -> UI paradigm, without having to write a secondary code path for partial updates. [0] ▶ this video
in “Vue.js: the good, the meh, and the ugly” · View on HN
kentorDec 2016Cites it
Yes and this is a tired argument by now. The talk by Pete Hunt aptly titled "React: Rethinking best practices"[0] given in 2013 points out how separating templates and logic is merely a separation of technologies, not concerns. [0]: ▶ this video
in “Why we chose Vue.js over React” · View on HN
MalcolmDiggsMar 2016Cites it
When React was released it pushed against some long-held (and still widely held) beliefs about separation of concerns, etc. ▶ this video Years later, it's still a major point of contention, and a bit of a taboo.
in “Ask HN: Long held tech taboos being broken?” · View on HN
danabramovMay 2014Cites it
Pete Hunt talks about this in Rethinking Best Practices video[1]. This is one concern, not two. [1]: ▶ this video
in “The Case for React.js and ClojureScript” · View on HN