Shanti’s Dispatches

Joel Spolsky has posted another thought-provoking strategy letter:

In the late 80s, Lotus was trying very hard to figure out what to do next with their flagship spreadsheet and graphics product, Lotus 1-2-3. There two obvious ideas: first, they could add more features. Word processing, say. This product was called Symphony. Another idea which seemed obvious was to make a 3-D spreadsheet. That became 1-2-3 version 3.0.

Both ideas ran head-first into a serious problem: the old DOS 640K memory limitation. IBM was starting to ship a few computers with 80286 chips, which could address more memory, but Lotus didn’t think there was a big enough market for software that needed a $10,000 computer to run. So they squeezed and squeezed. They spent 18 months cramming 1-2-3 for DOS into 640K, and eventually, after a lot of wasted time, had to give up the 3D feature to get it to fit. In the case of Symphony, they just chopped features left and right.

Neither strategy was right. By the time 123 3.0 was shipping, everybody had 80386s with 2M or 4M of RAM. And Symphony had an inadequate spreadsheet, an inadequate word processor, and some other inadequate bits.

Peter Colijn, a developer at Google, nails it in his response:

He then goes on to say that history is repeating itself with AJAX, giving Google, and Gmail in particular, as his choice for the contemporary Lotus. However, the comparison isn’t entirely apt.

The main point of Joel’s story, though, was that current AJAX developers (and in particular Google) are busy doing the present-day equivalent of rewriting inner loops in assembly, i.e. tweaking and heavily optimizing JavaScript and dealing with annoying browser compatibility issues and so on, and that soon this won’t matter because there will be some great platform that abstracts all of these details away. I find this hard to believe, for a number of reasons. JavaScript execution may get much faster, both due to hardware and software improvements. There are new JS engines that are much better than Spidermonkey, which is Gecko’s default. But that’s only a small part of the problem. Once you have the JavaScript on the client, it is already executing fast enough most of the time. It’s not the bottleneck.

The bigger problem is bandwidth and latency. Bandwidth does not increase at a pace at all similar to Moore’s law. A lot of people have broadband now, but the networks themselves are overloaded (the tubes, if you will, are clogged).

Similarly for latency; a typical HTTP request has about 50-100ms of latency each way on a very good connection, and that’s not getting any better any time soon. This means that doing frequent or large (or both) network requests will be problematic for some time to come. So a sloppily-written AJAX app that does 90 HTTP requests just to load is slow today, and guess what? It will still be slow in 6 months!

Exactly. But there’s more.

Over at SproutIt, when we were building the first iteration of Mailroom 2.0, it only took one extremely talented front-end developer (Charles Jolley) to optimize some pretty incredible AJAX.

See a preview below or signup for an account yourself and take it for a spin.

It’s just as fast as GMail’s JavaScript, and if we had millions of dollars to pay for infrastructure, our AJAX responses could be just as fast as Google’s as well. But even as is, our server-side responses are pretty darn fast, especially considering the under ~$2-3k pricetag of our boxes (monthly).

Charles even rolled the front-end JS framework into a reusable library, open-sourced as SproutCore. You may have seen it in the recently-launched .Mac Web Gallery (more on SproutCore here)

Thus, Joel’s assertion that a company needs an army of developers to sit around and optimize JavaScript, well, it’s simply bull hunkey.

So, a Team of 3-5 Could Compete with GMail?

Yes, on a functionality front. But once your site gets TechCrunch’d and 50,000 users are trying to signup all at once, your site will be pwned. Toast.

No startup (yet) can compete with Google’s infrastructure for massively deploying applications to millions of users. Someone might be able to get there, if they had to — but their solution would likely only solve a single aspect of the scalability problem. i.e. you might solve the problem of getting hundreds of thousands of email messages into an app within a short time span, but will you also have solved how to stream hundreds of gigabits of video too?

Options for Scalability Problem Vectors

Amazon S3 is a step in the right direction for sites that are very file-serving intensive. (think YouTube, Flickr, etc)

Amazon ECS, GridLayer, mediatemple’s Grid-Service, etc help if your site is very appserver-centric (i.e. lots of PHP or Mongrel/Ruby processes chewing up fatty amounts of CPU on biz logic, etc). Still grids are clearly not a panacea.

For database-intensive apps (like Wikipedia), there is no simple solution for scaling MySQL. Sure, it scales, but you have to do it per application. Does your site do 10,000 reads per second and 50 writes? Or 500 writes and 50 reads per second? Those two scenarios will need entirely different MySQL setups.

You can bookmark this, digg this or check the cosmos