16 ms·

React as a UI Runtime

343 points by danabramov 8y ago

revskill 8y ago
What's a UI Runtime ? The post should give that definition first before jumping into the details.
- danabramov 8y ago
  It links to the “programming runtime” definition on Wikipedia the first time that term is used.
- Vinnl 8y ago
  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.
m0meni 8y ago
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.
- jdc 8y ago
  From my dabbling with QT's QML, I gather it would be a lot more concise than React for some use cases.
- rpedela 8y ago
  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.
  - Bahamut 8y ago
    Just to correct this a bit, while this is certainly true of AngularJS, this is certainly not true of Angular. Angular since v2 has taken a reactive approach throughout, and even the two-way data bing is just syntactic sugar for an evented pattern powered by rxjs. Perf-wise, other than initial load, Angular is actually a little better from my understanding & based on numbers I’ve seen. React has certain weaknesses that aren’t seen in other UI libraries/frameworks as well - forms are a complete mess to work with, even with formik, and animations are pretty problematic. As with anything, there are tradeoffs to approaches. FB isn’t as form heavy in general, so optimizing how it works for the rendering inputs from external sources & dev usability makes sense for their use cases. It’s important not to conflate this by overpraising.
    - mds101 8y ago
      > forms are a complete mess to work with Could you elaborate on this? I've been creating form heavy react apps for a couple of years now and haven't really come across anything that would make it 'a mess'.
- fiddlerwoaroof 8y ago
  The best paradigm I’ve found is the way the Common Lisp Interface Manager (CLIM) works. Unfortunately, there aren’t any implementations available that look “modern”, but you can get a feel for the api on Linux.
- cageface 8y ago
  I like React’s model a lot too and I agree it simplifies typical UI development tasks considerably. The main weakness of this approach in my experience is that is can make it hard to have detailed control of what happens when transitioning between states. Animation is maybe the most obvious example of this. You often need to distinguish between the transitory state of the animation and the underlying React state. I know some interesting work has been done all this already in React but it’s an inherent problem in all reactive approaches.
- platz 8y ago
  WPF in dotnet uses MVVM is quite can different but express some interesting dynamic behaviors.
- Papirola 8y ago
  React == Windows 3.1
  - acemarke 8y ago
    This is actually a not entirely invalid description! There was a neat article a few years back that specifically compared Flux to a Win32 WndProc function: https://www.bitquabit.com/post/the-more-things-change/ https://www.bitquabit.com/post/the-more-things-change/ Prior discussion: https://news.ycombinator.com/item?id=10381015 https://news.ycombinator.com/item?id=10381015
  - mpweiher 8y ago
    Or pretty much any other MVC GUI framework, with modifications because it lives in the browser and renders to a DOM. Certainly when I first saw it my thought was, "hey someone did Cocoa for the Browser, nice". https://blog.metaobject.com/2018/12/uis-are-not-pure-functions-of-model.html https://blog.metaobject.com/2018/12/uis-are-not-pure-functio... "One way data flow" is pretty much exactly how MVC works, except that MVC decouples a bit more: the model is only allowed to send #changed notifications, the view then pulls what it needs. The data still only flows in one direction. "Actions" in Redux are very much the "Command" pattern as used in C++ GUI frameworks such as PowerPlant.
    - Marazan 8y ago
      React is not MVC. I mean, for a start, no 2 MVC frameworks actually agree on how to pass data around. React is just the V.
    - danabramov 8y ago
      Hmm I think the difference between a primarily imperative API like `addSubview` vs a primarily declarative one (“what’s the list of subviews at any given moment?”) is a pretty important differentiator. It has nothing to do with the browser DOM — it’s about the programming model. I tried to express that in the article but maybe I didn’t convey my point well enough.
      - 8y ago
- preommr 8y ago
  Wait a minute, react isn't great because they came up with some ground breaking new concept in ui programming. It's popular because it allows for component based design and updating only what it needs to by diffing. These aren't really novel concepts. It's just a good implementation of ideas that's really helped by mass adoption and the overall community converging on one particular framework leading to lots of tutorials, guides, etc. Even before react, I had webapps where I'd cobbled together helper objects that did things pretty similar to react, although obviously not as robust.
