More, a CSS compiler | Hacker News Reader

More, a CSS compiler

kevinmontrose.com

41 pointstnorthcutt35 comments

.NET / Mono dependency is somewhat of a dealbreaker here. .NET might be a fine technology to build an internal product on, like StackOvervlow, but for an open-source project it's a huge barrier to widespread adoption. Especially considering it's a proprietary technology from Microsoft.

The same could be said for Java. If it was up to me, my software stack would not include the JVM. Too bad there's no non-JVM alternative for Storm, and Clojure is so awesome.

Works fine under Mono, so you can OSS the whole stack even on Windows.

Frankly, especially with what Oracle's been up to lately, I tire of this style of .NET fear-mongering.

It's not that I'm fear-mongering against .NET / Mono. It's more that I find the idea of having to download, install, and maintain a 1GB proprietary runtime to run a CSS preprocessor, well, preposterous. Don't worry, I have the same repulsion against Java / HotSpot.

> Frankly, especially with what Oracle's been up to lately, I tire of this style of .NET fear-mongering.

Isn't what Oracle is doing more reason to be concerned about .Net? What if Microsoft failed, and the company that bought their assets rescinded the agreement they've made not to sue?

But... but... It's Microsoft, it'll never fail!

And people will always wear hats!

There is no .NET dependency, there is a CLR dependency. If you have mono installed, you can simply put a line like this in your .bashrc, and use the compiler anywhere: (which I just did)

alias more="mono /your/path/to/More.exe"

more is a common unix program http://unixhelp.ed.ac.uk/CGI/man-cgi?more aliasing it could interfere with some shell script

Aliases shouldn't interfere with shell scripts unless you do something very silly. They're shell-local, and typically you define them in your shell's interactive-initialization file (e.g. .bashrc, .zshrc).

Right, but it will break my ability to "| more" on the command line in my interactive shell.

If there is an executable, it can be named 'morec' after less CSS' 'lessc'

less is also a common UNIX program going back decades

Please come up with a better name. Less the CSS processor is a play on the ending of CSS. The unix command less is a play on the more command, which is a clever but descriptive name. This would be a play on Less, which is a play on CSS. Also more has been around a really long time, years before less. http://en.wikipedia.org/wiki/More_(command)

Naming's hard, and sort of pointless to obsess over for a programming tool IMO. Especially when the conflicting tool literally predates the web (and me, for that matter).

Of course, if a better name presents itself I'll run with it.

The real issue is this: if I Google 'more', I'm less likely to find what I want than if I search for 'MoreCSS' (or similar). And you'd also be surprised just how a name can click in people's minds. "MightyMouse" feels much cooler than "More".

Ask 5 of your friends to come up with 5 names and then pick from the best of the 25 you get back. BTW, awesome project, love the sprite work!

Yeah, the spriting here is interesting... I'm a fan of the spriting with compass (SASS/SCSS alternative). Could be a good guide as you're improving this. Check it out: http://compass-style.org/help/tutorials/spriting/

obcss?

Mess? (Or maybe Loss? ;-)

It is absolutely not pointless. Just because it's hard doesn't make it pointless.

Naming matters a ton if you want people to adopt your thing.

IMO, LESS's strength is that its implementation is JavaScript. Allowing for real-time compilation during authoring in-browser is great, and coupled with uglifyjs and cleancss (also js) allows for a single dependency during our build stage. This has some very interesting ideas, but maybe I'm just a purist- ignoring the concept of the "cascade" seems counter intuitive to me.

Well maybe I'm blind, but I honestly don't see the benefit of CSS compilation. Client side is the only use case I'd even consider, I've been using php to augment styles for years.

Yet, js compiled CSS seems like it breaks tools like Firebug or the Chrome inspector. And version control systems.

What am I missing?

You've used PHP to augment styles (as have I), I've even used Twig, and have now been using LESS.

Version control is no different, and you typically compile on the server before sending to the client. The LESS.js shim is for convenience, like when you're editing a site over FTP with no access to the server.

