Pete Hunt: React - Rethinking Best Practices (updated) - JSConf.Asia 2013
JSConf5 HN recommenders · recommended in 5 months, 2014-2024
58K views · 12 years ago · talk · dated
Pete Hunt of Facebook and Instagram presents React at JSConf.Asia 2013, explaining its design principles and why they seemed shocking at first. He argues that React separates concerns rather than technologies, and the talk also announces the React Chrome developer tools.
HN commenters credit it with persuading them to adopt React, and cite it for the argument that HTML and JS cannot truly be separated.
29:32Pete Hunt: React: Rethinking best practices -- JSConf EU
JSConf
548K views • 13 years ago
35:32Cheng Lou - On the Spectrum of Abstraction at react-europe 2016
ReactEurope
63K views • 10 years ago
44:36Hacker Way: Rethinking Web App Development at Facebook
Meta Developers
900K views • 12 years ago
18:55[JSConfUS 2013] Tom Occhino and Jordan Walke: JS Apps at Facebook
JSConf
45K views • 13 years ago
35:25Pete Hunt - The Secrets of React's Virtual DOM (FutureJS 2014)
Codegram
75K views • 12 years ago
27:45React.js Conf 2016 - Ben Alpert - What Lies Ahead
Meta Developers
50K views • 10 years ago
1:35:30React Today and Tomorrow and 90% Cleaner React With Hooks
React Conf
1.2M views • 8 years ago
24:28Sebastian Markbage: Minimal API Surface Area | JSConf EU 2014
JSConf
71K views • 12 years ago
36:45Jordan Walke - React to the Future
ReasonConf
48K views • 6 years ago
25:47React.js Conf 2015 - The complementarity of React and Web Components
Meta Developers
22K views • 11 years ago
33:25Dan Abramov: Beyond React 16 | JSConf Iceland
JSConf
139K views • 8 years ago
36:45Rich Harris - Rethinking reactivity
You Gotta Love Frontend
334K views • 7 years ago
31:11React.js Conf 2015 - Immutable Data and React
Meta Developers
159K views • 11 years ago
31:17React.js Conf 2015 - Hype!
Meta Developers
108K views • 11 years ago
31:48Lin Clark - A Cartoon Intro to Fiber - React Conf 2017
Meta Developers
216K views • 9 years ago
4:40React.js Conf 2016 - Lightning Talks - Elie Rotenberg
Meta Developers
4K views • 10 years ago
25:55React.js Conf 2015 - Beyond the DOM: How Netflix plans to enhance your television experience
Meta Developers
26K views • 11 years ago
1:03:48JavaScript: The Good Parts
Google TechTalks
589K views • 17 years ago
52:23Nicholas Zakas: Scalable JavaScript Application Architecture
YUI Library
68K views • 15 years ago
54:58Keynote - JSON Graph: Reactive REST at Netflix
Association for Computing Machinery (ACM)
41K views • 11 years ago
7 comments from Hacker News
Respectfully, my experience says otherwise: link - JS object appears to be at least 2x faster than document.createElement() (Chrome) - Note: JS object only loosely represents JSX element so it is a bit unfair. But with actual JSX objects I would assume it is still somewhat faster than the DOM API. ▶ this video - Pete Hunt, one of the React devs, says "JSX is faster than the DOM because it is JS memory."
I'll try one last time: > Sorry none of this makes any sense to me. If you're not familiar with the MVC variants (MVVM, MVP, MVI, MOVE)[0][1] we should start there. Next you should read through some common mistakes of Backbone.js like applications link and some criticisms of MVC on HackerNews in 2012[0]. Finally if you haven't before these talks, they are the ones that sold me on React: - link - ▶ this video - link [0] link [1] link
JSX & React were literally built to solve Facebook's maintainability concerns, which is one of the most complex client side web apps I can think of. JSX was a hard sell at first 4 years ago, but Pete Hunt did a great job then, explaining how the false separation of concerns between HTML and JS really is unavoidable. You end up with logic in HTML tightly coupled to your JS no matter which way you shake it. ▶ this video And HTML string template languages have been shown to have numerous shortcomings at scale.
Hence why Peter Hunt (react.js developer) named his presentation "Rethinking Best Practices" ▶ this video
This is amazing stuff, thanks Dan! Hopefully it is the beginning of the end of refresh-driven-development. If you are a web developer (front-end/back-end), and you haven't switched to React yet, take this for a spin, and read "Facebook just taught us all how to build websites" ( link ), and watch 'React - Rethinking Best Practices' by Pete Hunt ( ▶ this video ). The distinction between the back-end and front-end is a product of the complexity introduced by the web with its 'worse is better' mix of badly integrated tools. It made building user interfaces a dark art with all its quirks: - a layouting system that had an active vendetta against humans - Javascript with all its deficiencies - Connascence introduced by Server <-> Client communication (Server Model <-> API View <-> JS Model <-> JS View) - declarative views that were ill-suited for web-apps (logic-less templates, what a lie!) - cross-browser incompatibilities - difficulty in implementing client-side routing - immature developer tooling But worst of them all was DOM mutation and spaghetti code, which was in reality a fundamental deficiency of the development model itself, and not because web developers the world over were being deliberately irresponsible. React is changing all that with the help of ES6. It simplifies web development both in concept and in practice. In a few years, building UIs would be just another part of writing software, and competent Full-Stack developers would cease to remain unicorns. Here are a fe
I've always found it weird that many people put the HTML, JS, and CSS for one component in three different files, but never thought enough about it to put it into words. Pete Hunt (one of React's maintainers) does that here: ▶ this video React is about separating concerns, not technologies. Everything you need to know to draw an App Bar is in AppBar.jsx. You can dynamically generate the markup with JavaScript, but that doesn't change your separation of concerns, because everything concerning that component lives in that file.
Pete Hunt addresses this specifically in this React talk starting at 3 minutes: ▶ this video Basically, the idea is that most JS templating solutions separate technologies (HTML , JS, templating languages), but don't actually separate concerns, because the concern is simply generating and updating DOM regardless of how many technologies you use. Most JavaScript frameworks or libraries that handling generating and updating DOM, like Ember's two-way binding with Handlebars and Angular's dirty checking with directives, don't really separate markup from logic. They just invent a new language to mix with your HTML, and that new language is deliberately made extremely weak.