Mac Yosemite WebDev Setup

gistfile1.md

Setup Steps

1. Get Homebrew package manager. These instructions are reasonable to get homebrew setup.

2. Github for mac (if you plan on using GH, BB, or other Git service without having to cmdline everything).

3. Shell and Command Line Stuff

• Update bash and zsh, if you plan on using zsh. Zsh info: oh-my-zsh, zsh points
• iTerm2 (optional)
• Understand about login shells and what .bash_profile and .bashrc are for.
• Make your own .bash_profile and .bashrc in your home directory
  • cd ~ && touch .bash_profile && touch .bashrc
  • Make the zsh equivalents if you are going that route.
• Make your command aliases and source them in .bash_profile (optional).

3. Install NVM and use to manage Node/Iojs versions.

• If for some reason the NVM install did not update your .bash_profile follow the manual setup instructions to source the nvm script from .bash_profile.

4. Setup other tools.

• Ruby is optional, used primarily for Compass. Install RVM or Chruby for managing different Ruby versions.
• Ruby comes on the mac, and it's bound to be useful to manage multiple versions over time.

Tips

1. Cmd + Shift + U opens the Utilities folder.

Reasons to use Compass

1. For the less familiar, presents a CSS authoring API that by its presence gets you more familiar with the things to consider when writing CSS.
2. Actual Math (Trig functions, etc)
3. Allows environment configuration to control your Sass, asset paths/hosts for example, image-url(). Combined with a build tool, this keeps env specific paths out of your code, allows you to switch them per build.
4. Automatic spriting capabilities.
5. Compass on-board with more rapid release cycle (now).
6. Probably need a Ruby toolchain anyway. Other vendors/services sometimes release tools written in Ruby. Ruby is already on your mac, so might as well manage it.

Reasons to not use Compass

1. Our southern webdev partners use lib-sass directly, without the help of Compass.
2. Never plan on using math for graphics. When you do, the external libs for this work just fine in those rare cases.
3. Never plan on using (raster) sprites.
4. Forces you into managing another local dev toolchain (ruby+gems). This is the reasoning behind installing RVM/Chruby.

Old Reasons to not use Compass

1. Prefer to use autoprefixer step to handle prefixing, NOT Compass. However (again), looks like Compass got on-board with caniuse.db driven prefixes with 1.0 release.

Good set-up resource, Alex. 👍

RE Compass: you may be interested in Hugo Giraudel's Why I Don't Use Compass Anymore. It discusses many of the features you've outlined.

Thanks @AllThingsSmitty. All good points. For me, here are my remaining hangups for not abandoning (in the general case). Let me know if you have pointers on these as well:

1. Per env config for paths/hosts/cache-busting with adjustable import paths for project specific vendors. I'll need to find a comfortable substitute for this before totally releasing my dependence. I like having CSS free of this too much. Super easy to change stuff and switch envs. Maybe there already is a better substitute.
2. SVG familiarity. I'm not there yet.
3. CSS familiarity. Truth be told, I write CSS so infrequently that the Compass FWK is still helpful for me.

RE the last three points:

1. I agree it's a convenient feature. I haven't seen an alternative.
2. Creating or manipulating, or just for sprites? SVG usually starts off in something like Illustrator and the <svg> ouput added to the markup. SVG manipulation can be handled directly in the CSS and/or JS the same as other DOM elements. I wouldn't think we'd do much or any of the creating part, but I could be wrong.
3. You're using Compass more for the non-CSS-writing features? Would you agree that a prerequisite to using Sass (and Compass by extension) well for writing CSS is that it's important to know CSS well*, too, e.g., the "Inception Rule", avoiding bloat, etc.?

*For others: "writing CSS well" doesn't mean importing Bootstrap and washing your hand of it. 😱