[racket] fruit flies

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