Charles Engelke’s Blog

May 29, 2012

Fluentconf workshop: Breaking HTML5 Limits on Mobile JavaScript

Filed under: Uncategorized — Charles Engelke @ 3:28 pm
Tags: , , ,

O’Reilly’s Fluent Conference starts today with optional workshops. My morning selection is on JavaScript on mobile platforms, given by Maximiliano Firtman of ITMaster Professional Training. This post is just a stream-of-consciousness list of points I want to remember, rather than real notes for the talk.

In his introduction, he points to a resource on available APIs: www.mobilehtml5.org.

Mobile web development is different:

  • Slower networks
  • Different browsing (touch versus mouse, pinch to zoom, pop-up keyboard, etc.)
  • Different behavior (only current tab is running, file uploads and downloads)
  • Some browsers are proxy based (Kindle Fire, Opera Mini)
  • too many browsers (more than 40), some too limited, some too innovative, mostly without documentation, mostly unnamed, most without debugging tools
  • Four big rendering engines, five big execution engines

Check gs.statcounter.com for browser market shares. Much more even distributed among top seven dozen browsers.

Web views embed an HTML window in a native app. On iOS, web views have a different execution engine than the browser (2.5 times slower!). They often have differences in how they support HTML5 APIs.

Pseudo-browsers (his term) are native apps with a web view inside. They you don’t get a new rendering engine or execution engine, you just get new behaviors added by the native shell it is wrapped in. (Yahoo Axis, for example)

(Note to me: he’s using IPEVO P2V for Point2View cameras showing a mobile phone on a camera.)

Phonegap and similar tools for creating native apps use web tools but are native.

Remote debugging is available for some browsers with Remote Web Inspector. Adobe Shadow is a new debugging tool that’s free (at least, for now). Weinre can work with Chrome, making iPhone remotely debuggable. Looks pretty interesting.

Paper Who Killed My Battery from WWW2012 shows how different web sites consume power from your device’s battery. For example, 17% of the energy used to look at Amazon’s web site is for parsing JavaScript that isn’t ever used.

The speaker has a neat development tool he calls Chevron for working inside the browser, available at firt.mobi/material/FluentConf.zip. It has an in-browser code editor, and can save on-line to a unique URL. It will display a QR-code for that URL, so you can see what you’re developing on your mobile device as well as the built-in browser window. Very nice.

A service at www.blaze.io/mobile will run your public web page on a real device of your choice, and give you performance metrics on it.

You can build a real app (even offline) in the browser with HTML5, but it doesn’t look native on a mobile device. But (for Apple and maybe others) you can get it a lot closer with some meta tags:

<meta name="apple-mobile-web-app-capable" content="yes">
<meta name="apple-mobile-web-app-status-bar-style" content="black">
<link rel="apple-touch-startup-image" href="launch.png">

A lot of the second half of this talk is more on HTML5 in general (when it works in mobile browsers, too) than specific mobile issues. Most of the audience is finding this very useful, but it’s not new to me. Unfortunately, it doesn’t seem that he’s going to get to the Device Interaction part of his demonstrations, which I would really like to see. I can always fiddle with them myself later, I guess. But he’s a good speaker and I’d like to hear him talk about them.

You can use the orientationchange event (onorientationchange property) to run code when the device moves between portrait and landscape views. You can also check for going on and off-line with the online event (though this is not generally reliable).

Ah, he’s getting to Device Interaction! Geolocation first, which is neat but has been available for a while. But then a lot of really new capabilities, some of which only run on one or two browsers now. I need to start using Firefox on my Android phone.

A very useful talk and good kickoff to the conference for me.

February 16, 2011

IE9 and Web Apps

Filed under: Uncategorized — Charles Engelke @ 12:15 pm
Tags: , , ,

Yesterday, Paul Rouget, a Mozilla tech evangelist, wrote a blog entry stating that IE 9 is not a “modern browser”.  Not long after that, Ed Bott tweeted that the post was “surprisingly shrill”.  Several folks (including me) responded that the post made important points, and Bott asked for specific examples of real web sites that used the HTML5 features that IE9 is missing.  (I’m using “HTML5″ to refer not only to the language itself, but also to the new APIs related to it.)

That’s hard to do, especially in a tweet.  If the most widely used web browser doesn’t support these features, even in its upcoming newest release, how many mainstream sites can use them?  They’ve been added to the HTML5 spec because there are strong use cases for them, and when users have browsers that support them sites can start taking advantage of them.  Of course, there are some sites that use these features, but Bott specifically said he didn’t want to hear about pilots or demos, which excludes a lot of them.

