14 ms·
dōmo: Markup, style, and code in one language
- anons2011 14y agoPersonally I see this as completely redundant.
- antonpug 14y agoNO. 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 14y agoOh 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 14y agoIn 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 14y agoReminds me of http://coffeekup.org/ http://coffeekup.org/
- holic 14y agoSame! It's a shame CoffeeKup and Zappa were abandoned.
- duked 14y agoWhile 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
- jedschmidt 14y agoHey 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 14y agoWith 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 http://hobocentral.net
- ch0wn 14y agoThis 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 14y agoI 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 14y agoPlease 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.
- jedschmidt 14y agoExactly. 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 14y agoThe 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 14y agoA glaring issue with this is SEO. The page/site will appear empty for most web crawlers.
- JoelMcCracken 14y agoI imagine most users will want to compile the code on the server side to html/css, and javascript.
- jedschmidt 14y agoRight. This entire page could've been rendered on the server. The point is that you can choose the best tradeoff for your app.
- JoelMcCracken 14y agoI 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/ http://lispyscript.com/ with this
- IsaacSchlueter 14y agoThis 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.
- jedschmidt 14y agoHello 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 14y agoI 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 http://aakilfernandes.com/uiji.html I think the emphasis on callbacks has been the weakest point, domo looks promising.
- IheartApplesDix 14y agoHow 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?
- jedschmidt 14y agoI 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.
- deleted 14y ago[deleted]
- IWentToTheWoods 14y agoI 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 14y agoI (the author) agree. It's not for nostalgia's sake, but to avoid namespace collisions on the global object.
- ConstantineXVI 14y agoIn 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 https://github.com/ibdknox/crate
- jedschmidt 14y agoThanks 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 14y agoAnother Hiccup compiler for JavaScript and ClojureScript: https://github.com/lynaghk/singult https://github.com/lynaghk/singult
- batgaijin 14y agoaka shitty sexprs
- conorwade 14y agoInteresting 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 14y agoThis 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#L15-20 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#L309-314 https://github.com/jed/domo/blob/master/docs/index.coffee#L3...
- conorwade 14y agoThanks 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 14y agoThe 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 14y agoI 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 14y agoNo 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 14y ago>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.
- 14y ago
- njharman 14y ago> markup, style, and code Sounds like PHP, ColdFusion and other similar great ideas from the past.
- zaachary 14y ago> in one language It doesn't say "in one file".
- jasonkostempski 14y agoBut I've spent the last 11 years of my life trying to separate them!
- mmanfrin 14y agoMy 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?
- deleted 14y ago[deleted]
- ashray 14y agoThis 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 14y agoComplexity 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.
- deleted 14y ago[deleted]
- lemiffe 14y agoSome 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 14y agoThis 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 http://elm-lang.org
- amix 14y agoI have used something similar since 2007 ( http://amix.dk/blog/post/19199 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).
- perfunctory 14y agoThis is wonderful. The main challenge for this project will be not techical, but indeed getting the message accross. Wish you all the best.
- leeoniya 14y agothis has been around for some time now: http://code.google.com/p/domplate/ http://code.google.com/p/domplate/ EDIT: now here: https://github.com/cadorn/domplate https://github.com/cadorn/domplate more: http://www.softwareishard.com/blog/category/domplate/ http://www.softwareishard.com/blog/category/domplate/
- camus 14y agowhere is the doc ? domo-js.com takes me back to the github repo , hard to understand what it is actually about.
- jedschmidt 14y agoYou're being redirected because JavaScript is disabled. I should make this more clear.
- __david__ 14y agoReminds me of perl's CGI.pm html generators. Also, these are similar, though not function based: http://www.jsonml.org/ http://www.jsonml.org/ and http://jsml.org/ http://jsml.org/
- draegtun 14y agoAlso similar to (in Perl)... * HTML::AsSubs - https://metacpan.org/module/HTML::AsSubs https://metacpan.org/module/HTML::AsSubs * Template::Declare - https://metacpan.org/module/Template::Declare https://metacpan.org/module/Template::Declare * Template::Caribou - https://metacpan.org/module/Template::Caribou https://metacpan.org/module/Template::Caribou * Markapl - https://metacpan.org/module/Markapl https://metacpan.org/module/Markapl And in Perl6... * Tags - https://github.com/masak/web/blob/master/lib/Tags.pm https://github.com/masak/web/blob/master/lib/Tags.pm | http://blogs.gurulabs.com/stephen/2009/03/tagspm-for-the-perl-6-web-proj.html http://blogs.gurulabs.com/stephen/2009/03/tagspm-for-the-per... and in Ruby... * Markaby - http://markaby.github.com/ http://markaby.github.com/ * Erector - http://erector.rubyforge.org/ http://erector.rubyforge.org/ and in Common Lisp... * CL-WHO - http://weitz.de/cl-who/ http://weitz.de/cl-who/ and in Clojure... Hiccup - https://github.com/weavejester/hiccup https://github.com/weavejester/hiccup
- strictfp 14y agoWait 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 14y agoCargo-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 14y agoWe 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 14y agoI'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 14y agoCAPITAL LETTERS!? SERIOUSLY?