- nikki93 8y ago
  Immediate mode UI systems are p nice.
- ThePhysicist 8y ago
  I also think it’s a really great idea to use a declarative approach sprinkled with imperative code for logic. Combined with the smart diffing of a component tree this is really quite powerful and also easy to grasp for most developers at the same time.
- scarlac 8y ago
  It's a mix of a lot of relatively good choices/trade-offs from the React team. I've been doing GUI apps for long enough to have seen a few attempts in a variety of IDEs (and languages). I like React exactly for this reason - that it models what they've done with components, but in a way that is more robust and flexible. IDEs tend to come and go but JSX as a language seems to have grown beyond React. It's a relatively good way of describing UI that can be read and understood while leaving ample space for dynamic composability which has historically been an issue to represent in the IDE UI builders I've used. I've usually had to resort to mixing UI builders and own code, or giving up on the UI builder entirely and instantiate classes myself. I like React because of the trade-offs. It's not perfect. It's just imperfect in some acceptable ways.
- plq 8y ago
  I always felt like Polymer's component model (with "use the platform" as a motto/basis for implementation) had a bigger overlap with the kinds of problems a UI toolkit was supposed to solve though the frontend community seems to like React's approach better so far.
  - Vinnl 8y ago
    I'm curious what specifically you find that Polymer did to solve those problems (and what those problems are in the first place)? I've worked quite a bit with Polymer and React, and felt that there wasn't really an idea behind Polymer about the best way to solve problems - it seems to mostly be about promoting use of Web Components beyond just reusable date pickers and the likes.
    - plq 8y ago
      First, I do dabble in frontend dev but I'm more of a backend person. I never used React and briefly played with Polymer 2. Shadow DOM and custom tags make it possible to closely mimic the way we used to do UI development back in the Delphi/VB6 era. I like how eg. css properties only apply to a given component. Polymer seemed like the most lightweight possible way to implement this because it uses the browser facilities. I understand that React also has components and custom tags (JSX) but it doesn't use browser facilities but rather implements them itself, which just sounds like the wrong way of approaching the problem.
      - crooked-v 8y ago
        From what I understand, Web Components and Polymer have a ton of fundamental limitations, starting with how data in a component tree is bound to the DOM as strings, so for anything even mildly complicated you have to roll your own JSON.parse / JSON.stringify handling into every component and have to deal with the DOM parsing exploding if you dump too much data into it.
        ergo14 8y ago
        "component tree is bound to the DOM as strings" You can pass data as props instead of attrs, same as with react - https://github.com/Polymer/lit-element https://github.com/Polymer/lit-element. I wonder why this pop's up all the time. It is true that polymer had quite a bit of limitations, but there are other solutions like stencil, lit-element, svelte or vue (yes it can output WC's) that do not have those problems. Lit-html in latest version I think is only outperformed by inferno from popular solutions.
- jcelerier 8y ago
  Qt's QML is React with 1/3rd the bloat in terms of code
  - kbumsik 8y ago
    Yeah, I always tell people to look at QML when it comes to clean UI frameworks. It is a bit sad QML is not a web framework.
    - yen223 8y ago
      Any good examples?
      - jdc 8y ago
        https://github.com/jcelerier/TodoMVC-QML https://github.com/jcelerier/TodoMVC-QML
  - dmitriid 8y ago
    Qt's QML is "1/3 in terms of code" only because it has the entire Qt framework behind it. On the web you have to reinvent the wheel for everything (because there are no wheels in the browser and its APIs).
    - rat9988 8y ago
      I think he refers to the code you write.
- panic 8y ago
  Native UI systems tend to support more complex event dispatch, which often involves cross-component communication -- look at drag and drop, for example, or the complex exclusion behavior of gesture recognizers on iOS. Carrying an interactive gesture through to an animation while preserving velocity is also difficult to do using the DOM.
- mhd 8y ago
  To me a "holy grail" wouldn't just be about being superior, but about being complete. Even within the web space, with its simplistic UIs, React doesn't do a lot (intentionally). Whether it's a shining diamond of mathematical beauty or a plug in the bunghole of the web stack doesn't matter in that regard. For a complete UI you need more, and then the bikeshedding starts. And Desktop UI libraries tend to be even more complex. And as usual, warts are on the outside.
