9 ms·

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 t

by 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
      I find that the biggest issue with forms and react is attempting to use lifecycle methods and local state to manage the behavior of the controls: at work, I’ve done a bunch of refactorings to replace local state and lifecycle methods with redux and logic in the render method of the parent components, and this has always led to simpler components and has fixed a lot of bugs caused by inconsistencies between props and state.
      - jordic 8y ago
        You made not need redux! Found lot's of projects where they plug redux an turns the project a completly mess. (connected components everywhere), actions to manage local component ui state..
        danabramov 8y ago
- faitswulff 8y ago
  I was with you until the past sentence, which seems unsubstantiated. VueJS, at least, uses a similar virtual dom rendering concept. I find Vue's API much more natural than React's, but that's unrelated to their internal implementations. Can you provide further detail?
  - dmitriid 8y ago
    IMO Vue.js API is way messier than React's: https://news.ycombinator.com/item?id=17471199 https://news.ycombinator.com/item?id=17471199
  - rpedela 8y ago
    Yes, I am aware Vue is more similar to React than the others. I probably shouldn't have said anything about Vue. Since I did, here we go. There is another component to React which I didn't mention that gets inspiration from the 3D world: the API. When I first saw React's API, the first thing I thought was "that looks kinda like OpenSceneGraph, cool!" Now this is the very subjective part, having spent 8-9 years doing 3D graphics React felt natural to me. Given its popularity, I must not be the only one either. I am glad you like the Vue API but it doesn't feel like a 3D engine. For whatever reason, many people seem to prefer the 3D engine feel. On purely technical merits, I think React and Vue are basically the same. But I think there is some intangible difference in how the tools feel. Some people like React and some like Vue and both are right. However more people seem to like React.
    - faitswulff 8y ago
      > Now this is the very subjective part, having spent 8-9 years doing 3D graphics React felt natural to me. Given its popularity, I must not be the only one either. I am glad you like the Vue API but it doesn't feel like a 3D engine. I would postulate that the subset of people who are both web developers and have also worked on 3D graphics is a relatively small slice, so I wouldn't be convinced that a 3D engine-like API is the reason for its popularity.
      - rpedela 8y ago
- meandmycode 8y ago
  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.
  - Aeolun 8y ago
    3D engines have the part where they try to reduce rendering in the engine part, so you don’t deal with it when writing your application, but it’s definitely there.
  - wongarsu 8y ago
    > 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.
  - dsego 8y ago
    Have you looked at Mithril? Looks a lot like React, but there is no need for immutability, because it redraws after events or xhr calls. You can just mutate a model/store object in event handlers and the UI reflects the changes. Imho, this is a much simpler model and it's what you need 99% of the time.
  - faitswulff 8y ago
    OP is correct, the React render loop is very much inspired by 3D game engines: https://www.youtube.com/watch?v=x7cQ3mrcKaY#t=1196 https://www.youtube.com/watch?v=x7cQ3mrcKaY#t=1196
  - rpedela 8y ago
    When I say minimize rendering, I don't mean skipping frames although it could mean that. During a single frame, 3d engines try to minimize the number of triangles, textures, etc that need to be rendered in that frame. Also some non-realtime 3d applications, like CAD, will skip frames. If React has to do animation, then it can't skip frames either.
- foota 8y ago
  Makes me wonder what a web browser with an API like a graphics library (opengl, etc) would look like.
  - crooked-v 8y ago
    https://developer.mozilla.org/en-US/docs/Web/API/WebGL_API https://developer.mozilla.org/en-US/docs/Web/API/WebGL_API
- flohofwoe 8y ago
  High performance 3D applications (like games) typically recreate the entire rendering command list from scratch each frame instead of manipulating an existing "scene graph". React feels more like "retained mode rendering engines" which were popular in the 90's and early 2000's.
  - pygy_ 8y ago
    React provides an immediate mode API (virtual DOM, which is recreated from scratch on every render) implemented on top of a retained mode API (the actual DOM which is stateful). Diffing and piecemeal updates are an implementation detail/optimization.
    - jules 8y ago
      Diffing results in different behavior if components have internal state.
- dangerbird2 8y ago
  Under the hood, Vue uses a similar virtual dom model as react, and at its core is based on one-way data binding. Vue's `v-model` is not a two-way binding a la angular, but syntactic sugar for the common (non-flux) react idiom of updating a parent's state based on an event emmitted by the child (which is handled by a vanilla react-style prop function)
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.

