3 ms·
I think it's a valid view if you consider that the rendering is one-shot. All input → entire document. There is no concept of update during a server side page r
by strmpnk 11y ago
I think it's a valid view if you consider that the rendering is one-shot. All input → entire document. There is no concept of update during a server side page rendering, which is quite similar to how the mental model for libraries like react work.
Technically, we can find many differences but in terms of thinking about actual applications, they are a very similar mental burden and that's why I think it's been so popular. I always laugh when I see people talk about DOM diffing as motivation for react. Really, that's the implementation detail. The real motivation is the vastly simplified mental model of how the whole DOM is managed.
This article struck me as an interesting approach to applying new implementation approaches which could offer the ease of this mental model to a wider variety of scenarios. Just like immutability offered an easy way to avoid costly virtual DOM regeneration when the view gets rather large (in terms of instantiated component count). Ideas from SAC could offer efficiency improvements compared to some of the current modular approaches forcing things to fit into rather simple tree structures for state (the Elm architecture as it currently stands can make computation hard to share while keeping things modular).
- Touche 11y ago> I think it's a valid view if you consider that the rendering is one-shot. All input → entire document. There is no concept of update during a server side page rendering, which is quite similar to how the mental model for libraries like react work. There's no concept of update in Mustache either, but on the client updates do happen, and virtual DOMs present one strategy for that while preserving the mental model. > Technically, we can find many differences but in terms of thinking about actual applications, they are a very similar mental burden and that's why I think it's been so popular. I always laugh when I see people talk about DOM diffing as motivation for react. Really, that's the implementation detail. The real motivation is the vastly simplified mental model of how the whole DOM is managed. Why do you think that? A virtual DOM is not necessary for this mental model, Glimmer and other non-vdom libraries allow this as well. The advantage to the vdom approach is that it truly abstracts away UI rendering so that it's not tied to a DOM and therefore is more easily portable to Node, and various native environments.
- strmpnk 11y agoI never said it was necessary. I am mainly pointing out that there are similarities in the mental model of the original comment and the virtual dom. Of course there are many ways to get results. The virtual dom seems quite nice since it avoids the text parsing stage that a traditional template language might imply. regardless, you kind of make my point. A system like mustache is not all that different from how input and output are considered, regardless of whether it's on the client or server. Same with a virtual dom, which runs quite fine on the server side when generating HTML for response content.
- Touche 11y ago> The virtual dom seems quite nice since it avoids the text parsing stage that a traditional template language might imply. Probably 90% of users use JSX, so that need is the same.
- strmpnk 11y agoThat's not quite what I meant. By text parsing, I mean sending a big string to the DOM like: elem.innerHTML = "<p>Example. Please parse me.</p>"; That's going to take more time than carefully constructing elements and reusing things judiciously.
- Touche 11y agoThat's not how most templating languages work any more, they parse them into DOM elements and do minimal updates like virtual dom libraries.