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 <d...@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. > _________________________________________________ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/users