by m0meni 8y ago

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
    I find that the biggest issue with forms and react is attempting to use lifecycle methods and local state to manage the behavior of the controls: at work, I’ve done a bunch of refactorings to replace local state and lifecycle methods with redux and logic in the render method of the parent components, and this has always led to simpler components and has fixed a lot of bugs caused by inconsistencies between props and state.
    - jordic 8y ago
      You made not need redux! Found lot's of projects where they plug redux an turns the project a completly mess. (connected components everywhere), actions to manage local component ui state..
      - danabramov 8y ago
faitswulff 8y ago
I was with you until the past sentence, which seems unsubstantiated. VueJS, at least, uses a similar virtual dom rendering concept. I find Vue's API much more natural than React's, but that's unrelated to their internal implementations. Can you provide further detail?
- dmitriid 8y ago
  IMO Vue.js API is way messier than React's: https://news.ycombinator.com/item?id=17471199 https://news.ycombinator.com/item?id=17471199
- rpedela 8y ago
  Yes, I am aware Vue is more similar to React than the others. I probably shouldn't have said anything about Vue. Since I did, here we go. There is another component to React which I didn't mention that gets inspiration from the 3D world: the API. When I first saw React's API, the first thing I thought was "that looks kinda like OpenSceneGraph, cool!" Now this is the very subjective part, having spent 8-9 years doing 3D graphics React felt natural to me. Given its popularity, I must not be the only one either. I am glad you like the Vue API but it doesn't feel like a 3D engine. For whatever reason, many people seem to prefer the 3D engine feel. On purely technical merits, I think React and Vue are basically the same. But I think there is some intangible difference in how the tools feel. Some people like React and some like Vue and both are right. However more people seem to like React.
  - faitswulff 8y ago
    > Now this is the very subjective part, having spent 8-9 years doing 3D graphics React felt natural to me. Given its popularity, I must not be the only one either. I am glad you like the Vue API but it doesn't feel like a 3D engine. I would postulate that the subset of people who are both web developers and have also worked on 3D graphics is a relatively small slice, so I wouldn't be convinced that a 3D engine-like API is the reason for its popularity.
    - rpedela 8y ago
meandmycode 8y ago
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.
- Aeolun 8y ago
  3D engines have the part where they try to reduce rendering in the engine part, so you don’t deal with it when writing your application, but it’s definitely there.
- wongarsu 8y ago
  > 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.
- dsego 8y ago
  Have you looked at Mithril? Looks a lot like React, but there is no need for immutability, because it redraws after events or xhr calls. You can just mutate a model/store object in event handlers and the UI reflects the changes. Imho, this is a much simpler model and it's what you need 99% of the time.
- faitswulff 8y ago
  OP is correct, the React render loop is very much inspired by 3D game engines: https://www.youtube.com/watch?v=x7cQ3mrcKaY#t=1196 https://www.youtube.com/watch?v=x7cQ3mrcKaY#t=1196
- rpedela 8y ago
  When I say minimize rendering, I don't mean skipping frames although it could mean that. During a single frame, 3d engines try to minimize the number of triangles, textures, etc that need to be rendered in that frame. Also some non-realtime 3d applications, like CAD, will skip frames. If React has to do animation, then it can't skip frames either.
foota 8y ago
Makes me wonder what a web browser with an API like a graphics library (opengl, etc) would look like.
- crooked-v 8y ago
  https://developer.mozilla.org/en-US/docs/Web/API/WebGL_API https://developer.mozilla.org/en-US/docs/Web/API/WebGL_API
flohofwoe 8y ago
High performance 3D applications (like games) typically recreate the entire rendering command list from scratch each frame instead of manipulating an existing "scene graph". React feels more like "retained mode rendering engines" which were popular in the 90's and early 2000's.
- pygy_ 8y ago
  React provides an immediate mode API (virtual DOM, which is recreated from scratch on every render) implemented on top of a retained mode API (the actual DOM which is stateful). Diffing and piecemeal updates are an implementation detail/optimization.
  - jules 8y ago
    Diffing results in different behavior if components have internal state.
dangerbird2 8y ago
Under the hood, Vue uses a similar virtual dom model as react, and at its core is based on one-way data binding. Vue's `v-model` is not a two-way binding a la angular, but syntactic sugar for the common (non-flux) react idiom of updating a parent's state based on an event emmitted by the child (which is handled by a vanilla react-style prop function)

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.