Unsolvable Problems Of The Web OS
CNET just ran an article today about the future of the Web-based operating system, one that would operate independently of your actual operating system and utilize fat pipe bandwidth to get the job done. I don’t know how many people are actively putting thought into this subject or its monstrous hurdles, but I wanted to get some of my opinions down on “paper”.
Web Apps Are For Casual Creation
One thing that always bothers me about the Web OS argument is that the proponents continue to skip over my segment of the tech population — people who use desktop-class applications to get hardcore work done. I’m in Photoshop all day long with 15 windows open. I’ve got an Illustrator document to my right with over 40 layers. I have TextMate open with multiple projects, dozens of tabs, syntax-highlighted documents across 4 computer languages, you get the picture. I’m not jotting down little notes or cropping/resizing images (casual), I’m creating applications and creating images (professional, not casual) and that’s the difference. The power and multi-threading of desktop applications is needed when you do anything besides casual computer usage (upload photos, chat on IM, jot down notes, etc.) Unfortunately for Web OS proponents, the vast majority of my day is dedicated to non-casual usage because I use my computer for work. Adobe is taking Photoshop to the Web but will be positioned as the lowest-class Adobe photo app out there, lower than Elements. Hmm, I wonder why? Maybe because…
Forget Internet Bandwidth, Think Browser Execution Bandwidth
The tongue-cheeked answer to “why have a Web OS” is normally “because users’ Internet pipes are getting fatter and fatter and we need to utilize that bandwidth.” It sounds good in theory, but that’s not all there is to it. When you run a desktop application it blazes along as fast as clock cycles and RAM allow, but when you run an application based inside of a browser you have more constricting doors to lock and unlock. First off, you might just be a tab on a window with 50 other fully-loaded tabs, which kills your processor power right there (Camino and FF die slow deaths with dozens of tabs open.) Also, if you’re relying on hundreds or thousands of lines of JavaScript to run your application, it’s only going to run as fast as the JavaScript interpreter is allowed to run, and that depends on the browser and how much RAM is allocated to the browser at that particular point in time. When I used the door analogy earlier of locking and unlocking, I meant that a web application has to unlock the door to the JS engine, which needs to talk to the browser, which then talks to the operating system. At any step along that path, one of the doors might just snap shut or be less than fully open (memory problems, reallocated processor power, etc.) and the web app can’t do anything about it because it is at the mercy of the rest of the food chain.
I Don’t Know About You, But I Like Things Snappy
There’s a reason people buy fast computers and lots of memory and that is so their desktop applications zip around and operate at fast speeds. I have yet to use a web application that was as zippy as a desktop application, and that’s annoying. Why would I replace a perfectly good full-powered application with a crippled and slow web application? How is that alluring?
