Skip to content

Instantly share code, notes, and snippets.

@stephenhardy

stephenhardy/gist:5844048

Forked from paulirish/gist:5842309
Created June 23, 2013 06:40
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save stephenhardy/5844048 to your computer and use it in GitHub Desktop.
Save stephenhardy/5844048 to your computer and use it in GitHub Desktop.
Download ZIP
Raw
gistfile1.md

I wrote this in early January 2012, but never finished it. The research and thinking in this area led to a lot of the design of Yeoman and talks like "Javascript Development Workflow of 2013", "Web Application Development Workflow" and "App development stack for JS developers" (surpisingly little overlap in those talks, btw).

Now it's June 2013 and the state of web app tooling has matured quite a bit. But here's a snapshot of the story from 18 months ago, even if a little ugly and incomplete. :p

In the beginning…

  • Intro to tooling
  • build a picture of how it takes you from handcraft vs craftsman

Remember making edits in a text editor and FTP'ing those changes up to a server? Oh and waiting for other people to finish editing their file because you didn't have any version control in place? Yeah, it was rough for a lot of us, but we just didn't know how much better it could be.

Firebug was the first app that made web developers amazed and what they didn't know they could do. It's good to be unsatisfied with your workflow. You can want more. ~Rebecca Murphey

The ecosystem of tools for frontend developers has exploded in the past two years and, as always, keeping up is tough. But I'd like to share with you what tools you have at your disposal to make your job easier. In this article we'll cover all the tools, but instead of a round-up list, we're going to go through the full lifecycle of webapp development and investigate how we can be assisted at each step.

The Modern Web Development Workflow

** OMG PICTURE OF THE WORKFLOW THING **

** need text here to give an overview of how it all works **

The authoring experience

In the past, you start with essentially three different text files: your HTML, the CSS, the JavaScript. Nowdays you'll pull in code from your own starting template, use something like HTML5 Boilerplate, Twitter Bootstrap or perhaps a CSS grid framework. All the while you're building these text files up from empty files to more closely represent the core of your app.

Authoring abstractions

HTML, CSS, and JavaScript can't evolve quickly enough to ease developer ergonomics (and certainly our browser landscape doesn't update quick enough) so abstractions that improve these core languages have stepped in.

** note about --watch? **

Styling with CSS

It's always been the target of frustration, and while jQuery revolutionized dealing with the DOM a while ago, it's only been recently that we've seen dealing with styling improve through tooling.

http://lesscss.org/

  • Sass, and its companion Compass, probably have the best known CSS tools. If you haven't put them to use yet, you've probably heard again and again from others that you should. It means dealing with the command line, which might be a new part of your workflow, but everyone I know that has gone Sass hasn't gone back. A brief but powerful introduction is this deck: Sass and Compass: The Future of Stylesheets Now;
    • One of my favorite aspects of Sass is being able to transition an existing stylesheet over to it. The default dialect is SCSS, which is a superset of the CSS syntax which means we can run our current styles through it and just refactor to more logical styles as we go.
  • Less.js started in Ruby but made the switch over to JS, an attractive option if you've got a NodeJS stack already. While it is written in JavaScript, it's a poor choice to use client-side in production; the performance cost on mobile is significant.
    • Google Closure Stylesheets was announced recently, but for the most part, it was an open-sourcing of a tool internally developed long before these two projects. (Mozilla also made one they use for Firefox's UI) minification (incl vendor specific), linting, RTL flipping, and CSS class renaming.
  • Stylus is the latest entrant. It was designed from a frustration of the power of Sass and Less, so it's pretty next-level. Nib is its CSS3 companion library.

Easier Markup

Matching your angle brackets visually in your text editor gets tiring sometimes. Markup has been abstracted a number of times, sometimes for easier user contributions (BBCode, Textile) or imperitively as in Zen Coding. They all have different uses, sometimes for scaffolding a markup structure you'll fill in later, managing through a template, or authoring the primary content in perpituity.

  • Haml was crafted by the same gent who created Sass, Googler Nathan Weizenbaum. Haml takes the class and ID syntax and blends it with a indent specific structure to scaffold your HTML. However, don't be tempted to write your content with HAML; in fact, HAML sucks for content -- for that, we'll use something different.
  • Markdown is what this article was drafted in and has become many developers' default markup abstraction for writing prose. It works very well for body content. Tooling for writing it has improved as well; certainly there are many CLI compilers like maraku and kramdown which extend the core language, but editors like Mou.app and the web-based Dillinger make authoring content a dream.
  • Jade, from the creator of Stylus, took a lot of inspiration from HAML, and works great in a NodeJS stack. It also offers a debug view, which is invaluable when your template is misbehaving.
  • Handlebars is likely the speediest and most extensible templating engine around and plugs in very nicely when you're matching JSON data up against markup.
  • Zen Coding differs from the above as it is an imperative HTML scaffolding tool or "abbreviation engine". If you're working in a team and can't migrate to one of the above abstractions, you'll enjoy typing div#content>h2+p hitting Ctrl , and getting <div id="content"><h2></h2><p></p></div> (properly formatted) expanded in your editor.

Simpler Script

Just like jQuery improved the DOM, ECMAScript the language is ripe for improvements. Coffeescript is the clear innovator here, and was designed to save time typing but also maintain the same readability of JavaScript. So essentially it's killing off superfluous and redundant syntax so can more clearly look at the semantics of the code itself.

Iteration Workflow

IDEs?

For some reason, I don't see IDE's widely used by frontend developers. Pretty much everyone uses Textmate, Sublime Text, or Vim. Nonetheless, there is a space for web developer IDE's and right now WebStorm owns the space. It has one of the best code completion algorithms for JavaScript available; a language that is notoriously difficult to write tooling for. It's not stodgy old software either; it's got built-in support for Coffeescript, JSHint, jQuery, YUI, JSTestDriver, Zen Coding and plenty more.

  • intro
    • Intro to tooling
    • build a picture of how it takes you from handcraft vs craftsman
  • authoring experience
    • abstractions
    • IDEs
    • more???
  • app arch
    • dependency mgmt
    • app frameworks
  • iteration workflow
  • build & deploy
    • build tools
    • image compress
    • minify
    • spriting
    • testing
    • CI

othersomethign

  • bundles

tooling antipatterns

conclusion

the list

bundles:

styling

  • sass (w/ compass)
  • less
  • stylus (w/ nib)
  • closure-styelsheets

markup

  • markdown
  • haml
  • jade
  • mustache
  • liquid

script

  • coffeescript

app arch

  • module pattern. AMD modules.
  • dependency mgmt
  • app frameworks

iteration

  • codekit, livereload
  • python httpsimpleserver
  • IDE
    • webstorm

browser devtools

build

Image compression tools

  • pngout, optipng
  • imageoptim
  • spriteme

Minification & concat tooling

code quality:

dependency mangement

  • require
  • sprockets

frameworks

  • jQuery Mobile
  • Sencha
  • jQuery UI
  • Sproutcore

Testing

  • Selenium
  • QUnit
  • Jasmine
  • jstestdriver
  • testling

browser testing

Continuous integration

CLI

static site generators:

APP STACK

error reporting:

"code splitting"

related tooling articles

_todo:)

"On the various Microsoft Windows platforms, command-line tools for development are seldom used. " ~ http://en.wikipedia.org/wiki/Integrated_Development_Environment#Attitudes_across_different_computing_platforms

Framework tooling

http://docs.webplatform.org/wiki/concepts/internet_and_web/html5_hybrid_applications/concepts/mobile_tools

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment