[racket] fruit flies

Oh, I see. This is not about performance at all (I was confused by the
verb "redraw" FWIW).

It does seem good to be able to specify a path & a change when you
have huge nesting like that, I agree.

Robby

On Mon, Sep 12, 2011 at 8:51 PM, Danny Yoo <dyoo at cs.wpi.edu> wrote:
>> 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.
>