- kbumsik 8y ago
  Well, React concepts is not new at all. Things like data fetching and state management are done in Desktop UI frameworks more than a decade ago. All the praise around react is because they did it well on the web.
- flohofwoe 8y ago
  Immediate Mode UIs, at least for "code driven UIs" (as opposed to artist-driven UIs): https://caseymuratori.com/blog_0001 https://caseymuratori.com/blog_0001 https://github.com/ocornut/imgui https://github.com/ocornut/imgui
- machiaweliczny 8y ago
  If you have complex state MobX is very nice and performant and works with Typescript well. Apollo is also nice. It's best for display heavy apps as documentation and typechecking is at least enforced/built-in. But I feel it's too abstracted/magic for heavy state apps. I still need to find good flow with Typescript and Apollo though. (to not repeat types - haven't tried yet really). Redux IMO is overkill and is/was abused. It's good if you want to store some global data/config and have clear view od it. But for very dynamic state MobX is much less overhead. I would just like a good way to share components and simpler styling. BTW for simplest state management I like pure class implementation and just calling update on main component after event handler finishes. It's easier to test and good enough for simple UIs.
- c-smile 8y ago
  > Is there anything out there that you guys feel is superior? React is just one of paradigms. And UI is a multi-paradigm entity. When architecture of one component can benefit from React model, others - may not. Consider basic <input> as a component. In order to update its value you just need to execute this: input.value = "New value"; Wrapping such input into React.Component is a waste of resources. As for me Twitter's Flight ( https://flightjs.github.io/ https://flightjs.github.io/ ) is less constraining - more general if you wish. It is just very simple infrastructure around PubSub idea. Loosely coupled components interact with each other by posting UI lifecycle events. Components subscribe themselves to such events and react on them in most optimal, component specific way. Some of components may use React internally, some have better means to update themselves.
chrislloyd 8y ago
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 8y ago
  Context for where that syntax came from: http://displayscript.org/language-reference-state-and-identity.html http://displayscript.org/language-reference-state-and-identi...
  - danabramov 8y ago
    Yep, also a few other references are here https://reactjs.org/docs/hooks-faq.html#what-is-the-prior-art-for-hooks https://reactjs.org/docs/hooks-faq.html#what-is-the-prior-ar...
platform 8y ago
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 8y ago
  How do you solve B and C without coupling the shape of the components tree to the state of the state tree?
  - platform 8y ago
    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'
self_awareness 8y ago
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 8y ago
  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/example-with-redux https://github.com/longseespace/react-qml/tree/next/packages...
  - lol768 8y ago
    >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.
- rohan1024 8y ago
  There's already work going on in that direction https://github.com/google/flutter-desktop-embedding https://github.com/google/flutter-desktop-embedding
szines 8y ago
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/
BossingAround 8y ago
> 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 8y ago
  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 8y ago
    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.
    - WA 8y ago
      The disclaimer might serve an important purpose: reduce the amount of questions the author receives via email/Twitter. The disclaimer is obviously not written for you who can decide for yourself, but for people who are quick to write questions instead of reading the damn thing. How do I know? Because I have disclaimers here and there that are obvious for most people and still help to reduce the support burden.
    - russx2 8y ago
      Because the author doesn't want to intimidate new users by making them feel this is necessary knowledge to learn react. As someone presumably more knowledgeable in the field, it's much easier to judge whether an article is at the right level for you than someone just starting out. I really don't understand your issue here.
vnorilo 8y ago
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).
aliswe 8y ago
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...
- blitmap 8y ago
  I had hoped we were moving toward that with Universal Windows Platform apps. :3
- coldtea 8y ago
  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 8y ago
    I get your drift but I just feel development of UIs all over the place (in windows) have stagnated and they are too costly to modify
  - aliswe 8y ago
    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.
erik14th 8y ago
React sure sounds interesting, what puts me off of it is its license. edit: disregard that...
- kaoD 8y ago
  What's wrong with MIT?
  - erik14th 8y ago
    I didn't know about the relicensing, ok, now I have no excuses :E
sktrdie 8y ago
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 8y ago
  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 8y ago
    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.
m_fayer 8y ago
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 8y ago
  This is a fundamental problem with most programming languages I’ve come across. It’s quite annoying.
