5 ms·

The fundamental problem solved by React is being able to express a UI as a function from Application State to DOM, and not having to worry about manually comput

by jowiar 10y ago

The fundamental problem solved by React is being able to express a UI as a function from Application State to DOM, and not having to worry about manually computing the changes to the DOM that need to occur to reflect the new state of the world. It changes the fundamental question of UI development from "How do I get from where I am to where I want to be?", but "Where do I want to be?" The funny thing about the particular example in the article is that React was heavily inspired by event loops used in Game Development.

softawre 10y ago
So.. data binding? Like backbone did, and knockout? I know React has some things going for it, but data binding on the web is an old trick.
- jowiar 10y ago
  Not really "binding" per se -- mostly because "binding" implies you're attaching events to objects and thinking about "changes", and object lifecycle is still something you're concerned with. React is more functional in nature -- A react component is, almost entirely, a function that takes arguments and spits out DOM elements. React then diffs the desired DOM with the current DOM, and computes the set of transformations needed to update the UI to match the new state -- i.e. "Add a few rows to the table, change the text in a particular span equal to 'boom'" or whatnot.
  - fullofit 10y ago
    That's just an implementation detail. All these declarative UI ideas are variations of sprintf. Something, somewhere, is going to do a diff no matter what, whether it's a virtual DOM or the browser itself.
    - munro 10y ago
      Try making a web app rerenders the DOM on any state change, it will be extremely slow--the browser doesn't diff. :) That's why vDOM & diffing is necessary. Also so UI inputs don't lose focus / selection state / etc.
      - daliwali 10y ago
        State change, eh? There's this, which diffs only local updates and doesn't use a vDOM: http://simulacra.js.org/ http://simulacra.js.org/ Disclosure: I'm the author.
        munro 10y ago
        Tracking changes to application state & translating to DOM changes is nothing new, [1] it's what Angular, Angular2, Riot, Knockout all do, and doomed to efficiently translating any complex state changes. [2] Not only that, feeding application state in from an API will cause the all the dependent UI to completely rerender. [1] https://github.com/sapeien/simulacra/blob/master/lib/bind_keys.js#L143-L148 https://github.com/sapeien/simulacra/blob/master/lib/bind_ke... [2] https://news.ycombinator.com/item?id=12757722 https://news.ycombinator.com/item?id=12757722
      - icedchai 10y ago
        You don't need vDOM/diffing for many types of applications. Your CRUD app doesn't need to update at 60 FPS.
        munro 10y ago
        Diffing is an implementation detail. Imperatively updating might still be needed to hit that 60 FPS ;D Personally, I lean toward server side web apps ATM--users are familiar with page reloads, and developers are familiar with building them. This is changing--users want faster UX, designers want fancier UI, PMs want cross platform apps. These external wants have developers creating & familiarizing with simpler ways to achieve them.
- dlwj 10y ago
  IMO React is popular because it forces people to understand MVC. I've actually never seen a Backbone app where views render based on the model. It's too easy to just ram in jQuery in the render function. A lot of new frameworks just try to reduce Backbone's boilerplate of manual model-view event binding in different ways, dirty watching, virtual DOM, etc... Even flux is basically organized pub/sub. Instead of shouting out what you're doing, you're logging your actions in a logbook. Also, instead of arbitrary actions, you can only combine certain pre-approved actions. It's a natural extension from using globals (too messy) to shouting out your intent while basically using globals (too noisy, still kinda messy) to what I've described above. (still kinda messy, but can be traced and unit tested easily) Flux/Redux and whatever still doesn't help you solve problems that truly reduce complexity like how to organize scope or what abstractions to use. There are tons of good frameworks out there, and it's rather disappointing to me that people don't realize that the basics are the same and insist on everyone jumping on the same bandwagon (that just happens to be supported by a rich large company).
