

dōmo: Markup, style, and code in one language - jedschmidt
http://domo-js.com

======
jedschmidt
Hello there, author here.

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.

~~~
lhorie
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)

~~~
jedschmidt
This is great feedback, will definitely look into this.

------
duked
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

~~~
bryanlarsen
With a system like this you choose where to decouple rather than having the
boundary arbitrarily forced on 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.

[1] <http://hobocentral.net>

------
ashray
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.

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 ?

~~~
Hermitian
Complexity along should not be a negative trait. There are different
applications with different needs, the more diversity is (in the beginning)
always better.

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.

------
ConstantineXVI
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.

[0] <https://github.com/ibdknox/crate>

~~~
jedschmidt
Thanks for the reference to crate, I'd never heard of it. I'd imagine the
pushback on ideas like this is much less in homoiconic lanugages like clojure,
since when all is said and done everything is an AST.

------
antonpug
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.

~~~
perfunctory
Oh no. How do i make this javascript code modular?! There is no way i can
split it in multiple functions or files. Now my code will be one giant blob.

~~~
vidarh
In my experience, when you give developers an easy way to mangle everything
together, a sufficiently large number of developers takes advantage to cause
chaos. Sometimes it takes substantially less effort to deal with artificial
hurdles than it takes to keep a team disciplined without them.

(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...)

------
IsaacSchlueter
This reminds me a lot of fab. I dig it.

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.

------
jasonkostempski
But I've spent the last 11 years of my life trying to separate them!

~~~
mmanfrin
My resistance to change has paid off! Now, can someone tell me how to build my
layout table with javascript? Also, what is the best way to factor in my Flash
navbar effects?

~~~
viraptor
Try at <http://www.flash-navbars-and-java-applet-clocks.com> ; they're also
part of a really cool webring!

~~~
mmanfrin
Webrings? AWESOME. Adding this to my Aim Subprofile page.

------
shaunxcode
Reminds me of <http://coffeekup.org/>

~~~
holic
Same! It's a shame CoffeeKup and Zappa were abandoned.

------
strictfp
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?

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.

~~~
po
We all know how to keep our model code separated from our view and controller
code even though it's all written in the same language. I think maybe people
are worried a bit too much about the language here.

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.

~~~
strictfp
I'm not saying that it's a bad idea. But for the longest time web designers
refused learning to code. They wanted to edit their html in dreamwaver, and it
was up to the coder to make that possible. When you look at modern web apps,
they are very code-centric. Good luck editing that page in dreamweaver. I
never found the separation of html and code very useful and welcome this
movement. But it feels like we wasted so much time just because the
frontenders where afraid of anything resembling code.

------
Semaphor
Please read the lines at the top: "alternative to template engines and CSS
pre-processors".

It's not supposed to be used instead of HTML and CSS overall.

~~~
agscala
The example should really be changed to reflect this.

If it's not supposed to be for rendering a whole page, the example shouldn't
be rendering a whole page.

------
JoelMcCracken
I really like this. The inability to share information between the server,
stylesheets, and javascript is problematic.

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

------
njharman
> markup, style, and code

Sounds like PHP, ColdFusion and other similar great ideas from the past.

~~~
zaachary
> in one language

It doesn't say "in one file".

------
akdetrick
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.

~~~
lmm
I don't see the use for CSS; it's not powerful enough to express your styling,
so you always need some kind of programmatic processor that generates it
(whether in javascript or some other language), at which point you might as
well have that same program apply styling directly to your elements.

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.

~~~
talmand
No use for CSS? CSS not powerful enough to express styling? Huh?

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.

~~~
lmm
>The processors you speak of output CSS. They do nothing that cannot already
be done with CSS, they just make it easier.

And CSS does nothing that can't be done with inline styling (well, that's
probably not true now, but it was once and could be made so again), it just
makes it easier.

If your site's styling is being produced by some program which knows things
like "the nav bar is 20% blue" and "all otherwise unstyled text boxes have a
grey background", there's no reason that program couldn't put the styles in
the html directly.

~~~
talmand
Sure, an application that inserts into HTML can handle what you speak of, but
that doesn't address my questions about the statement of CSS being unsuitable
for the task of styles.

