The way enliven works is really neat and interesting.
One thing that jumped out at me though. The author talked about how he changed the login/logout text from being plan HTML in his template, to being what looks like a tokenized representation, a pre parsed format, f or performance reasons.
If this is something people are tempted to do whenever they use large sequences of static text in enliven templates, then it seems like there's maybe room for an improvement in enliven here. Since it's lisp, couldn't enliven somehow detect that this is the first time a template is used, and scan through the code looking for opportunities to make these kinds of speed optimizations automatically before first use?
It seems like a great way to keep design from getting too tightly coupled with a changing app. It would be great if there was some way to "precompile" the selectors and use this as a performant replacement for messy templates.
Enlive already performs some caching on static parts of the template (and will do more as soon as I get enough time in a row to work on it). Lau's way of handling login/logout is rather unusual and goes against the grain of Enlive: he puts html in program code! A way to do that in enlive is to put both login form and logout text in the html template and then to make Enlive remove the one which doesn't apply.
One thing that jumped out at me though. The author talked about how he changed the login/logout text from being plan HTML in his template, to being what looks like a tokenized representation, a pre parsed format, f or performance reasons.
If this is something people are tempted to do whenever they use large sequences of static text in enliven templates, then it seems like there's maybe room for an improvement in enliven here. Since it's lisp, couldn't enliven somehow detect that this is the first time a template is used, and scan through the code looking for opportunities to make these kinds of speed optimizations automatically before first use?
Still, really impressed with the whole setup.