Less, a leaner CSS(lesscss.org)
lesscss.org
Less, a leaner CSS
http://lesscss.org
87 comments
Great to have you on board! Compass was definitely one of the inspirations behind Less. Unlike Compass, though, I'd like to keep it small, as it is and as close to CSS as possible, so the more complex features of Compass probably won't find their way in Less, unless they fit the ideal.
I know the distinction between Sass and Compass is blurred for many folks, much like ruby and rails.
Compass is libraries and tools to provide project management and community features, sass is the syntax that makes compass possible. Compass could be built on any css syntax with a comparable feature set to sass.
So my point was that until you provide those more heavyweight features in the core language, you cannot have a framework like compass. Frameworks drive adoption, so think about that decision carefully. Having powerful features doesn't force them to be used, but not having them, creates limitations.
Compass is libraries and tools to provide project management and community features, sass is the syntax that makes compass possible. Compass could be built on any css syntax with a comparable feature set to sass.
So my point was that until you provide those more heavyweight features in the core language, you cannot have a framework like compass. Frameworks drive adoption, so think about that decision carefully. Having powerful features doesn't force them to be used, but not having them, creates limitations.
'Having more features doesn't force them to be used' — correct, but it changes the perception people have of the tool, as well as what they start to expect from it.
I personally favor smaller tools which do the least amount possible while still fulfilling your needs. That's why, for example, I'm not a huge fan of Rails, and would much rather use Sinatra when I can. I know I'm not the only one.
It's this sort of overhead I'm trying to avoid. Less is very straightforward, and I want to keep it that way—there's not much you need to learn to start using it, and the code base is tiny. For most use cases I think the feature-set will be more than enough, and if it's not, we have Compass.
I personally favor smaller tools which do the least amount possible while still fulfilling your needs. That's why, for example, I'm not a huge fan of Rails, and would much rather use Sinatra when I can. I know I'm not the only one.
It's this sort of overhead I'm trying to avoid. Less is very straightforward, and I want to keep it that way—there's not much you need to learn to start using it, and the code base is tiny. For most use cases I think the feature-set will be more than enough, and if it's not, we have Compass.
You're still confusing sass and compass.
Like I said, your current feature set is ample for the 95% use case of normal web development. To that end, we are in complete agreement.
I don't know how familiar you are with blueprint, but the less syntax doesn't support creating new abstractions that simplify design.
In sass using the compass port of blueprint we can do this:
#sidebar +column(8)
which generates:
#sidebar { float: left; margin-right: 10px; width: 310px; }
The column mixin is defined here: http://github.com/chriseppstein/compass/blob/master/framewor...
So what could be the equivalent less syntax for this?
div#sidebar { .column: 8; }
This is wonderfully easy for end users, but the language syntax has to become more complicated to support it. You have to be able to specify the arguments for the mixin. Also, you need a way to refer to the parent selector within the mixin abstractly. In sass we use the & symbol to represent the selector's context. I don't know what a "css-like" syntax would be for these capabilities. I would argue that they don't really have to be that "css-y", but they just have to play nicely with existing CSS syntax, because normal users don't need them.
Anyways, it's your project... But I've spent the last year thinking about these sorts of issues. If you want to discuss further, you can hit me up on github.
-chris
Like I said, your current feature set is ample for the 95% use case of normal web development. To that end, we are in complete agreement.
I don't know how familiar you are with blueprint, but the less syntax doesn't support creating new abstractions that simplify design.
In sass using the compass port of blueprint we can do this:
#sidebar +column(8)
which generates:
#sidebar { float: left; margin-right: 10px; width: 310px; }
The column mixin is defined here: http://github.com/chriseppstein/compass/blob/master/framewor...
So what could be the equivalent less syntax for this?
div#sidebar { .column: 8; }
This is wonderfully easy for end users, but the language syntax has to become more complicated to support it. You have to be able to specify the arguments for the mixin. Also, you need a way to refer to the parent selector within the mixin abstractly. In sass we use the & symbol to represent the selector's context. I don't know what a "css-like" syntax would be for these capabilities. I would argue that they don't really have to be that "css-y", but they just have to play nicely with existing CSS syntax, because normal users don't need them.
Anyways, it's your project... But I've spent the last year thinking about these sorts of issues. If you want to discuss further, you can hit me up on github.
-chris
I think you made the right call. CSS isn't complex enough to need a framework. In a lot of cases, CSS frameworks abuse the primary motivating factor for trying to separate style and content in the first place. If I have to use particular HTML markup or class naming conventions, I may as well just forego the separation of content and style altogether and use table layouts.
But less appears to make desperately needed additions that should ultimately show up in CSS itself IMHO. Certainly when I was first picking up CSS -- given my programming background -- I was reaching for the concept of variables and in fact was surprised that they did not exist in CSS. For that reason, I'd consider less to be more of a language extension than a framework.
But less appears to make desperately needed additions that should ultimately show up in CSS itself IMHO. Certainly when I was first picking up CSS -- given my programming background -- I was reaching for the concept of variables and in fact was surprised that they did not exist in CSS. For that reason, I'd consider less to be more of a language extension than a framework.
You don't know about compass then. Go watch the screencast.
CSS isn't complex, but building websites that work correctly in 8 web browsers most certainly is. Compass frameworks give you re-use without semantic fail.
CSS isn't complex, but building websites that work correctly in 8 web browsers most certainly is. Compass frameworks give you re-use without semantic fail.
I've just started using sass/compass for a project and I can tell I am more productive than ever, though I am using 960.gs instead of blueprint with compass. I am using compass for sass/960 and staticmatic for haml - so I can output a set of html/css files which are used in my php project.
I am loving it, especially since staticmatic has preview mode and compass has --watch mode - so I have both running and auto updating my preview while I work on it. Even if I didn't use haml at all and no framework (960), it would still make sense for sass variables and mixins with input variables alone.
building sites that work across browsers is easier with reset+some framework, but I still have to have IE7+ specific css, and compass seems a bit moody on windows.
edit: I am not sure if I would be comfortable using anything external to css to output css that has the same syntax, like less seems to have - it would most likely pollute my way of thinking down the road.
I am loving it, especially since staticmatic has preview mode and compass has --watch mode - so I have both running and auto updating my preview while I work on it. Even if I didn't use haml at all and no framework (960), it would still make sense for sass variables and mixins with input variables alone.
building sites that work across browsers is easier with reset+some framework, but I still have to have IE7+ specific css, and compass seems a bit moody on windows.
edit: I am not sure if I would be comfortable using anything external to css to output css that has the same syntax, like less seems to have - it would most likely pollute my way of thinking down the road.
I do know about compass, but I have a feeling compass will be to less what Prototype is to jQuery, at least for me. When I first learned Prototype I thought it was awesome, but jQuery just ended up making a whole lot more sense to me. Different strokes for different folks I suppose.
What you are describing would be closer to Sass vs Less, not Compass vs Less. Compass is a meta-framework built on Sass to make working with CSS frameworks much simpler, easier, cleaner and more flexible.
In your case, you don't use CSS frameworks at all, but you just want a few features that aren't in CSS, so Compass isn't what you'd be considering, Less or Sass would be.
In your case, you don't use CSS frameworks at all, but you just want a few features that aren't in CSS, so Compass isn't what you'd be considering, Less or Sass would be.
At least someone gets it ;-)
If I don't want to use a framework like blueprint, and I actually prefer (in this context) the CSS syntax (e.g., braces et al) as opposed to HAML, then is compass still useful to me? That's what is (now) confusing to me given your replies to my original comment. My original criticism isn't of compass. It's just that if I don't like blueprint/YUI/960, then would it not be redundant to use compass?
Hopefully you don't take this personally. If I ever find myself required to use one of the above frameworks, they would probably be a lot more palatable when used in conjunction with compass.
Hopefully you don't take this personally. If I ever find myself required to use one of the above frameworks, they would probably be a lot more palatable when used in conjunction with compass.
That web page has shiny-excellent design. It immediately tells you what Less is, how to install and run it, and then launches into source code examples so you can immediately learn how to use it. Very smooth!
(Someone needs to recognize these things and give praise to the people who so richly deserve it.)
(Someone needs to recognize these things and give praise to the people who so richly deserve it.)
That's a very good point.
Also a somewhat embarrassing one. My standard practice is to go to Wikipedia to find out what is going on, then back to the page to find out more. And yet, when I came across a good, helpful page, where that was not necessary, I didn't even notice.
I guess this is yet another example of good design being design you don't notice. (Although, obviously, that "you" isn't referring to you.)
Also a somewhat embarrassing one. My standard practice is to go to Wikipedia to find out what is going on, then back to the page to find out more. And yet, when I came across a good, helpful page, where that was not necessary, I didn't even notice.
I guess this is yet another example of good design being design you don't notice. (Although, obviously, that "you" isn't referring to you.)
"good design being design one doesn't notice"?
Yeah, that works. Also "good design being design that isn't noticed".
After suffering through a project with complex css I felt a similar itch
and tried to scratch it by developing http://moonfall.org/
Its very similar to this, differences I see are:
It uses C/Lua, not ruby, so the cool kids probably wont use it.
Its compiled, so no interpreter needs to be installed.
Its very fast so it can be run as a cgi script, either for just development (avoiding the compile annoyance), or live (as its site uses now), or run from the command line to avoid the compile overhead in production.
You can add functions written in lua and compile them into the executable.
The variables are defined in a separate file, so your editor won't freak out in css mode.
When I introduced it got on smashing magazines best of whatever, http://www.smashingmagazine.com/2007/08/14/best-of-july-2007...
I had a lot of css hipsters hating on me... a lot. They despised it.
Their arguments were like "you don't need variables in css, you have to use the cascade!"
Something like
.my_colored_div, .my_other_colored_div { background-color:red }
... then way further down...
.my_colored_div { width: 100px} .my_other_colored_div { width: 200px}
So instead of defining something once, (a variable), you should define something (dom element) in multiple places.
I'm sure its obvious to you guys that defining something in multiple places like that would end up a big mess. So it didn't bother me so much being criticised by a group of developers who probably haven't done more complicated coding than a few pages of php.
Anyway, I'm not promoting moonfall, I honestly don't know if anybody is even using it, I never did, (although somebody ported it to a perl module), what I want to say is ever since that project that motivated me to develop moonfall, I haven't needed it, because the way I approach css has changed for the better.
I have a few simple rules.
1. Avoid using css, it relatively sucks. Try to let the html do what it wants. The more css you have, the more you will be fighting the browsers.
2. If you need variables in your css, you are probably making a big mess that you will regret.
3. If you have a web page that needs a lot of css, its too busy, or looks too much like a desktop application.
4. Only put global styles in the main css file.
4. My most controversial rule, one that has helped me the most but will probably bring on the hating... If a style only needs to be used in one place, or you cannot come up with a good name for it, don't put it in the css file, put it in the style tag attribute in the html style="blah:blahpx". Trust me, try it.
Its very similar to this, differences I see are:
It uses C/Lua, not ruby, so the cool kids probably wont use it.
Its compiled, so no interpreter needs to be installed.
Its very fast so it can be run as a cgi script, either for just development (avoiding the compile annoyance), or live (as its site uses now), or run from the command line to avoid the compile overhead in production.
You can add functions written in lua and compile them into the executable.
The variables are defined in a separate file, so your editor won't freak out in css mode.
When I introduced it got on smashing magazines best of whatever, http://www.smashingmagazine.com/2007/08/14/best-of-july-2007...
I had a lot of css hipsters hating on me... a lot. They despised it.
Their arguments were like "you don't need variables in css, you have to use the cascade!"
Something like
.my_colored_div, .my_other_colored_div { background-color:red }
... then way further down...
.my_colored_div { width: 100px} .my_other_colored_div { width: 200px}
So instead of defining something once, (a variable), you should define something (dom element) in multiple places.
I'm sure its obvious to you guys that defining something in multiple places like that would end up a big mess. So it didn't bother me so much being criticised by a group of developers who probably haven't done more complicated coding than a few pages of php.
Anyway, I'm not promoting moonfall, I honestly don't know if anybody is even using it, I never did, (although somebody ported it to a perl module), what I want to say is ever since that project that motivated me to develop moonfall, I haven't needed it, because the way I approach css has changed for the better.
I have a few simple rules.
1. Avoid using css, it relatively sucks. Try to let the html do what it wants. The more css you have, the more you will be fighting the browsers.
2. If you need variables in your css, you are probably making a big mess that you will regret.
3. If you have a web page that needs a lot of css, its too busy, or looks too much like a desktop application.
4. Only put global styles in the main css file.
4. My most controversial rule, one that has helped me the most but will probably bring on the hating... If a style only needs to be used in one place, or you cannot come up with a good name for it, don't put it in the css file, put it in the style tag attribute in the html style="blah:blahpx". Trust me, try it.
Even very complex and messy CSS is easily handled using something like Firebug for Firefox or the Web inspector in Safari.
I won't even comment on the inline styles recommendation.
I won't even comment on the inline styles recommendation.
Thank you for the "shameless" plug for moonfall.
I just regret that it never got on my radar - I'm definitely going to test-drive it.
I just regret that it never got on my radar - I'm definitely going to test-drive it.
Yes yes a million times yes. I've looked at Sass before but its HAML syntax made it less than appealing. This is beautiful, its just a smarter CSS, leveraging everything you already know about CSS but with the things you wish CSS had.
Totally agreed here. The reason I don't want to move to HAML and Sass is the learning curve required of devs, especially those that aren't necessarily familiar with scripting languages (like visual designers, etc). but do know about HTML and CSS.
This is just a simple enough extension to CSS that is natural, but still giving power to express styles much more concisely.
This is just a simple enough extension to CSS that is natural, but still giving power to express styles much more concisely.
I think it is important to differentiate between HAML syntax and SASS. Even though both are part of the same package, SASS syntax is actually quite minimal and closely follows CSS syntax, without the extraneous syntactical elements like curly braces etc.
Chris Eppstein, the inventor of SASS has stated elsewhere that one of his primary goals is to make SASS friendly for designers to use, and he claims to have sought feedback from designers as well. See comments here : http://jeffcroft.com/blog/2009/may/20/applying-oop-concepts-...
Chris Eppstein, the inventor of SASS has stated elsewhere that one of his primary goals is to make SASS friendly for designers to use, and he claims to have sought feedback from designers as well. See comments here : http://jeffcroft.com/blog/2009/may/20/applying-oop-concepts-...
Hampton Catlin invented Sass. Nathan Weizenbaum is the primary maintainer now, and I'm just a newbie, only around since Sass 2.0.
Everyone seems to give designers an insultingly small credit for their ability to do development. But the concepts behind CSS and Sass are the hard parts (flow, positioning, block, layout, etc), the syntax is easy in comparison. Every designer that I've worked with who knew css took 1 hour to learn sass and fell in love.
Everyone seems to give designers an insultingly small credit for their ability to do development. But the concepts behind CSS and Sass are the hard parts (flow, positioning, block, layout, etc), the syntax is easy in comparison. Every designer that I've worked with who knew css took 1 hour to learn sass and fell in love.
Now if they would just write a compiler that fixes everything that's wrong with CSS positioning...
</cynicism>
</cynicism>
I like how the examples were all, bar one, longer than the long-winded CSS it was replacing
... looks like a good compromise of SASS though. I might jump!
... looks like a good compromise of SASS though. I might jump!
Nice looking project, but...
Am I the only one in the world that bemoans naming decisions like this? The name is not just a dictionary word, and hard to get page rank with; it's even the name of an already-existing popular geek word (namely, the UNIX pager).
Am I the only one that thinks that the best names for things are the ones that have extremely few search engine hits before you choose them?
Am I the only one in the world that bemoans naming decisions like this? The name is not just a dictionary word, and hard to get page rank with; it's even the name of an already-existing popular geek word (namely, the UNIX pager).
Am I the only one that thinks that the best names for things are the ones that have extremely few search engine hits before you choose them?
Less will always be the UNIX pager for me. Why couldn't they call this lecss (pronounced as "leks") so everyone gets the css reference?
I like the name a lot, but I agree that its going to be difficult to google search. Sucks, but doesn't that seem like a limitation of search engines?
search for "less css". hmmm. "less extend css" no problem.
i agree that some names are ridiculous for search engines; this one might be ok. jury is still out.
i agree that some names are ridiculous for search engines; this one might be ok. jury is still out.
Is that like how we "need" to search for: "flickr photo sharing", "wikipedia encyclopedia", "facebook social networking", or "youtube video sharing"?
I think it's better to name your software or site (or company?) something that can be searched for and found by the name alone.
I think it's better to name your software or site (or company?) something that can be searched for and found by the name alone.
This would be more of an issue if it was a consumer service/product. I'm going to give web developers the benefit of the doubt and say they'll probably find this if they're looking for it.
Now it's the third entry for 'less css'. The interweb moves fast.
I like that I can spell it :).
For once, I'd love to see one of these things built with a proper parser. The regex madness has to stop!
Why? Sane regexes aren't all that inefficient, and here efficiency doesn't matter much anyhow.
It's not about efficiency, it's about robust parsing.
Actually, I think it's about ease of implementation.
Correctness > Ease of implementation
That statement is content-free. Robust parsing can be achieved using regexes as a tool. I want some reasoning better than "ew, regexes!"
If the "regexes" can call each other recursively, then this is possible. If not, then it is theoretically impossible. The proof is often given as a problem in your basic automata class. "Regexes" are no longer the same as "Regular Expressions" in automata theory. But their origin is in automata theory. A lot of the "ew, regexes" reaction comes from this.
I'm skeptical that augmented "regexes" are any more maintainable than compiler compilers.
I'm skeptical that augmented "regexes" are any more maintainable than compiler compilers.
Yes, I am talking about using regexes where a "standard" parser would use getc() and switch statements all over the place. You can't just write a clever regex and wrap it in a while loop and have a parser to go; as you mention, this is theoretically impossible.
I agree.
Also, check out the article @ usabilitypost.com for the full story:
http://www.usabilitypost.com/2009/06/16/introducing-less-a-b...
http://www.usabilitypost.com/2009/06/16/introducing-less-a-b...
I like the look of Less. I've taken cursory looks at other CSS generation tools have been less than enthralled by the ugly syntax and over-complications. Less is lean and looks like something that might be a future CSS extension. I'm definitely going to give it a try.
Sass definitely needs some competition. I love it, but there's some things it could improve on.
Allowing the mixin of any class into any class is genius. A very standard workflow when developing SASS stylesheets is extracting out a rule into a mixin, and mixing them into multiple classes. However, eliminating this step is huge.
I really like removing semicolons and braces, so SASS wins out huge in that regard.
I also really like SASS's new syntax for interpolation (standard ruby #{}). It's variable are lame though (use of the bang character for variables was a mistake).
Anyways, good stuff. I'm glad LESS exists and allows people to work around some of the missed opportunities of the CSS syntax.
Allowing the mixin of any class into any class is genius. A very standard workflow when developing SASS stylesheets is extracting out a rule into a mixin, and mixing them into multiple classes. However, eliminating this step is huge.
I really like removing semicolons and braces, so SASS wins out huge in that regard.
I also really like SASS's new syntax for interpolation (standard ruby #{}). It's variable are lame though (use of the bang character for variables was a mistake).
Anyways, good stuff. I'm glad LESS exists and allows people to work around some of the missed opportunities of the CSS syntax.
We deprecated some features in Sass 2.2 that will allow us to change the variable syntax in 2.4. Legacy users are a bitch ;-)
The idea of allowing any top-level css class be used as a mixin is a really interesting one that we could consider adding to sass. However, I would argue that you still need an abstract class syntax like the current mixin, especially where arguments are in use.
As a sass framework builder, I really like that I don't have to define a presentational class name that would end up in your stylesheets just so that you can mix them into your semantic selectors. It makes it much easier to keep presentation out of markup.
The idea of allowing any top-level css class be used as a mixin is a really interesting one that we could consider adding to sass. However, I would argue that you still need an abstract class syntax like the current mixin, especially where arguments are in use.
As a sass framework builder, I really like that I don't have to define a presentational class name that would end up in your stylesheets just so that you can mix them into your semantic selectors. It makes it much easier to keep presentation out of markup.
One big problem with making selectors into mixins is that then every mixin takes up valuable space in the CSS file. This is enough of a problem as-is with Sass, although work is going to go into space optimizations in version 2.4.
Now if anyone feels like writing a tmbundle for Less, I'll be more than happy to put it up on the site!
This is outstanding. It's simple and logical. You don't need to learn any new language. It doesn't "fix" CSS but it provides a lot of very useful features to help clean it up. The nested rules and variables are really useful. The mix-ins seem like they are already "sort of" available in CSS by just assigning multiple classes to an element.
Any plans to port this to other languages?
Any plans to port this to other languages?
This is a near perfect example of an incremental improvement. Kind of reads one's mind about what would be ideal to add to css - and provides it in a completely intuitive implementation. Bravo.
Mixins! Why has CSS not implemented these brilliant syntax rules? It's so intuitive and fits in with any programmatic workflow.
Coming to CSS about 6 months ago I was just amazed that it doesn't have these features already, like variables and mixins. Is there anything like this out there already for PHP?
What is it about php folks that think that everything has to be implemented in php?
I'm not suggestion everything has to be implemented in php, however, I'd have thought the answer was pretty obvious in this case. FAIL!
It seems slightly odd to call it "leaner" when you're adding stuff on top of CSS. The additions seem nice enough, but to me, "leaner" means that the number of [mis]features is being reduced to make a smaller spec and implementation.
I find it interesting that these tools are targetted at developers when designers could easily benefit from these even more. What would be interesting is if someone could build this into a Javascript library that compiles and converts the Less/sass/Compass code into CSS on the fly. If Cappuccino can do it for executed code written in an entirely different language, I don't think CSS would be that hard either. Of course, it's been a long time since I wrote a lexer/parser from scratch.
I think the reason is because designers are not into complex toolchains. Just the fact that you need to compile this CSS is a hurdle that makes this much less usable in a designers world.
I've often bemoaned the lack of variables in CSS for things like colors, especially because hex numbers are not very readable, but overall I'm not an advocate of these kinds of CSS pre-processors. It's not that I don't see the value, but I think they can easily become a crutch for developers who don't want to learn how to write clean CSS and utilize the cascade or refactor their HTML into a more sensible structure (hint: sometimes the most semantic class name is actually a presentational one, rather than duplicating a bunch of CSS, 'mixins' just serving to mask the smell).
The other thing is that cutting designers out of your project just because they can't or won't set up a Ruby environment is a pretty easy way to eliminate a lot of the best designers.
I've often bemoaned the lack of variables in CSS for things like colors, especially because hex numbers are not very readable, but overall I'm not an advocate of these kinds of CSS pre-processors. It's not that I don't see the value, but I think they can easily become a crutch for developers who don't want to learn how to write clean CSS and utilize the cascade or refactor their HTML into a more sensible structure (hint: sometimes the most semantic class name is actually a presentational one, rather than duplicating a bunch of CSS, 'mixins' just serving to mask the smell).
The other thing is that cutting designers out of your project just because they can't or won't set up a Ruby environment is a pretty easy way to eliminate a lot of the best designers.
I use Sass daily and I will continue to. I don't understand the hate for the indentation sensitivity; no curly braces or semi-colons to deal with and visible structure are huge wins as far as I'm concerned. I guess I'm just not seeing the "obvious awesomeness" that makes this so much of an improvement over Sass. I can see the appeal for the use case of existing CSS but I find that rarely happens.
Surely everyone has been using a homegrown version of this since they started with css? We use a build script to generate our css files with things such as:
.header { background: @BACKGROUND } .maintable { margin-left: 5+@DEFAULT_MARGIN }
I mean, without it you are left writing it all manually! Good to see something open source though, and I love the hierarchy.
.header { background: @BACKGROUND } .maintable { margin-left: 5+@DEFAULT_MARGIN }
I mean, without it you are left writing it all manually! Good to see something open source though, and I love the hierarchy.
This is ridiculous. The first two examples they give you, you are actually producing more code than if you had done it properly to begin with.
#header, #footer {
/* styling here */
}
That's because they are trying to make simple examples. I've wanted this functionality in CSS many times, and in my real-world CSS, it would have made it a _lot_ easier and shorter.
I think you've missed the point. They are trying to show you that you can define variables for use throughout your CSS, so you aren't forced to search and replace every time you want to change something. Their examples have higher line counts than the pure CSS because their examples have more functionality than pure CSS.
I'm not sure if you're serious. First, there are going to be differences between header and footer styles, which means you're going to have to declare them once as you say, and then at least one of them after that for the differences. Second, this offers the opportunity to do things only once, which is helpful for maintenance (though Firebug helps a lot, in my experience, in telling you exactly how you got this style).
How come no one is making these things for Java? Do people just use Ant to do the same thing?
No one makes any stuff like this for Java. Java has lost the wind from its sails. Java has been relegated to beige cubicles and enterprise solutions.
I say this as a disheartened Java programmer. I've recently been involved in a Rails project and a couple of Django projects, and then jumped back into Java. The difference in energy is amazing. Who would make something like this for Java? What would its success path be? Acceptance into an Apache incubator and then into "Commons?" Spec JSR-123987 finally being accepted by Sun/Oracle five years after its written?
I know this isn't a new revelation and I'm far from the first person to bemoan the stale, slow death of Java - but I'm sitting at an airport terminal with nothing better to do, and it's raining out, I'm depressed, and probably shouldn't be posting to HN. :)
I say this as a disheartened Java programmer. I've recently been involved in a Rails project and a couple of Django projects, and then jumped back into Java. The difference in energy is amazing. Who would make something like this for Java? What would its success path be? Acceptance into an Apache incubator and then into "Commons?" Spec JSR-123987 finally being accepted by Sun/Oracle five years after its written?
I know this isn't a new revelation and I'm far from the first person to bemoan the stale, slow death of Java - but I'm sitting at an airport terminal with nothing better to do, and it's raining out, I'm depressed, and probably shouldn't be posting to HN. :)
Check out GWT's CssResource support, which is a much more powerful version of Less backed by a real compiler instead of a collection of regexes: http://code.google.com/p/google-web-toolkit/wiki/CssResource
I agree that most of the Java web bits (including pretty much all the popular web frameworks) are, for lack of a better term, enterprisey crap. It saddens me a bit that GWT isn't more popular - there's a lot of innovation and power there that gets ignored simply because the framework's written in Java. IMHO, Rails and Django et al are just kind of standard web MVC frameworks that happen to be implemented on fun-to-write languages: the only thing out there that has the real "right" approach to web _application_ dev is GWT, which is fundamentally difference from all the rest (per the Google Maps/Wave team, Wave would not have been possible without GWT).
I agree that most of the Java web bits (including pretty much all the popular web frameworks) are, for lack of a better term, enterprisey crap. It saddens me a bit that GWT isn't more popular - there's a lot of innovation and power there that gets ignored simply because the framework's written in Java. IMHO, Rails and Django et al are just kind of standard web MVC frameworks that happen to be implemented on fun-to-write languages: the only thing out there that has the real "right" approach to web _application_ dev is GWT, which is fundamentally difference from all the rest (per the Google Maps/Wave team, Wave would not have been possible without GWT).
I've never tried GWT. I'll be sure to check it out, thanks for the recommendation.
The most "fun" Java web development framework, IMHO, is Stripes. I think what sets it apart is the lack of enterprisey crap - it's simplicity is refreshing, but it's still powerful enough to be useful.
The most "fun" Java web development framework, IMHO, is Stripes. I think what sets it apart is the lack of enterprisey crap - it's simplicity is refreshing, but it's still powerful enough to be useful.
[deleted]
You're a little harsh. It sounds like you're looking back at the old places you left from java and guest what ... they're old ... everyone left, just like you did. In the meantime though the Java language has moved on and become the JVM platform and there's plenty of energy in it. Take a look at Grails, for an example. And there are new modern Java frameworks as well (someone else mentioned Stripes, and I agree with them).
I don't understand... isn't this a compiler that translates a CSSish syntax to proper CSS? What would it mean to make stuff like this "for Java"? You mean writing it in Java?
It's true that Java has become utterly unfashionable. Unfortunately the popular replacements are very much limited by the fact that they are hundereds of times slower and force you into a multi process design in order to use multiple CPUs.
I've been trying really hard to replace Java in some projects and it's been really difficult, so I guess Java has got to have some quality beyond fashion. If you look for libraries that are well maintained, do non-trivial stuff that you don't want to do yourself, are fast, reasonably complete and up-to-date on Unix and Windows, you will find that 98% of them are written in Java or C.
It's true that Java has become utterly unfashionable. Unfortunately the popular replacements are very much limited by the fact that they are hundereds of times slower and force you into a multi process design in order to use multiple CPUs.
I've been trying really hard to replace Java in some projects and it's been really difficult, so I guess Java has got to have some quality beyond fashion. If you look for libraries that are well maintained, do non-trivial stuff that you don't want to do yourself, are fast, reasonably complete and up-to-date on Unix and Windows, you will find that 98% of them are written in Java or C.
It's interesting, for sure, but I like haml/sass and that style much more.
Not to mention, having arguments for mixins is really, really nice. And compass is solid too.
Not to mention, having arguments for mixins is really, really nice. And compass is solid too.
A follow-up: http://news.ycombinator.com/item?id=662669
for people who want to try out or develop with less without installing the ruby gem, you can compile documents via http here:
http://www.tripeedo.com/less
just as i switched to Compass/Sass...
Well lessc is just a replacement for the sass compiler so far. It lacks the project management and ruby framework integration features that you get with compass and sass.
For those of us not using Ruby frameworks, that's a definite plus. It's nice to have a simple standalone tool that does this.
Except that I doubt that anyone not using Ruby is going to install Ruby just to run this. It looks very promising, but without a standalone compiler it is useless to me.
You can use Compass/Sass with non-ruby projects. I do.
I know, but they're not that simple, so the integration helps a lot. Less seems pretty straightforward to use as a standalone tool.
Less looks great for a variety of use cases. Sass is also very simple and usable outside of ruby projects, Compass more so in any situation involving CSS frameworks. The sass and less commands basically do the same thing at their core:
Less fills a good, important niche by being very close to CSS while adding the core features that most people long for when working with it, and I will certainly use it in some situations. But Sass and Compass are both perfectly usable in non-ruby projects. Currently I'd argue Compass is more portable than Sass, both because of certain features (its --watch option that it shares with less, but, afaik, sass itself doesn't have) and its primary function, which is making CSS frameworks much simpler and more powerful.
sass -h
Usage: sass [options] [INPUT] [OUTPUT]
lessc -h
usage: lessc source [destination] [--watch]
Less fills a good, important niche by being very close to CSS while adding the core features that most people long for when working with it, and I will certainly use it in some situations. But Sass and Compass are both perfectly usable in non-ruby projects. Currently I'd argue Compass is more portable than Sass, both because of certain features (its --watch option that it shares with less, but, afaik, sass itself doesn't have) and its primary function, which is making CSS frameworks much simpler and more powerful.
Perfect
So I will be following along the development. There's still a lot of features that would be required of less to support a framework like compass. There's currently no arguments for mixins, no way to extend the language with functions that call out to code, no macro syntax allowing branching/looping and generation of selectors and properties. Such features aren't needed by your average user writing their own content, but they are absolutely core to building reusable design that can be configured and applied to your code using a simple and intuitive interface.
Anyways, it's really great to see new ideas and innovation in the css compiler space. We all win as these ideas mature and gain acceptance in the web development community.
-chris eppstein (sass core team)