Sorry, but inline styling is still CSS. I know that CSS standing for
"cascading style sheets" may cause confusion but all styling for an HTML
document is done with CSS. Even the default styles a browser uses on an
otherwise "unstyled" document is based on CSS. You can insert styles directly
into an HTML element with Javascript and you are still using CSS.

But if you start using such an application to insert your CSS directly into
HTML then I'm willing to bet you are due for a headache in the future. There
are several reasons why inserting CSS inline is a bad idea. First, you are
seriously duplicating your code since you have no class structure to work
with. Second, you've just given up pseudo classes. Third, good luck
maintaining that code, especially if you eventually stop using the program
that created this code in the first place. I fail to see how that's easier.

"all otherwise unstyled text boxes have a grey background" - those "unstyled"
text boxes are now "styled", you seem to be repeating the statement that
prompted my response in that somehow CSS is not the answer but then you
provide an example that uses CSS.

~~~
lmm
>Sorry, but inline styling is still CSS. I know that CSS standing for
"cascading style sheets" may cause confusion but all styling for an HTML
document is done with CSS. Even the default styles a browser uses on an
otherwise "unstyled" document is based on CSS. You can insert styles directly
into an HTML element with Javascript and you are still using CSS.

Matter of definitions. I'm advocating styling one's page inline and/or via
javascript, without using external stylesheets. (Well, I'd really advocate
styling using attributes a la html3, but it's too late for that now). Call
that what you will.

>First, you are seriously duplicating your code since you have no class
structure to work with. Second, you've just given up pseudo classes. Third,
good luck maintaining that code, especially if you eventually stop using the
program that created this code in the first place. I fail to see how that's
easier.

I already have a class structure, because my HTML is being generated by a
program. The actual HTML is like an assembly language, not meant for manual
reading or editing.

Yes, I've given up pseudo classes. I don't think I'll miss them.

~~~
talmand
By what you say it seems you don't understand what a class means in terms of
CSS, because what you advocate is not it. In fact, your avoidance of external
stylesheets heavily suggests you don't understand the idea at all. I'm not
saying you don't understand these things, but what you say doesn't show it
very well.

No one expects a layperson to read or edit HTML, but they do have to receive
it in some manner and your method is the most bloated way to do so.

Why can't your magical application just output proper HTML and CSS, with
external files if need be, without you ever having to deal with it? I
understand wanting an easier way to do things but making something that
outputs what amounts to a crappy substitution is not the solution.

Anyway, I wish you luck with the most inefficient method possible of creating
and providing styled HTML documents.

EDIT: to the creator of domo if they happen to read this, to me this thread
has nothing to do with your endeavor, I actually find it somewhat interesting
despite its obvious problems. This thread is about the idea proposed about CSS
as if we can be rid of it, as to be tossed away. My original intention is to
explain that this is a silly idea and this has gone in a different direction.

~~~
lmm
I know it's not a class in CSS terms, I didn't think that distinction was
relevant.

>No one expects a layperson to read or edit HTML, but they do have to receive
it in some manner and your method is the most bloated way to do so.

Sending things over the wire in compressed form is trivial (many servers do it
already) so this doesn't bother me.

>Why can't your magical application just output proper HTML and CSS, with
external files if need be, without you ever having to deal with it?

My goal here is to reduce the number of layers you need to understand to debug
your webapp. Fundamentally CSS selectors provide a way to reuse (some small
specific parts of) your markup in several places - but any web application
framework will already provide a way to reuse markup, with its own logic. So
why should developers have to learn two different ways of abstracting their
markup?

~~~
talmand
The distinction is relevant in that you seem to want to ignore them for a less
efficient method.

Yes, indeed, many servers send the HTML, CSS, and JS files compressed and is
trivial, but bloated code that is compressed still takes more bandwidth than
more efficient code compressed. There might be something said about combining
all three into one HTTP request but to say that there's little difference
between bloated inline styles and a properly created style sheet is an odd
one. Even if the difference between the two is 10k per page then it adds up
over time. It would be far better to rely on CSS classes in the head section
of the document than to have duplicated inline styles throughout the document.
It seems you are willing to create inefficient output for the sake of
attempting efficient input, which only benefits you personally as the coder
during the creation process of the project.

Therefore I don't think you are reducing the number of layers involved, but
only masking it. In the end you will still have HTML and CSS but with a
slightly different way to code them. If that's the extent of the goal then
congratulations on duplicating what we already have. Although these
applications are interesting and have intriguing ideas, they don't
fundamentally address the inherent problems of HTML and CSS. For things like
this all your doing is creating a new way to write inline styles which can be
done right now without adding in new inherent problems.

What's the difference between this:

STYLE.on("element", {textAlign: "center", fontSize: 50})

or this:

element style="text-align: center; font-size: 50px;"

or this: .element {text-align: center; font-size: 50px;}

Almost nothing, in terms of inline styles. Except that the first two have to
be duplicated throughout the code wherever they are required while the third
only requires a reference. Now, if you need to change that text-align to left
you have to change every instance of it throughout your code, except for the
third where it only needs to be changed once. If this code is duplicated in
multiple files then you've added complexity to the task, while with a single
style sheet you only change one line. Also keep in mind that with the first
example that code has to parsed on every single page load before it can be
rendered.

Now, in the cases of small webapps I can see these things being of little
concern. But for large projects or a regular website it's asking for
headaches. Not because of things like domo, but because the end result has to
be what the browser expects. Plus, there's the issue that if you want this web
page to be indexed by search engines you're going to have problems. If people
have turned javascript off or use a white list to control scripts then this
page simply will not work with very little available fallback. If someone
other than you needs to maintain or update this code and don't know this
system then you will have problems.

So, am I saying that people should stop making these type of things and stop
experimenting? Of course not, this type of exercise is interesting if the end
goal is to determine how we could possibly replace HTML/CSS with something
more useful in terms of modern websites and apps. For instance, being able to
do mixins and the like in CSS is incredibly useful, which is why the CSS
processors are popular. But to say that we can take something like domo to be
used today as a replacement to HTML/CSS is a bit misguided. In the end it is
still HTML/CSS, what we have here is the equivalent of a WYSIWYG editor for
javascript coders who, for whatever reason, don't/can't/won't learn HTML and
CSS even though those are the easiest parts of the equation.

Keep in mind this thread started for me because of your statement that CSS is
not powerful enough to express styling when that's exactly what it does and
all that it does. In the end I fail to see how what you propose is better than
what we have today, in fact I feel it is worse.

By the way, CSS selectors do not provide a way to reuse your markup in several
places. That is, if you are referring to HTML when you say markup, which is
the usual definition of the word. CSS selectors let you target elements in
your markup to style them, nothing else. You can use these selectors to reuse
your CSS stylings for duplicate elements that require the same styling. It is
statements like that suggest to me you don't fully understand the relationship
between HTML and CSS.

~~~
lmm
>What's the difference between this: >STYLE.on("element", {textAlign:
"center", fontSize: 50}) >or this: >element style="text-align: center; font-
size: 50px;" >or this: .element {text-align: center; font-size: 50px;}

