Re:How to avoid rewriting your JavaScript application
by fullofit on Thursday October 20, 2016 @05:35PM
(#12756390)
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.
Re:How to avoid rewriting your JavaScript application
by munro on Thursday October 20, 2016 @10:32PM
(#12757783)
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.
Re:How to avoid rewriting your JavaScript application
by daliwali on Friday October 21, 2016 @03:50AM
(#12758847)
State change, eh? There's this, which diffs only local updates and doesn't use a vDOM: http://simulacra.js.org/
Disclosure: I'm the author.
Re:How to avoid rewriting your JavaScript application
by munro on Friday October 21, 2016 @04:42PM
(#12764553)
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_ke... [2] https://news.ycombinator.com/item?id=12757722
Re:How to avoid rewriting your JavaScript application
by icedchai on Friday October 21, 2016 @09:30AM
(#12760216)
You don't need vDOM/diffing for many types of applications. Your CRUD app doesn't need to update at 60 FPS.
Re:How to avoid rewriting your JavaScript application
by munro on Friday October 21, 2016 @04:59PM
(#12764729)
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.
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.