Why it doesn't matter that you can't run Photoshop on ChromeOS today

The more I read about ChromeOS, the more excited I get about it. I think there's a lot of potential, but I keep hearing one argument against its significance that I'd like to address.

"I'm not interested in ChromeOS, since it won't be able to handle heavy-duty programs like Photoshop."

That might be true today, but it won't be true forever (or even for long). Here's why:

The first computers were programmed by directly writing instructions to the CPU - take this bit here, do this to it, send it there, etc - and all of that coding was done by hand, which is extremely difficult and tedious work. Even today, if you want to write fast code, that's what you do - write directly to the metal (typically using an assembly language, which is basically semi-readable machine code).

But what most people who want something pretty fast (like Photoshop) do is write in C/C++, which gets compiled into that same machine code. It runs a bit slower than if it had been written directly in machine code or assembly, but the tradeoff is it's insanely easier to write and debug. And as compilers get better, it becomes almost as fast as straight machine code.

It wasn't always that way, however, and when C came along, it wasn't nearly as fast as assembly; and when C++ came along, it wasn't nearly as fast as C.

Eventually, Java was introduced, and for years, the C/C++ folks argued that nobody who wanted to write a powerful application would ever do it in Java, because it would be too slow. That's because everything in Java has to get run inside of a virtual machine, which sits on top of your actual machine, and so it just adds this other layer of stuff that has to get executed. Initially, that made Java really slow. But the virtual machines got better and better, and today, Java is basically as fast as C/C++, and many high-performance applications are written in Java.

It's important to note that minor speed differences remain among all these languages, but those differences are completely overwhelmed by how much faster CPUs, hard drives, RAM, graphics cards, etc are. So it's still true that running a virtual machine beneath a Java app is slower than if you didn't need the VM at all, but the speed penalty is at this point extremely small (I'm sure there are language pedants on both sides of the C++/Java divide who would take issue with this, but for this discussion, I think it's a fair point to make).

And so today, faced with a new layer of abstraction - Javascript running in a browser written in C++ on top of a kernel, also written in C++ - people are saying, "No way could you write a web app that would perform as well as a C/C++/Java app." And today, that's true.

There's really only one main reason for that (plus a few small implementation quirks): browsers, which can be thought of as the new Java virtual machines in this story, are slow, and both HTML and Javascript aren't considered "fast" or even particularly pleasant to program in. But that's changing: HTML5 is a substantial improvement on HTML, and Javascript is becoming more and more powerful every day. And browsers - Chrome, Safari, Firefox and even Internet Explorer - are getting faster and faster at running HTML/Javascript apps. In a few years, they'll be fast enough that the performance of web apps will only be a little worse than that of C/C++/Java apps. And CPUs, and every other piece of hardware, will be faster, so it won't matter that much.

In addition, there are a number of projects that already aim to make it even easier to write high-performance code for the web - nativeclient and O3D being just two (Googley) examples.

So yeah, as of right now, you can't and wouldn't want to run Photoshop in a browser. But by the time ChromeOS ships next year, that may be less true. And a year or two after that? Mmhm.