The difference is that CSS has its own syntax, its own semantics, and its own
set of gotchas to learn, different from any other language. (Obviously for a
simple selector like .element it's easy to know what it's going to refer to,
but CSS is not limited to things that are so clear).

>Now, if you need to change that text-align to left you have to change every
instance of it throughout your code, except for the third where it only needs
to be changed once.

Only if you're a muppet. Your HTML is being generated by a program; that
program should have a single place where it knows what the text-align of this
class (in the general sense of the term) of elements should be, and you can
change it in that one place if you want to change it.

>Plus, there's the issue that if you want this web page to be indexed by
search engines you're going to have problems. If people have turned javascript
off or use a white list to control scripts then this page simply will not work
with very little available fallback.

Right; it only makes sense to use javascript if you're already using
javascript for major functionality. That's what I'm really advocating for
here: write your styling logic in the same language as the rest of your site's
logic.

>Keep in mind this thread started for me because of your statement that CSS is
not powerful enough to express styling when that's exactly what it does and
all that it does.

My point was that it isn't powerful enough to express your styling in a fully
abstracted way. E.g. if your website's general colour scheme is blue and you
have parts that are a light blue, a mid blue and a dark blue, CSS doesn't let
you define these colours in terms of each other - so if you want to change it
to be green, you have to change three different colour definitions. Because of
this kind of thing, people use pre-processors like LESS - which means using
yet another language with its own syntax and logic to learn, when you're
already using a perfectly good programming language to generate most of your
site.

>CSS selectors let you target elements in your markup to style them, nothing
else. You can use these selectors to reuse your CSS stylings for duplicate
elements that require the same styling.

Yes, that was why I took pains to say "some small specific parts of your
markup". Your styles are part of your markup, at least traditionally.

~~~
talmand
But if you use CSS within javascript you are still using CSS syntax. The only
thing you seem to be saying is that you've removed the need for selectors.
Which you can do right now with inline styles, which I've been saying is not
the best thing to do. If the CSS selectors for a page are difficult for you to
understand then the problem lay in the HTML, not the CSS.

I guess I'm a muppet that doesn't understand how you avoid having to update
lines of code all over the place when your code is sprinkled with inline
styles. Unless you are advocating using some kind of class system for styling
within javascript, which is odd since CSS already offers that. If you are
speaking of applying CSS classes through javascript, which sounds like what
you are describing, then I'm confused over what the point is. You can create
CSS classes and apply them to elements on the fly right now, you just seem to
saying you want to create the CSS classes in javascript. Which makes no sense
when you can do the exact same thing more efficiently in an external style
sheet. The reason it is more efficient is because those classes will not need
to be created on every single page load.

So your answer to the problems I point out is to ignore the problems I point
out. Sure, use javascript for everything and wonder why no one can find your
site on their favorite search engine or why some people cannot see your site
at all. I understand what you're saying about writing your styling in
javascript, which is really CSS, but you are skipping over the problems I
point out that are inherent in that solution.

I've already agreed that CSS has serious limitations and that pre-processors
(even domo) attempt to address them, some do so quite well. The syntax that
SASS and Less use is actually existing CSS syntax with extensions, there's
very little new syntax to learn. I would say your solution has more of a
learning curve involved because you are adding completely new syntax and logic
to javascript when it wasn't designed to do these things. The solution is to
update what the browsers expect from CSS. There is no reason why CSS itself
cannot be extended to do what you are speaking of, probably most people
(including me) would want that functionality right now. But again, the very
thing you speak of is CSS, syntax and all, it changes nothing other than how
you code it. Much like my three examples you pretty much ignored, you still
have to learn the CSS syntax and capabilities regardless of how you feed it to
browser. Unless you advocate coming up with a whole new styling language that
eventually outputs to CSS, which is required because that's what the browsers
expect. In the end, it doesn't matter how you use CSS but you are advocating
an inefficient way of doing it.

As I said before, creating a more inefficient output for the sake of maybe,
just maybe, slighly more efficient input is not the solution. What you want is
to reverse the progress that's been made over the last ten years or so because
you can't be bothered to learn some of the easiest syntax in the industry.
Well, actually with your solution you still have to learn the same syntax.
It's not even as if HTML and CSS were programming languages. There's next to
no functionality involved with these two. I would say what you want would make
these things more complicated for the coder and less useful to the end-user.

Again, CSS has nothing at all to do with markup. Saying "small specific part
of your markup" doesn't qualify your statement, since it doesn't actually do
that. Styles are not part of your markup, period. Well, maybe inline styles
but, again, that's bad. Sure, you can add classes and ids to your markup for
CSS to use as selectors but even then they are not required. Plus the fact
that ids are already needed within HTML for various things and using classes
with javascript libraries such as jQuery (javascript is almost ready out of
the box to do this itself) has become almost standard. Basically, you are
already using for other purposes the very things that CSS needs to make coding
easier, yet you say selectors are difficult and confusing to use. If they are
difficult and confusing to use then you shouldn't be using them in javascript,
which I bet you do. The closest to providing markup in CSS is with using
:after or :before pseudo-classes with the content property, which has its uses
but severely limited. But you've given up on pseudo-classes so that is
irrelevant to you.

