
React as a UI Runtime - danabramov
https://overreacted.io/react-as-a-ui-runtime/
======
sktrdie
I think React is a big deal because we can finally think of UIs as pure
functions of data.

However, the entire mentality of the community is moving towards having
behavior tied to specific portions of the tree; in essence it's common-
practice to have stateful components. With Hooks this is even more the case.

Instead, the nature of UIs is that changing something in a part of a UI might
and will effect something in a completely different location: when I click the
button, open a dialog, show a spinner and reset the user profile screen.

The problem with writing stateful components is that the behavior (such as the
one above) is _tied_ to the UI representation (at which level of the tree
should I write this logic so that it effects all the aforementioned
components?).

We are essentially going back to tying logic and representation; something
that we've been trying to avoid over the past decade or so.

I'm not saying React doesn't allow you to do differently; things like global-
state (Redux, MobX, etc.) allow you to separate behavior and representation
quite well. I'm more confused about the recent lack of best-practices
surrounding this idea of separating logic-and-UI, and instead they're pushing
towards: "Yeah now with Hooks you can even more easily bundle logic-and-UI
together and have them tightly coupled". Which to me seems really confusing.

~~~
adamkl
I’ve become a big fan of using finite state machines (more specifically xstate
[1]) to encapsulate all the logic and states of a particular UI. You can
essentially create all the behaviour of your application without writing a
single line of UI code. At that point, you can use React exactly as you
described, as pure functions of data.

[1]
[https://github.com/davidkpiano/xstate](https://github.com/davidkpiano/xstate)

~~~
matb33
As a company we’ve been experimenting with xstate for about a year. Generally
speaking, bug counts go down as a direct result. We’re at a point now that
it’s part of our process — a key deliverable as part of our first phase of
development is what we call a “navigational statechart” which informs the
development of the wireframes. The beauty of this process is that we can take
that same statechart directly into the later development stages.

~~~
adamkl
We recently did a proof-of-concept at my company and came to some similar
conclusions. We can see state charts driving our development process exactly
as you described, so it’s good hear that others are finding success with this
approach!

We are going to be incorporating xstate at a basic level in one of our next
projects, but I’d eventually like to see it become entrenched in how we do all
UI development.

------
m0meni
React's model kind of feels like the holy grail of UI development to me (at
least on web). Is there anything out there that you guys feel is superior? I'm
not talking different frameworks like vue or angular, but rather UI paradigms
on platforms that aren't web. People have been making UIs for desktop and
mobile for a very long time now, and I'm curious how people have historically
dealt with all the problems that React addresses, and moreover, how they deal
with other problems like data-fetching, state-management, etc.

~~~
rpedela
React's model is very similar to how 3D applications work at a high-level.
There is a render loop that is either on-demand or continuous, the latter is
more common in 3D. During each iteration, input is collected, background
processes are run like AI, etc. and they all change the state of the
application's data. The new state is given to the rendering engine, and the
rendering engine re-renders the entire scene as efficiently as possible.

It turns out it is a lot easier to program dynamic 3D scenes using this
method, rather than trying to do two-way binding like Angular, JQuery, etc do.
And the performance is typically better too. Imagine trying to do two-way
binding in a AAA game with 1,000s or even 100,000s of individual objects in a
scene. It would be a programming nightmare! Instead much of the effort is
spent trying to reduce the amount work the GPU has to do when rendering the
entire scene such as occlusion culling, distance-based level of detail, etc.
React's virtual DOM renderer is also trying to render the scene (DOM) as
efficiently as possible. But admittedly it is much simpler than Unreal
Engine's renderer, but the high-level concept is similar.

I think this is why React feels so natural to so many people when building
dynamic web UIs compared to JQuery, Angular, and even Vue.

~~~
meandmycode
I'm not sure I agree at all, 3d engines render loop foregoes any attempt to
skip unnecessary rendering to focus on fast, continuous rendering.

React on the other hand tries as hard as possible to avoid rendering, in fact
it's whole design of immutability isn't because functional style is better,
it's just convenient for it's requirements to avoid rendering.

For me react is more of an antichrist of UI tech, as much as I use it and rely
on it, the day I can just mutate some state and that renders (i.e. .. just
straight up dom), the better.. if I want to then layer on some immutability
patterns then that's entirely in my apps domain.

