4 ms·

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

by csmuk 13y ago

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.

lmm 13y ago
> 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.
- masklinn 13y ago
  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.
- csmuk 13y ago
  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.
  - egypturnash 13y ago
    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/ http://incident57.com/codekit/ 2: https://www.google.com/search?client=safari&rls=en&q=codekit+for+windows&ie=UTF-8&oe=UTF-8 https://www.google.com/search?client=safari&rls=en&q=codekit...
  - castis 13y ago
    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.
  - lmm 13y ago
    > 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.
leeoniya 13y ago
> 5. It's another layer of abstraction. Less abstraction decreases debugging effort. http://snugug.com/musings/debugging-sass-source-maps http://snugug.com/musings/debugging-sass-source-maps
- csmuk 13y ago
  Another tool shaped like a crutch, another layer of abstraction etc etc. I have nothing positive to say about source maps.
  - leeoniya 13y ago
    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.
masklinn 13y ago
> 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.
- csmuk 13y ago
  > 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.
  - w0rd-driven 13y ago
    I think you're looking for Mindscape Web Workbench (http://visualstudiogallery.msdn.microsoft.com/2b96d16a-c986-4501-8f97-8008f9db141a 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.
  - masklinn 13y ago
    > 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?
timme 13y ago
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.
daniel-levin 13y ago
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 http://www.yonbergman.com/2012/05/19/why-you-should-use-sass [2] http://getbootstrap.com/getting-started/ http://getbootstrap.com/getting-started/
awj 13y ago
> 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. 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.

by csmuk 13y ago

lmm 13y ago

masklinn 13y ago
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.
csmuk 13y ago
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.
- egypturnash 13y ago
  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/ http://incident57.com/codekit/ 2: https://www.google.com/search?client=safari&rls=en&q=codekit+for+windows&ie=UTF-8&oe=UTF-8 https://www.google.com/search?client=safari&rls=en&q=codekit...
- castis 13y ago
  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.
- lmm 13y ago
  > 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.

leeoniya 13y ago

> 5. It's another layer of abstraction. Less abstraction decreases debugging effort. http://snugug.com/musings/debugging-sass-source-maps http://snugug.com/musings/debugging-sass-source-maps

csmuk 13y ago
Another tool shaped like a crutch, another layer of abstraction etc etc. I have nothing positive to say about source maps.
- leeoniya 13y ago
  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.

masklinn 13y ago

> 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.

csmuk 13y ago
> 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.
- w0rd-driven 13y ago
  I think you're looking for Mindscape Web Workbench (http://visualstudiogallery.msdn.microsoft.com/2b96d16a-c986-4501-8f97-8008f9db141a 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.
- masklinn 13y ago
  > 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?

timme 13y ago

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.

daniel-levin 13y ago

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 http://www.yonbergman.com/2012/05/19/why-you-should-use-sass [2] http://getbootstrap.com/getting-started/ http://getbootstrap.com/getting-started/

awj 13y ago

> 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. 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.