Hello there, author here.<p>I'm still working on how to get the message across, but the idea is this:<p>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.<p>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.<p>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.<p>Feedback welcome.
While I appreciate the effort and the work of the author, I really don't think it's a good idea. Decoupling makes things easier. Nevertheless good work
This looks very complicated to me. HTML and CSS have separate structures because they do different things. It's like roads and the lines on a road.<p>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 ?
In a similar vein, I've found ClojureScript and Crate[0]/Hiccup to be a rather potent mix for solo web dev in Clojure. It's a liberating feeling to be able to effectively write your backend, frontend, and layout in the same language.<p>[0] <a href="https://github.com/ibdknox/crate" rel="nofollow">https://github.com/ibdknox/crate</a>
NO. NO. NO.
This is exactly why styling in HTML failed. Things work great when they are broken down anatomically into specific functions. Let's not try to put all of our eggs in one basket.
This reminds me a lot of fab. I dig it.<p>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.
Wait a sec. Wasn't css invented in order to separate style and structure? Now we have frameworks and libs trying to marry them back together. Why not just use old style html?<p>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.
Please read the lines at the top: "alternative to template engines and CSS pre-processors".<p>It's not supposed to be used instead of HTML and CSS overall.
I really like this. The inability to share information between the server, stylesheets, and javascript is problematic.<p>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.<p>edit:<p>I'd love to see someone mix in some <a href="http://lispyscript.com/" rel="nofollow">http://lispyscript.com/</a> with this
The looks like a joy to write, and a nightmare to maintain. I may be old fashioned, but I still see content, style, and behavior as best expressed as separate concerns in source.
I have used something similar since 2007 ( <a href="http://amix.dk/blog/post/19199" rel="nofollow">http://amix.dk/blog/post/19199</a> ), I only use it on client side to generate DOM elements and generally it's a nice approach (I like this much better than constructing HTML via innerHTML). The general idea for this is from MochiKit and I think they were inspired by stan (that ships with Nevow framework - - which seems to be dead now).
Some people like building good, simple things (CSS)
Some people like making these things better (HTML5, CSS3)
Some people like adding extra features and options, disregarding the loss of a bit of simplicity (LESS/SASS)
And some people just like making things more complex for the sake of it (Domo.js)
Reminds me of perl's CGI.pm html generators.<p>Also, these are similar, though not function based: <a href="http://www.jsonml.org/" rel="nofollow">http://www.jsonml.org/</a> and <a href="http://jsml.org/" rel="nofollow">http://jsml.org/</a>
This seems like it could get unwieldy fast. If you are looking for a way to abstract web development to a single, concise language, why not check out <a href="http://elm-lang.org" rel="nofollow">http://elm-lang.org</a>
Interesting idea, but I just don't like the implementation. Just a few points that jump out for me.<p>- 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.<p>Just my thoughts, I would love to know what others think.
this has been around for some time now: <a href="http://code.google.com/p/domplate/" rel="nofollow">http://code.google.com/p/domplate/</a><p>EDIT: now here: <a href="https://github.com/cadorn/domplate" rel="nofollow">https://github.com/cadorn/domplate</a><p>more: <a href="http://www.softwareishard.com/blog/category/domplate/" rel="nofollow">http://www.softwareishard.com/blog/category/domplate/</a>