CoffeeScript CSS
github.com
github.com
So think of an original name instead of latching onto the cachet of another project.
> it just makes writing objects (as well as everything else) easier.
I actually find the CSS example in your README to be far easier to understand than the convoluted mess above it.
'#id .className': do ->
#id .className {
IMHO If you're after more from your CSS, just use Sass (or LESS if you don't want the Ruby dependancy).
The `do ->` is a self-invoking function which allows for logic and computation in style definitions.
These are particularly concise in CoffeeScript since functions implicitly return the result of their final expression.
`: do ->` is idiomatic CoffeeScript to set a complex value inside an object literal; it compiles to `: (function () {...})()`. The output of that file is a JavaScript object which is translated into CSS by the library.
This might be preferable to raw CSS or LESS/Sass if you want to write more complex CSS generation code in the same language as the rest of your stack, especially if you want to integrate your CSS with the rest of your app somehow.
I'm a big fan of the idea in the abstract, although I'm not sure I love this implementation.
Say you would want to write a mixin for a better border radius, you'll have to call your variables MozBorderRadiusBottomleft and borderTopLeftRadius. Clearly not a good style. Why? Because it's just a simple regex: key.replace /[A-Z]/g, (s) -> '-' + s.toLowerCase()
That's why I'm afraid of uploading half baked projects to Github. Though so far, even my fully baked projects didn't get any attention.
i can see the disadvantages:
- have to learn a new thing
- another thing to break
- more difficult for new people to work on
- probably a speed decrease (even if its a one off parse during deploy, it will still take more time..)
what's the advantages?
- slightly nicer (subjective?) syntax?
If you want to write prettier CSS without straying too far away from standard CSS syntax, I suggest using LESS or SASS/Compass which allows you to have functions, nest CSS rules and even write normal standard CSS.
This Coffeescript trend for JS is really starting to scare me as a developer that we are going to see a whole new generation of developers who don't know actual JavaScript, only the frameworks built upon them hiding the language itself. Is saving time really worth the cost of not understanding the code these compile-to-Javascript libraries generate? If the same thing were to happen to CSS to the point people don't know what real CSS syntax looks like, then we are all in trouble.
In fact, the same thing was said when Assembly itself was invented: what kind of programmer wouldn't know the opcodes by heart, and need to use an assembler? Lazy buggers.
That's not to say that all abstractions are good. It's really hard to make good abstractions, but you shouldn't be scared that people are trying hard things and sometimes failing. If we end up with something better than CSS that everyone ends up using, that doesn't sound like trouble, that sounds like awesome!
I would hardly call Coffeescript a contender for a new language built on Javascript. I think CSS is easy enough as it is, I don't see how removing braces and using indentation would make it better, I don't mind the braces. If you want better CSS use LESS or Compass, both exceptionally great additions to CSS that don't detract away from the native way to do things.
Having said all of that, I can see that my argument is somewhat flawed. I'm not against change, change is great and in the case of the whole Assembly > C change it was definitely a refreshing change for the industry I just think some things are good the way they are like CSS. If something were to come along for CSS that made our lives easier and things prettier that became the standard I wouldn't be against it at all.
His shares similar concerns that I do in the first few paragraphs of his article.
To quote:
In the case of these language abstractions you are gaining none of the benefit of learning the JavaScript language. When a leak in the abstraction occurs (and it will occur - just as it's bound to occur in any abstraction) what resources do you have, as a developer, to correct the problem? If you've learned nothing about JavaScript then you stand no chance in trying to repair, or work around, the issue.
http://www.html5rocks.com/en/tutorials/developertools/source...
* The distinction between representing a selector as a JS object and representing it as an immediately-invoked anonymous JS function that evaluates to a JS object is whether or not it declares any local variables.
* If your selector has a colon in it (in other words, :hover/:active/:before/:active or any other pseudo-selectors), it needs to be wrapped in quotes. Otherwise, it doesn't need the quotes.
Both of these make complete sense when viewed in context of "you're actually writing CoffeeScript", and are sensible solutions to problems you will encounter when writing day-to-day CS. But writing code that compiles down to a static stylesheet is a very different problem than writing business logic: it seems weird to present a DSL where writing two blocks of 'CCSS' code that compile down to nearly-identical blocks of CSS could easily require the two CCSS blocks to superficially look very different due to the accumulation of edge-case language quirks like these.
That is to say: CSS has a lot of quirks. CoffeeScript also has some quirks. It seems to me that this doesn't necessarily do a better job of masking CSS's issues than Less/SASS/Stylus, while adding in the mental overhead of dealing with some of CS's syntactic quirks.
Both are widely adopted. Bracket-free syntax, variables, mixins, if/else, more. And you can get started without learning anything new!
A coffeescript-based syntax signals true object-oriented behavior - but the compiled CSS declarations are still ruled by specificity and inheritance. Danger zone.
Sass is just plain awesome.
Dropping the curly braces stays true to these origins. Presenting style declarations as json in anonymous functions misrepresents compiled behavior.
http://www.w3.org/Submission/1996/1/WD-jsss-960822
The declarative CSS syntax we know won out.
(Netscape's CSS implementation remained tied to JavaScript anyway, a detail that was normally hidden, except when a JavaScript error also killed the remaining CSS on the page.)