Ask HN: What are the essential components of your front-end workflow?
Whether it's for ongoing work, or starting a new project, what are tools that have become indispensable components of your workflow?
54 comments
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
This is the exact workflow I've settled on. NPM run scripts until the build complexity gets overwhelming, then build a grunt or gulp taskfile. Tape is awesome.
Why is grunt better than gulp for teams?
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.
They are both good though... it won't make a big difference if you choose one over the other.
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.
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.
You should replace bower with npm/browserify and grunt with gulp. Trust me.
Can you offer a bit more reason than "trust me"?
I used Grunt for a little while until I discovered Gulp. Thought I'd post another option if anyone is interested. Much easier to get up and going. Although it doesn't have as large a community of tools. I'm confident it will get there.
Both are great work horses.
Both are great work horses.
Gulp needs a bunch of work IMO, too much emphasis on streams and not enough composability. Most of my tasks are gulp-esque through streams, and I use a lot of things from the gulp ecosystem, but gulp itself doesn't do a whole lot for me. For anyone using it I recommend lazypipe and runtasks, they've been indispensable in making my tasks work the way I want.
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
- 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.
- 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
- 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.
I love 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.
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.
What are some free alternatives to this, or to LiveReload?
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...
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
- LESSTools:
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:
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.
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')
@require 'my-component'
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/> Stylus is great. Compared to Sass, I think it’s easier, more or equally powerful
In what ways is Stylus more powerful than Sass?
In what ways is Stylus more powerful than Sass?
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.
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.
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).
What is in a typical make file for your projects?
It really depends of the project, but here are two examples, complete and simple: https://gist.github.com/bpierre/da5283f34a03b26e2833
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) ?
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
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.
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.
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"
}
npm run buildThis 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.
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.
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.
Npm run should work fine on windows.
Make is another story.
Make is another story.
Manuel: http://manuel.00null.net
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.
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.
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.
This is fast, really easy and powerful.
[deleted]
http://mixture.io is worth a look :)
http://yeoman.io/
+ (shameless plug) http://htmlshell.com/ (if I need to generate 5-line snippets)
+ (shameless plug) http://htmlshell.com/ (if I need to generate 5-line snippets)
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
Ember CLI is pretty dope https://github.com/stefanpenner/ember-cli if you are using Ember.
I agree, but the canonical link is now http://www.ember-cli.com/ :)
That design is very.. retro?
- 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.
- npm for dependency management; notable package:
- jstransform for transforming ES6/ES7 & JSX to JS
All on a heavily React-based stack.
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.
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).
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).
Adding to OP's question: Does anyone know of any good reads for writing maintainable JS?
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...
[1] - http://www.amazon.com/Testable-JavaScript-Mark-Ethan-Trostle...
Testable JavaScript - Trostler [1]
Both fairly recent and for the most part, useful.
[0] - http://www.amazon.com/Maintainable-JavaScript-Nicholas-C-Zak...
[1] - http://www.amazon.com/Testable-JavaScript-Mark-Ethan-Trostle...
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
[1] http://amzn.to/1nLAVa0
Secrets of the JavaScript Ninja [0]
The Principles of Object-Oriented JavaScript [1]
[0] http://amzn.to/1xl6Huq
[1] http://amzn.to/1nLAVa0
http://alistapart.com/article/writing-testable-javascript
This article was really helpful for me-I had been writing too much "choose your own adventure" code.
This article was really helpful for me-I had been writing too much "choose your own adventure" code.
This titles recent
http://read.humanjavascript.com/ch01-introduction.html
http://read.humanjavascript.com/ch01-introduction.html
npm, broccoli, ember-cli, emberjs, chrome
js_of_ocaml, fswatch to rebuild when source files change.
Why is npm indispensable?
- eclipse
- npm
- firefox
- firebug
- grunt
- git
- jenkins
- javascriptmvc
- npm
- firefox
- firebug
- grunt
- git
- jenkins
- javascriptmvc