Web Vs Native at State of the Browser 2

(via Steve Workman)

I was at State of the Browser 2 yesterday, an event comprising reps from the browsers. I’m happy to be part of this event as I think it’s valuable for the web as a whole for devrels to get together with developers in this way. The browsers do spend a lot of time talking to each other about specs etc in meetings and mailing lists, but at State of the Browser, they’re facing the developers. So straight up, thanks to the organisers for doing a great job running this great event again.

Thankyou for the sketchnotes UBelly :)

Slides for my keynote talk on Web vs Native are here. I’ll highlight the four challenges of the web which

In order of increasing threat, I mentioned:

  • UI Low threat. A lot of the capabilities are already in place and we can already do decent UIs if not “gorgeous”/”sexy” like Path or Paper.

  • Offline Medium threat. DHH wrote his famous You’re Not on a Plane argument in the desktop era. Mobile is way important these days, connectivity remains sketchy, and 3G is expensive for many. The pure offline scenario may matter less, at least for many people in developed nations, but latency matters a lot to everyone. HTML5 does have offline technologies, but browser support is extremely fragmented and there are many debates about what to use where.

  • Device Integration Medium threat. Web needs permissioned access to camera, contacts, etc. But my bigger concern is peripheral aspects like single sign-on, notifications, Android intents. These things, for the most part, are not possible in web apps. There are signs that’s changing as the speakers yesterday highlighted, e.g. Chrome’s adding Web Intents, IE’s adding native notifications like the OSX native notifications I mentioned. But it’s really early days, and I don’t see anyone talking about single sign-on for web apps, which is hugely concerning considering how personal in nature smartphones and native apps are.

  • Background Processing High threat. This doesn’t get much play, but is something I’ve been thinking about since writing this and listening to the related Jason Grigsby podcast. With modern smartphone apps, we see the long-anticipated trend of software that acts as intelligent agents. An app is not just something you open, interact with, and close. Through its smartphone vehicle, the app serves as an extra brain, extra set of eyes and ears, extra communication agent. With you at all times, proactively scanning the environment for anything useful. Sucking down content and syncing with servers. Notifying you when anything particular important happens. Web apps are shut out of this game. They are useful as long as the user is looking at them. Out of sight, out of mind. Or more generously, as long as they are still open in a tab, but they may have restricted functionality in mobile background tabs to preserve battery life. Chrome has done some work here with background apps, but it’s really early days and I don’t see anyone thinking about this problem in mobile space.

I also mentioned monetization and competing standards as additional threats, only reason I didn’t cover them in detail is time. I did mention a little of it in the recent bonus HNPod episode on HTML5 vs Native and we had a Twitter conversation about it yesterday.

Remy blogged all the morning talks and raised some questions about each.

Is the point: browsers don’t matter – the web does…?

The underlying assumption is that the web matters more than any individual browser.

Should the browser just be the webview?

No. Browsers add a lot of value beyond the web view. One of many examples is customisation via preferences and extensions.

“You’re not on a fucking plane” – but then do all devs know how to build apps like gmail where it’s insanely quick because they know how to work the mobile device?

Agree. It’s hard right now. And even harder if you wish to use the same core app for both online and offline (as well as desktop and mobile).

AppCache is not a replicatement (sic.) for localStorage – far from it.

Definitely not.

Is there a larger problem that the browser (and a pro) exposes data if the user wants to get to it. It makes SSO harder because of security, etc?

Yes, but just like camera access, geolocation, etc, you can handle it with permissions. If HTML5 doesn’t stay competitive with native on SSO, background apps, etc, it’s not going to be a modern platform for apps. There’s enough UI widgets already, it’s these peripheral aspects — those where security is an issue — where native is surging ahead. You can either do basic websites without app-iness or you can do apps which use the full range of possibilities available in a modern device and operating system.

Web vs. Native seems like two issues: browser and the web. Browsers being the limitation

Both as we’d want web standards too for whatever the browsers offer developers. But definitely down to the browsers and possibly the OSs when you consider SSO for example.

The panel I moderated. Devrels from four browsers and the forbidden fruit. (via james_smith88)

The Non-Visual Web

Looking Forward

7 years on from Ajax, we have our JavaScript-fu down and the APIs we could ever have dreamt of are baked into the desktop browsers of note. So what’s next for the web? The latest 5×5 podcast with Jason Grigsby is illuminating on future trends (as well as being a must-listen for all its practical advice):

Episode Homepage

Here I want to outline a few specific features which will challenge the boundaries of the web as we know it. And then I’ll explain how the web community can meet those challenges.

Tip of the Iceberg

In 2009, I gave a talk at London Web Standards on eight features of HTML5 you won’t see, features such as offline storage, geolocation, and history API.

That’s the tip of the iceberg of the tip of the iceberg. An example in this podcast is walking down the street and having your phone’s navigation system vibrate once if you should turn left, twice if you turn right. Another example mentioned in the podcast is a JavaScript vehicle API! webinos.vehicle.addEventListener (webinos.vehicle.NavigationEvent.DESTINATION_REACHED, handleDestinations, false); Checking fuel level, engine condition, etc. via a high-level API. And of course, there’s the whole medium of sound…this post was kicked off by a podcast after all!

The web has traditionally been a visual medium. As Jen Simmons observes here, even when it’s not visual, we use the word “Screen Reader” to emphasise its visual foundations. While it’s moved from text to images to fancy graphics and multimedia, those things are still visual elements on the page. Yet all of the above are not about elements on the page. That’s where technology is headed. So is it even sensible to handle these things through the web?

Model-View Separation

On a technical level, what makes the web incredibly powerful is the DOM concept. DOM is sync’d to UI. Update the DOM and it changes the user-interface. Change the UI and the DOM updates. The programmer doesn’t have to facilitate this bidirectional sync; it just happens.

Really, on a technical level, this is an incredibly important and overlooked aspect of HTML5. Too many HTML5 APIs are pure JavaScript functions and ignore the DOM altogether. For the web to thrive, vehicle APIs should not just be webinos.vehicle.addEventListener. The vehicle itself should be part of the DOM. If that sounds too domain-specific, that’s okay, because look at the work of Web Components. These guys are bringing about a world where anyone, or any community, can create a first-class <x-vehicle> element with its own look-and-feel.

Open Standards

Of course, at a higher level, the web is about open standards. That’s really what sets it apart from iOS, Android, and .Net. There’s no single vendor in charge. Something like the Java Virtual Machine comes close, but the web stack stands out as a more balanced control system. If there are to be standards for things like vehicle APIs, the web is attractive as the best stab at a neutral ground with real developer buy-in.

For this reason, the web can successfully move beyond the visual medium without losing what makes it the web in the first place.

“A” is for Asynchronous, Again.

Here’s an infographic I made for my QCon talk this week, Single Page Apps and the Future of History:

I think it sums up a key point about Ajax, which is sometimes overlooked: Asynchrony. One of my first posts on Ajax, back in 2005, covered it, but it still took years to really sink in. At the time, I was thinking mostly of “Asynchronous” as XHR’s asynchronous mode, so seeing it in contrast to running XHR synchronously. But really, the big deal about Ajax is the UI can carry on, while networking happens in the background. That’s what makes filling out forms faster and what makes tools like Google Docs possible, especially in multi-user mode.

Letters from a Gaming Newbie

I was pleased to attend Casual Connect this week and talked about how HTML5 is becoming viable for games development, alongside my colleague Mark, who covered the Chrome Web Store in general. I was definitively there in a purely web geek capacity, as gaming is not an industry I’m very familiar with. So here are a few things I learned:

  • Casual gaming is quite distinct from “hardcore” gaming. (as @Eastmad reminded me on Twitter.)
  • Casual gaming is heavily intertwined with “social” gaming these days – games on Facebook et al.
  • The social network is just “the graph”. At least for some games, they’re architected to separate “the graph” from the core game logic, so you can swap in and out different social networks. The graph is of course essential for gameplay with social games as well as viral adoption.
  • The industry is mature – there is a clear ecosystem of companies with different roles. Studios make games, publishers distribute them, portals aggregate them, social networks provide the graph. And then there are ad networks, analytics, hosts/caches, development tools, virtual currency providers, consultants. (Very cool seeing how any vertical quickly evolves into a distinct industry structure. Adam Smith approves.)
  • The industry is sophisticated. There is a big aspect of number-crunching, analytics-driven, thinking, e.g. pinning down the cost of customer acquisition. There’s a feeling that monetization is the best growth opportunity right now, more so than increasing the number of players. 1-2% of people spend, whereas with Massive Multiplayer Online games and in Asian markets, 5-10% is more common.
  • Trends to watch: Streaming games (Gaikai, Onlive) – It’s amazing it actually works, but these are technologies that treat the user’s computer/browser as a dumb terminal and stream the game’s video down to them; location based games, merging real and virtual worlds; embedding games into the fabric of the web (e.g. through widgets etc), so they’re not just isolated in social network sites and dedicated game portals; combining genres, so that hardcore gamers can interact with their casual gamer friends; using multiple channels in clever ways, rather than just porting the same game to ten different platforms.

Using BrowserScope to Detect Geolocation Support

About Browserscope

Browserscope is a very cool tool coming out of Steve Souders’ performance efforts and being developed by Steve along with Lindsey Simon. It’s part of a trend towards crowdsourcing browser info, in similar vein to TestSwarm, for testing specific code, and along the lines of what I did with WebWait, which is to support multiple people benchmarking a website at once. (Though I’ve not set up reporting on it – one day…)

So anyway, Browserscope began life as a way to benchmark just performance, but is now a general-purpose tool for crowdsourcing tests about anything browsers do, e.g. checking for security vulnerabilities is one vital application. HTML5 does not miss out – HTML5Test.com has been ported over too – see beta.html5test.com.

Geolocation Test

I decided to make my own test recently, to see what extent Geolocation is being supported by the browsers. Run the test against your browser here (it will upload only information about whether geo is supported, not your actual geolocation data):

http://test.mahemoff.com/geo.html

The results so far indicate browsers either don’t support it, or support accuracy+lat+lon. I was hoping to see at least direction, and would <3 to see altitude! But it will have to wait.

How to Make your Own Browserscope Test

If you ever wanted to know how every browser under the sun handles a particular something, Browserscope is your new hotness. It makes it trivial. Register with Browserscope to get the boilerplate code. Then you just write an app that does the exercises and builds up a hashmap of the info you want to collect, and BAM, submit it. The hashmap should have values between 1 and 1000. Do that, and you’ll end up with a nice summary page showing your test results aggregated across all browsers that ran them.

The submission is taken care of by some boilerplate code – it uses on-demand Javascript to pass the data back to the third-party BrowserScope domain (you host the test yourself). Aside from writing the actual test and promoting its location, the only thing you have to do is make a nice UI to show the users what you just did, and perhaps get their consent before uploading. I think those are actually two things Browserscope could automate too, at least providing a nice default UI which test creators can customise.

Another HTML5 Tidbit: Web SQL Database

I coded up a small demo of Web SQL Database. As the demo points out, notice you can hit reload and the data remains, being that it’s one of the several techniques for offline storage.

There’s not much to say about Web SQL – you either know SQL already, in which case it’s fairly straightforward and just a matter of squeezing your SQL calls into the conventions of the API, like any other SQL framework as, lamentably, there’s never been any kind of standardisation on the wrappers that go around SQL – or you don’t know SQL, in which case there’s your bottleneck child if you intend to use Web SQL Database for offline storage.

