Your Website is Too Damn Big

According to HTTP Archive, websites are approaching an average of 2MB per page. That's nearly double the average from just two years ago. I have some ideas why and how you can fix it.

Aug 2012 vs. Aug 2014

Other *18K131K+627%

* Custom fonts and vector icons seem to be most of "Other"

But what's to blame?

The three bigges are:

  • Images: most likely due to retina displays, web developers are under more pressure than ever to keep the eye candy pretty at an additional average cost of nearly 500K per page since 2012.

  • Custom fonts & vector icons: also due to retina displays (and to a lesser extent mobile devices), these techniques (e.g. icoMoon and SVG glyphs) are super cool but


Letting Go of Node.js

TL;DR version: I'm a JavaScript snob who's now learning Go ( and plans to drop Node.js. I'll be sharing my learnings here in the coming weeks.

Why Dave... why?!

I love JavaScript. I've been a huge advocate (both figurative and literal) of this quirky language since 1995. And for the past ten years I've been focused on using JavaScript for app development for the browser, wrapped in some native app, or installed directly as first class citizens on certain web-centric operating systems like Chrome OS, BlackBerry 10, Tizen, FireFox OS and webOS. I've even written a few JavaScript app frameworks, including Jo app framework which I open sourced in 2009.

I was an early advocate of JavaScript on the command line (remember Rhino?) and even as a web server (Helma). When Node.js came out, I was a big fan (again, both literal and figurative), but


I'll be at Desert Code Camp April 5

My first time attending this show; hoping to meet a ton of local Phoenix valley developer types.

Looks to be 500 or so interested folks with 200 confirmed attendees. See you there!


Introducing GOTOJS: Sequential Programming for JavaScript

With all the Javafication of JavaScript still going around today, I'd like to take the conversation in another direction and humbly introduce GOTOJS.

It's a lightweight, low-level library that:

  • Introduces proper sequential programming based on line numbers, something sorely missing from JavaScript
  • Reduces complexity by eliminating the need for semicolons
  • Works exclusively in global space; no more var statements for your variables (seriously, don't use them or something may break)
  • Simple, direct control of code execution with goto()
  • Powered by eval()


Basically, it's BASIC.


program = {  
    10: "x = 0",
    20: "x = x + 1",
    30: "print(x)",
    40: "if (x < 5) goto(20)",
    50: "print('Done!')",
    60: "end()",

    100: "print('Hello World!')"




You can also run from a given line number:



Hello World!  



  • run(line) start execution of the program at the beginning


Is JavaScript's eval really evil?

"eval() is evil."

If you're a Web developer, you've probably heard this, along with other JavaScript commandments like "don't use with()" and "don't use ++ or --". Doug Crockford's list of "bad" JavaScript language elements is pretty long, and they're pretty subjective.

Meanwhile, Crockford had for much of his JavaScript career been a driving force behind what I call the "Javafication of JavaScript". That is, making complex hunks of code in JavaScript to simulate Java idioms and behaviors (like classical inheritance).

While Crockford has since recanted much of that "Javafication", the ripple effects are still with us today. Further, his "bad parts" of JavaScript stem from the same mindset. Basically: JavaScript is somehow "broken" and we must avoid tangling with complexities like when you need curly braces.

An open-minded approach

We should all be aware of the features and complexities of JavaScript. Instead of blindly following word from on high about