There’s a chicken and egg problem here.  We can’t make heavy use of HTML5 features in web sites unless web browsers support them, and Ed Bott seems to be saying that the upcoming version of IE9 doesn’t need to support them because they aren’t yet widely used.  That kind of problem is part of what stalled HTML and browser advances ten years ago.  The WHAT WG didn’t accept that, and pushed for what became HTML5.  I think that Google was a major help because it had the resources to improve browsers (first with the non-standard Gears plug-in, later with their standards-based Chrome web browser) in order to be able to develop more sophisticated web applications.  Their experimental ChromeOS devices like the CR-48 show that Google is still very interested in the idea that the browser can be an application platform, not just a viewer of web sites.

For me, IE9 is most disappointing because it fails to implement many key HTML5 features that are essential to building good web apps.  (I use “web apps” to mean platform independent applications that live and run inside a modern browser, including many mobile browsers.)  Yes, IE9 makes a lot of advances and I appreciate them all, but some of what it leaves out is essential and does not seem nearly as hard to implement as some of what they included.  Consider some use cases that I actually encounter.

In a traditional web browser no data persists in the browser between separate visits to a web page.  If I want to start working on something in my web browser and then finish it later, the browser has to send it to a server to remember it, and when I revisit the page in the future it has to fetch that information back from the server.  But what if I don’t want to disclose that information to the server yet?  Maybe I’m preparing a tax form, and I don’t want to give a third party a history of all the changes I’m making as I fill it out, I just want to submit the final filled-out form?  In a traditional web browser I can only do that if I perform all the work during a single page visit.

If only the browser could store the data I enter within the browser, so I could come back and work on the form over multiple visits without ever disclosing my work in progress.  Actually, HTML5 (and related technologies) lets you do that.  Web storage (including local storage and session storage), indexed database, and the file system API can each meet that need.  (So can web SQL databases, but that approach will likely not be in any final standard.)  Of these solutions, only web storage is widely available today.  It’s on all major current browsers, including IE8 and IE9.  Good for IE.

Now, suppose I want to work on my tax form and I don’t have an internet connection.  The data I need is in my browser, so shouldn’t I be able to do this?  If my web browser supports application cache, I can.  Every major web browser supports this, and most have for the last several versions of them.  Except for IE.  Not only does IE8 fail to support this, so does IE9.  If I try to work on my tax form in IE9 I’ll just get an error message that the page is unavailable.  Even though all the functionality of my tax form program lives inside the web browser I can’t get to it unless the server is reachable.  That’s a problem for an app.  This is my biggest disappointment with IE9, especially since application cache seems like a pretty easy extension of the caching all web browsers, including IE, already do.

But you might ask, so what?  This is a web app, and it’s not that big a problem if it only works when the server can be reached.  After all, it’s going to have to talk to that server sooner or later in order to submit the tax form.  But let’s switch to a different use case.  Suppose I want to do some photo editing.  The HTML5 canvas API gives me a lot of ways to do that.  I gave some talks last summer on HTML5 techniques and built an application that could resize photos and convert color photos to black and white or sepia toned.  The whole example took less than an hour to do.  This is an application that doesn’t need to ever talk to a server except for the initial installation.  It’s something that I could use on my machine with any modern web browser, so I can write it once and use it everywhere.  There are two big challenges for this application, though: getting photos into the code in my browser, and then getting the edited photos back out.

There’s no way to do that in an old-fashioned web browser.  If I’ve got a binary file on my PC and want to get it to the code in the browser, I have to use a form to upload that file to a server.  My browser code can then fetch it back from the server.  It goes through the browser to get to the server, but is inaccessible to code running inside the browser.  With the HTML5 File API, I no longer have that restriction.  I can select a file with a form and the code in the browser can directly read that file instead of sending it to the server.  That’s how I get a photo into my application.  Every current major browser supports the File API except for IE and Opera.  And Opera might add it in their next version (they haven’t said), but IE9 won’t have it.

Once I’ve edited the photo I need to get it back out.  What I need is either an img element (so the user can right-click and choose to save the image) or a simple link that user can click to download the image.  The problem here is that for either of these methods to work, the photo has to be in a resource with a URL.  How do I get it there?  In an old fashioned web browser, the code in the browser would send it to a server, which would save it and make it accessible at some specific URL.  Once again, my browser ends up having to send something to a server so that the browser code and browser user can share something.  With a Data URL, I can create a resource with a URL inside the browser so that no server is needed.  Data URLs are a lot older than HTML5 and have been supported in all major browsers.  However, until recently IE limited their size so much as to make them not very useful.  IE9 does allow large Data URLs, though.  Again, good for IE9.

So, for these use cases we need four key technologies: persistent storage in the browser, offline access, reading files, and creating resources and URLs for them in the browser.  Every modern web browser supports all of them (assuming the next version of Opera adds the File API).  IE9 supports only half of them, and can’t serve either use case.

That’s one reason we should not consider IE9 to be a “modern browser”.

The Rubric Theme. Blog at WordPress.com.

Follow

Get every new post delivered to your Inbox.

Join 44 other followers