~~~
wongarsu
> 3d engines render loop foregoes any attempt to skip unnecessary rendering to
> focus on fast, continuous rendering.

3d engines often go to great lengths to avoid sending unnessesary data to the
GPU. Frustum culling or more sophisticated occlusion culling are standard
practices.

------
m_fayer
This article hit a rare perfect note for me, I wish there was more
documentation like this out there. Instead, the choice is often between very
basic introductory stuff, API docs, and step by step "how to build a todo
list" tutorials. What all those things miss is the theoretical motivation and
the primitives that have been established to address that motivation. That's
where I'm happiest starting when I try to pick up something new, since I feel
that all the details snap neatly into place once you understand the ground
level stuff, but to get this ground-level view I have to hunt for independent
articles, online courses, or books, when it should exist in the official docs.

~~~
debt
This is a fundamental problem with most programming languages I’ve come
across. It’s quite annoying.

------
self_awareness
Flutter uses React model for creating UI and it feels very nice. I would be
happy to use this model for standard desktop UI programming as well (Qt,
Gtk+).

~~~
longnguyen
I'm working on react-qml[1] to pursuit that exact goal: bringing React model
to desktop UI development. Thought you might be interested. We're running this
in production for over a year now and quite happy with that. Team's
productivity improved a lot, mostly because of better tooling for desktop
development:

    
    
      - Write codes in ES6/7 or TypeScript (transpiling using babel).
      So the syntax is exactly like what you're writing on the web (not React-like syntax)
      - Bundling using webpack (with a sensible default, zero-configuration FTW)
      - Use any front-end library (redux, lodash, rxjs, redux-observable etc.)
      - Supports Hot Module Reloading (sub-second reloading)
      - Supports react-devtools & redux-devtools (Time Travel Debugging possible)
      - Super easy to test & debug in multiple platforms
    
    

The problem we're facing now is that it required both React & QML knowledge.
In the new version, I'm working on completely new APIs to support developing
desktop application using only React. Would love to hear your opinions on this
approach.

[1]: [https://github.com/longseespace/react-
qml/tree/next/packages...](https://github.com/longseespace/react-
qml/tree/next/packages/example-with-redux)

~~~
lol768
>I'm working on react-qml to pursue that exact goal: bringing React model to
desktop UI development

This project looks really interesting, definitely something I'll be following.

Do you have any plans to expand on documentation a bit more? At present your
HN comment tells me more than the README does.

------
vnorilo
I have experienced two times a leap in productivity that subjectively felt
like a game changer. The first was from a baseline of a good MVC kit like
Cocoa or pre-QML Qt to the MVVM paradigm, and the second was to React (with
ClojureScript and Reagent).

------
chrislloyd
The biggest shift in my mental model of React was considering it closer to a
programming language than traditional UI libraries. Dan hints at this when
describing how it is used to manipulate view trees and proposing special
syntax for hooks.

~~~
bcherny
Context for where that syntax came from: [http://displayscript.org/language-
reference-state-and-identi...](http://displayscript.org/language-reference-
state-and-identity.html)

~~~
danabramov
Yep, also a few other references are here

[https://reactjs.org/docs/hooks-faq.html#what-is-the-prior-
ar...](https://reactjs.org/docs/hooks-faq.html#what-is-the-prior-art-for-
hooks)

------
revskill
What's a UI Runtime ? The post should give that definition first before
jumping into the details.

~~~
Vinnl
You might want to follow the link behind the first mention of the word
"runtime":
[https://en.wikipedia.org/wiki/Runtime_system](https://en.wikipedia.org/wiki/Runtime_system)

So in a nutshell: "React as a UI runtime" considers React as implementing part
of your UI's execution model. In other words: instead of your code having to
call appendChild, setAttribute, etc. to modify the UI, React does that.

------
szines
Other framework, like Ember, uses so called Run Loop to solve these problems.
Quite similar concept, but it is not only for UI, it is for the whole app
(route, state management, interactions, etc...) Maybe it could be interesting
if someone would like to dig deeper in this topic.

[https://guides.emberjs.com/release/applications/run-
loop/](https://guides.emberjs.com/release/applications/run-loop/)

------
platform
I like it. Here is my own rendition of Dan's approach (interleaved with
experience from about 12 K lines of React native/ react native web)

A ) Dependency Tree (eg dom or virtual dom) is the interface user interacts
with.

