Monthly Archives: April 2011

Why we should support users with no Javascript

If you take The Guardian as an example, the current average visitors per day is around 2,200,000. 1.3% of that is 28,600 users browsing without Javascript. Per day.
more on

While I had always believed in progressive enhancement and the need to ensure that my sites work without JavaScript, this article almost convinced me to change my mind, by using weak argumentation.

While it still makes sense for content websites, providing a non-JavaScript and usable fallback for modern web apps is really a significant effort. For what benefit? Support for 1.3% users (I hope that this number excludes bots). With such a small number it really becomes a business decision: is it worth spending extra money (usually much more than 1.3% of the cost of development) to support that group?

Ability to link to a page and letting crawlers in are worth extra effort, though. But optimization of user experience for 1.3% of users who disable JS, sometimes for misguided reasons? Show me the money from that investment first.

How to evaluate a non-technical co-founder

Most non-technical founders think they’re great product people because it’s so easy to be an ok product person. You’re going to have to decide whether you’re dealing with a great product person or not. A great product person:
  • Is relentlessly focused on making sure you’re making the right product for the right market.
  • Has a clear vision of what success for your product looks like and is probably addicted to metrics.
  • Knows when to cut features and can prevent you from wasting time on developing irrelevant features early on.
  • You can point to any piece of a product and ask “Why?” and they have an answer.

Worth reading before engaging with somebody on a new venture. Interestingly, most of this advice seems to be also applicable to product owners in non-startup environments.

The Sad, Beautiful Fact That We’re All Going To Miss Almost Everything

Surrender, on the other hand, is the realization that you do not have time for everything that would be worth the time you invested in it if you had the time, and that this fact doesn’t have to threaten your sense that you are well-read. Surrender is the moment when you say, “I bet every single one of those 1,000 books I’m supposed to read before I die is very, very good, but I cannot read them all, and they will have to go on the list of things I didn’t get to.
more on

You’re NOT going to be well read. Don’t worry, that’s OK.

SPDY: An experimental protocol for a faster web

Some specific technical goals are:
  • To allow many concurrent HTTP requests to run across a single TCP session.

  • To reduce the bandwidth currently used by HTTP by compressing headers and eliminating unnecessary headers.

  • To define a protocol that is easy to implement and server-efficient. We hope to reduce the complexity of HTTP by cutting down on edge cases and defining easily parsed message formats.

  • To make SSL the underlying transport protocol, for better security and compatibility with existing network infrastructure. Although SSL does introduce a latency penalty, we believe that the long-term future of the web depends on a secure network connection. In addition, the use of SSL is necessary to ensure that communication across existing proxies is not broken.
  • To enable the server to initiate communications with the client and push data to the client whenever possible.
more on

White paper of SPDY, Google’s new protocol to improve and potentially replace HTTP. The latter has served us well, but is not really optimized for speed.

Staging Servers, Source Control & Deploy Workflows, And Other Stuff Nobody Teaches You

What I would like to give is some practical pointers for implementing three practices which, if you’re not already doing, will greatly improve the experience of writing software for the web:

  1. Staging servers
  2. Version control workflows
  3. Tested, repeatable deployments

These things may sound basic for people working in larger organizations, but are in fact indispensable for anybody making software.

Leaving in a Huff

Arianna Huffington, photographed immediately prior to her ripping an ox apart with her teeth.

An account of what happened to some of AOL’s online properties after Huffington Post acquisition. The way AOL handled this is so humiliating that it’s almost unbelievable.

The story itself reads very well – it was written by a professional. Because, believe it or not, in the past there had been people who were getting paid for writing!

Modern JavaScript

We’ve already seen what this means for JavaScript as a language: it was years after JavaScript’s debut before we really started seeing conversations about what a module should look like in JavaScript, and we’re still fighting over it today. Without a solid dependency management system — something you can take for granted in any 15-year-old community-driven language — dependency management often means sticking another script tag on the page, and even the most popular JavaScript library on the planet struggles with how to participate in a fledgling ecosystem. With no arbiter of common, tested, community-approved, community-vetted solutions — see Perl’s CPAN — it’s an environment that’s ripe for fragmentation, and shining examples of Not Invented Here (NIH) litter the JavaScript landscape. Lacking even an agreed-upon method of expressing dependencies, the findability of good solutions is low, and coalescence only occurs around tools with extremely low barriers to entry and extremely high near-term reward.

Thoughtful post on the current state of JavaScript and the future it should be heading to.