Web SQL Database lies at the other end of the complexity spectrum from Web Storage (aka localStorage and sessionStorage), which is simply a big ol’ hashmap for your domain. The complexity is fairly manageable, though, as there’s literally a generation of SQL know-how out there, and hopefully ActiveRecord-like libraries on their way.

IndexedDB promises to offer a third way – more like the hashmap approach, but with some of the indexing-based performance gains SQL has to offer. No browsers have implemented it yet, though you can build an experimental windows version using a third-party Firebreath implementation.

Upcoming: UXCampEurope and SWDC

Google I/O is over and I’ll post a bit about the HTML5 hack session I ran later, but here I want to highlight a couple of upcoming sessions in Europe:

UXCampEurope. If this is anything like the Bay Area and London UX camps I’ve been fortunate to attend, it will be huge, and being Europe-wide and in Berlin, this expectation might just be met. I was sitting on the browser along with @mattlucht hitting refresh 10 times a second when the tickets were released at the start of the year! I’ll set up a slot called “What did HTML5 ever do for users, anyway?”. I’m planning to overview some of the features of HTML5 and its evolution from Ajax, and ask how it might be used to improve UX. It’s a camp, so I’ll also be hoping to collect contributions and writing them up somewhere.

SWDC. The first Scandinavian Web Developer Conference and Peter Svensson is organising, so I know it will be an awesome event, and the sessions speak for themselves. I’ve bumped into the guy twice in the past month – he travelled from Stockholm to DC for JSConf, and again to SF for I/O. My session is on the mobile day, called “HTML5 Gives You Wings”, focusing on HTML5 techniques for performance and app-like behaviour. Here’s the summary:

Welcome to the dynamic world of mobile development, where new browsers stay close to the edge and HTML5 is already a reality. Despite the impressive advances, many mobile apps are still bottlenecked by the network and compact processors continue to lag behind their desktop counterparts. So how can HTML5 help? This talk will focus on those features of HTML5 that are interesting for performance optimisation and the techniques for emulating native apps, such as offline data storage.

Offline Apps with Application Cache: Quickstart, Tips, and Deep Dive

I’ve been mucking with AppCache, aka ApplicationCache. It’s the secret sauce that lets you build offline apps, which is great for performance and fabulous for pretending to be an iPhone app when you’re not.

Quickstart an Offline App

As with most HTML5 technologies, the basic usage is quite simple:

  1. Create a trivial trio of HTML, CSS, and JS files, maybe with an image or two. (Or reuse an existing toy app.)
  2. Link to a “cache manifest” file from your HTML file’s html tag like so:
    1. <html manifest="clock.manifest">
  3. Make the manifest file. It’s just the literal phrase “CACHE MANIFEST” on the top line (I know, bit random), followed by the list of files in your app:
    CACHE MANIFEST
    clock.html
    clock.css
    clock.js
    clock.png
    
  4. Mark it as MIME type text/cache-manifest. If you’re SSHing to a virtual host (like I did with Dreamhost), all you need here is a one-line .htaccess file:
    AddType text/cache-manifest manifest
    

That’s it. Now those files above will be cached locally and won’t need to be downloaded again next time. To test it, load the site, shut down your net connection, and reload. It’s still there innit.

It works the same on your app-phone – on iPhone or Android (or others maybe), load the site, switch to airport mode, go back to the browser and reload … the site’s still there. Where it gets really fun is making it into a regular app:

  • On iPhone, bookmark the site with the Safari “+” button, choose “Add to Home Screen”, and the app will be sitting alongside all your other apps on the home screen.
  • On Android, bookmark the app in the browser. Hold your finger down somewhere empty on the home screen, choose add “Shortcuts” | “Bookmark”, and choose the bookmark you’ve made.

You could do the same with any website of course, but it’s particularly cool when the website is an offline one…it works just like a regular app!

Practical Tips and Troubleshooting

Purging the Cache

