
Incrementality and the web - strmpnk
https://blogs.janestreet.com/incrementality-and-the-web/
======
cies
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 :)

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

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

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

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

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

