"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 <a href="http://www.amazon.com/Kindle-Color-Multi-touch-Display-Wi-Fi/dp/B0051VVOB2/ref=amb_link_357575542_4?pf_rd_m=ATVPDKIKX0DER&pf_rd_s=gateway-center-column&pf_rd_r=0N625M4JAW6DBV6QKRXA&pf_rd_t=101&pf_rd_p=1321408942&pf_rd_i=507846#silk" rel="nofollow">http://www.amazon.com/Kindle-Color-Multi-touch-Display-Wi-Fi...</a>)<p>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?
So... from the sounds of it... they rebuilt what Opera Mobile does and what RIM does with Blackberry?<p>They offload some of the compositing and some of the fetching and asset flattening server side, and then serve up to the device with custom protocol the pre-rendered flattened data anything that can be done server side. That is exactly the same way those other accelerator products already work for mobile.<p>While it's a nice design, it's been done. The limitations and issues are well know as well, like having trouble with private intranet sites and VPNs or that because all the requests come from a few centralized IPs, geoip doesn't offer any benefit (GEOIP is a hack anyways but sites use it and users get confused when their pages think they are where ever some colo is). It also creates a single point of failure which, pedantically, is counter to the design of the internet.<p>I was a little inflamed by the video's first statement that browsers have been built pretty much the same as they were since the beginning without many innovations. Sounds like marketing spin. I can name several notable amazing advancements in browser design since the days of WordWideWeb at CERN and Mosaic. A good number of amazing achievements around security for sure.<p>Also, on top of that, you know what happens when Silk touches Fire? It's not pretty.
This sounds like the tips & tricks you see in Pagespeed/Yslow, moving it to a proxy, coupling it with something like SPDY, and mixing in some server side caching. Which is neat, and no doubt will achieve some speedups. But I don't know if it is as revolutionary as Amazon is trying to make it sound.<p>There are also some serious privacy implications here. I don't really know if I want Amazon to cache & potentially record all my browsing, especially since that device is something they can directly connect to all my personal info (purchasing history, CC number, home address, etc..).
As more of us rely on our mobile devices to browse the net, and as this trend picks up, wouldn't this mean that Amazon has a unique vantage point to see what people are searching for, in terms of content, products etc?<p>With each product iteration or rollout, it seems like we are increasingly giving up more than our dollars at the point of sale, like privacy - allowing companies to have complete access to our browsing/spending preferences.
Does it seem like Amazon is solving yesterdays problem instead of the futures? With the speed of CPU's doubling every 18 months and the amount of bandwidth increasing by 50% annually, the accelerating growth of CPU's and bandwidth will leave this sort of client-server architecture behind. It's only a matter of time.
This seems very similar to Opera Turbo (<a href="http://en.wikipedia.org/wiki/Opera_Turbo#Opera_Turbo" rel="nofollow">http://en.wikipedia.org/wiki/Opera_Turbo#Opera_Turbo</a>) - no?
This suggests to me an interesting idea. Lets say you used the CSS media tag to include style sheets for 'e-ink', then if such a style existed you could 'send this to my kindle'. A sort of instapaper meets Kindle Publishing.<p>Amazon could pull something like that off, it would be useful to have a wordpress template that included the e-ink stylesheet.
I'm not a front end developer, but it seems to me that pre-evaluation of javascript, or even compiling the js into byte code, would be something that front end developers would want to try in order to speed up their own users' experience of their site. Is there anything that the cloud part of Silk is doing that can be applied to websites in general, regardless of what browser is doing the rendering? Or is this optimization uniquely possible because Amazon controls the browser itself?
For those of us working on mobile browsers this means a whole new set of implementation quirks we have to deal with even without the server side assist they are including. Even if they choose webkit as the rendering engine god knows what the event system will behave like.
The best news about this in my opinion is that websites can no longer block EC2 IPs if they want to work properly on the Kindle Fire... between this and free inbound bandwidth (now we know why they made that happen in the first place), scraping just got a lot easier.
It would be really interesting if they could integrate some form of parental controls along with this whole caching/prefetching/data crunching process.<p>Say you logged into your Amazon account and set the rating level for content available in Fire and then Amazon's servers would block your kid from accessing freepr0n4all.com. You could add exceptions, specific sites to block, etc. and there would be a known, ever-evolving database of "unsafe" sites by rating.<p>The ability to filter content in a mobile browser isn't something that exists as of yet, I don't believe.<p>If I could do this, I'd buy one for my 9yr old today.<p>Of course, this could then be combined with other tools to "lock down" the fire, e.g. disabling the ability to exit "cloud mode" and thus bypass the filters, password protection for app/movie purchases, like iOS parental controls do, and so on.
So it's OnLive for webpages; putting the client-side on the server-side. Well, half (or a dynamically allocated proportion) anyway.<p>But compositing dozens of network fetches from the same cloud, centrally caching the rest, and predictive pre-fetch are big wins. The endless traipsing back-and-forth is frustrating even on the desktop.
These aren't new ideas, but if Amazon implements them to deliver a better experience, users won't care - and neither will you. A sad truth for pioneers.<p>Also gives Amazon a competitive advantage: host <i>all</i> your stuff with us, users will love you (google's experiments showed that even fraction-of-a-second latency loses users.)<p><i>EDIT</i> but... amazon.com is one of the slowest websites on the internet for me, and I'd expect them to be doing all of the above on their own site...
This Silk browser could be the "killer feature" of the Kindle Fire... something that allows it to really compete in the tablet space. It'll be interesting to really see how well it works in the real world and what the form factor of the Fire feels like.
Advantages:<p>-cheap devices (the fire?) get to see complex websites<p>-server side webgl?<p>-server side java applets?<p>Disadvantages:<p>-you partially browse the web on Amazon's cloud so Amazon can track your behaviour (and your data)<p>-your site is part of an internal network that can only be accessed using a vpn from the outside world? bad luck.<p>-you have to buy a cheap device to see a real pageload speed,considered that you should get your data from amazon anyway<p>-if the world uses ec2 for browsing its performance will probably suffer<p>if you have the ipad you can test a lot of similar apps anyway,like puffin or skyfire,and see if you would like it,I prefer the native browser myself,yet I know that the infrastructure would be better in theory.
A Wordpress blog running a theme from WooThemes. I guess we know we're dealing directly with the developers (but at least they listened to patio11's advice ;-).
I think this may be much more than Operas method. Note that it includes formatting, layout and display. This makes me think they essentially run a clone of the browser on ec2 and could literally swap in the completed Dom, and layout. Or even a a memory diff.
Having a persistent connection would also allow local events (clicks etc) to be sent back to mirror the state as you interact with the page.
Hmmm ... if they can reformat a 3MB JPEG to a 50KB JPEG on-the-fly, then they can also replace the ad that might have been placed on a site by the owner with one of their choosing. It would be interesting to see if there's a difference in click-through rates between Silk's user-agent and a traditional web browser.
SEOmoz have been seeing extreme volatility in EC2 spot pricing - could this have been related to pre-release testing of Silk?<p><a href="http://devblog.seomoz.org/2011/09/amazon-ec2-spot-request-volatility-hits-1000hour/" rel="nofollow">http://devblog.seomoz.org/2011/09/amazon-ec2-spot-request-vo...</a>
"Computing Power in the Cloud<p>EC2 servers have massive computational power. On EC2, available CPU, storage, and available memory can be orders of magnitudes larger than on mobile devices. Silk uses the power and speed of the EC2 server fleet to retrieve all of the components of a website simultaneously, and delivers them to Kindle Fire in a single, fast stream. Transferring computing-intensive tasks to EC2 helps to conserve your Kindle Fire battery life."<p><a href="http://www.amazon.com/gp/product/B0051VVOB2#silk" rel="nofollow">http://www.amazon.com/gp/product/B0051VVOB2#silk</a><p>What does this mean? "Transferring computing-intensive tasks to EC2 helps to conserve your Kindle Fire battery life". Are we offloading javascripting processing to the cloud and returning the results?<p>If so it will be different than Opera Mini.
This seems sort of like CloudFlare built directly into the browser. Essentially, using EC2 as an http optimizing and caching proxy through which requests are routed. They might also geo balance traffic to the closest EC2 region.
Why do you need a car which goes at 300 KM/hr when you drive at 50 KM/hr all the time, and don't have any issue with speed?<p>When it comes to web browsing most of us have very good speed for browsing, then why do we need to speed up the browsing?
Google also has a massive network of distributed servers and a couple browsers. I wonder if they'll start doing this for the Android browser and maybe even as an option for faster browsing on Chome.
Most tablet makers would kill to have this much developer interest. I'm fascinated by Silk and have wasted the better part of the day trying to figure out exactly what they're doing.<p>Here's an independent description of Silk behind the scenes:<p><a href="http://www.webmonkey.com/2011/09/amazons-silk-web-browser-adds-new-twist-to-old-idea/" rel="nofollow">http://www.webmonkey.com/2011/09/amazons-silk-web-browser-ad...</a><p>I am hoping that Amazon gets a developers guide up soon that fills in more of the gaps. Already on EC2 and I want to start experimenting.
While I think the idea is brilliant - do as much precomputation and rendering and content consolidation in the cloud as you can - the strange thing to me is that all this stuff is <i>really</i> mainly a problem for browsing over cell networks while the Fire itself only supports Wifi. It kind of hints to me that there <i>is</i> a 3G Fire coming, they just aren't able to release it yet ...
Does it seem like Amazon is solving yesterdays problem instead of futures? With the speed of CPU's doubling every 18 months and the amount of bandwidth increasing by 50% annually, the accelerating growth of CPU's and bandwidth will leave this sort of client-server architecture behind. It's only a matter of time.
Here is a screenshot from 1:58 in the video: <a href="http://i.imgur.com/jcVOT.png" rel="nofollow">http://i.imgur.com/jcVOT.png</a><p>(If this is any indicator of the actual product), it says that the whole JavaScript processing will be done on the server.
I wonder, in terms of having many connections, could the same thing be done by a HTTP -> SPDY gateway? It saves having a multitude of connections for a single request, and also is more compressed.