The Web Development Workflow of 2013

paul irish · fluent 2012

You can also watch a video of this talk
(Hit space key to advance)
We're seeing the emphasis shift from valuing trivia to valuing tools
As an engineer, there is a short list of tools that you must be rabid about. Rabid. Foaming at the mouth crazy.
# The current _(and near future)_ workflow for webapp developers
## Your shell * Make it sexy. * Join the [dotfile community](http://dotfiles.github.com/) * My faves: `z` script, `server` alias

Shell augments


# Start an HTTP server from a directory, optionally specifying the port

function server() {
        local port="${1:-8000}"
        open "http://localhost:${port}/"
        python SimpleHTTPServer "$port"
}
## Your editor * Learn it well, whatever it is * A good editor is an onion application * Keep peeling back layers to reveal more functionality * More than any other tool, prioritize your familiarity with it


### _Code Linting is your first unit test._
## Realtime feedback * live linting * live recompilation * live reload
## Modules / Dependency Management
##### Possibilities: * AMD modules * CommonJS Modules * ECMAScript Harmony modules * [Minispade require](https://github.com/emberjs/ember.js/blob/master/packages/ember-views/lib/views/states/default.js)
## Dependency management tricks * Template Precompilation * Custom build output [based on build-time forks](http://requirejs.org/docs/optimization.html#hasjs) * [More module magic](http://alexsexton.com/talks/backboneconf2012/#/0/1) [from](http://alexsexton.com/talks/backboneconf2012/#/35/3) Alex Sexton
# Package Management _Coming soon..._
## In-browser Devtools * [`sourceURL`](http://www.thecssninja.com/demo/source_mapping/compile.html) * Source maps * Navigating scripts
## Mobile 1. Test in Chrome * Emulate touches, override device metrics 1. Emulators & [Browserstack](http://www.browserstack.com/mobile-browser-emulator) 1. Real devices & Adobe Shadow 1. Chrome on Android w/ DevTools
## Testing ![](http://farm3.staticflickr.com/2621/3712840085_099a5d1fc3_z.jpg)
## Testing #### Author in whatever is most comfortable Jasmine, QUnit or Mocha
#### Execute tests in a variety of settings: 1. In [the browser](http://localhost:8000/test/) 1. In a headless browser on-demand via cmd line * `grunt qunit` (uses PhantomJS) 1. In a headless browser [post-push](http://travis-ci.org/#!/Modernizr/Modernizr) 1. In multiple browsers via cmd line * `[bunyip](http://ryanseddon.github.com/bunyip/) -f test/index.html` 1. In multiple browsers _in the cloud_ via cmd line * `[bunyip](http://ryanseddon.github.com/bunyip/) -f test/index.html -b ios`
## Build system
Resolve your dependency chain. concatenate. compile. Flatten your CSS @imports. Remove debugging statement. Compress images. Precompile templates. Run tests in a variety of environments. Revs asset paths for caching. Affirm code quality.

& grunt-contrib

Client-side error tracking

# _phew_
## Projects that hide the complexity * [Grunt](http://gruntjs.com/) * [LiveReload](http://livereload.com/) * [Shadow](http://labs.adobe.com/technologies/shadow/) * [CodeKit](//incident57.com/codekit/) * [Brunch](http://brunch.io/) * [WebStorm](http://www.jetbrains.com/webstorm/) * I use [these desktop apps](http://setapp.me/users/paul_irish)
# Near future * [Code coverage realtime](http://blog.jetbrains.com/webide/2012/04/javascript-unit-testing-with-code-coverage/) reports * stub out models/views with tests at the cmd line


### Reduce friction for the things you *should* be doing, like testing.


DRY applies to using tools, too!

  • Don't type ./build.sh everytime you save a file.
  • Dont ftp everytime up you update the site's release branch.


### Sit with another developer, learn from their workflow. (and teach them things)


### Blog or screencast your workflow style.
# _thank you much!_
## `@paul_irish`
## [bit.ly/fluent-workflow](//bit.ly/fluent-workflow)