dōmo: Markup, style, and code in one language

by jedschmidt • 14 years ago

83 75 14 years ago

anons2011• 14 years ago

Personally I see this as completely redundant.

antonpug• 14 years ago

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.

perfunctory2• 14 years ago

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.

vidarh2• 14 years ago

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

shaunxcode• 14 years ago

Reminds me of http://coffeekup.org/

holic• 14 years ago

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

duked• 14 years ago

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

jedschmidt11• 14 years ago

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.

bryanlarsen• 14 years ago

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

ch0wn• 14 years ago

This is what I thought. CSS for example grew so large that it often doesn't feel like the right tool anymore. That's why preprocessors like Sass, Less and Stylus are so popular. Trying to combine everything into one language is a really hard problem and I'm not sure it can be solved.

ww520• 14 years ago

I agree. It's a good project to experiment but the intended goal is not practical.

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.

Semaphor• 14 years ago

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.

jedschmidt11• 14 years ago

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.

agscala• 14 years ago

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.

tseven• 14 years ago

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

JoelMcCracken2• 14 years ago

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

jedschmidt11• 14 years ago

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

JoelMcCracken2• 14 years ago

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

IsaacSchlueter• 14 years ago

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.

jedschmidt11• 14 years ago

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.

grimtrigger• 14 years ago

I think this is the right philosophy and it is going to do some amazing things in the near future. Here's my interpretation:

http://aakilfernandes.com/uiji.html

I think the emphasis on callbacks has been the weakest point, domo looks promising.

IheartApplesDix• 14 years ago

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?

jedschmidt11• 14 years ago

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.

xvolter• 14 years ago

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.

jimmyhchan• 14 years ago

High quality code. Good job!

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?

jedschmidt11• 14 years ago

Put your domo code into a function that takes data and returns a DOM object. BAM, there's your template.

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.

lhorie• 14 years ago

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)

jedschmidt11• 14 years ago

This is great feedback, will definitely look into this.

DanielRibeiro• 14 years ago

Great project. Loved the idea.

IWentToTheWoods• 14 years ago

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.

jedschmidt11• 14 years ago

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

ConstantineXVI• 14 years ago

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

jedschmidt11• 14 years ago

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.

Qerub• 14 years ago

Another Hiccup compiler for JavaScript and ClojureScript: https://github.com/lynaghk/singult

batgaijin• 14 years ago

aka shitty sexprs

conorwade2• 14 years ago

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.

jedschmidt11• 14 years ago

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

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

conorwade2• 14 years ago

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.

akdetrick• 14 years ago

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.

lmm7• 14 years ago

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.

talmand6• 14 years ago

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.

vidarh2• 14 years ago

Not to mention that for any project where you end up getting a designer involved, odds are pretty high that designer will end up handing you plain HTML and CSS.

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.

njharman• 14 years ago

> markup, style, and code

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

zaachary• 14 years ago

> in one language

It doesn't say "in one file".

jasonkostempski• 14 years ago

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

mmanfrin2• 14 years ago

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• 14 years ago

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

ashray• 14 years ago

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• 14 years ago

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.

lemiffe• 14 years ago

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)

jeffreybaird• 14 years ago

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

amix• 14 years ago

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

perfunctory2• 14 years ago

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

leeoniya• 14 years ago

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/

camus• 14 years ago

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

jedschmidt11• 14 years ago

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

__david__• 14 years ago

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• 14 years ago

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

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

strictfp2• 14 years ago

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.

frankus• 14 years ago

Cargo-Cult types notwithstanding, I think developers were mostly smart enough to interpret "separate the view from the code" to mean "separate the application logic from the presentation logic".

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.

po• 14 years ago

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.

strictfp2• 14 years ago

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.

v33ra• 14 years ago

CAPITAL LETTERS!? SERIOUSLY?

dōmo: Markup, style, and code in one language

Related Stories