B ) Each interactable element in the tree can have its own state.

C ) Each interactable element gets data or update data from/to its own state.

It can also get data from 'properties' that a parent passed on (but the
interactable cannot update those properties itself, instead it must call its
parent's function to do that)

D ) After the above A, B, C are setup -- the code interacts with the state,
not with UI elements

E) The UI runtime is a collection of mechanism that supports A, B, C.

This includes :

1) Primitives allowing Interactable to be attached and interact with the
dependency tree, ability to receive data from parents

2) Well defined (from both APIs, callbacks, and Data) primitives -- that
enable state management within the Interactable, and across their dependency
tree

This also includes mechanism deciding efficiently, which state changes affect
which Interactable)

3) Developer friendly run time helpers to debug and manage the above

\----

Cleary A) --> can be a dependency tree of Excel cells, or Matrices, or robot's
extremities, for that matter.

Clearly B) (the state) is widely appreciated these day ViewModel (as it is
called in Android's new JetPack LiveData components)

The state is also the thing that can be validated, even with TLA+ (which is
what am thinking about, in a downtime).

And it is much much easier, in my view to map interaction business rules to
state, rather than to UI.

\---

I am looking forward to try this with my console UIs project.

\---

I also have a strange feeling, that this model will work when I have to manage
complex backend interdependencies,

where updates to distributed caches affect the algorithms running across a
server farm.

\---

~~~
marton78
How do you solve B and C without coupling the shape of the components tree to
the state of the state tree?

~~~
platform
state of the tree is a composite of states of the components.

components know about their state only.

the UI runtime is the one that understands 'state of the tree'

------
Zooper
For people that feel the virtual-dom is anything but a hack, please read up on
this: [https://github.com/Polymer/lit-html](https://github.com/Polymer/lit-
html). Do you really not get a code smell from keeping an in-memory copy of
the DOM and doing "Reconciliation"? Most of this article is about the vdom.

------
BossingAround
> This is a deep dive — THIS IS NOT a beginner-friendly post. In this post,
> I’m describing most of the React programming model from first principles. I
> don’t explain how to use it — just how it works.

Ok, now that author feels better, let's move on..? Or what is the purpose of
such 'disclaimers' and 'warnings'? Let the reader see whether the article is
at their appropriate level, don't patronize...

I really dislike these. I can skim the text, and within 30s, I can see whether
it might be my level or not. This feels, however, that the author is purposely
driving me away for no other reason than 'you don't make a living with react,
so shoo, this is for the big boys'.

~~~
WA
The author of the article is a contributor to React and the author of Redux.
So the disclaimer is valid, because lots of people read his stuff and might
expect some React tutorial or whatever.

~~~
BossingAround
I can decide that for myself. I don't need an 'authority' to tell me,
regardless of who the author is.

Do you think that without the warning, a beginner would deep into the article,
and 50 minutes in, he/she would be like 'heeeey, wait a minute! This is not
for me! Why didn't he tell me?'

If not, then such a disclaimer is meaningless.

~~~
bromuro
I am not a “beginner” and I appreciate the disclaimer. I value my time: i know
the level of the article and i decide to read it when i have more time.

~~~
wolco
I don't understand why a beginner would skip an article like this. I
understand as a beginner I may not understand what's going on. Shielding
myself from knowledge I might not fully understand slows down learning. Messy
learning by trying to absorb more than can be taken in yet is more effective
because the mind will store the parts not understood and you'll be able to
connect it as you learn other concepts.

------
erik14th
React sure sounds interesting, what puts me off of it is its license.

edit: disregard that...

~~~
kaoD
What's wrong with MIT?

~~~
erik14th
I didn't know about the relicensing, ok, now I have no excuses :E

------
aliswe
This really isn't a fanboyish idea, I hope, but doesn't anyone else think that
Windows should support some kind of javascript UI natively? One can just feel
that they aren't improving their own dialogs etc as fast as they would like
because of implementation complexity...

~~~
coldtea
Yes, we absolutely need an order of magnitude slowdown and more memory use on
our desktops.

Why should Electron users have all the fun?

~~~
aliswe
Just take a look at Sql server management studio, not a ui refresh in what...
20 years?

Some Ux in regedit?

Run dialog not permitting ctrl-arrows?

Really, we need to wake up and realise the fact that the ui experience in
windows is not good enough at all.

