Isomorphic - runs the same on both web browser and server nodejs.
Virtual dom - not the real dom tree but a representation of the dom using nested objects. You can diff two versions of trees (current and updated) and apply the changes to the real browser dom. This makes building pretty UIs super easy since a view is essentially a function of state. Diffing the virtual dom and patching the real dom is much faster than iterating over the the real dom for every update.
On the server side, you use the virtual dom to render to html string.
So true isomorphism is basically when the same code is used in both browser and server. Server renders the initial page load to html string, once loaded by the browser the browser again uses the same view code to make further UI changes without causing a page reload (single page app). Good for search engines and crawlers, good for blazing fast performance and instaneous interactivity.
Some definitions from my understanding: "isomorphic" - can render on server and client side with same code, "virtual dom" - non-browser DOM, i.e. often just a HTML data model useful for mutating and then diffing to minimize changes to the page DOM, "dom" - the data model of the page.
An isomorphic virtual DOM is much like an inverted-index homomorphic shadow DOM, but instead of using a shadowed mapping they virtualize the original elements themselves.
Yup. Otherwise he's basically talking about a structure-preserving index that maps DOM elements - that are rendered outside the main document DOM tree - to a file.
I don't think many would understand what an inverted-index homomorphic shadow DOM is, though I think I can cobble together a very very vague understanding.
In a regular DOM there's just a tree of elements, this makes many operations tedious, e.g. finding elements with a given set of classes and so on. So with an inverted-index shadow DOM you get another DOM with element shadows and an index of element properties back to the shadow elements (making it an inverted index). Then simple boolean retrieval can be used instead of DOM traversal. Much more efficient. The actual reason why you want to use shadowing instead of direct-mapped nodes/elements is shadowing enabling E2C (element change coalescing) meaning instead of shadow element changes directly transferring over to a change of the actual DOM element you can batch changes on shadow elements together and change a bunch of DOM elements in one go, which avoids unpartitioned (and therefore wasteful) re-renders by the browser engine.
(Ok, before anyone goes running off telling their colleagues about this great new tech: I literally made all of this up on the fly except the batching stuff. That's actually one of two reasons why this whole shadow-DOM-stuff exists. The other is encapsulation. I think this whole thread is a most beautiful demonstration of Poe's law in its original form.)
> An isomorphic virtual DOM is much like an inverted-index homomorphic shadow DOM, but instead of using a shadowed mapping they virtualize the original elements themselves.
Not sure if this is ironic, but a 5 year old definitely wouldn't understand this!
Virtual dom - not the real dom tree but a representation of the dom using nested objects. You can diff two versions of trees (current and updated) and apply the changes to the real browser dom. This makes building pretty UIs super easy since a view is essentially a function of state. Diffing the virtual dom and patching the real dom is much faster than iterating over the the real dom for every update.
On the server side, you use the virtual dom to render to html string.
So true isomorphism is basically when the same code is used in both browser and server. Server renders the initial page load to html string, once loaded by the browser the browser again uses the same view code to make further UI changes without causing a page reload (single page app). Good for search engines and crawlers, good for blazing fast performance and instaneous interactivity.