
Ask HN: What are the essential components of your front-end workflow? - Gabriel_Martin
Whether it&#x27;s for ongoing work, or starting a new project, what are tools that have become indispensable components of your workflow?
======
mattdesl
I'm a big fan of npm and modular code.

    
    
      - 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
    

I try to avoid bower since it's no good for re-usable modules. But sometimes
you can't avoid it (e.g. threejs, pixi).

~~~
Kiro
Why is grunt better than gulp for teams?

~~~
mattdesl
Because it's been around for longer; new devs are more likely to be familiar
with it, easier to find tutorials/docs on the web, better stability, more
tasks to choose from, etc.

They are both good though... it won't make a big difference if you choose one
over the other.

------
snide
Bower and Grunt. Dunno how I lived without them.

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.

~~~
Kiro
You should replace bower with npm/browserify and grunt with gulp. Trust me.

~~~
ehutch79
i'm not sure how browserify replaces bower?

~~~
sehr
It (or something like it) is a requirement for using node modules in the
browser

------
grayrest
Current preferred setup is:

\- npm for javascript dependencies

\- vendor dir for sass deps (I've had problems with Bower don't run enough
deps to put up with it)

\- Webpack [1] 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.

[1] [https://github.com/petehunt/webpack-
howto](https://github.com/petehunt/webpack-howto)

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

\- Vim with my own set of javascript + library UltiSnips snippets. Tip: when
you're writing library snippets, write them as e.g. 'react.snippets' and NOT
'javascript_react.snippets'. This prevents the various library snippets from
interfering with each other. Vim supports a file having multiple simultaneous
filetypes using a dotted notation `:set ft=javascript.react` and you can use
ftdetect to automate the setting.

------
alexknowshtml
I love [http://hammerformac.com](http://hammerformac.com)

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.

~~~
meowface
What are some free alternatives to this, or to LiveReload?

------
arnaudbreton
Few weeks ago, I've written an article about my 5 favorite front-end tools:
[http://thenextweb.com/dd/2014/05/29/5-great-front-end-
develo...](http://thenextweb.com/dd/2014/05/29/5-great-front-end-developer-
tools-try/)

------
nodesocket
Here is my setup:

    
    
        - SublimeText 3
             SublimeLinter (plugin)
        - NPM
        - Gulp
            gulp-concat
            gulp-uglify
            gulp-ng-annotate
            gulp-connect
            gulp-watch
            gulp-livereload
            gulp-less
    
         - LESS

------
simfoo
Qt.

I know that's probably not what you meant, I just wanted to remind people that
there's a world outside of the browser.

~~~
rubiquity
It would be great then if you would take the time to explain why it is
invaluable to you. Thanks.

------
bpierre
Tools:

Browserify [1]. 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 [2] 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:

    
    
      require('my-component')
    

And in Stylus:

    
    
      @require 'my-component'
    

For the build step, I always use Make because it’s everywhere except Windows,
and I switch on gulp [3] if things get complicated or if I need Windows
compatibility.

I’m using tape [4] and testling [5] (locally) for tests. Simple.

jspage [6] (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.

Services:

Cloudup [7] 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 [8] (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.

    
    
      [1] http://browserify.org/
      [2] http://learnboost.github.io/stylus/
      [3] http://gulpjs.com/
      [4] https://github.com/substack/tape
      [5] https://ci.testling.com/
      [6] https://github.com/bpierre/jspage
      [7] https://cloudup.com/
      [8] http://scri.ch/

~~~
subsection1h
> _Stylus is great. Compared to Sass, I think it’s easier, more or equally
> powerful_

In what ways is Stylus more powerful than Sass?

~~~
grayrest
I'm a different person but I did use and prefer Stylus for a while.

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.

~~~
bpierre
I agree with the last part, of course the community is a strong advantage for
Sass. @extend is in Stylus too, but it supports any selectors (last time I
checked, Sass’s @extend was only supporting classes).

------
polskibus
That's a great question. Can anyone say something about their .NET front-end
workflow? Do you use only VS built-ins ? Or perhaps you've found a way to use
browserify, node, etc. efficiently whend creating UI in the MS world? So that,
when your work is done, it is easy to move your stuff to project files and
back (if necessary to correct something) ?

------
krapp
Composer, and this (quick, dirty) shell script I wrote to build a basic
composer web app setup (including /public with an index.php which loads the
autoloader and an .htaccess which auto-routes to it.)

[https://gist.github.com/kennethrapp/701c275ff0a2349fc51f](https://gist.github.com/kennethrapp/701c275ff0a2349fc51f)

------
tzaman
I have a question here, has anyone tried to create a task runner in plain
shell (as bash script maybe). I imagine it could perform similar/same tasks as
GruntJS, with maybe a bit more speed. At the cost of being slightly more
complicated and I'd need to update/install dependencies manually. Just a
thought.

~~~
mattdesl
Sounds like Make.

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
      "scripts": {
        "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"     
      }
    

Now a user just needs to run this to build your app:

    
    
        npm run build

~~~
joshuacc
This will certainly work in an exclusively *nix environment. However, if you
need your build system to be Windows-compatible, you'll need to go with
something like Grunt.

~~~
aeflash
My team decided to just forget about Windows, and only use Linux or OSX. It is
so much more convenient when you can rely on Bash, Make, and Unix conventions.
(It is interesting discovering the slight incompatibilities between GNU core
utils and OSX core utils, though, but usually the GNU versions just have extra
features.)

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.

------
foozoor
I use yeoman for a lot of thing. In my strict frontend workflow I use the
gulp-webapp generator.

This is fast, really easy and powerful.

------
neilkinnish
[http://mixture.io](http://mixture.io) is worth a look :)

------
stefek99
[http://yeoman.io/](http://yeoman.io/)

\+ (shameless plug) [http://htmlshell.com/](http://htmlshell.com/) (if I need
to generate 5-line snippets)

------
Gabriel_Martin
Personally, I've only recently learned about Bower and Grunt, so I can't
particularly evangelize for them. However, a basic tool which offer similar
functionality, which I certainly can give love to, it the nentuts+ fetch
package for Sublime Text 2/3\. It allows you to, as the GIT repo so concisely
puts it: Fetch the latest version of remote files and zip packages. It's
great!

[https://github.com/weslly/Nettuts-Fetch](https://github.com/weslly/Nettuts-
Fetch)

------
adamnemecek
Ember CLI is pretty dope [https://github.com/stefanpenner/ember-
cli](https://github.com/stefanpenner/ember-cli) if you are using Ember.

~~~
Kerrick
I agree, but the canonical link is now [http://www.ember-
cli.com/](http://www.ember-cli.com/) :)

~~~
sehr
That design is very.. retro?

------
jxg
\- Webpack for building, watching, optimizing / bundling

\- npm for dependency management; notable package:

\- jstransform for transforming ES6/ES7 & JSX to JS

All on a heavily React-based stack.

------
cnaut
I love usemin. It is really simple and works perfect for my workflow. In
development, it allows me to have all my js and css files referenced normally.
In my build process, usemin concats all the js and css files, minifies them,
and replaces the references to them to the minified concatenated resource. You
don't have to have any script running watching your files for changes or
anything like that.

------
sehr
NPM

Browserify - Common JS kicks ass.

Gulp

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

------
kparaju
Adding to OP's question: Does anyone know of any good reads for writing
maintainable JS?

~~~
sehr
Maintainable JavaScript - Zakas [0]

Testable JavaScript - Trostler [1]

Both fairly recent and for the most part, useful.

[0] - [http://www.amazon.com/Maintainable-JavaScript-Nicholas-C-
Zak...](http://www.amazon.com/Maintainable-JavaScript-Nicholas-C-
Zakas/dp/1449327680)

[1] - [http://www.amazon.com/Testable-JavaScript-Mark-Ethan-
Trostle...](http://www.amazon.com/Testable-JavaScript-Mark-Ethan-
Trostler/dp/1449323391/ref=pd_sim_b_1?ie=UTF8&refRID=125HM4BH9E78W7A3Y2EC)

~~~
zercool
Depending on your end-goal, I would also suggest:

Secrets of the JavaScript Ninja [0]

The Principles of Object-Oriented JavaScript [1]

[0] [http://amzn.to/1xl6Huq](http://amzn.to/1xl6Huq)

[1] [http://amzn.to/1nLAVa0](http://amzn.to/1nLAVa0)

------
k__
npm, bower, gulp, shippable, webstorm, git, chrome, bitbucket.

~~~
cnaut
+1 for webstorm. Very powerful IDE especially if your backend is node

------
kyrre
npm, broccoli, ember-cli, emberjs, chrome

------
jasonpriestley
js_of_ocaml, fswatch to rebuild when source files change.

------
swah
Why is npm indispensable?

------
y0ghur7_xxx
\- eclipse

\- npm

\- firefox

\- firebug

\- grunt

\- git

\- jenkins

\- javascriptmvc