supercarsw 8y ago
why to glorify facebook technology ?
Zooper 8y ago
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.

343 points by danabramov 8y ago

revskill 8y ago

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

danabramov 8y ago
It links to the “programming runtime” definition on Wikipedia the first time that term is used.
Vinnl 8y ago
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.

m0meni 8y ago

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.

jdc 8y ago
From my dabbling with QT's QML, I gather it would be a lot more concise than React for some use cases.
rpedela 8y ago
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.
- Bahamut 8y ago
  Just to correct this a bit, while this is certainly true of AngularJS, this is certainly not true of Angular. Angular since v2 has taken a reactive approach throughout, and even the two-way data bing is just syntactic sugar for an evented pattern powered by rxjs. Perf-wise, other than initial load, Angular is actually a little better from my understanding & based on numbers I’ve seen. React has certain weaknesses that aren’t seen in other UI libraries/frameworks as well - forms are a complete mess to work with, even with formik, and animations are pretty problematic. As with anything, there are tradeoffs to approaches. FB isn’t as form heavy in general, so optimizing how it works for the rendering inputs from external sources & dev usability makes sense for their use cases. It’s important not to conflate this by overpraising.
  - mds101 8y ago
    > forms are a complete mess to work with Could you elaborate on this? I've been creating form heavy react apps for a couple of years now and haven't really come across anything that would make it 'a mess'.
fiddlerwoaroof 8y ago
The best paradigm I’ve found is the way the Common Lisp Interface Manager (CLIM) works. Unfortunately, there aren’t any implementations available that look “modern”, but you can get a feel for the api on Linux.
cageface 8y ago
I like React’s model a lot too and I agree it simplifies typical UI development tasks considerably. The main weakness of this approach in my experience is that is can make it hard to have detailed control of what happens when transitioning between states. Animation is maybe the most obvious example of this. You often need to distinguish between the transitory state of the animation and the underlying React state. I know some interesting work has been done all this already in React but it’s an inherent problem in all reactive approaches.
platz 8y ago
WPF in dotnet uses MVVM is quite can different but express some interesting dynamic behaviors.
Papirola 8y ago
React == Windows 3.1
- acemarke 8y ago
  This is actually a not entirely invalid description! There was a neat article a few years back that specifically compared Flux to a Win32 WndProc function: https://www.bitquabit.com/post/the-more-things-change/ https://www.bitquabit.com/post/the-more-things-change/ Prior discussion: https://news.ycombinator.com/item?id=10381015 https://news.ycombinator.com/item?id=10381015
- mpweiher 8y ago
  Or pretty much any other MVC GUI framework, with modifications because it lives in the browser and renders to a DOM. Certainly when I first saw it my thought was, "hey someone did Cocoa for the Browser, nice". https://blog.metaobject.com/2018/12/uis-are-not-pure-functions-of-model.html https://blog.metaobject.com/2018/12/uis-are-not-pure-functio... "One way data flow" is pretty much exactly how MVC works, except that MVC decouples a bit more: the model is only allowed to send #changed notifications, the view then pulls what it needs. The data still only flows in one direction. "Actions" in Redux are very much the "Command" pattern as used in C++ GUI frameworks such as PowerPlant.
  - Marazan 8y ago
    React is not MVC. I mean, for a start, no 2 MVC frameworks actually agree on how to pass data around. React is just the V.
  - danabramov 8y ago
    Hmm I think the difference between a primarily imperative API like `addSubview` vs a primarily declarative one (“what’s the list of subviews at any given moment?”) is a pretty important differentiator. It has nothing to do with the browser DOM — it’s about the programming model. I tried to express that in the article but maybe I didn’t convey my point well enough.
    - 8y ago
preommr 8y ago
Wait a minute, react isn't great because they came up with some ground breaking new concept in ui programming. It's popular because it allows for component based design and updating only what it needs to by diffing. These aren't really novel concepts. It's just a good implementation of ideas that's really helped by mass adoption and the overall community converging on one particular framework leading to lots of tutorials, guides, etc. Even before react, I had webapps where I'd cobbled together helper objects that did things pretty similar to react, although obviously not as robust.
nikki93 8y ago
Immediate mode UI systems are p nice.
ThePhysicist 8y ago
I also think it’s a really great idea to use a declarative approach sprinkled with imperative code for logic. Combined with the smart diffing of a component tree this is really quite powerful and also easy to grasp for most developers at the same time.
scarlac 8y ago
It's a mix of a lot of relatively good choices/trade-offs from the React team. I've been doing GUI apps for long enough to have seen a few attempts in a variety of IDEs (and languages). I like React exactly for this reason - that it models what they've done with components, but in a way that is more robust and flexible. IDEs tend to come and go but JSX as a language seems to have grown beyond React. It's a relatively good way of describing UI that can be read and understood while leaving ample space for dynamic composability which has historically been an issue to represent in the IDE UI builders I've used. I've usually had to resort to mixing UI builders and own code, or giving up on the UI builder entirely and instantiate classes myself. I like React because of the trade-offs. It's not perfect. It's just imperfect in some acceptable ways.
plq 8y ago
I always felt like Polymer's component model (with "use the platform" as a motto/basis for implementation) had a bigger overlap with the kinds of problems a UI toolkit was supposed to solve though the frontend community seems to like React's approach better so far.
- Vinnl 8y ago
  I'm curious what specifically you find that Polymer did to solve those problems (and what those problems are in the first place)? I've worked quite a bit with Polymer and React, and felt that there wasn't really an idea behind Polymer about the best way to solve problems - it seems to mostly be about promoting use of Web Components beyond just reusable date pickers and the likes.
  - plq 8y ago
    First, I do dabble in frontend dev but I'm more of a backend person. I never used React and briefly played with Polymer 2. Shadow DOM and custom tags make it possible to closely mimic the way we used to do UI development back in the Delphi/VB6 era. I like how eg. css properties only apply to a given component. Polymer seemed like the most lightweight possible way to implement this because it uses the browser facilities. I understand that React also has components and custom tags (JSX) but it doesn't use browser facilities but rather implements them itself, which just sounds like the wrong way of approaching the problem.
    - crooked-v 8y ago
      From what I understand, Web Components and Polymer have a ton of fundamental limitations, starting with how data in a component tree is bound to the DOM as strings, so for anything even mildly complicated you have to roll your own JSON.parse / JSON.stringify handling into every component and have to deal with the DOM parsing exploding if you dump too much data into it.
      - ergo14 8y ago
        "component tree is bound to the DOM as strings" You can pass data as props instead of attrs, same as with react - https://github.com/Polymer/lit-element https://github.com/Polymer/lit-element. I wonder why this pop's up all the time. It is true that polymer had quite a bit of limitations, but there are other solutions like stencil, lit-element, svelte or vue (yes it can output WC's) that do not have those problems. Lit-html in latest version I think is only outperformed by inferno from popular solutions.
jcelerier 8y ago
Qt's QML is React with 1/3rd the bloat in terms of code
- kbumsik 8y ago
  Yeah, I always tell people to look at QML when it comes to clean UI frameworks. It is a bit sad QML is not a web framework.
  - yen223 8y ago
    Any good examples?
    - jdc 8y ago
      https://github.com/jcelerier/TodoMVC-QML https://github.com/jcelerier/TodoMVC-QML
- dmitriid 8y ago
  Qt's QML is "1/3 in terms of code" only because it has the entire Qt framework behind it. On the web you have to reinvent the wheel for everything (because there are no wheels in the browser and its APIs).
  - rat9988 8y ago
    I think he refers to the code you write.
