Hacker News Reader

Comment by csmuk | Hacker News Reader

I still refuse to use Sass or LESS.

1. Tooling integration is a PITA, especially with Visual Studio.

2. Nothing but trouble merging the stored output from the tooling if you are in a branchy development. Basically, merge the CSS, then run sass/less and check in the change. Too much friction on a large project, especially when it comes to a non-Sass/Less dude doing the merge.

3. Parsers are both shit. Sometimes attributes don't get "understood" properly resulting in compile errors and point blank refusal to work.

4. Hacks used for older browsers aren't parsable by either.

5. It's another layer of abstraction. Less abstraction decreases debugging effort.

Sorry but I don't buy it despite the promoted advantages.

View on HN

> 1. Visual Studio is a PITA

FTFY. Jetbrains IDE have sass support.

> 2. Nothing but trouble merging the stored output from the tooling if you are in a branchy development. Basically, merge the CSS

There is no reason or justification for merging the CSS. Merge the source, regenerate.

> especially when it comes to a non-Sass/Less dude doing the merge.

That's not a problem with Sass or Less or whatever.

> 3. Parsers are both shit. Sometimes attributes don't get "understood" properly resulting in compile errors and point blank refusal to work.

Incorrect source not compiling correctly is not exactly abnormal. The only issue I met was the watcher getting wedged once in a while after a bad compile (no issue with IDE-integrated compilation since it does the watching and recompilation explicitly)

> 4. Hacks used for older browsers aren't parsable by either.

Not seen any issues with that.

> 5. It's another layer of abstraction. Less abstraction decreases debugging effort.

At the cost of increased maintenance effort.

> FTFY. Jetbrains IDE have sass support.

But I can't write C# in it.

> There is no reason or justification for merging the CSS. Merge the source, regenerate.

Regeneration is a problem when you have lots of developer workstations, build agents and test machines to deploy the Sass stack to.

> That's not a problem with Sass or Less or whatever.

Nope but it's a real problem. Some of our guys don't do the web.

> At the cost of increased maintenance effort.

Well the maintenance effort went up to unacceptable amounts for us so I don't believe that.

> Regeneration is a problem when you have lots of developer workstations, build agents and test machines to deploy the Sass stack to.

If you can't make something like sass work with your version control, it's a problem with your workforce or workflow, not the technology. It is trivial to set up a ruby command line on any OS and then have a .gemfile in your version control to ensure that everyone is using the same version of sass. Then all that is required to generate the css files from the sass sources is opening up a command prompt with ruby and typing `compass watch`. It's worth it for the time saved writing css.

> Nope but it's a real problem. Some of our guys don't do the web.

Is it not also a problem that you have people writing your css who "don't do the web"? That seems like the bigger issue here to me.

It becomes less trivial when you have 100 computers to throw it on at once before it works.

If you read my comments carefully, you will see this is a merge time issue. Many different people do merges. Some reintegration merges will be performed by people who don't do web stuff. There may be trivial web changes on a feature branch but people have absolutely no idea about Sass or associated tooling. They can cope with css fine.

Our product has about 5000 lines of css and about 3 million lines of other languages. Web is a tiny part of our applications.

I did read your comments, and I still think that you're making sass out to be entirely more complicated than it has to be. It's somewhat clear from your comments that you never gave css preprocessors a fair shake. There is no 'associated tooling' with sass. It's just a preprocessor. It doesn't need to integrate with your IDE (doing so would be somewhat pointless, IMO). You just invoke it from the CL and let it do it's thing. It really couldn't be any easier.

