Skyfire is a mobile browser that has been exhibited at DEMO and has just closed a $13 million B-series funding round (they had received $4.8 million total prior funding). The elevator pitch is that Skyfire brings any web content to the mobile phone, including Flash applications, YouTube videos, Ajax, etc.
I've been trying the Skyfire beta, and I have to say that it's a neat piece of engineering, even if it's just a stripped down VNC-style screen/audio scraping client for a server-side browser session.
But I'm stunned that it has received this level of venture backing.
My surprise isn't because the software is buggy, slow, and has a bad interface on my Samsung Blackjack. Since I'm running a beta in the 0.6 or 0.7 version range, I feel I should be charitable and I'll pretend that all the bugs will be fixed by 1.0, the interface will be great, and it'll run 10x as fast as it does today.
Instead, my surprise is because Skyfire is really about a great periodic function known as "thin client, no, fat client, no, thin client, no, fat client ..." and Skyfire is the epitome of the thin-client position.
Instead of running a browser (which ironically was once considered the thin client, but is now just the universal fat client, consuming hundreds of MB of memory on a desktop to run several Flash or Ajax apps) on a small device, they punted. They'd run the browser in a data center with memory, CPU, and bandwidth, and hand the phone a 2008 equivalent of a green-screen terminal.
This is a losing proposition. For a long time now, all signs have pointed to the fact that fat clients win. And not just because they happen to offer a better user experience (thin-client proponents insist that will change 'someday' although I doubt it).
The economics and technology lean toward the fat client: Although bandwidth has gotten cheaper on an absolute dollars-per-megabit basis,
- Bandwidth has gotten more expensive relative to the speed of "local" hardware buses: USB 2.0, eSATA, PCI-X, 1333MHz memory, gigabit Ethernet etc.
- Bandwidth has gotten more expensive relative to the cost of local computation: a midgrade Intel proc costs the equivalent of a few months of home DSL or cable ISP service, and this equivalent has been stable for a number of years ... and the computational power of that midgrade CPU has gone up severalfold, while the DSL/cable bandwidth has stagnated ... and now is threatened by both metered-pricing and traffic-shaping schemes. On the GPU side, the differential has changed by orders of magnitude to the advantage of the fat client.
- A given "bandwidth experience" has gotten more expensive as users expect to be connected in multiple contexts: To have the same "experience" I have to buy the same bandwidth several times, once for when I'm home, again for when I'm on my cell phone, again when I need to use WiFi somewhere, and maybe a fourth time for a 3G laptop card.
- Cheap powerful computation has innovators, while bandwidth has innovation obstructers.
Sure, raw dollars-per-CPU-cycle and per-kWh can be optimized in a data center somewhere.