Architecture

1. It's forbidden for the entire system to become a monolithic 'take it or leave it' lib. If you want the maps, currently you only need the info/maps subtree, the static files from statics, resources, and keys. After a bit I'm hoping a core of infrastructure settles down so to use a piece you just take the tiny infrastructure and the piece.

2. I'm liking the interface to the maps. User supplies a closure that we call with a partially instantiated structure. They fill it in to supply us info. This works well for systems that have to ask lots of questions about different dribs and drabs of data - like a map with various icons and points and popups and views and.... So I'm thinking of moving towards that pattern for most things, so there's not a learning curve with each new widget.

3. javascript, and to a lesser extent HTML, are assembler languages. They should be swept under the rug by higher level abstractions.

4. widgets are of minimal use by themselves without good low friction ways to glue them to backend data. Ideally, putting a signin box on your web page is all you have to do to have registration and signin.

I've been trying recently to figure out a good architecture for sweeping the fact that something's ajax under the rug. Ideally you'd just do \ajax([inner html]) and it'd automagically figure out when it needed the innerds and go get them from an autogenerated handler.