Amazon Silk Splits the Web Browser

With all the Kindle Fire brou-ha-ha, the fact that Amazon is coming out with a new kind of web browers, dubbed Silk, may have been missed by some. I know, “Yawn” you say. Between Firefox, Chrome, Safari, oh, and yeah, Internet Explorer, why do we need another browser?

That’s a good question that Amazon might answer with “Because we can architect it to take advantage of our vast cloud computing resources to make the user browsing experience much faster and more efficient.” You see, at the heart of the Silk browser is a split between what runs on the tablet device (likely very little beyond the rendering of the page) and what runs “in the could cloud” on Amazon’s Web Services empire.

A few of the stated benefits of this include:

• Optimizing images — Rather than shipping a 3MB image to your phone, they can shrink it down on their servers and deliver a much smaller, but still usable image.
• Pre-caching — Since Amazon will know pretty much every move you make on the web, it can begin to aggregate this knowledge and make predictions on where you will go next. Using this information, the server side of the browser can fetch the page and prepare it in advance of your request for it. While this isn’t a new concept, one could argue that Amazon’s much more complete information on the typical user click path would lead to better pre-caching.
• Fewer requests — A typical web page might require a browser to initiate a dozen or more separate web requests to servers on the network. Each of these requests comes at a cost — a cost in potentially performing a DNS lookup, setting up the network connection and breaking it down again, etc. With Silk, the browser can execute one request up to the cloud and the servers on really fast network connections at Amazon can gather everything and send it back in one response.
• Network effects — By handling most of the requesting at the network level, certain economies of scale begin to kick in. For example, if there is a hot story, and Amazon’s web servers have just fetched that photo of Angelina and Brad’s kids for some other user, they don’t have to fetch it again. They can send it down to your client immediately.

What we’re seeing is by thinking carefully about what needs to run at the client side and what can be more efficiently run on the server side, we can build better and faster applications. I would be very surprised if library automation companies haven’t already copped to this fact, and are developing their next generation library systems clients with this in mind. If they aren’t, they will likely be surpassed by those who are.