Teacup (HTML templating in CoffeeScript) is a fantastic DSL (domain specific language). Less “specific” than Jade, but it’s a programming language, so the potential for extending is exciting! I’ve been writing “helpers” to abstract HTML details, make my templates a higher level DSL.
But, although Teacup has nice facilities for extendibility, it’s restricted by its rendering architecture: a single pass, depth first recursion, immediately rendering CS→HTML. This limitation obviously prevents post-processing of nested contents by wrappers higher up the call stack, given, of course, we don’t want to manipulate/parse rendered HTML — that would smell wrong, and require a complex and slow full parser… which really misses the point.
Two use cases I’m sorely missing: patching any nested content to, eg, provide defaults, and freely composing helpers, eg:
# Allow wrapping immediate calls: mockup initially_hidden screen '#home' # But also support wrapping callbacks: mockup ->initially_hidden ->screen '#home'
(First form calls inner, then wrapper; second form — reversed order.)
Thus, Teacup must be hacked!
Systematic web apps development (notes towards…). The method I follow with my still work in progress Constitution stack.
I was tasked with upgrading the Bchirometer, a simple single page app (SPA), to a narrow (first?) UI, given a bunch of sketches in PNGs.
Rewriting, really. Repo was a mess of drafts, and… nu.
App uses Open Knesset‘s data, but otherwise it’s independent — separate (sub)domain. Not even same servers: it’s on S3, because pure client side, aka static.
(I still (it’s 2015!) can’t understand why open/activist projects use obsolete technologies: Django, Bootstrap, and other, unmentionable, crap. What would Ivan Illich have said? I’m still revolting against “worse is better“.)
CLI for transforming some JSON — Chromium’s bookmarks, specifically — into HTML, for quick (and dirty) publishing here.
And while we’re at it, let’s ponder Node streams again?
Been cloning this document for so long, so many times…