- The caps are there to prevent global namespace collisions, since the chances of UPPERCASE global variables existing is smaller. I don't want to add lowercase names to the global, but they would be fine on the domo object itself, so maybe I should put both UPPER and lower there anyway.
- The CSS may be more verbose that LESS in JavaScript, but it compiles much faster and there's only 228 of code needed to get it. If you want sugar, just use CoffeeScript and it's probably even cleaner than LESS.
Thanks for the reply Jed, yeah I understand your decisions and some of the advantages of going with CoffeeScript. I will definitely keep an eye on the project going forward. Just a quick thought:
- Maybe better syntax highlighting of the core elements on the website might help with new potential users.
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.
Hey there (author here), can you explain what you mean by decoupling? I'm not sure how this is any less decoupled; you can still keep everything modular in separate files/systems. You can use this to compile your CSS and still LINK it as a separate file, for example.
Exactly. Instead of learning arbitrary meta-languages on top of these technologies, I think we're better off just porting the syntax to JavaScript and using a more reliable and well-tested foundation to build abstractions.
- Performance: It's about half of Underscore.js on Webkit[1], so it's not so horrible, and has yet to be optimized at all (such as by using document fragments, etc.)
- Readability: The JS statement here is only long to show a unified example. Since the inputs and outputs of each call are DOM nodes, everything is trivially composable, something not possible with XML/CSS.
- Error recovery: Yes, having seen the error output of things like LESS, I see this as a feature.
- Namespacing: Absolutely agree. I think this is best solved the way jQuery and other libraries do it: pollute by default, and then let the developer "opt out" using noConflict.
- The caps are there to prevent global namespace collisions, since the chances of UPPERCASE global variables existing is smaller. I don't want to add lowercase names to the global, but they would be fine on the domo object itself, so maybe I should put both UPPER and lower there anyway.
- The CSS may be more verbose that LESS in JavaScript, but it compiles much faster and there's only 228 of code needed to get it. If you want sugar, just use CoffeeScript and it's probably even cleaner than LESS.
https://github.com/jed/domo/blob/master/docs/index.coffee#L1...
- The STYLE keyword is just there because that's where the "on" function lives. You could assign it to a local variable make the reference shorter.
- Yes, with bare JavaScript this is probably true, but the idea is to make sugar optional. Add your own and it looks like HAML:
https://github.com/jed/domo/blob/master/docs/index.coffee#L3...