I haven't even brought up the serious accessibility problems this solution has
which can get you sued in the real world, or the US at least.

By the way, stimulating conversation we have here.

~~~
lmm
>Unless you are advocating using some kind of class system for styling within
javascript, which is odd since CSS already offers that. If you are speaking of
applying CSS classes through javascript, which sounds like what you are
describing, then I'm confused over what the point is. You can create CSS
classes and apply them to elements on the fly right now, you just seem to
saying you want to create the CSS classes in javascript. Which makes no sense
when you can do the exact same thing more efficiently in an external style
sheet. The reason it is more efficient is because those classes will not need
to be created on every single page load.

I'm advocating using whatever programming language you use to apply behaviour
to your site, whether that be javascript or something else, to apply a style
where it's needed, rather than via CSS selectors. Any language you're using to
generate web pages will already have this functionality, because it's needed
to e.g. attach event handlers (or equivalent) to text boxes. If your
application uses jquery, use that (but it's probably not the best example,
because jquery uses pretty much the same selector syntax). If your application
uses some awful adobe templating engine and does everything via XPath, use
that. If your application uses a java class hierarchy, use that. Etc.

>I would say your solution has more of a learning curve involved because you
are adding completely new syntax and logic to javascript when it wasn't
designed to do these things.

I think javascript is already very much optimized for functions of the form:
find some subset of the elements on the page, and then do something to them.

>The solution is to update what the browsers expect from CSS. There is no
reason why CSS itself cannot be extended to do what you are speaking of,
probably most people (including me) would want that functionality right now.

Unfortunately the W3C is unwilling to even add variables to CSS. Even if they
did, it would be years before we could rely on new functionality being present
in end-user browers - and then what if we realised we wanted some additional
functionality? Better for the logic to be written in server-side code, and we
can use new languages as they're invented. (With javascript we don't get to
use new language features but we can at least use new libraries, which is more
than can be said for CSS)

>Much like my three examples you pretty much ignored, you still have to learn
the CSS syntax and capabilities regardless of how you feed it to browser.
Unless you advocate coming up with a whole new styling language that
eventually outputs to CSS

Up to a point. Things like the box model there's no getting away from, but I
see no need to use the CSS syntax or CSS selectors. Just like the way we
currently handle the DOM, there can be a single styling API but you can use it
in javascript with javascript syntax, or in python with python syntax, or in
whichever language you like.

>Styles are not part of your markup, period. Well, maybe inline styles but,
again, that's bad.

Without/before CSS, all styling was inline, i.e. part of your markup. The
whole reason CSS was invented was, as I originally said, to provide a way to
reuse (some small specific parts of) your markup in several places.

~~~
talmand
I apologize, I fail to see how what you want to do is any different than what
you can do today. Almost everything you just said is what I've been saying the
whole time. You can create a CSS class in either a external style sheet or in
a style section in the head of the document and use javascript to apply that
class to any element on the page. Since you are already using CSS selector
syntax in javascript to target these elements I really don't see how having
something in between that makes it any easier. If I understand what you are
saying, you wish to remove the selector part out of CSS and apply it directly
to elements as they are used. But, again, that's already there, right now,
today, for you to use with no third-party tool with its own syntax/language to
get in the way.

All I can see at this point is that you wish to stop using CSS selectors but
still use CSS syntax in describing properties of the elements to be styled. As
stated in the beginning, you wish to remove CSS for styling and replace it
with something else for, styling. That makes no sense. You are already using
these very same selectors to target these elements with javascript. Plus the
same syntax can be used in any programming language that outputs HTML, just
assign class names to the element as they are created.

Since you propose to no longer use CSS syntax nor selectors in styling
elements then I require an example of how you propose to handle this with
current browsers. I really just don't understand the concept of creating CSS
to style elements without using CSS, that's the circular argument you are
using.

You say you want a single styling API, that already exists and it's named CSS.

~~~
lmm
>Since you are already using CSS selector syntax in javascript to target these
elements I really don't see how having something in between that makes it any
easier.

Stop fixating on javascript. Sure, javascript uses the CSS selector syntax.
But other languages use other ways of addressing particular page elements, and
I don't think the CSS selector syntax is a good way in general.

