“We set out to make this framework easy for developers to get up and running fast, with a minimal learning curve. Less technical folks can configure the framework with just HTML markup, but we maintain the full power of jQuery and a robust event and plugin system under the hood for developers who want to deeply extend the framework. By using tools like PhoneGap, jQuery Mobile code can be transformed into apps to be distributed through all popular app stores.”

Make your own here, it’s easy.

Here are screenshots:

The technical details of the new Silk browser are fascinating. Silk is a custom webkit browser that routes page requests through an Amazon proxy server. Pages get optimized within the proxy server. Information gets cached on EC2 servers to speed up DNS lookups and file downloads such as images, CSS, and JavaScript. EC2 will keep permanent connections open to popular sites like Facebook and Google to reduce latency.

Going still further, Amazon will monitor a user’s web traffic and intelligently pre-load pages on their actual device if it’s likely the user will soon visit that page. And like the Android world (and unlike the crazy world of iOS), Flash is supported.

At the Internet protocol level, the new browser improves performance further through the use of SPDY, short for “speedy”, that was developed by Google to enhance HTTP internet speeds through a combination of compression, optimization, and request prediction.

Quoted verbatim here:

• Now, let’s talk about mobile devices and optimization. There is no mobile version of canvas, there’s just canvas. It’s the same API on desktop and mobile devices. Mobile devices are sometimes missing features, however, and are usually slower; but the same could be true on older desktops and browsers. So whenever you are making a canvas app it’s important to consider performance and different ways to optimize your code.
• The general mantra for performance is draw less.
• Don’t draw hidden things. If you have four screens of information but only one is visible at a time, then don’t draw the others.
• Use images instead of shapes. If you have some graphic that won’t ever change or be scaled, then consider drawing it into an image at compile time using something like photoshop. In general images can be drawn much faster to the screen than vector artwork. This is especially true if you have some graphic that will be repainted over and over again like a sprite in a game.
• Cache using offscreen canvases. You can create new instance of the canvas object at runtime that aren’t visible on screen. You can use these offscreen canvasas as a cache. When your app starts draw graphics into the offscreen canvas then just copy that over and over again to draw it. This gives you the same speed as using images over shapes, but you are generating these images at runtime and could potentially change them if needed.
• Image stretching. Since we are using images for lots of things already, consider stretching them for effects. Most canvas implementations have highly optimized code for scaling and cropping images so it should be quite fast. There are also several versions of drawImage that let you draw subsections of an image. With these apis you can do clever things like caching a bunch of sprites into a single image, or wildly stretching images for funky effects. [screenshots]
• Only redraw the part of the screen you need. Depending on your app it may be possible to just redraw part of the screen. For example, if I have a ball bouncing around I don’t need to erase and redraw the entire background. Instead I just need to redraw where the ball is and where it was on the previous frame. For some apps this could be a huge speedup.
• Draw fewer frames Now that you are drawing as little per frame as possible try to draw fewer frames. To get smooth animation you might want to draw 100fps, but most computers max out at a 60fps screen refresh rate. There’s no point in drawing more frames because the user will never see them. So how do you sync up with the screen refresh? Mozilla and WebKit have experimental apis to request that the browser call your code on the next screen refresh. This will replace your call to setInterval or setTimeout. Now the browser is in charge of giving you a consistent framerate, and it will ensure you don’t go over 60fps. It can also do smart things like lowering the framerate if the user switches to a different tab. Mobile browsers are starting to implement this as well so background apps will be throttled back, saving on battery life.
• The best way to draw less is to not draw it at all. If you have a static background then move it out of canvas and draw it with just an image in the browser. You can make the background of a canvas transparent so that a background image will show through. If you have large images to move around you may find they move faster and smoother by using CSS transitions rather than doing it with javascript in the canvas. In general CSS transitions will be faster because they are implemented in C rather than JS, but your mileage may vary, so test test test. Speaking of which: Chrome and Mozilla have great tools to help you debug and test your JavaScript. [names? examples?]
• Pixel aligned images. One final tip, in some implementations images and shapes will draw faster if they are draw on pixel boundaries. Some tests show a 2 to 3x speedup [verify] on the ipad canvas impl if you pixel align your sprites.  http://jsperf.com/drawimage-whole-pixels http://sebleedelisle.com/2011/02/html5-canvas-sprite-optimisation/

