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.
- 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)
http://aakilfernandes.com/uiji.html
I think the emphasis on callbacks has been the weakest point, domo looks promising.
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?
Your JavaScript code can only have one global object, I don't see a reason to pass it in instead of finding it for you.
I've found the HTML/CSS boundary very stifling at times. I use a framework[1] that let's me define my HTML in a very DRY (don't repeat yourself) fashion. Components can be nicely defined in a single small tag, and it would be very appropriate to define some (but not all) of the styling & event handlers in the same place. Sometimes I do via style= and onclick= attributes, but those are very much second class citizens in the modern world.
In other words, I've got a much more powerful mechanism for decoupling & abstraction, so the HTML/CSS/Javascript boundaries are more harmful than helpful.
The stated goal is: markup [html], style, and code in one language. However, I still have to deal with the syntax of the 3 languages, just that they are wrapped in the Javascript library calls. It doesn't help in lessen the effort in working with 3 languages. In fact, it adds complexity. Now I have to worry about how the code generated with respect to each language, another indirection. Just more trouble than it's worth.
It's also funny that there was such a strong movement which tried to separate the view from the code, and now everyone just accepts that you need to code to make ui. Crazy times, makes me think of all those wasted efforts.
The problem that this project is trying to solve isn't that style and structure are too loosely coupled, but rather that declaring style in a DRY, high-level manner typically uses one language (e.g. LESS) and declaring structure in a dynamic manner often uses at least two more (HTML, JavaScript). Otherwise sane people have been known to use HTML, JavaScript, PHP, SQL, and a templating engine (and maybe another language or three for cron jobs and shell scripts).
If there's a weakness here it's that it's explicitly avoiding the concept of DSLs, which may or may not be a wise move.
The final HTML is just a serialization of the DOM tree structure that is built up in memory. We can build that tree by parsing chunks of HTML source and looping or substituting in values when we see special non-html tags. On the other hand, we can also build our tree using any other programming language we want.
The trick Jed is pulling here is to make the html builder code a DSL that looks a lot like HTML to make it more approachable and predictable for people.
It's often hard enough to find designers that'll work well with templates that are relatively unobtrusively combined with plain HTML.
Have fun converting back and forth.
But yeah, I'd rather have strong separation of markup and behaviour. I love the wicket approach to this (your templates are plain html; the only thing you can add to them is identifiers that mark a tag as being replaced by a component; all logic goes in the code), and wish I could find a templating engine for more modern technologies that used the same approach.
You want to get rid of CSS for styling and replace it with something else for styling? Wha?
The processors you speak of output CSS. They do nothing that cannot already be done with CSS, they just make it easier. Plus, when using javascript to apply styles you are still using CSS, you are just applying it in a different way.
(brings back memories of one of my earliest web apps where I'd written a template system that on purpose delegated all by basic conditions and looping to the calling script on purpose to enforce separation; and then two of my developers tried to sneak in a new tag to allow them to embed Perl in the templates...)
It's not supposed to be used instead of HTML and CSS overall.
If it's not supposed to be for rendering a whole page, the example shouldn't be rendering a whole page.
- The all CAPS make me feel it will be a pain to type. - The CSS looks more verbose than SASS or LESS. The STYLE keyword each time seems like needless repetition. - I feel like the HTML templating is less readable than plain HTML or Slim or such tempting engines.
Just my thoughts, I would love to know what others think.
- 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...
- Maybe better syntax highlighting of the core elements on the website might help with new potential users.
I took a look at the examples and I'm sure that this style of coding would solve some problems. But how many would it create ?
Personally, I will need to look at the source-code before I can make an initial judgement. But the idea is definitely promising. :)
Just my two-cents.
Sounds like PHP, ColdFusion and other similar great ideas from the past.
It doesn't say "in one file".
Also, these are similar, though not function based: http://www.jsonml.org/ and http://jsml.org/
* HTML::AsSubs - https://metacpan.org/module/HTML::AsSubs
* Template::Declare - https://metacpan.org/module/Template::Declare
* Template::Caribou - https://metacpan.org/module/Template::Caribou
* Markapl - https://metacpan.org/module/Markapl
And in Perl6...
* Tags - https://github.com/masak/web/blob/master/lib/Tags.pm | http://blogs.gurulabs.com/stephen/2009/03/tagspm-for-the-per...
and in Ruby...
* Markaby - http://markaby.github.com/
* Erector - http://erector.rubyforge.org/
and in Common Lisp...
* CL-WHO - http://weitz.de/cl-who/
and in Clojure...
Other comments on this page so far show predictable HN-style "Hate anything new" bias. The page is pretty easy to understand what's going on, and all of the objections don't make any sense. Good work. Ignore the bozos.
Imagine, for example, using this to semantically declare the frontend elements that your website uses, and thus allowing your server to render them, your css to style them, and your javascript to render/manipulate them, all using the same, DRY data. I much prefer something like elements.user_login_form.class_name to needing to remember / deal with naming conflicts.
edit:
I'd love to see someone mix in some http://lispyscript.com/ with this
EDIT: now here: https://github.com/cadorn/domplate
