> Danny: why do you think that changing those elements does less work
> than what happens when you create a new scene with the 2htdp/universe
> version of this program?
The diff-based approach I'm taking in web-world makes it easier to
preserve pieces of state embedded in the dom, without the user having
to know about it. My point of comparison isn't really versus
2htdp/universe's performance: it's versus the functionality of my old
jsworld library from Moby.
One of the things I learned from the previous time I implemented a
world+dom library is that there's a tremendous amount of state in the
DOM that I don't want to explicitly construct. Expressing to-draw in
terms of diffs is nice precisely because the stuff you don't mention
stays the same.
Let me mock up a quick example to demonstrate:
http://hashcollision.org/whalesong/examples/field2/field2.html
The source code is
http://hashcollision.org/whalesong/examples/field2/field2.rkt, with
its template http://hashcollision.org/whalesong/examples/field2/index.html.
The program demos two sources of events: clock ticks, and button entry.
I could not cleanly write this program in my old jsworld library.
In old jsworld, my to-draw handler consumed xexpr representations of
the dom. What makes this problematic is that it's not a complete
representation of the dom: there's state in the text field's cursor
position. That state needs to be somehow represented in the to-draw,
and that state needs to be stable across world updates: if it weren't,
it wouldn't be fun to try to type text into the field, because the
cursor would otherwise jump back to the beginning of the text field on
every clock tick!
Although I could work around that by representing cursor state in my
world, the state of the view is something that isn't really supposed
to be part of the program model.
_________________________________________________
For list-related administrative tasks:
http://lists.racket-lang.org/listinfo/users