- munro 10y ago
  Data binding exactly, like binding a declarative formula in Excel. Not like Backbone, which did event binding, invoking the programmer's code to imperatively update the DOM. Knockout, and Angular, both do data binding, but their implementations fall short on complex application state changes & how it translates to DOM changes--leading to incidental complexity: digest loop, TTL, $watch, observable, custom handlers. React stupidly doesn't try to understand how the state changes translates DOM changes, and instead rerenders, diffs, and applies the update. React's declarative model is also why it can render on the server side, iOS, or Android. Still, React doesn't translate list sorting to DOM changes efficiently, so imperatively optimizing is still sometimes needed, but less often than in Angular & thankfully not complected by the DOM. React will be replaced when someone solves this. Most likely needing a new programming language, to analyze the application logic & automatically translate into efficient UI updates.
hypertexthero 10y ago
Good description of event loops in games: http://gameprogrammingpatterns.com/game-loop.html http://gameprogrammingpatterns.com/game-loop.html
daliwali 10y ago
I think you just described one way of updating things on a web page. The paradigm which React uses is popular in this moment, but there are many other ways to update things on a web page. It does not actually do anything that couldn't be done before, or with other frameworks or libraries.
- brlewis 10y ago
  Using jQuery you can express a UI as a function from Application State to DOM? I'd be really interested in an example. I've only ever used jQuery to do lots of imperative-looking DOM state changes.
  - daliwali 10y ago
    The end user doesn't know or care about implementation details. It's bikeshedding that nobody cares about except the developers themselves. Facebook could have built their web app with Angular or Ember or whatever and nobody would give a shit except developers. Even as a developer I don't give a shit about what framework a web app I'm using is made with as long as it works (if it's horribly broken then I know what to avoid).
    - brlewis 10y ago
      Isn't that like saying I'm not an architect so I don't really care what kind of foundation my house is built on as long as it hasn't fallen down yet? They're all held up by the same laws of physics anyway.
  - henriquelimao 10y ago
    It is not common, easy, efficient or idiomatic, but you can: Imagine that in each event handler, instead of doing something, you just update some state somewhere, and after that call a common "draw" function. Inside the "draw" function you redraw all your UI: apply effects, etc. That's it, you have it.
    - jowiar 10y ago

by jowiar 10y ago

softawre 10y ago

So.. data binding? Like backbone did, and knockout? I know React has some things going for it, but data binding on the web is an old trick.

jowiar 10y ago
Not really "binding" per se -- mostly because "binding" implies you're attaching events to objects and thinking about "changes", and object lifecycle is still something you're concerned with. React is more functional in nature -- A react component is, almost entirely, a function that takes arguments and spits out DOM elements. React then diffs the desired DOM with the current DOM, and computes the set of transformations needed to update the UI to match the new state -- i.e. "Add a few rows to the table, change the text in a particular span equal to 'boom'" or whatnot.
- fullofit 10y ago
  That's just an implementation detail. All these declarative UI ideas are variations of sprintf. Something, somewhere, is going to do a diff no matter what, whether it's a virtual DOM or the browser itself.
  - munro 10y ago
    Try making a web app rerenders the DOM on any state change, it will be extremely slow--the browser doesn't diff. :) That's why vDOM & diffing is necessary. Also so UI inputs don't lose focus / selection state / etc.
    - daliwali 10y ago
      State change, eh? There's this, which diffs only local updates and doesn't use a vDOM: http://simulacra.js.org/ http://simulacra.js.org/ Disclosure: I'm the author.
      - munro 10y ago
        Tracking changes to application state & translating to DOM changes is nothing new, [1] it's what Angular, Angular2, Riot, Knockout all do, and doomed to efficiently translating any complex state changes. [2] Not only that, feeding application state in from an API will cause the all the dependent UI to completely rerender. [1] https://github.com/sapeien/simulacra/blob/master/lib/bind_keys.js#L143-L148 https://github.com/sapeien/simulacra/blob/master/lib/bind_ke... [2] https://news.ycombinator.com/item?id=12757722 https://news.ycombinator.com/item?id=12757722
    - icedchai 10y ago
      You don't need vDOM/diffing for many types of applications. Your CRUD app doesn't need to update at 60 FPS.
      - munro 10y ago
        Diffing is an implementation detail. Imperatively updating might still be needed to hit that 60 FPS ;D Personally, I lean toward server side web apps ATM--users are familiar with page reloads, and developers are familiar with building them. This is changing--users want faster UX, designers want fancier UI, PMs want cross platform apps. These external wants have developers creating & familiarizing with simpler ways to achieve them.
dlwj 10y ago
IMO React is popular because it forces people to understand MVC. I've actually never seen a Backbone app where views render based on the model. It's too easy to just ram in jQuery in the render function. A lot of new frameworks just try to reduce Backbone's boilerplate of manual model-view event binding in different ways, dirty watching, virtual DOM, etc... Even flux is basically organized pub/sub. Instead of shouting out what you're doing, you're logging your actions in a logbook. Also, instead of arbitrary actions, you can only combine certain pre-approved actions. It's a natural extension from using globals (too messy) to shouting out your intent while basically using globals (too noisy, still kinda messy) to what I've described above. (still kinda messy, but can be traced and unit tested easily) Flux/Redux and whatever still doesn't help you solve problems that truly reduce complexity like how to organize scope or what abstractions to use. There are tons of good frameworks out there, and it's rather disappointing to me that people don't realize that the basics are the same and insist on everyone jumping on the same bandwagon (that just happens to be supported by a rich large company).
munro 10y ago
Data binding exactly, like binding a declarative formula in Excel. Not like Backbone, which did event binding, invoking the programmer's code to imperatively update the DOM. Knockout, and Angular, both do data binding, but their implementations fall short on complex application state changes & how it translates to DOM changes--leading to incidental complexity: digest loop, TTL, $watch, observable, custom handlers. React stupidly doesn't try to understand how the state changes translates DOM changes, and instead rerenders, diffs, and applies the update. React's declarative model is also why it can render on the server side, iOS, or Android. Still, React doesn't translate list sorting to DOM changes efficiently, so imperatively optimizing is still sometimes needed, but less often than in Angular & thankfully not complected by the DOM. React will be replaced when someone solves this. Most likely needing a new programming language, to analyze the application logic & automatically translate into efficient UI updates.

hypertexthero 10y ago

Good description of event loops in games: http://gameprogrammingpatterns.com/game-loop.html http://gameprogrammingpatterns.com/game-loop.html

daliwali 10y ago

I think you just described one way of updating things on a web page. The paradigm which React uses is popular in this moment, but there are many other ways to update things on a web page. It does not actually do anything that couldn't be done before, or with other frameworks or libraries.

brlewis 10y ago
Using jQuery you can express a UI as a function from Application State to DOM? I'd be really interested in an example. I've only ever used jQuery to do lots of imperative-looking DOM state changes.
- daliwali 10y ago
  The end user doesn't know or care about implementation details. It's bikeshedding that nobody cares about except the developers themselves. Facebook could have built their web app with Angular or Ember or whatever and nobody would give a shit except developers. Even as a developer I don't give a shit about what framework a web app I'm using is made with as long as it works (if it's horribly broken then I know what to avoid).
  - brlewis 10y ago
    Isn't that like saying I'm not an architect so I don't really care what kind of foundation my house is built on as long as it hasn't fallen down yet? They're all held up by the same laws of physics anyway.
- henriquelimao 10y ago
  It is not common, easy, efficient or idiomatic, but you can: Imagine that in each event handler, instead of doing something, you just update some state somewhere, and after that call a common "draw" function. Inside the "draw" function you redraw all your UI: apply effects, etc. That's it, you have it.
  - jowiar 10y ago