panic 8y ago
Native UI systems tend to support more complex event dispatch, which often involves cross-component communication -- look at drag and drop, for example, or the complex exclusion behavior of gesture recognizers on iOS. Carrying an interactive gesture through to an animation while preserving velocity is also difficult to do using the DOM.
mhd 8y ago
To me a "holy grail" wouldn't just be about being superior, but about being complete. Even within the web space, with its simplistic UIs, React doesn't do a lot (intentionally). Whether it's a shining diamond of mathematical beauty or a plug in the bunghole of the web stack doesn't matter in that regard. For a complete UI you need more, and then the bikeshedding starts. And Desktop UI libraries tend to be even more complex. And as usual, warts are on the outside.
kbumsik 8y ago
Well, React concepts is not new at all. Things like data fetching and state management are done in Desktop UI frameworks more than a decade ago. All the praise around react is because they did it well on the web.
flohofwoe 8y ago
Immediate Mode UIs, at least for "code driven UIs" (as opposed to artist-driven UIs): https://caseymuratori.com/blog_0001 https://caseymuratori.com/blog_0001 https://github.com/ocornut/imgui https://github.com/ocornut/imgui
machiaweliczny 8y ago
If you have complex state MobX is very nice and performant and works with Typescript well. Apollo is also nice. It's best for display heavy apps as documentation and typechecking is at least enforced/built-in. But I feel it's too abstracted/magic for heavy state apps. I still need to find good flow with Typescript and Apollo though. (to not repeat types - haven't tried yet really). Redux IMO is overkill and is/was abused. It's good if you want to store some global data/config and have clear view od it. But for very dynamic state MobX is much less overhead. I would just like a good way to share components and simpler styling. BTW for simplest state management I like pure class implementation and just calling update on main component after event handler finishes. It's easier to test and good enough for simple UIs.
c-smile 8y ago
> Is there anything out there that you guys feel is superior? React is just one of paradigms. And UI is a multi-paradigm entity. When architecture of one component can benefit from React model, others - may not. Consider basic <input> as a component. In order to update its value you just need to execute this: input.value = "New value"; Wrapping such input into React.Component is a waste of resources. As for me Twitter's Flight ( https://flightjs.github.io/ https://flightjs.github.io/ ) is less constraining - more general if you wish. It is just very simple infrastructure around PubSub idea. Loosely coupled components interact with each other by posting UI lifecycle events. Components subscribe themselves to such events and react on them in most optimal, component specific way. Some of components may use React internally, some have better means to update themselves.

chrislloyd 8y ago

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 8y ago
Context for where that syntax came from: http://displayscript.org/language-reference-state-and-identity.html http://displayscript.org/language-reference-state-and-identi...
- danabramov 8y ago
  Yep, also a few other references are here https://reactjs.org/docs/hooks-faq.html#what-is-the-prior-art-for-hooks https://reactjs.org/docs/hooks-faq.html#what-is-the-prior-ar...

platform 8y ago

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 8y ago
How do you solve B and C without coupling the shape of the components tree to the state of the state tree?
- platform 8y ago
  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'

self_awareness 8y ago

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 8y ago
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/example-with-redux https://github.com/longseespace/react-qml/tree/next/packages...
- lol768 8y ago
  >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.
rohan1024 8y ago
There's already work going on in that direction https://github.com/google/flutter-desktop-embedding https://github.com/google/flutter-desktop-embedding

szines 8y ago

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/

BossingAround 8y ago

> 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 8y ago
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 8y ago
  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.
  - WA 8y ago
    The disclaimer might serve an important purpose: reduce the amount of questions the author receives via email/Twitter. The disclaimer is obviously not written for you who can decide for yourself, but for people who are quick to write questions instead of reading the damn thing. How do I know? Because I have disclaimers here and there that are obvious for most people and still help to reduce the support burden.
  - russx2 8y ago
    Because the author doesn't want to intimidate new users by making them feel this is necessary knowledge to learn react. As someone presumably more knowledgeable in the field, it's much easier to judge whether an article is at the right level for you than someone just starting out. I really don't understand your issue here.

vnorilo 8y ago

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).

aliswe 8y ago

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...

blitmap 8y ago
I had hoped we were moving toward that with Universal Windows Platform apps. :3
coldtea 8y ago
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 8y ago
  I get your drift but I just feel development of UIs all over the place (in windows) have stagnated and they are too costly to modify
- aliswe 8y ago
  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.

erik14th 8y ago

React sure sounds interesting, what puts me off of it is its license. edit: disregard that...

kaoD 8y ago
What's wrong with MIT?
- erik14th 8y ago
  I didn't know about the relicensing, ok, now I have no excuses :E

sktrdie 8y ago

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 8y ago
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 8y ago
  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.

m_fayer 8y ago

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 8y ago
This is a fundamental problem with most programming languages I’ve come across. It’s quite annoying.

supercarsw 8y ago

why to glorify facebook technology ?

Zooper 8y ago

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.