HN Theater @HNTheaterMonth

The best talks and videos of Hacker News.

Hacker News Comments on
Pete Hunt: React: Rethinking best practices -- JSConf EU

JSConf · Youtube · 33 HN comments
HN Theater has aggregated all Hacker News stories and comments that mention JSConf's video "Pete Hunt: React: Rethinking best practices -- JSConf EU".
Youtube Summary
Slides: http://www.slideshare.net/floydophone/react-preso-v2
React, the new open-source JS library from Facebook and Instagram, is a different way to write JavaScript apps. When it was introduced at JSConf US in May, the audience was shocked by some of its design principles. One sarcastic tweet from an audience member ended up describing React's philosophy quite accurately: https://twitter.com/cowboy/status/339858717451362304

At Facebook and Instagram, we're trying to push the limits of what's possible on the web with React. My talk will start with a brief introduction to the framework, and then dive into three controversial topics: Throwing out the notion of templates and building views with JavaScript, "re-rendering" your entire application when your data changes, and a lightweight implementation of the DOM and events.


License: For reuse of this video under a more permissive license please get in touch with us. The speakers retain the copyright for their performances.
HN Theater Rankings

Hacker News Stories and Comments

All the comments and stories posted to Hacker News that reference this video.
I actually much prefer how react handles this, I think this very early react talk makes a very good point https://youtu.be/x7cQ3mrcKaY?t=183
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 to run in a browser, so what other options are there?

I'm genuinely not understanding what you're trying to envision or describe here. You seem to have a particular vision or set of ideas - can you describe what you're picturing more specifically?

[0] https://www.youtube.com/watch?v=x7cQ3mrcKaY

unclebucknasty
First, thanks for the thoughtful reply.

>It seems like you're conflating a few different concerns here:

>Those are all entirely different questions and concerns.

What you're picking up on is that I'm talking about all of it, as my call is for a completely new paradigm, which necessarily upends everything. As such, these are not "entirely different concerns". They are tightly coupled concerns.

So, to your points, respectively:

1. Yes. JSX is flawed (for a different reason)*.

2. Yes. We should be building graphically

3. Yes. The tooling should reflect the paradigm

4. N/A. We shouldn't care about the underlying display layer (perhaps the most meaningful point)

5. Yes. It makes sense to run in the browser because ubiquity and standards. But a lightweight "VM" that translates from a more idiomatically suitable mental model/coding approach to raw web standards can be used to insulate us from thinking in HTML.

*JSX is flawed not by its design, but by the problem it's trying to address. That problem is emblematic of outdated, low-level thinking. I'm trying to push the discussion up a layer or two: that is, there is no need for a webdev to ever type an angled bracket.

Anyone who has ever worked in an app-building environment that's purpose-built for creating apps should look at that return statement in my comment at the top of this subthread and think "What the?".

