3 ms·

Not really "binding" per se -- mostly because "binding" implies you're attaching events to objects and thinking about "changes", and object lifecycle is still s

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

by jowiar 10y ago

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.