In practical terms, you are quickly going to come up the no. 1 problem of developing against a cache. How do you purge it whenever you update your code?

Simple. You only need to make an arbitrary change to the cache manifest file, so just include a version number in the comment:

CACHE MANIFEST

v1

clock.html clock.css clock.js clock.png

Keep revving it up every time you change any file, because changing those files alone won’t have any effect. And if it’s getting serious, you’ll want to practice the principles of DRY and continuous integration by automating this process.

Ridding yourself of Errors

An unfortunate thing happens when there’s a downloading error: The whole thing silently fails. Until debugging tools get better, if you find your app’s not updating, you ought to check each of the resources specified in the manifest really, really, carefully.

Cached Resources

Cache manifests are not exempt from standard caching rules, so the manifest itself, as well as other files might be cached. Pain. A good solution is to use the following Apache directives to .htaccess:

ExpiresActive On
ExpiresDefault

That MIME Type

Things might fail if the Cache Manifest MIME type is wrong, so use your browser’s debugging tools or a service like Web Sniffer to check it (thanks CSS Ninja).

The Wording

The wording can also trip you up. Be really sure it’s exactly “CACHE MANIFEST” at the start of the file. Again, better debugging tools in the future will help here.

The Fancy Stuff

All of the above is enough to get up and running with an offline app, and maintaining it too. But wait, there’s complexity too!

Fine Control Over What Gets Cached

The cache manifest file actually allows three kinds of resources:

  • Online resources that can be cached (CACHED). As shown in the example above, it’s the stuff that’s available for caching.
  • “Fallback” resources in case a file isn’t cached (FALLBACK). These are like catch-all email addresses; any resource that’s not cached, is a candidate for a fallback. There’s a pattern-matching algorithm to map resources (which mightn’t have been cached) to other resources (which hopefully have been cached). For example, you probably wouldn’t cache every wikipedia article, so the fallback section would ensure a special “offline.html” page is shown for those missing articles.
  • Online-only resources (NETWORK) Resources which should never be cached, e.g. it would be a good idea not to cache stock prices if people were making million-dollar decisions on the back of what they see on your possibly-cached web application.

The syntax (adapted from the WHATWG example):

CACHE MANIFEST

a comment

v37

(version number unnecessary

but recommended for cache purposes)

the following "CACHE:" is optional;

a special case because top of file

is cache by default

CACHE:

images/sound-icon.png images/background.png

note that each file has to be put on its own line

FALLBACK: / /sorry-i-am-offline.html