>Plus the same syntax can be used in any programming language that outputs
HTML, just assign class names to the element as they are created.

The same syntax as CSS, which is different from that programming language's
natural syntax. Outputting class names adds an extra level of indirection
that's just unnecessary. Why not just add the relevant style inline?

>You say you want a single styling API, that already exists and it's named
CSS.

A single API, not a single syntax. What I want is two things: 1. A natural way
to build up a style declaration programatically in python or java (javascript
already has this to a certain extent), not a string in CSS property syntax. 2.
A natural way to apply this to some subset of the elements on my page, which I
identify using whatever tools my programming language has (which in javascript
might be CSS selectors, but in general won't be).

Now you're right that the second half is almost-possible. I can use my
language to put class attributes on those elements I want to style, and then
have a CSS file (or rather, a CSS-preprocessor file) that only ever uses these
classes as selectors. As long as I keep the class names unique that works and
it keeps the CSS comprehensible.

But I've still got two separate programs in different languages that don't
need to be separate - my main program generates a mapping from page element to
classname, and my CSS-preprocessor program generates a mapping from classname
to set of properties[1]. The latter is a task that my primary programming
language is perfectly adequate for (and vanilla CSS is not, because it's not
powerful enough, hence the need for a preprocessor). So what I want is to have
a bit of code that generates an object representing a set of properties (which
would "really" be a string in CSS property syntax, sure, I don't care as long
as it has a reasonable API for manipulating it in my programming language),
and then rather than attaching a classname to the elements I want to style, I
attach this style object, which applies it directly inline.

At that point the inline style would still be sent to the browser with CSS
property syntax, but there'd be no separate CSS file and no cascading, so I
think it's fair to say this would not be using CSS.

[1] A program which happens to be interpreted by the browser (after
preprocessing), but conceptually a program nonetheless.

------
amix
I have used something similar since 2007 ( <http://amix.dk/blog/post/19199> ),
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).

------
anons2011
Personally I see this as completely redundant.

------
lemiffe
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)

------
__david__
Reminds me of perl's CGI.pm html generators.

Also, these are similar, though not function based: <http://www.jsonml.org/>
and <http://jsml.org/>

~~~
draegtun
Also similar to (in Perl)...

* 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...](http://blogs.gurulabs.com/stephen/2009/03/tagspm-for-the-perl-6-web-proj.html)

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...

Hiccup - <https://github.com/weavejester/hiccup>

------
tseven
A glaring issue with this is SEO. The page/site will appear empty for most web
crawlers.

~~~
JoelMcCracken
I imagine most users will want to compile the code on the server side to
html/css, and javascript.

~~~
jedschmidt
Right. This entire page could've been rendered on the server. The point is
that you can choose the best tradeoff for your app.

------
jeffreybaird
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
<http://elm-lang.org>

------
conorwade
Interesting idea, but I just don't like the implementation. Just a few points
that jump out for me.

\- 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.

~~~
jedschmidt
This is great feedback.

\- 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...](https://github.com/jed/domo/blob/master/docs/index.coffee#L15-20)

\- 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...](https://github.com/jed/domo/blob/master/docs/index.coffee#L309-314)

~~~
conorwade
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.

------
IWentToTheWoods
I think this is an intriguing idea, and I know this is a silly nitpick, but
the all caps function names make me feel like I'm reading HTML from 1995.

~~~
jedschmidt
I (the author) agree. It's not for nostalgia's sake, but to avoid namespace
collisions on the global object.

------
leeoniya
this has been around for some time now: <http://code.google.com/p/domplate/>

EDIT: now here: <https://github.com/cadorn/domplate>

more: <http://www.softwareishard.com/blog/category/domplate/>

------
perfunctory
This is wonderful. The main challenge for this project will be not techical,
but indeed getting the message accross. Wish you all the best.

------
batgaijin
aka shitty sexprs

------
v33ra
CAPITAL LETTERS!? SERIOUSLY?

------
camus
where is the doc ? domo-js.com takes me back to the github repo , hard to
understand what it is actually about.

~~~
jedschmidt
You're being redirected because JavaScript is disabled. I should make this
more clear.

