
Incrementally Improving the DOM - ingve
http://blog.functorial.com/posts/2018-04-08-Incrementally-Improving-The-DOM.html
======
liquidify
Man this entire article was hard to approach. Some internal links to some
background info, or a bit deeper background introduction section would be
really great. The writing style is great, but there were some real leaps for a
one off article. If there is some history behind this that I was supposed to
implicitly know about then I apologize for the comment.

~~~
mikekchar
When I was working through his Purescript book (and later watching some of his
videos) I had the same problem. He strikes me as one of these very intelligent
people who have difficulty explaining what he's talking about because
everything is so clear to him.

What I found with the previous things I've seen from him is that if I write
some code I get stuck. Then I look at what he wrote again - lo and behold, he
has the answer. Rinse and repeat. I've learned a ridiculous amount from him in
this fashion :-)

~~~
latchkey
"He strikes me as one of these very intelligent people who have difficulty
explaining what he's talking about because everything is so clear to him."

There needs to be a word for that.

~~~
girvo
Wizards. Indistinguishable from magic and all that.

------
nobleach
Phil's brain is extraordinary. I find that I need to read and re-read his blog
posts/listen and re-listen to his talks to pick up on even a small amount of
what he's saying. Great content.

~~~
mindB
I'm not disagreeing that this is good content, but doesn't having to reread
something or relisten to something indicate that the pedagogical approach
could have been better rather than that the teacher is a good teacher? In
general, for teaching (note that this is very different than resources used
for reference), caeteris paribus shouldn't we prefer the teacher who is easier
to understand?

EDIT: It occurs to me that possibly your first and third statement were
actually intended to be unrelated to your second. In which case, please
disregard this comment.

~~~
setr
It's also a question of density; if he's simply saying a lot in very little,
or assuming you'll do the menial work like a paper will (offers a theorem,
properties and consequences, but proving the theorem is left as an exercise
for the reader), then itll have the same property of having to re-read it, or
rather, read it very carefully, but still be very valuable.

The difference is in the goal. If its _just_ pedagogical, then you'd want to
explain it in three different ways, hoping one will stick; but if its also
intended as a reference to review, and discuss, after understanding the
general principles (and believing in the theorems), then conciseness is
preferable. Three different explanations just makes it _more_ difficult to
figure out what you're looking for

------
kepano
If you are in Los Angeles and curious about PureScript, Phil (the author) is
hosting a meetup at Lumi HQ tomorrow, April 9th. This will be one of the
topics. We're also streaming it on YouTube. [https://www.meetup.com/LA-
PureScript/events/249209149/](https://www.meetup.com/LA-
PureScript/events/249209149/)

------
leeoniya
it'd be interesting to see where the purescript impl lands in this bench [1].
there are some truly fast vdom implementations out there. i also think a lot
of this type of stuff can be compiled more optimally from a custom DSL to vdom
rather than JSX to vdom (e.g.
[https://github.com/sveltejs/svelte](https://github.com/sveltejs/svelte))

[1] [https://rawgit.com/krausest/js-framework-
benchmark/master/we...](https://rawgit.com/krausest/js-framework-
benchmark/master/webdriver-ts-results/table.html)

------
moosingin3space
Is this similar to what Svelte does, where Svelte compiles down to the right
DOM transformations?

------
jochung
Oh lovely. I've been trying to figure out how to address this in the context
of GPU shaders and here comes the perfect paper!

------
jiyinyiyong
Someone please explain that without ADT? And with graphs?

