Incrementality and the web | Hacker News Reader

Incrementality and the web

blogs.janestreet.com

54 pointsstrmpnk11 comments

Cool to read this from Janestreet. More functional, more compile-to-JS, more well-typedness, more reusing code between server and client (isomorphic). Good stuff.

Still working on bringing these things to the place where I work :)

It’s kinda interesting that when people ponder React, they sometimes think of complex ideas and cite math-related terms like Immutability, Isomorphism, or as in this article, examples from circuit design. When I look at it, the first thing I think is that it’s like server-side rendering. It’s not necessarily some mind-bending JavaScript phenomenon; it’s exactly what you’d do when making a WordPress template.

Not sure what you mean by that, it's nothing like server side templates. Server side templates work by string interpolation, like older JavaScript templating languages (Mustache, for example).

It's like server side templates in that an entire refresh of the page occurs without preserving any state, which the React core developers stated as their main motivation behind creating it.

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

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

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

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

That'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.

That's not how most templating languages work any more, they parse them into DOM elements and do minimal updates like virtual dom libraries.

Consider a list. If you only had server-side rendering, you would define a function that iterates through the list and outputs list items. If the list is to be changed when you reload the page, you'd use the same function to render the list, just modifying the variable that contains the list items.

Now in React, you define a component that renders the list. If the list is to be changed, you modify the variable that contains the list items. That same component renders the list again.

If you were using jQuery to change a list it's a whole different story: you'd have some variables that represent the latest state of the list (or the item to change, etc.) but then you have to select and manipulate the list items in the DOM.

So in that way React & server-side rendering are very similar.

Reply on news.ycombinator.com