Hacker News Reader

Comment by moxiemk1 | Hacker News Reader

"Silk browser software resides both on Kindle Fire and on the massive server fleet that comprises the Amazon Elastic Compute Cloud (Amazon EC2). With each page request, Silk dynamically determines a division of labor between the mobile hardware and Amazon EC2 (i.e. which browser sub-components run where) that takes into consideration factors like network conditions, page complexity and the location of any cached content." (from http://www.amazon.com/Kindle-Color-Multi-touch-Display-Wi-Fi...)

This sounds conceptually similar to how Opera delivers pages with one of its mobile browsers, which is to say that Javascript and rich web apps will be severely crippled. Is it indeed possible for the server and client to collaboratively decide what parts of my code to run client-side and which ones proxy-side and still have anything approximating good performance/identical functionality?

View on HN

From the video, I got the impression that they might even not be sending html, css and javascript at all. Instead they might be sending some javascript bytecode and a binary DOM tree.

That would be really interesting! Any implementations of something like that working today?

OBML: http://dev.opera.com/articles/view/opera-binary-markup-langu...

Conceptually its almost identical to Opera Mini. Amazon, however, gets to take advantage of their massive infrastructure.

> Conceptually its almost identical to Opera Mini. Amazon, however, gets to take advantage of their massive infrastructure.

Perhaps Opera Mini runs on Amazon EC2, which would mean they use the same infrastructure ;)

Opera has their own server infrastructure for Opera Mini, although I'm sure it could run on EC2 as well. For a while all the servers were in Oslo, Norway, but now they have servers around the world. Here's an article from last year where they installed some new servers in Iceland: http://my.opera.com/portalnews/blog/2010/11/01/20-million-op...

The video explicitly states that the browser+ec2 work together to decide how to divide up the work based on network conditions, page complexity and other factors.

I would assume that to mean that if there's Javascript that can't be run on the server side, it will be run on the client.

The mind bogging part is that this should still be faster than just rendering the damn page and executing the JS.

How's it mind boggling that a single SPDY connection to a distributed network that has nearly unlimited bandwidth and computing power would be faster than having a mobile device negotiate its own connections?

Even if it was just a proxy for resources it would be way faster, but they gain the benefit of knowing what resources are needed based on past events and likely already having them cached. Not to mention all the sites that will be local to AWS.

I dont think there was any indication of javascript changes. At least all they mentioned was image and dns optimization, as well as prefetching and caching.

http://www.blogcdn.com/www.engadget.com/media/2011/09/amazon...

Now, the picture could be incorrect or stretching the truth, but there was some indication.

touche, sir. Thank you very much for pointing that out.

On the page I link to, Amazon says "We've refactored and rebuilt the browser software stack to push pieces of the computation into the AWS cloud. This lets Silk do more work, more quickly, and all at once. We call this “split browser” architecture."

Computation (in the context of webpages) indicates JS to me, though they concievably could mean DOM construction. I'm fairly skeptical that transmitting a serialized DOM and unpacking it could be more efficient over mobile network connections that is using our time-honored DOM serialization, HTML.

I do hope I'm wrong, as I can't see how this sort of proxy can be healthy for the web, but I don't think my speculations are out if the realm of reasonable given the information.

The Kindle Fire is wifi-only, and Silk is only on the Kindle Fire. They are probably optimizing battery and latency. Bandwidth is important but not as important as if they had to deal with 3g.

That's an interesting point. Most WiFI APs are pretty snappy. Optimizing EDGE connections and weak cellular signals are one thing, but how much faster can it really be on my a 10GPS down connection?

A ton. When you request a site in Silk it's very probable Amazon already knows about all the dependencies and already has them cached locally. So you make a request for a site (in the existing SPDY connection) and in return get everything needed to display it at once. In a pre-computed format so the relatively slow mobile CPU doesn't have to spend cycles parsing it into something readable.

Just the CPU thing makes a big difference. There's a noticeable timing lag between loading a page on my iPad vs on my computer. Same wireless network so it's not the connection slowing things down.

The main reason I'd be happy getting a Wi-Fi tablet is that 3G smartphone based hotspots are becoming ubiquitous. I'd imagine they'll be tuning for that usage as well as couch surfing on home broadband, possibly even intelligently moving more work to the cloud when it detects a slower connection.

A binary DOM would be much more efficient than HTML, by an order of magnitude or more. When I was working on the BlackBerry browser we did the same thing and had gains at least as big. The problem comes when you have document.write calls in scripts, and start getting dynamic content inserted during parsing. That gets really tricky to handle in a server-side environment if it depends on client-side properties or user input.

Very true - this is what old WML based devices use to do - WML got compiled to WBXML or WMLC (depending on who wrote the docs :), and that got sent to the device, making much easier to handle parsing for the device. There were really big speed ups both computing wise - but (especially in those days) also transport.

I don't know how Amazon is doing it with Silk, but I'm guessing they're seeing enough of a speed up to make it worthwhile.

Even if a binary DOM was the same size as HTML (it would actually be much smaller), eliminating the cost of parsing HTML (forgivingly) and serializing it into a DOM would be a significant improvement.

Similarly, even if JS bytecode was the same size as the JS itself, eliminating the cost of parsing, constructing an AST, (possibly) transforming the AST, creating bytecode, and (possibly) doing an optimization pass on the bytecode would be significant.

I wonder if they'll use non-TCP connections on 3G. That'd be cool. (http://blog.davidsingleton.org/mobiletcp)

Based on their jobs page (http://aws.amazon.com/amazonsilk-jobs/) it looks like they're using SPDY.

SPDY is a replacement of HTTP(s) not TCP [1]\

[1] - http://arstechnica.com/web/news/2009/11/spdy-google-wants-to...

We don't have much information on Amazon Silk. It be interesting to know how it works in depth and how web apps will be affected.

*affected

Reply on news.ycombinator.com