CSS precompilers help DRY up your code and introduce structure. For example, no more repeating that hex value and forgetting which red is the error red vs the logo red, constantly retyping vendor prefixes, or maintaining a single gigantic stylesheet.

As a PHP developer, I prefer to "refresh to see changes", which is why using Assetic is a must for compiling both CSS and JS resources.

By augmenting CSS with PHP, do you mean something like this?

  p {color: <?=$mainColor?>}

And then just setting .htaccess (or whatever) to allow PHP execution in .css files?

You can just process main.css.php (or whatever)

Here's some of my (old crappy)code:

  color: <?php echo $foreground1; ?>;
  font-family: <?php echo $font2; ?>;

But I'm sure there's libs out there that make it really easy and pretty.

Compiling CSS client-side slows the page load down...

For less.js the browser has to download the js, then the less file and then produces the CSS

Until the browser has the CSS it can't start rendering the page.

Here's a waterfall for lesscss.org (http://www.webpagetest.org/result/120509_18_ff2ca6e34c6b8e90...) notice how for a really simple webpage that the rendering doesn't start until over 1.2 seconds in!!!

Hmm, I'm not really sure how I'd pull off spriting if More were implemented in javascript. Maybe something with canvas and data uris, but file permissions would be really "fun".

At Stack Exchange, we use dotLESS just fine without having to recompile when we change our .less files. Something Ben Dumke cooked up, an IIS HTTP module I want to say (honestly haven't dug into it).

All that aside, tightening up the REPL is always worthwhile; something I'll through some time at. Maybe a file watcher approach, if I can get it working well cross-platform.

While we kind of like Less' approach to CSS, we were not thrilled with the performance and also found it not really enough for serious development.

We opensourced our attempt at CSS generation in a java environment.

The website is a little outdated http://dynamic-style-sheets.org/dss-website/index.jsp but might give a rough overview. The SVN is more up-to-date ( http://opensaga.org/svn/opensaga-dynamic-stylesheets/trunk/ )

In addition to rule nesting and mixings, variables, expressions, etc, DSS allows user-defined functions to be written. Some come with it, including a system do imagemagick or so like processing of images in the CSS.

It's a funny little thing that kind of just wanted to be written that way.

Have you checked out SASS and the new libsass library? If you want speed, you can't beat a 0-dependency c / c++ library.

https://github.com/hcatlin/libsass

As I said: in a Java environment, which rules out C/C++.

20 times the speed of JRuby based Less is not shabby though.

edit: Performance was never the top motivation though. Architectural concerns and resilience were. Although based on a decent JavaCC grammar generated parser DSS should be able to eat any CSS and spit it out again as-is. While I certainly wouldn't want to write such dismal CSS, I also don't want to work on some richtext editor CSS just because I want to integrate that with our system.

You could try the node.js version of less, I've found it to be much faster.

Obligatory "just what the world needs: another super-CSS language". Why not use an existing solution?

At work (Stack Exchange) we use LESS. LESS is pretty good, especially compared to plain-jane CSS.

This is a fun personal project, I think it has some neat ideas and may be solid enough for actual use; so I wrote it up and open sourced it.

Sort of meta-discussion, but lots of the fancy stuff we used today started with someone creating a new tool to solve an already "solved" problem. I love the O'Reilly chart for demonstrating that http://oreilly.com/news/graphics/prog_lang_poster.pdf [pdf].

I like the design decisions you have made and the general direction. I will probably use this, my question is: Why do you write "experimental" css compiler on your github page? Do you think there are still bugs in it, are you going to keep maintaining it? (assuming it is you who posted this, otherwise I will create a github issue)

Submitter didn't write the code, I did.

Experimental was just left over from when it wasn't finished. Corrected the Github page.

I will fix bugs (I doubt it's bug free, it's young code after all), and future development is conditioned on a) my free time and b) interest from others than me.

Might wanna check out morecss.org

That is gold.

I laid down the first bits of this code a long time ago (first public commit 6 months ago https://github.com/kevin-montrose/More/commit/8392f0f4008fe7... ). Pretty hilarious to get bit by a subsequent April Fools.

Reply on news.ycombinator.com