So, again, if you're not seeing it, then one approach is to think Java Swing or similar for building web apps. And, it doesn't just end at a GUI builder. From event processing to component bindings, we should be dealing with higher level concepts, not web stuff like HTML-ish templates (irrespective of whether we rename them to **X because they're mixed with code and delivered via return statements).

Sure, there'll be times when you need an escape hatch to target lower-level constructs. But these should be rare and, even then, the available API should allow us to target these with clean idioms, not:

x = '<div>'

If you're still not seeing it, I can guarantee you that in a couple of years we're going to have something much more akin to what I'm talking about. Maybe it'll be delivered via one of the low-code platforms or similar. JSX and the React-ish frameworks will soon-after be dead, or perhaps these environments will generate something akin to it on our behalf. I really don't care if React, et. al. get a second-life as compiler output. And, that's the point.

acemarke
Okay, so what I _think_ you're saying here is that we should no longer be thinking about divs and spans and such as the raw materials we use to write a page, nor should we be writing HTML itself, but rather VB6-style "I want to drag a widget onto the layout screen"?

That does exist in some form today, between "low-code" tools and React-based drag-and-drop tools.

But then again, this also treads awfully close to the argument that "devs shouldn't be writing 'code' any more anyway, we can just hook together a bunch of boxes with arrows on screen and it all works". Thus far, those approaches still haven't taken over devs from writing code despite years and years of promises.

unclebucknasty
>Okay, so what I _think_ you're saying here is that we should no longer be thinking about divs and spans and such as the raw materials we use to write a page, nor should we be writing HTML itself,

Yes. It seems you grasped that some time ago, as you refuted it.

>this also treads awfully close to the argument that "devs shouldn't be writing 'code' any more anyway

Is Java Swing 'code'? WinUI? Was VB?

I don't think what I'm suggesting here is really that difficult to grok. But, hey I believe this thread has run its course. Appreciate the discussion.

Some of the early React talks from 2013 give great answers to this question IMO https://www.youtube.com/watch?v=x7cQ3mrcKaY
> 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: https://youtu.be/x7cQ3mrcKaY (2013). Around 20:00 in that video he compares React with the Doom3 engine.

None
None
jonathanaird
Yes, Flutter does this as well and they’re both very popular. When done properly, UI is a pure function of state and you have some simple mechanism for notifying the UI that state has changed.
millstone
How does this work with e.g. a text editor? It doesn't seem practical to have your UI be a pure function of an input which is 100+ MBs of text and formatting.
jonathanaird
Both Flutter and React will take the next UI frame and figure out what the diff is between the last frame and the next and only apply the difference. In React it’s called the shadow dom. Flutter will also only render what it needs to so you shouldn’t render the entire file at once. Just render what’s on screen and lazy load as you’re scrolling.
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: https://www.youtube.com/watch?v=x7cQ3mrcKaY#t=35s

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.

tshaddox
Getting ridiculed early on and then quickly becoming by far the most prominent and popular library in your category doesn’t sound so bad. It’s not something I would criticize React for.
antris
I'm not criticizing the team. I definitely couldn't have done a better job myself. Hindsight is 20/20, I'm just observing and trying to dissect what it's like to learn React from scratch in... 2020.
Aug 24, 2020 · iaml on Unity Software Inc S-1
Specifically, it looks like doom 3 engine

https://www.youtube.com/watch?v=x7cQ3mrcKaY#t=1196

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 (https://www.webstandards.org/2006/04/13/dom-builder) and the earliest variant I can recall was Mochikit.DOM (https://mochi.github.io/mochikit/doc/html/MochiKit/DOM.html)

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 (https://www.youtube.com/watch?v=x7cQ3mrcKaY) 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.

Link?

You might be misremembering Pete Hunt's talk about React's design decisions: https://www.youtube.com/watch?v=x7cQ3mrcKaY where he makes the case against the "separation of concerns" cargo cult.

jannes
Sorry, I don't remember the link. It may have been this talk from 2013, but I haven't rewatched it: https://www.youtube.com/watch?v=XxVg_s8xAms

However, if you check out the History section [0] on Wikipedia you will see this confirmed:

> React was created by Jordan Walke, a software engineer at Facebook, who released an early prototype of React called "FaxJS". He was influenced by XHP, an HTML component library for PHP.

[0]: https://en.wikipedia.org/wiki/React_(web_framework)#History

Oct 24, 2019 · PKop on React Concurrent Mode
Rethinking best practices absolutely addressed misapplication of separation of concerns.

https://www.youtube.com/watch?v=x7cQ3mrcKaY

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.

Feb 03, 2019 · faitswulff on React as a UI Runtime
OP is correct, the React render loop is very much inspired by 3D game engines: https://www.youtube.com/watch?v=x7cQ3mrcKaY#t=1196
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] https://www.youtube.com/watch?v=x7cQ3mrcKaY

acemarke
Out of curiosity, what are you using instead of JSX? Plain `React.createElement()` calls, `createElement` aliased to a shorter variable like `e`, or something like the `react-hyperscript-helpers` library?
spiritcat
it's funny how originally jsx is what kept me away from react, and now it's what keeps me from leaving.
interlocutor
You can actually leave react and still keep JSX. This tiny library lets you use JSX as a templating mechanism: https://github.com/wisercoder/uibuilder
kibibu
It's funny how everybody hated E4X when Adobe and Mozilla were doing it, and love JSX now.
spiritcat
I didn't even know this existed.
DougBTX
We’re still using https://www.npmjs.com/package/react-dom-factories for plain DOM elements, so code looks like

    dom.div({ props }, ...)
For our own components, we export the output of React.createFactory https://reactjs.org/docs/react-api.html#createfactory rather that the component itself, so rendering code looks like:

    MyComponent({ props }, ...)
I realise that both of those are marked legacy, with a nudge towards using JSX instead, but they are pretty thin wrappers around createElement so it seems like a small dependency.
I think by now many HNers will have grasped the idea behind "The core premise for React is that UIs are simply a projection of data into a different form of data", but here's a related good read from around the time this was written: Pure UI https://rauchg.com/2015/pure-ui

Also of interest, the classic 'Rethinking best practices' presentation: https://www.youtube.com/watch?v=x7cQ3mrcKaY

seanmcdirmid
The problem with retained mode UIs is that they lose the ability to continuously translate data with functions. Immediate mode UIs don’t have that problem (since you are just drawing to the screen on each frame), but suffer from efficiency problems (not to mention you have to do your own layout). Databinding (e.g. as in WPF) allowed some of these transformation to occur declaratively, but were too inexpressive in general.

React is a nice new point in the space, and is much more pragmatic than FRP or Rx.

davedx
Yes, React is an interesting middle ground that hits a sweet spot for many classes of web apps. Try and make (real time) games with it and you soon realize that despite it being a good conceptual model, you really need to be in an immediate mode rendering mode.

Does anyone know of any immediate mode game engines using concepts from React?

seanmcdirmid
Immediate mode is really the sweet spot for games, I still do most of my experimental UIs using immediate mode on top of canvas for that reason. If you need to write something like a code editor, it is just much easier than fighting the DOM (you can easily do your own caching using images), though you have to roll a lot on your own.

The problem with gaming is that you usually don’t want to use the DOM, and React’s value add is mostly in its DOM handling.

swyx
So I've never done game dev - can anyone explain what immediate mode rendering is like to a React webdev?
untog
In the simplest way possible, it would be like running

   this.element.innerHTML = "new value"
instead of

   this.setState({text: "new value"})
React's method of async state setting is really great when you have a bunch of components that know little to nothing about each other, because it'll automatically batch things up. But in some situations, and games are a perfect example, you need the value to change right now.
seanmcdirmid
Actually, that looks like retained mode.

Immediate mode simply means you specify what to redraw on every frame, there is no caching unless you specify it. And you basically redraw whenever some state changes (in a game this is going to be at frame rate).

In React, when some state changes, you respecify the DOM for components whose state has changed, but asynchronously the library determines how to make the DOM update more efficient on the next frame redraw.

swyx
thanks, what is the benefit of no caching then? seems fairly wasteful if you have an engine capable of rendering at frame rate already.
seanmcdirmid
Simplicity. Retained-mode means you modify the scene graph (aka DOM) using imperative statements, it is difficult to keep your UI in synch with your models. With immediate-mode, you simply create a function f(m) over your model m to render it on each frame rate (which also often involves imperative instructions affecting the frame buffer, but the buffer can be cleared on each frame so who cares).

Retained-mode caches by default (often in opaque ways), which was the whole point (only re-render parts of the scene that have changed). You can roll your own caching for immediate mode, usually via some kind of invalidation scheme (use image for a node if nothing changed for this component, otherwise call that node's re-render method). On the other side, projects like React takes the retained-mode DOM and make it look more like an immediate-mode abstraction without sacrificing so much performance.

swyx
thank you!
nervestaple
I'd be curious to know too -- I've been working on a custom React renderer for the Phaser webgame engine after dealing with a lot of frustration around state management in Phaser. (https://github.com/nervestaple/react-phaser-kit) I know there are similar parallel approaches like https://github.com/FormidableLabs/react-game-kit and https://github.com/michalochman/react-pixi-fiber. You can sort of use them in immediate mode by calling setState inside the update loop, but the abstraction leaves a bit to be desired...
None
None
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.

https://youtu.be/x7cQ3mrcKaY

Have you seen the talk "Rethinking best practices" from back when React was first launched?

https://www.youtube.com/watch?v=x7cQ3mrcKaY

It addresses this and is pretty great in my opinion. Of course one does not have to agree with it but it is not the same as the mess back then and usually the separation of concerns is more about separations of technology than concerns.

As an an example:

Let us say we have a shopping basket up in the top right corner of our web page. For me there is a big difference between the logic of calculating to the total sum of the parts we have in it or collapsing/expanding it. One is "business logic" and one is "presentation logic" and they are not the same.

And I also bet that if for example HTML or CSS had native collapse/expand then people would consider that presentation as well and not to mention all the logic you usually have (loops, conditions) in a normal template language.

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 https://www.youtube.com/watch?v=x7cQ3mrcKaY

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, action) => state

Redux can get complicated when you add to the mix schemas, normalization, selectors et al. My advice and I can't stress this enough: Don't try and learn everything at once, start with simple core concepts, iterate later, add tiny new pieces when it makes sense. You don't always need Redux anyway.

RE: Redux boilerplate: It's a lot, yes, but that's by design. Redux is simply a tradeoff between boilerplate and repetitive, dead simple management of your complicated state. I'd rather write a few lines of code more if it means I'd avoid having logic bugs or getting confused where my data comes from.

RE: React Router:

[...] the maintainers had the great idea of bumping 3 major versions in 5 months completely not backward compatible to each other

This is simply not true. React Router has had a single major breaking API change in 2 years. RR 2 and 3 where the same thing and 4 has just now been released after 2 years of stability.

RE: Final complaints:

[...] you must use className instead of class to define the DOM css classes

This is an extremely weak point to complain about.

[...] you will need to import in your scripts react-dom and react without never using the last one instance for some wild reason known only by the React team

You only need react-dom once, to the point where you ReactDOM.render your application. You need React because you're using it implicitly with JSX. I'm not on the React team by the way, it's a simple google search: http://stackoverflow.com/questions/38206646/do-we-need-to-im...

[...] you can render functional components just by using js functions but you will need to wrap all your markup always in a wrapper tag to properly allow the Virtual DOM creation

Valid point, although it's a nitpick. In any case, this is going away with the newer version of React's reconciler (Fiber).

[...] its apparent simplicity is hidden behind a whole toolchain you need to configure before you can even writing 1 line of code

create-react-app is great, officially supported, and does everything, is it the fault of the ecosystem that the author is reluctant to try the official CLI?

https://github.com/facebookincubator/create-react-app

andrewingram
I agree on everything except what you're saying about React Router. I've been working on projects that tracked React Router since it was first announced. Understandably, every pre-1.0 release broke something, 1 to 2 broke things, 2 - 3 was compatible but slower in enough scenarios that it's questionable whether you should upgrade. RR4 just isn't the same library, and due to its reduced scope has thrown a few problems back into the realm of being unsolved.

It's fairer to say that the year during which RR2 and RR3 were the primary releases, was a relatively stable time.

I've generally been pretty tolerant of the amount of library churn within the React ecosystem, I'm the kind of person who will happily keep dependencies up-to-date and upgrade apps to newer/better tools when they emerge (I'd even say I enjoy it more than actual day-to-day coding), but React Router has been a major source of frustration for a long time now. Hopefully, the version 4 API is going to be stable for a while (even though getting efficient data-loading with Relay is now an utter pain).

gianlucaguarini
ditto https://medium.com/@gianluca.guarini/i-thought-it-was-clear-...
lawik
I've had really bad experiences trying to get going with React but I just found this article ranty. I was also expecting something more interesting. No feeling of depth to the analysis, just "I did not like this and now I will complain about it".

I'm guessing english is not the authors first language so I won't dwell on it but I found it somewhat hard to follow.

gianlucaguarini
Thanks for your feedback I have tried to fix some grammar and syntax errors. Please ping me in case you find it still confusing
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]: https://www.youtube.com/watch?v=x7cQ3mrcKaY

ggregoire
Thanks for posting this, it was really interesting. Everyone who criticizes JSX should have watched it before doing so.
Jun 22, 2016 · firasd on Learn React.js in a weekend
The argument (among others) is that if you're going to be using if/else, for loops, and all that in a templating language you might as well use a full-featured language like JavaScript... (youtube timestamp: https://www.youtube.com/watch?v=x7cQ3mrcKaY&t=4m13s)
leeoniya
or, you know, just write the app in pure javascript and still reap the benefits of [2-3x faster than React] virtual dom. though i'm a bit biased [1] ;)

[1] https://github.com/leeoniya/domvm

[2] http://mithril.js.org/

a13n
Meh since when is computational performance really a bottleneck? Do you find your site is loading seconds too slowly because JS is executing? I sure don't.

On today's machines the much larger bottleneck is how fast and easily you can iterate on product at scale which is a problem that React is a fantastic solution for.

Bahamut
On mobile, it matters a lot, especially older/low-end Android phones.
pigeons
Actually I do find javascript making many sites that are ultimately just displaying text, so slow as to be unusable.
a13n
How do you know it's the JS executing and not network time or the result of a poor infra decision?
pigeons
Because it works great with JS turned off, and you can measure what is using your CPU an d what it is doing and how much time it is taking (also you can measure the network).
None
None
leeoniya
> Meh since when is computational performance really a bottleneck?

Ever used a phone that wasn't < 6 months old to browse the modern web?

> at scale

React is a front-end framework. The only "scale" that exists in its world is the fat DOM you generate and how fast it can mutate it. From that perspective, it sucks at scale (take a look at Preact and Inferno). Your iteration speed depends on good app architecture, not a specific framework. React Native does sound like a good perk, but likely isnt useful enough to make anything you cannot do anyway in HTML5.

a13n
Scale in terms of number of engineers and app size, not users
leeoniya
> number of engineers

can't this be said about any popular framework? "it scales because everyone knows it"

> app size

what specifically makes React scale better with app size than any other properly componentized architecture?

a13n
It doesn't scale because everyone knows it. It scales because React by nature isolates business logic into components so that for the most part 100 engineers can simultaneously work on the same product and be confident they aren't breaking stuff. (Or realize they are through merge conflicts)

> "properly componentized"

With React, 100 engineers don't have to know how to "properly componentize" things because it's already baked into the framework. You can't really write React code without proper componentization.

leeoniya
> React by nature isolates business logic into components

The essence is simply this:

    function MyView(model) {
      return template;
    }
...which can work with any view layer and the same 100 engineers. Especially if the model is an API with business logic around some immutable stream/state. The concept is simple enough to be described in one sentance :)

> don't have to know how to "properly componentize" things

I think you're overstating how difficult this problem is or forgetting that React's API must still be learned from documentation and examples.

a13n
What about state within a component? How do you encapsulate that state so that other components can't muck with it? What about passing data to that component? What about type checking that data passed in in debug mode? What about a formal API for components to talk to one another? What about knowing the explicit amount of the view tree that needs to be re-rendered based on what data changed?

React has answers to all these questions and so much more. Answers that very smart people have spent years coming up with.

Sure you could reinvent the wheel and build all that into your custom component framework, but then you may as well just use React.

leeoniya
I will address these with respect to domvm [1]

> What about state within a component? How do you encapsulate that state so that other components can't muck with it?

Solved.

> What about passing data to that component?

Solved.

> What about type checking that data passed in in debug mode?

Could be solved if i rewrote in TypeScript. But this has never been a problematic issue in 10k+ LOC apps.

> What about a formal API for components to talk to one another?

Yep.

> What about knowing the explicit amount of the view tree that needs to be re-rendered based on what data changed?

Obviously, that's what virtual dom is.

In addition to all of this and much more, materialized views are independently refreshable, can be composed between disjoint components. There are async lifecycle hooks, a router, mutation observers, ajax sugar.

All of it is 17k min, requires no special tooling or IDE to write, is isomorphic and is 2-3x faster than React.

I have no doubt that React brings a lot to the table, but I hesitate to treat it as the final word in frontend frameworks for all the above reasons.

[1] https://github.com/leeoniya/domvm

May 27, 2016 · firasd on Thinking in React
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.” https://github.com/reactjs/react-basic

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." http://rauchg.com/2015/pure-ui/

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.” http://jlongster.com/Removing-User-Interface-Complexity,-or-...

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.” https://www.youtube.com/watch?v=x7cQ3mrcKaY

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.” http://staltz.com/nothing-new-in-react-and-flux-except-one-t...

(I collected them to go along with something I wrote in the same vein: https://medium.com/@firasd/interface-from-data-using-react-t...)

clessg
#4 is really my favorite. I know a lot of people who were hardcore opposed to React until they watched that presentation.

> React — Basic Theoretical Concepts

"Basic"

Let's just say, save this one for last.

mrkgnao
I don't know much JS, let alone React, but after reading the OP link, "Basic Theoretical Concepts" made sense to me. The bit of Haskell experience I have probably helped.
firasd
Yeah. When looking for videos I saw he updated his presentation and gave it again, but there’s raw appeal in that first ‘Rethinking best practices’ talk. Just something coming in out of left field. (Another early presentation: “Tom Occhino and Jordan Walke: JS Apps at Facebook” https://www.youtube.com/watch?v=GW0rj4sNH2w)

Re: basic concepts, I admit my eyes glaze over by the time I read the heading “Memoization”. Opens with this great sentence though—I like to say ‘view as a function of state’, but he breaks it down even simpler—“The core premise for React is that UIs are simply a projection of data into a different form of data.”

haberman
Throwing mine in there too: http://blog.reverberate.org/2014/02/react-demystified.html
When React was released it pushed against some long-held (and still widely held) beliefs about separation of concerns, etc.

https://www.youtube.com/watch?v=x7cQ3mrcKaY

Years later, it's still a major point of contention, and a bit of a taboo.

When the parent says view, they're not talking about "a) markup", they're talking about the thing the user is looking at.

> b) ids that indicate that a given tag will be replaced with a component

With that in mind, your disagreement is contradicted by this statement because logic has just been described to update the view. Logic is necessary to generate a view of the data for the user.

With JSX, keeping all of this code closer together that is intrinsically tied together increases cohesion, by definition. Subjectively, this makes it easier to manage UI because one only have too check one place for all the pieces. For further exploration of this idea, check out the intro of this video on separation of concerns vs technology. [1]

On a separate point, it sounds like one must imperatively update the UI with Wicket, which is objectively more complex than what React affords, which is stateless UI. Time is removed from the equation, which also makes things easier to reason about.

[1] https://www.youtube.com/watch?time_continue=275&v=x7cQ3mrcKa...

lmm
> With that in mind, your disagreement is contradicted by this statement because logic has just been described to update the view. Logic is necessary to generate a view of the data for the user.

There is no logic in the "template". No looping, no branching. Only inert ids. There is logic in determining which component replaces each id, but that logic lies in the code, not the template.

> it sounds like one must imperatively update the UI with Wicket, which is objectively more complex than what React affords, which is stateless UI.

Not so. Wicket clearly separates its state into models, you write UI that depends on a model as a function of that model. It leads to a very declarative/functional style, where the only "magic" is encapsulated and explicitly managed. (You do have to declare which changes update which UI (for performance reasons), but you can make that "always re-render the whole page" if that suits your use case).

munro
> There is no logic in the "template". No looping, no branching. Only inert ids. There is logic in determining which component replaces each id, but that logic lies in the code, not the template.

Again, changing view to mean "template" is a strawman.

> Wicket clearly separates its state into models > You do have to declare which changes update which UI (for performance reasons),

Separating state isn't the same as no state. Also imperatively updating the UI on state changes is stateful. Which increases complexity, which for most people makes code hard to reason about.

> but you can make that "always re-render the whole page" if that suits your use case

Anything can be made to do anything, so this point is moot. If this model was trivially applied, would it lead to flickering, lower performance, losing scroll position, losing selection, or losing input focus?

lmm
> Again, changing view to mean "template" is a strawman.

Call it what you like. The point is that clear separation between logic and markup can be done and is valuable.

> Separating state isn't the same as no state.

Any web page that has inputs or controls is necessarily stateful - otherwise where does the input go?

> Also imperatively updating the UI on state changes is stateful.

There's nothing imperative about it. Have you looked seriously at Wicket or are you just throwing buzzwords around?

munro
> Call it what you like. The point is that clear separation between logic and markup can be done and is valuable.

You concede the original point. To your new point, saying something is valuable doesn't make it valuable. Why? It decreases cohesion, which is not good.

> Any web page that has inputs or controls is necessarily stateful - otherwise where does the input go?

If this is a serious question, it's too far off any original point to teach you unfamiliar concepts. Learn about what stateless, declaratively, & imperatively UI means so there aren't strawmans, and so you can weigh in on these discussions.

> There's nothing imperative about it. Have you looked seriously at Wicket or are you just throwing buzzwords around?

Please do not dilute conversations on here by name calling. Imperative & state are basic computer science terms... o_O

lmm
> You concede the original point.

No. Your original claim was that you need to mix logic and layout. You don't.

> If this is a serious question, it's too far off any original point to teach you unfamiliar concepts. Learn about what stateless, declaratively, & imperatively UI means so there aren't strawmans, and so you can weigh in on these discussions.

It's not me who needs to learn what those words mean. Either you're just trolling, you don't understand the terms, or you don't understand wicket.

munro
If you disagree with something I said, please disagree with it directly with reasoning, without name calling, ad hominem, or strawmans, at the exact thread. If I use terms incorrectly, correct me, and better yet, give an ironman of what I was trying to say.
lmm
To the extent that react is "stateless" (which I don't consider an accurate or useful term, because UI is inherently stateful - the meaningful distinction is whether state is managed or pervasive) so too is Wicket. That is to say, you declare what your UI looks like as a function of the model values. There is no "imperatively updating" and no increased complexity.
Take a look at the talk where the concepts behind React are introduced:

https://www.youtube.com/watch?v=x7cQ3mrcKaY

It turns out there is no good reason to separate code and templates, because they are intrisically linked; one cannot work without the other. The separation should rather happen on units that are really independent, such as 2 separate pages of your application.

kls
Yep, it was an old rule for an old time when back-end functionality, UI functionality and presentation could all get jammed into one *SP or PHP page. While the times changed the common wisdom remained. There is no reason for a component that's sole purpose is to be a component should not be self contained. It is a black box to the consumers.
Pete Hunt's talk is good. https://youtu.be/x7cQ3mrcKaY?t=1112 I'd recommend watching the entire video if you have time, but that's the gist of it. More detail:

http://stackoverflow.com/questions/21109361/why-is-reacts-co...

It is challenging to make a large app with lots of state be performant when you manually mutate the DOM, and there's no way for the browser to fix that because of the way things work.

For example, if you move an element, and then request the position of another element immediately after, the browser will be forced to recalculate layout before giving you an answer. With lots of state and lots of updates, it's very challenging to keep this in the right order.

As virtual DOM is an abstraction over the DOM, you can make a vanilla app that is much faster, but as your app grows, that quickly reverses.

jarek-foksa
Shadow DOM will allow browsers to optimise their rendering code to re-render encapsulated DOM subtrees independently of each other.

Virtual DOM makes sense when (A) you have a huge tree and (B) you show only a small portion of that tree to the user at any given time.

For example a long scrollable list or a multi-line text editor would be better implemented with virtual DOM, but using it everywhere is an overkill.

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:

https://www.youtube.com/watch?v=x7cQ3mrcKaY

EugeneOZ
Hm.. I didn't say a word about separation of technologies. If you have one non-broken piece of HTML and related piece of JS to make it "live" - it's one thing. If you use JS/php/python/ruby/lua/whatever to generate HTML, composing it by small pieces into one (inside one component) - it's another thing and it's exactly what I'm talking about.
A good talk about that is "Pete Hunt: React: Rethinking best practices -- JSConf EU 2013" http://www.youtube.com/watch?v=x7cQ3mrcKaY
ufo
When you do everything from inside JS (as Pete advocates) then you have a real programming language to work with. Inline JS in the HTML is much less expressive.
#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] https://www.youtube.com/watch?v=x7cQ3mrcKaY

Jul 10, 2014 · munro on When REST Gets Messy
It's hard for me to submit to a philosophy for reasons like that it's beautiful, and that you will reach zen. Level 3 enlightenment sounds very cultish to me. :) I've dropped the notion of REST and been very happy with simple RPC, instead of contorting my mental model into resources or to align with the HTTP spec.

I personally have found zen in applying simpler concepts to software development. Such as composition over inheritance to my API design, mixing in certain aspects like content negotiation or caching, when those complexities become necessary. Or separation of concerns, making sure endpoints don't do too much, and the realization of concerns vs technology [1]. Really thinking about the notion of simplicity as describe by Rick Hickley in Simple Made Easy [2]. Or "There are only two hard problems in Computer Science: cache invalidation and naming things"--putting off caching until an endpoint becomes a problem--and not worrying if my URL structure is RESTful.

Here's an example of an API that I find beautiful [3].

[1] https://www.youtube.com/watch?v=x7cQ3mrcKaY [2] http://www.infoq.com/presentations/Simple-Made-Easy [3] https://mandrillapp.com/api/docs/

Pete Hunt talks about this in Rethinking Best Practices video[1]. This is one concern, not two.

[1]: http://www.youtube.com/watch?feature=player_embedded&v=x7cQ3...

Have you seen Rethinking Best Practices video[1] from JSConf?

I think it explains the point.

[1]: http://www.youtube.com/watch?feature=player_embedded&v=x7cQ3...

chao-
I have not. I will watch it soon and see if it changes my opinion.

And I recognize it is just that: an opinion. A habit developed over time. But as a result, after all these years, I am also familiar with its advantages.

The idea of "Data comes from X, gets passed to Y, and combined into a display", where "Y" gets stored in its own file somewhere, can be reused everywhere, and decoupled from whatever is passing it the data that will be displayed within.

plorkyeran
The general premise is that in practice templates usually end up very tightly bound to the view using the template, so you're not actually gaining anything by putting them in a different file and there's a lot of downsides to using a different language for templating.
chao-
Having watched the talk now, I see what he's getting at. I have maintained, at most, a small-approaching-medium-sized single-page app, and it was an internal tool. Clearly I have not felt any of the same pain that inspired React.

But within that particular experience, despite my "underpowered" templating tools, I've settled on a style that very close to what he calls "components", built instead from pairs of one partial and one viewmodel. Tightly coupled (cohesive?) within each pair, but as a unit are reusable together elsewhere in the front-end app.

So I can agree in theory, and see where my ideas have wandered close to the path that React takes. Really the only thing to do now is try it on a substantial project to see how it compares in experience. I suspect I'll still feel the urge to want the JSX in a separate file in some cases.

xtrumanx
Wow, that was a great talk. I really didn't like React and didn't get why they've decided to mix concerns but I think I've understood their design decisions now.

I think I'll go give it another try sometime soon.

This seems slightly cribbed from "Rethinking Best Practices" by Pete Hunt https://www.youtube.com/watch?v=x7cQ3mrcKaY
Confusion
Pete Hunt is quoted on one of the slides, so that sounds likely :)
> To me, there is a reason to abstract javascript and similar logic outside the plain html -- however the workflow of including script sources inside html that in turn include html that gets rendered is backwards

Yes, coming from a traditional JavaScript MVC background it's hard to let go of this idea, when it's been touted everywhere for years. But the fact is, there's no fundamental reason why we need to put these technologies into separate containers.

I recommend this talk by Pete Hunt: https://www.youtube.com/watch?v=x7cQ3mrcKaY

edit. oops, linked the wrong talk

Mar 18, 2014 · versusdotcom on Angular 2.0
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: http://versus.com/en/angularjs-vs-react

Here a pretty good video of React's founder pointing on some weakness of Angular: http://www.youtube.com/watch?v=x7cQ3mrcKaY

Dec 19, 2013 · jonahx on React v0.8 is out
The React devs are well aware of what they are doing, and argue that they are merely coupling technologies, not coupling design concerns:

http://www.youtube.com/watch?v=x7cQ3mrcKaY&list=FLuFwYXJkbMi...

Of course you're free to agree or disagree with their argument, but I wouldn't assume they are just newbs who are unaware of standard best practices. They know the "rules" and are breaking them consciously.

HN Theater is an independent project and is not operated by Y Combinator or any of the video hosting platforms linked to on this site.
~ yaj@
;laksdfhjdhksalkfj more things
yahnd.com ~ Privacy Policy ~
Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.