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.
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.
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.
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.
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.
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.
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.