All of your problems are actually easily solvable, but it'd be rather pointless to use sass on a project that only has 5000 lines of css anyways. About as pointless as commenting on a thread about a technology you don't really understand to say that you "refuse to use" it, then trying to prove everyone wrong for pointing out that your issues with it are actually either not actually issues with the technology or have trivial solutions (i.e. you're not the first person to run into these issues).

> It doesn't need to integrate with your IDE (doing so would be somewhat pointless, IMO).

It's somewhat neat, actually. Not necessary by a long shot but 1. there's a chance the IDE understands the precompiled languages (and offers syntax checks, autocompletion, etc...) and 2. you don't need to run the compiler/watcher because the IDE takes care of that when you or it saves, as part of its normal "stuff to do when saving".

I think you're looking for Mindscape Web Workbench (http://visualstudiogallery.msdn.microsoft.com/2b96d16a-c986-...)

Not part of VS proper but if you can use extensions it's a good alternative. I haven't used it unfortunately as my work doesn't really keep me in VS for web dev but the tooling should be rather decent from what little I've touched. YMMV though, obviously.

> But I can't write C# in it.

Doesn't change what I wrote.

> Regeneration is a problem when you have lots of developer workstations, build agents and test machines to deploy the Sass stack to.

It's no more a problem than all the other stacks you have to deploy. And if you can't deploy any stacks, maybe that is the core problem.

> Nope but it's a real problem. Some of our guys don't do the web.

They won't be able to merge HTML, CSS or JS any more reliably than Sass or Less, why are they doing those merges? Do you also ask designers to merge WPF?

> Nothing but trouble merging the stored output from the tooling if you are in a branchy development. Basically, merge the CSS, then run sass/less and check in the change. Too much friction on a large project, especially when it comes to a non-Sass/Less dude doing the merge.

Wtf? You don't check generated files into VCS. You check in the source sass/less, and do the generation as part of the build process.

Checking generated files can be useful for simpler projects so you don't have a remote build.

There is no bloody reason to merge it though, just wipe it, merge sources and regenerate.

Actually no it doesn't work like that. It's really a pain in the arse for windows users like myself who are part of more than a one man team.

What happens is, you get three options:

1. Deploy Ruby, Sass and associated dependencies to every workstation, build agent, test machine etc. Deploy tooling and build integration to the above so that any changes to .sass files in the IDE and build process get reflected on disk in the VCS. Educate every developer who touches the project on what they are, how to manage them effectively, the rules around merging etc.

-or-

2. Do the above but ship the entire Ruby VM and libraries in your VCS.

-or-

3. Get random build failures company-wide, old versions of generated CSS files and crap floating around and being checked in by developers, half arsed merges and just pain.

I'll pick option (4) which is don't use it.

I've been at ALL of the above steps. We have removed it from our product. Life is better now.

> Deploy Ruby, Sass and associated dependencies to every workstation, build agent, test machine etc. Deploy tooling and build integration to the above so that any changes to .sass files in the IDE and build process get reflected on disk in the VCS

This should be easy. If it is hard that means your deployment/ops infrastructure is inadequate, and you should fix that now rather than after your build machine suffers a hard disk failure.

> Educate every developer who touches the project on what they are, how to manage them effectively, the rules around merging etc.

You don't edit files that aren't in VCS; if some files are ignored you assume there's a good reason for it; you edit the source version, and you merge the normal way you merge source. These are all standard rules of development that every developer should know.

I guess using sass means every developer needs to learn sass, sure. But in terms of how quickly you can learn, and how much time it saves you over editing raw css, that pays for itself in like an hour.

Sucks you guys couldn't get it to work. LESS has made our lives easier. We have a LESS parser in javascript that gets put in place of the css includes in a dev environment. When deployed, that whole block is replaced by css that was compiled at the build point.

Here's an option you haven't tried:

5. Use CodeKit[1] on the Mac, and similar tools for Windows.

I can't tell you which ones on Windows are the best but damn it sure is nice to just casually write SASS/LSSS and have it get compiled when you save it because the compiler's sitting there watching for file changes.

1: http://incident57.com/codekit/ 2: https://www.google.com/search?client=safari&rls=en&q=codekit...

For all the rails asset pipeline's issues and the grievances it causes, it makes it really convenient to use either Sass or LESS. The tooling integration is trivial to setup (add [sass|less]-rails to your Gemfile) and it compiles assets automatically. Also, browser hacks work fine [1, 2].

[1] http://www.yonbergman.com/2012/05/19/why-you-should-use-sass

[2] http://getbootstrap.com/getting-started/

Re 2:

Never, ever handle output files directly.

Re 3/4:

So far I haven't seen a single useful thing that SASS doesn't process. Chances are that those attributes/hacks aren't something you want to have in your CSS to begin with.

What is your reason for merging this? Accept whichever set of changes you want then rebuild the generated css at the end. If you can swing it not committing generated CSS to development branches is the way to go, but that isn't always an option.

Another option is to push merging/building duties off to your CI server. Little weird but it keeps things consistently updated and provides a backstop against parser errors.

> 5. It's another layer of abstraction. Less abstraction decreases debugging effort.

http://snugug.com/musings/debugging-sass-source-maps

Another tool shaped like a crutch, another layer of abstraction etc etc. I have nothing positive to say about source maps.

i agree and personally dont use them either. they're really only ever useful for live-debugging production code, which should almost never happen.

i still use LESS for its conciseness, the abstraction layer really ain't so deep or different (like CoffeeScript) that you can't track down where the issue is very quickly.

Reply on news.ycombinator.com