- npm to manage dependencies and versions
- npm-scripts to handle basic build tasks
- beefy during module development
(when a bundle isn't necessary)
- watchify & browserify/uglifyjs during app development
(when a bundle is necessary)
- gulp if the project is more involved (LESS, etc)
- grunt if the project is with a team
- tape / tap for testing, and testlingify for the git hook
They are both good though... it won't make a big difference if you choose one over the other.
Bower is fantastic for dependency management. This is apparent as soon as you use it to manage the reqs for your project, but becomes even more awesome when you start publishing your own code, even if it's something not many other people use. Right now I have a bootstrap like Sass framework that I built and use between five or six projects. Not too big, but each one of those projects is pretty popular and actively edited. I needed a way to make sure everything updated well and could be temporarily stalled while I worked on better releases. Bower does all that.
Grunt is just my workhorse. Bower may install my files, but I need them moved around into certain folders in my project. Grunt handles that with a line or two. I also use it to watch my sass files and rebuild my static sites when changes to the templates or JS files occur. Since I publish some of my code to github I have grunt commands to auto tag and version my git repo and build, merge and publish a gh-pages branch so my documentation is kept up to speed. It also minifies whatever files I need minified/uglified and adds some license and documentation to the top of the files.
Almost all of these things I used to do manually or hand separate processes for.
Both are great work horses.
- vendor dir for sass deps (I've had problems with Bower don't run enough deps to put up with it)
- Webpack  and some shell scripts for builds. Webpack does all the hard/coordinated stuff and the scripts copy files. I've used Rake, Grunt, and Gulp with Browserify to do the same things and find my current setup works better.
- Sass. I strongly dislike Less.
- React with Bacon
- Jest for testing. I'm not completely thrilled with this. It's awesome when it works but I've also spent half a day tracking down a bug that turned out to not be a bug and instead an artifact of the Jest module loader.
It's like having a precompiler for everything that does live-rebuild/reload, and creates deployable builds of front end code.
None of the individual things that Hammer does automatically is actually hard, but the fact that I don't have to think about firing up a bunch of watch commands before getting to work is awesome.
- SublimeText 3
I know that's probably not what you meant, I just wanted to remind people that there's a world outside of the browser.
Browserify . You have all the npm packages available, and your modules are compatible with Node. This allows you to easily test your modules, or reuse some of your modules in the browser, the CLI and a webserver for example.
Stylus  is great. Compared to Sass, I think it’s easier, more or equally powerful, and more future-proof. It’s basically a programming language on top of CSS, while Sass looks more like another language that produces CSS. It’s also written in JS, so you can easily write your own plugins (as npm modules).
Browserify and Stylus are also quite nice if your code is component-oriented.
This is how you import a component in Browserify:
I’m using tape  and testling  (locally) for tests. Simple.
jspage  (I’m the author) is a simple tool I often use to transform some JS into a page. Useful for quick tests if you work in the CLI.
Cloudup  is nice for quick screenshot sharing. On OS X, I just use the built-in tool to make a screenshot, and an URL is immediately copied to the clipboard, I just have to paste it to someone. The delay between the moment when you take the screenshot and the moment when the other person loads the page is usually enough for the screenshot to be uploaded and displayed.
scri.ch  (I wrote this tool) is a simple drawing tool I’m using to share visual ideas, especially in GitHub issues (just add .png to an URL to get the image). I also use it to make quick interface elements that I can integrate into a web mockup.
In what ways is Stylus more powerful than Sass?
When Stylus was created it was definitely more powerful than Sass. The syntactic flexibility of mixin invocation lets you define your own css properties and override how others work transparently. It also had a better story for defining in-language functions and whatnot.
Since TJ stopped working on Stylus the Sass guys have continued adding features. Using @extend can significantly reduce the size of the output CSS file, the ability to pass blocks into mixins was added, and SassScript roughly matches stylus' language. I consider Sass to be more powerful but someone using a different/older feature set could easily argue the other way.
The sass community is also larger/more prolific so you have sass frameworks (not that I generally use them but they're there) and things like the Team Sass github org doing interesting/random things.
You can also use npm-scripts for basic shell commands. You can rely on NPM-authored tasks and have them listed as a devDependency, so that users don't need to install anything manually.
//create a UMD build for the browser
"bundle": "browserify index.js -s foo > build/foo.js",
"minify": "uglifyjs build/foo.js > build/foo.min.js",
"build": "npm run bundle && npm run minify"
npm run build
Make plays nicely with npm once you set the PATH to include ./node_modules/.bin . Watching is the only thing Make can't do, so I usually set up a very simple Gruntfile that watches the source files, launches a livereload server, and just calls `make` when anything changes.
Make is another story.
The main issue I have faced when trying to use bash scripts for this is that most frontend developers are not familiar with it, and a (thankfully) minority still uses Windows. You can still install dependencies from package.json and use ./node_modules/bin/xxx to execute them, so that's not a stopper.
I wrote a simple task-runner around the same time Grunt was born: http://ricardo.cc/cake-flour/, I still use it daily thought it's a bit out of date. Or you can use Gulp, still simpler and faster despite the quirky api.
This is fast, really easy and powerful.
+ (shameless plug) http://htmlshell.com/ (if I need to generate 5-line snippets)
- npm for dependency management; notable package:
- jstransform for transforming ES6/ES7 & JSX to JS
All on a heavily React-based stack.
Browserify - Common JS kicks ass.
Most of the non js assets I regularly use (normalize css, bootstrap) are all available on NPM nowadays, so I was able to get rid of bower (thank god).
Both fairly recent and for the most part, useful.
This article was really helpful for me-I had been writing too much "choose your own adventure" code.