NETWORK: /stocks/*

Checking if We’re Online

window.navigator.onLine … try it now in your console (and try it again with your connection off).

Monitoring State and State Changes

What do you notice about all the app cache stuff above? It’s all declarative, no Javascript. But you can go on to do extra stuff with Javascript too, via the Application Cache API. (I am somewhat skeptical about the applications for this API, since simple and declarative is the way to go for something as potentially hairy as offline…but that’s for another rant.)

The window is effective tied one-to-one to the cache object, so you can just access the cache with window.applicationCache. For example, you can get cache state with window.applicationCache.status, try it now in your console. It will probably be zero…the possible values range from 0 to 5, representing: UNCACHED, IDLE CHECKING, DOWNLOADING, UPDATEREADY, OBSOLETE. (These constants are also available on the cache object, i.e. window.applicationCache.UNCACHED is 0.)

There are also event handlers to monitor event state: onchecking, onerror, onnoupdate, ondownloading, onprogress, onupdateready, oncached, onobsolete.

Forcing Updates

applicationCache.update() will force an update, i.e. start downloading the application again if the manifest has changed. However, it won’t suddenly switch over after downloading. To do so would be to pull the rug from under your live, running, application. It will be there next time. But if you do want it right away, use applicationCache.swapCache().

Offline Mobile Apps: It’s More than Application Cache

Application cache certainly is a critical feature of mobile apps; it’s a basic user expectation that a mobile app starts right away, unlike a complex web app which must be downloaded. However, there are other things too. For example, offline storage. That’s another feature of HTML5, comes in many incaranations, and something for another day. The other really big deal is the UI. Of course, you need to simulate certain UI features of the native apps if you want your web app to go native. Hence, libraries like IUI, jQTouch, and Apple’s secret PastryKit. On the input side, your UI must also handle touch events, something some of the aformentioned brand of libraries will support. Finally, there will be specific features of the platform that can help; for example, setting the home screen icon and going full-screen so the browser chrome doesn’t show up.

HTML5 is a Brand

HTML5 has conflicting definitions.

If you go by the official WHAT-WG spec, HTML5 is a list of specific features, including Canvas, Video, Audio, the new form controls, the new semantic markups, and microdata.

If you go by the media and Steve Jobs, HTML5 is simply a new platform that lets us do rich, interactive, applications without the need for the desktop, or browser plugins. This definition implies a superset of the WHAT-WG HTML5 features. As the HTML5 spec notes, the following are frequently confused as being part of HTML5:

  • Web Workers
  • Web Storage
  • WebSocket API
  • WebSocket protocol
  • Server-sent Events
  • Web SQL Database
  • Geolocation API
  • SVG
  • MathML
  • XMLHttpRequest

The spec says it’s the media who confuse those items; I’d say it’s just about everyone who doesn’t read Last Week In HTML5 (NSFW) religiously, i.e. most people. Furthermore, I would add the following delicious ingredients to the HTML5 mix:

  • CSS 3
  • ECMAScript 5

And now that we’re getting real, as far as most people are concerned, HTML5 is about what the technologies do for end-users. So I’ll add the following, which all have an impact on programmer productivity and hence indirectly improve the user experience by making development more agile and effective:

  • Javascript libraries and frameworks
  • Web Development Tooling
  • Web Development Theory (guidelines, principles, hacks, “browser physics”, patterns)

And I’ll also add the containers in which web apps run, where features such as add-ons and improved security are also making things more splendid for users:

  • Browsers
  • App wrappers (PhoneGap, Titanium, Air)
  • Operating Systems (WebOS, ChromeOS, Yahoo! TV widgets, Web Widgets

And in addition, there are the anticipated features, which the HTML5 spec says will come with a later version, but are still considered by many to be the promise of HTML5:

  • Device APIs (microphone, webcams – these can’t come sooner!)
  • Ping attribute

If you want, you can stick your head in the sand and declare “HTML5 is the limited subset of technologies addressed in the WHAT-WG specification”. However, the ship has already set sail and thanks to the ongoing Apple vs Adobe saga, HTML5 has been deeply etched into the fabric of the industry as “the technology that makes rich web applications”. HTML5 is now a brand referring to all of the things mentioned above. Better get used to it.

WebWait Updated

One of the projects I wanted to work on in my time off was WebWait.

It finally does what I wanted it to do all along: Permanently record benchmarks. You can get a unique URL for each benchmarking session you run by hitting Save. Funny – WebWait was running as a Rails app for several years, but was always a pure browser-side client until I finally completed this. (Ultimately, I didn’t use Rails anyway – see below.)

Some other enhancements too …

  • Bar charts (using the Google Charts API):

  • Expanded dashboard, showing a box for each site you’ve trialled. (Previously, there was only one box ever shown, the latest one. Since people like taking screenshots of these, I figured it would be cool to include multiple boxes.)

  • There is also a JSON view of the trials that were recorded.

It would be cool to expand it further, for example allowing pages to be cross-linked when they benchmark the same trial. But I’ll leave it here and see where demand takes it.

The new WebWait server is powered by the incredibly productive trio of Ruby, Sinatra, and TokyoCabinet. On the browser, it’s still jQuery, with the DataTables plugin and my own jQuery iFrame plugin. Hosted on SliceHost (where I have now happily migrated many things.)