I'm still working on how to get the message across, but the idea is this:
We all know CSS. We all know HTML. Most of us agree that neither is powerful enough to build modern web apps, hence the explosion of CSS-preprocessors and templating engines.
If we're going to build tools to improve browser technologies like CSS and HTML, let's build them using another browser technology: JavaScript. Instead of adding incompatible extensions to CSS and HTML, let's first port them as-is to JavaScript syntax and then do the extending there, where at least the tools we build will interoperate.
Instead of learning increasingly arcane/proprietary/underpowered syntax for looping or doing arithmetic or writing functions, let's just use the tools we already have. Not to mention this gives us a streamlined development process and lower cognitive overhead for free.
Looks like a neat idea, but I see a few technical problems with it:
- afaik, <meta> doesn't work properly if injected via js (e.g. try the viewport meta tag to control screen width in an ipad)
- <object> (for Flash fallbacks in IE) and a few other tags also have DOM API composability issues (i.e. you need to innerHTML an entire snippet rather than using appendChild's)
I believe I understand the concept, and the purpose, but this seems limited to specific types of web apps. General sites (news, blogs, and most services) - this approach would not make the most sense, since JavaScript interacting with the DOM does not compare speed-wise at this time.
This would work well for example and demo sites (portfolios, resumes, showcaes, etc) and possibly web games. It could be useful for building in-app content, such as if you have a large project like lucidchart.com - you could use something like this to build dialogs, modals, help content, and those types of things easily, in page, by loading a javascript asset on demand rather than running a request for more HTML/CSS/etc.
Template engines allow you to reuse template as functions. I do not believe this system promotes reusable markup. If this is intended for simple static HTML, I would rather use static HTML -- pre-generated using HAML or mustache.
Determine the global object: why not just pass this into your closure function?
How do you think this compares to Perl::Mason? How are you avoiding the same pitfalls that Mason has? complicated failure modes, pretty much impossible to improve timing and create on demand resource prefetching without increasing complexity greatly?
I don't know much about Mason, but this isn't a templating engine; it's just a wrapper library on top of the DOM API. Since it doesn't need any compilation or coordination outside of the JavaScript process, it's much less complex, and composes well without passing partials and other cruft into the template data.
I'm still working on how to get the message across, but the idea is this:
We all know CSS. We all know HTML. Most of us agree that neither is powerful enough to build modern web apps, hence the explosion of CSS-preprocessors and templating engines.
If we're going to build tools to improve browser technologies like CSS and HTML, let's build them using another browser technology: JavaScript. Instead of adding incompatible extensions to CSS and HTML, let's first port them as-is to JavaScript syntax and then do the extending there, where at least the tools we build will interoperate.
Instead of learning increasingly arcane/proprietary/underpowered syntax for looping or doing arithmetic or writing functions, let's just use the tools we already have. Not to mention this gives us a streamlined development process and lower cognitive overhead for free.
Feedback welcome.