Well, it was bummer for me I can't to listen, since I am deaf on my right ear (for real, accident when I was a kid). But the power point presentation was nice!

Hi Craig, 1. Thanks for the correction on Ted's name spelling. I can't understand how I mispeled his name! I corrected the updated version at the Cuis repo. 2. To see why I think that SystemTracer and MicroSqueak are brittle, check how they handle identity hash and hashed collections, and what it would take to make the image builder able to assign new hashes. I think that MicroSqueak is hacky because of the way it detangles objects from existing image to the new image. You may disagree, and that's ok. I didn't use any of these as starting points. I actually reviewed to find out which of them would be a better starting point. The only one that does something similar to what I want is PharoBootstrap. But it using VMMaker to handle the inner details results in a design that is too hard to evolve into other image formats than those supported by VMMaker. 3. You don't want "primacy of source code". That's ok. Your objectives are different from mine. I don't see a problem. Again, I wanted something quite different from Spoon. So, I wrote it. 4. Only method explicitly specified are included. See, for instance, #addBasicMethodsAndReferencedClasses and #addExample03FloatMethods. 5. Because morphing X into what I want is not worth it if X is too different. It is not my intention to downplay anybody's work. I just wanted to explain why I didn't use them as starting point. I took a lot of inspiration from MicroSqueak, and used VMMaker as Reference Implementation for many details. Thanks, Juan Vuletich 25 Feb 2024

Illustrates the point beautifully, because it’s consistent and works on every platform (presenters laptop) with 0 reconfiguration and shows exactly what the audience saw.

I think I've mentioned in the talk that there was a design decision in making frictionless to take HTML that was already made from other sources like a designer's handout or some example or template that you have predesigned already and want to incorporate easily. There is also the compute factor since by being "more static" presumably will use less CPU and be more cacheable per rendered request, hence more capacity keeping cloud costs at bay. That said, an HTMLRenderer object is cool and might be an addition that I do not discard for Ride. Just isn't the priority now. What I'm already doing for it is to make the Views design to be able to come from different sources: Mustache templates, potentially that HTMLRenderer and SSTemplates, which I've published this week because they are faster and smarter.

@@SebastianSastrefair points. I’ve gotten used to hiccup and clojure so it’s hard to go back to standalone html files