“When we started development on our first title, the first thing as usual was to find our needs and select an engine in accordance to them. After considerable debate, we knew what we really needed was a cross-platform engine for mobile phones which should have solid 3D apis and support as many platforms as possible. This hunt coupled with our naivety as it was our first title, led to us the EdgeLib Engine. Our experiences with it was scarring to say the least, but definitely a huge learning experience which we will leave at that for a post in the future. This made us hunt for a new stronger solution, that we can call our base, our motherland, and that is exactly what we found with Airplay SDK now called Marmalade.”

Marmalade’s strength is in taking iOS games to Android. They allow the use of full-featured C++ and support both Microsoft Visual C++ and Mac XCode.

Marmalade is fully owned by Ideaworks3D Limited. Learn more on their website.

Here’s an excerpt on Viewport:

“When you visit a website not designed for mobile browsers, it first appears very zoomed out. This is done intentionally by the mobile browsers to make the website viewable. They set the default viewport width to between 800 and 980 pixels (depending on the browser). This allows the user to view the whole website and then zoom in as needed. However, if you are crafting a website specifically for mobile, it make sense to set the initial viewport for the mobile device. This is accomplished with the viewport meta tag.”

Read more at EngineYard.

“Of the top 100 sites most visited on the internet5, 71 of them have content specifically designed for mobile devices. The remaining 29 either do not support mobile devices or, depending on the device, prompt the user about a device specific application.”

Contrast this with this Google / Mary Meeker chart of smartphone penetration:

Read the full report from BuiltWith. Read more about Google’s mobile web stats here.

While HTML is a great platform fit for Netflix, it’s not the platform they originally started out with for their device UIs. The initial platform was a mixture of Flash Lite and C++, which Andy characterized as a real integration challenge. They wanted to try a different approach. He explains, “About a year and a half ago, the team sat down and we realized that devices were getting faster quickly. At the same time, WebKit was starting to pick up steam as a great embeddable Web runtime. YouYou combine that with the huge breadth of HTML talent at Netflix, and we saw an opportunity to leverage that talent across all our devices. We decided the time was right to take a dive into the HTML pool.”

The Netflix team realized almost immediately that if they chose HTML for their mobile applications, they’d have to provide their own WebKit runtime to power it. This became apparent as they evaluated using the browser engines third-party device manufacturers provided. “We found that verifying a third-party browser engine against our current and future needs was nearly impossible,” Andy said. And when gaps in such are identified, there’s the issue of cadence to consider. “We’re Web guys. We release new versions nearly every two weeks. Our entire business is based on this flexibility. But device manufacturers work on much longer timelines as they are dealing with hardware. We didn’t want to lose our ability to work rapidly.”

Netflix selected a webkit framework created by QT and built some additional features on top to better handle rapid graphics processing. Then they sent this proprietary webkit version as an SDK to their device partners, and put them through a certification process before they can go live. An exception is Apple, where they had to do their own integration into iOS webkit.

Overall, an impressive HTML5 project.

Financially speaking, Elevation Partners may have made the right decision selling to HP, but for consumers, they clearly sold to the wrong partner.  If Google had picked up WebOS, maybe Android would have a nicer look to it.

I still remember a meeting with the design team at Palm right before they launched WebOS.  It was a spectacular team, picked from all the best companies in Silicon Valley.  Sharp, confident people who knew how to build a mobile interface that really worked for people.  It felt like a product from the early days of Palm, revolutionary user experience.