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)

Marcin Wichary: You Gotta Do What You gotta Do [Full Frontal Live Blog]

Marcin explains the hacks that went into the Atari 2600, moving from a crappy “tennis” game in 1978 to a somewhat less-crappy Pitfall in 1982, doing things the Atari architects never anticipated. (Covered in “Racing the Beam”) Which would be the same if you showed 1990 TBL the web today.

Google Doodles have gotten bigger over the years … lines of code: 2009: 1, 2010: 5000, 2011: 13000 (thx @suhajdab)

Marcin shows various iterations of the underwater doodle:

On the theme of pragmatism, it went through a bunch of iterations, to get to the point where people would know they can control the water flow, ultimately leading to an explicit handle control. And degrades gracefully to IE6 (choppy, but works) and no-JavaScript (nice image).

We haven’t gone beyond the IE6 graceful degradation…we still have this in HTML5, so it’s not going to go away. WebSocket keeps changing, different audio support, etc. Which means you sometimes have to do what it takes.

Rality of JavaScript is if you don’t do anything that feels a bit nasty, you’re a bit behind. So you have to embrace some of these nasty hacks. With doodles, the endpoint is about doing something with a sense of purpose, not being infatuated with the technology, or, for that matter, the art.

Nicholas Zakas: Scalable Web Architecture [Full Frontal Live Blog]

Nicholas Zakas is talking about scalable JS architecture.

He begins with a straw poll. Turns out half of the Full Frontal room is working on a Single Page App, right now.

Framework != Library. jQuery? Not a framework. It’s a library you call to perform some limited functionality.

What’s a “module”? Very overloaded term, but Nicholas wants us to think about a module as a block of HTML, CSS, and JavaScript together. Like a widget on the Yahoo! homepage. Modules should be loosely coupled, and this can be achieved with the modules living in a sandbox.

Nicholas identifies a layered architecture, where an application core mediates between independent modules, which use a base library (jQuery etc).

Think of modules as little kids – they can do lots of cool stuff, but need strict supervision: * Hands to yourself (limiting what they can access) * Ask, don’t take * Don’t leave your toys around * Don’t talk to strangers

The Application core manages module lifecycles and mediates between them. There’s also an error handling role, and Nicholas gave a talk about this previously: JS Error Handling.

People are usually too coupled to their base libraries, like jQuery. As Joe Smarr pointed out in a 2007 talk, you’re better off using them as scaffolding, and building modules around them.

img

Jeremy Ashkenas: CoffeeScript [Full Frontal 2011 Live Blog]

Live blogging at Full Frontal 2011, where Jeremy Ashkenas is first up, presenting on CoffeScript.

Motivation

Good work is being done inside and outside of the TC39 committee. The next version of JavaScript is an open process, a working mailing list you can get involved with, and there’s a chance to experiment and shape it.

“It’s just JavaScript”: CoffeeScript is not about creating a new language or letting us apply an existing language in a browser.

Bootstrapping

Original version of CoffeeScript was written in Ruby, but as v0.5, it became significant enough to bootstrap it: Ruby builds an initial CoffeeScript compiler, which then compiles the real CoffeeScript compiler. Slightly more complicated, but you get the idea: CoffeeScript is basically written in CoffeeScript.

Language Features

  • No “var”
  • No “function”
  • Significant whitespace
  • Comprehensions:

    1. for stooge in list
    2.     console.log 'hi ' + stooge

  • Block strings and interpolation (works for regex’s too):

    1. """
    2. An old pond
    3. a #{animal} jumps in
    4. the sound of water
    5. """

  • Object-oriented, and unlike normal prototype stuff, you get to call super.
  • Binding “this” to the actual object with =>

How it happens

Instead of waiting for a standards body or a browser to give you the language, you can roll your own today. CoffeeScript uses Jison for parsing, there’s also Pegs if you prefer. A nice tip is “it’s okay to cheat”! CoffeeScript uses a strict tokeniser to disambiguate, making the parsing much easier than if it allowed all sorts of ambiguities.

Live Blog: PPK on the Future of the Mobile Web

This comes from a talk on mobile web given by PPK the last time I was in this part of the world, before a full house at the very large eBay/PayPal “town hall” in San Jose on April 6. I decided to hold off posting it as he mentioned he’s not releasing the slides so he can deliver the same talk a few more times. With two imminent talks on mobile HTML5 today at Google IO, timing is right to hit the Publish button.

This is still a live blog (I’m far too lazy to edit such things even after the event), so usual typo etc caveats apply.

(>Picture from a different event on the same topic…but how could I not include this one?)

Amid a frenzy of mobile HTML5 hacking at the HQ, I spot a tweet from the veritable @dalmaer:

@AndreCharland come to the @PPK meetup tonight! A bunch of folks are going :) less than a minute ago via Twitter for Mac Favorite Retweet Reply


I’m in the area and not going to let the opportunity pass. So here I am.

PPK, Quirks man that he is, explains that the mobile web is more exciting than desktop these days. Twenty browsers and counting! But beyond the proliferation of browsers to pore into, mobile matters. Eventually around five times the number of desktop users in PPK’s estimate.

Luke Wroblewski invented the “Mobile First” mantra. The mobile constraint forces you to design lean. Even a big screen is 480*360…that’s what you get to deal with, and any fluff sends them right to your competitor. Consider a news site. All you see is headlines. Funny about that, it’s all you really need.

On Mobile Browsers

PPK lists a plethora of mobile browsers and asks, “Do you have to test on each of these?”. Answer: “In theory, yes. In practice, don’t be silly.” PPK continues to drive his message that there’s “no” mobile WebKit. Witness the comparison of mobile WebKits at http://quirksmode.org/webkit.html.

It’s important to be aware of the Proxy Browsers, namely: Opera Mini (not Opera Mobile), Ovi (upcoming from Opera), Bolt, and UCWeb. With these browsers, a highly compressed image is sent to the client, and this actually has two (potential) benefits: less network cost and less device requirement. However, once you get fancy with client-side scripting, these devices won’t do much at all. It’s just not what they’re made for.

The Stattage

Time for some stats. According to StatCounter, in Q4, 2010:

  • Safari: 23%
  • Opera: 22%
  • BlackBerry: 18% and dropping
  • Nokia: 16%
  • Android: 12% and growing fast
  • NetFront 4% (on basic Sony Ericsson and Samsung)
  • Samsung 1% (on Bada)

MS doesn’t feature here because many manufacturers introduce Opera (or other) instead of relying on the default IE browser. Interestingly, the Bada browser was met approvingly when PPK showed it to folks recently, and does well in performance.

It’s important to be aware of your own stats and circumstances too, e.g. PPK noticed, for his site at least, social media referrals cause disproportionate queries from iPhone and Android. So people dependent on social media should think about those.

PPK says right now, the browsers for most developers to consider, are Safari iPhone, Opera Mini, and Android Webkit. Beyond that, it depends on geography. In the US, BlackBerry is next to consider. Unfortunately, a recent stat said 90% of BlackBerry users are still on 5.0 or older, ie no WebKit and a very quirky browser. In Europe, Nokia WebKit matters more. Beyond that, Dolfin for bada and Opera Mobile are worth considering; fairly low mobile share, but pretty easy if the others worked.

“Mobile gives us the opportunity to practice what we preach when we talk about web standards”

We all talk about progressive enhancement, but who actually uses it? Again, mobile forces your hand! Basic JavaScript, to augment your semantically sweet HTML, is fine. But advanced – Ajax requests and beyond – may not, so think of progressive enhancement as a spectrum. Also, remember Ajax reuests go over the network, so they can slow things right down and require caution.

PPK argues for feature detection where possible, but experienced developers say browser detection is the only way in some cases.

The Future of Apps

HTML5 is not just a technology that runs in the browser, but one that powers apps. This is a conversation PPK just about kicked off a couple of years ago, and recent trends have begun to vindicate this view. Plugs for http://apparat.io and http://build.phonegap.com from PPK right about now.

PPK Questions the Future of App Marketplaces

Right now, the proverbial developing-national fisherman might pay $25 for a Nokia feature phone. Stuff is changing. This year, we’ll probably get $75 Android phones, says PPK. Too much for the fisherman right now. But give it a few years and the fisherman’s phone is running apps. Is he using a marketplace? Right now, those mostly require credit cards, so what happens? Download from the net? Too expensive.

So this is where PPK talks about transferring apps device-to-device. The apps are transferred by bluetooth or NFC and the data transferred with JSON-over-SMS. PPK says it’s hard right now to transfer via bluetooth on newer phones, where it works fine on future phones. The end of app stores is a consequence of this vision, sharing Eric Meyer’s quote: “Why is everyone so exercised? As with all walled gardens, the web will interpret the App Store as damage and route around it.”

(MM – This opens up a lot of security concerns.)

Why does PPK think the marketplaces won’t work for all the platforms in the long term? * Discoverability – worked in the past, but is harder in a more cluttered environment. * Distribution – the web works just as well or better for distribution * Works for Apple – it’s proven that the average Apple consumer will spend money on Apple. PPK argues Google has more leverage with developers than consumers. He says that’s the opposite for Nokia, Samsung, and RIM – in his theory, they have high leverage with consumers and low leverage with developers. * Cost of Ownership – Marketplaces need payment systems, sysadmins, content checkers, documentation and best practices writers, and they cost money.

PPK notes there’s a problem with Device APIs right now, i.e. users are prone to “Yes” everything. He notes there’s a UI issue with modal dialogs – users will say yes! Specs are BONDI, JIL, DAP, and WAC 2.0.

James Pearce on Mobile Web: More QCon Live Blogging

Sencha’s James Pearce explains why HTML5 rocks mobile apps.

Benefits of the web for mobile apps:

  • well understood
  • cross-platform
  • familiar skills and tools
  • decentralised
  • easily updated (no store process)
  • indexed
  • well understood

Mobile is about to explode – where the web escapes and comes with us, to the car and walking around etc.

Same way you had to sit down and listen to the record player instead of having music mobile. “I can’t believe you had to sit down to use the web”. Use it like a phone, e.g. avoid long forms, make phone numbers clickable, don’t include word docs!

The Web is evolving:

  • Web of documents is becoming a web of applications
  • Declarative HTML becoming programmatic DOM
  • Templates becoming APIs on the server-side
  • URLs becoming arguments (ie command-line)
  • RequestResponse becoming synchronisation

The HTML5 mobile stack looks basically like a native mobile stack

Browsers are much stronger these days, including IE9′s effort. But nevertheless, there’s still a range of varying support for the browsers.

So can’t rely on everything, but some features are there now and diversity is something web developers do have to live with. These tools help:

  • http://caniuse.com
  • http://modernizr.com
  • http://deviceatlas.com

Many mobile frameworks around: * Sencha (James’ company), jQTouch, jQuery Mobile, Sproutcore, * xui iui zepto embedJS …

James walks through some of the frameworks. Compared to jQuery mobile, Sencha is more of a pure client-side library – less reliant on a server outputting HTML. Tends to be more script focused than markup. In an MVC way.

Demo: http://sencha.com/x/5e

What W3C calls Thematic Consistency – should get same content on different devices, even if laid out differently. Lots of possibilities – e.g. do you have a special mobile version.

We can have user interface, business logic, and storage on the client; and security and storage on the server.

Whoa – security on two sides means we have a new problem for the web. Storage on both sides. But it’s a well-understood problem outside of the web.

Mark Miller on Securing JavaScript: More Qcon Live Blogging

Google Research’s Mark Miller is presenting a talk on Caja and web security. He emphasises that this is all bleeding-edge; no current browser fully supports this yet.

There are a ton of attack vectors for browsers, as shown on the Caja wiki. There are spec vulnerabilities, implementation vulnerabilities, and an ongoing arms race emerges. Mark shows a table of numerous variables for each browser, where the variation is not just wild but more or less random. The attacker only need to find one vulnerability here.

Perhaps the ongoing cat-and-mouse game means there’s something wrong with the whole identity-centric paradigm. Instead, maybe we can look at access control – don’t worry about who’s sending the request, worry about if the request has the correct level of access.

Mark walks us through the history of web kludges – JSON and Comet for cross-domain calls and streaming, respectively. HTML5 gets us towards a truer web of distributed objects, which all leads towards a symmetric network.

Safe Mobile Messages: Uniform XHR

Uniform as in “Uniform Resource Location”.

The proposal is for the server to ignore browser’s “helpful” extras.

Authorise based on payload. HTTPS URL or request body – info the requestor knows.

HTML5 allows servers to waive response protection using “Access-Control-Allow-Origin: *”.

Mobile Code

How do you mix coded from multiple untrusted sources into the same frame?

To solve this problem, we bring other security models to the world of JavaScript. With EcmaScript 3, Caja had to perform complex, server-side, translation with a runtime overhead.

The lessons of this effort were taken to the Ecmascript committee, and accordingly, EcmaScript 5 is one of the easiest OO languages to secure, instead of one of the hardest, as was the case previously.

Security as Extreme Modularity

This view treats security as an extreme form of modularity (ie the mutually suspicious components are seen as modules). Vulnerability is a form of dependency…so improving security also helps in other aspects, ie. makes the architecture cleaner.

So we marry up these closely related principles: * Software Engineering Principle of info hiding: Need to know. * Security Engineering Principle of least authority: Need to do.

These are the rules enforced: * Memory safety and encapsulation * Effects only by using held references * No powerful references by default

Objects as Closures

javascript
< view plain text >
  1. function makeCounter() {
  2.   var count=0;
  3.   return {
  4.     incr: function() { return ++count; }
  5.     decr: function() { return --count; }
  6.   };
  7. }

A record of closures hiding state is a fine representation of an object of methods hiding instance variables.

With “use strict”, we can enforce freezing of values. So if you have object A which depends on object B, object A can freeze properties of object “B” to make sure the reference doesn’t change. An important aspect of this is the ability to feeze a prototype.

For now, we have the “initSES.js” library. It monkey patches away bad non-standard behaviours, freezes whitelisted global variables…among other measures.

There’s a concept of membranes (wrappers) to encapsulate/secure message passing. e.g. if you don’t trust object X, you can make a read-only version of its return value. It’s also possible to wipe out what’s inside the membrane at some later stage, if desired. Even if that thing had references to external objects, only what was inside the membrane will be wiped.

Live Blogging at QCon HTML5 Track: Dave Recordon on HTML5 at Facebook

I did my talk on Single Page Apps and this morning at QCon today on Single Page Apps and HTML5 History. The demo raised a number of interesting design principles/patterns which I’ll cover in a later post…but for now, I’m going to post a few live blogs from sessions here. [Update - AlBlue's posted a summary of talk.]

First up, Dave Recordon explains how HTML5 is being used at Facebook.

Dave Recordon explains he works with Facebook’s developers to promote web standards and HTML. What is the promise of HTML5?

He begins by asking the obligatory, “What is HTML5″? His definition agrees with mine – not just a spec, but the technologies that let developers make awesome apps, and a brand that developers can rally around.

HTML5 at Facebook – Today

While some say HTML5 isn’t ready till 2025, Facebook wrote on their blog about “Using HTML5 Today”, a look at a bunch of things they’re already working on:

History.

Facebook has a framework called Big Pipe which loads the overall page structure, and then a second structure called QuickLink which overloads links to reload just parts of the page. This led to ugly URLs, with fragment IDs e.g. http://www.facebook.com/profile.php?id=24400320#!pages/Engadget/5738237369, and history gets them around that.

Recently, they created a new photo app which involves photo sharing and lightboxen to show the photos.

window.history.pushState(“http://facebook.com/full/url/to/photo”, null, “http://facebook.com/photo.php?fbid=123456678 ….”);

Web Video

Dave explains that Facebook hosts a lot of web video, and there’s no clear way to deal with it rigt now because of codecs…but, he says, it’s fair to say most people today would go with H.264 or WebM. Today, H.264 is Safari and IE, WebM on Chrome, Firefox, IE, and Opera. This difference, as well as DRM, is one of the reasons why people are still choosing Flash for video.

Dave bigs up video.js as a way of dealing with the complexity, and says they’re still using Flash for the most part, with the following advice:

  • Use your own Flash player if you’re already built one.
  • Use the same size poster image, raw video file, and Flash player.
  • iOS devices only support H.264.
  • Storage for double (or even triple) encode become costly, quickly.

Sprites and Gaming

They analysed the requirements for gaming. 10fps gets you minimum interaction for a game, but really you need to focus on 30+ frames per second, so this is where they focused. How many sprites do you need for a game? 5 sprites for a simple baord game, leading up to 100 for a 2D game (that’s the scope they focused on). They found the modern browsers can deal with the requirements well, e.g. with WbGL, Chrome 11 can handle 4000+ sprires.

He walks through various options for showing a spaceship. Just an image? A sprite? But if so, a div with a background image or a mask over the big sprite sheet image. They’ve done research to this end.

See http://github.com/facebook/jsgamebench

Mobile

Hundreds of millions of people access Facebook from their phones, so Facebook’s looking into how HTML5 can help here. Which platforms do you need to target?

  • Features phone
  • iPhone
  • Android
  • BlackBerry
  • Palm Pre
  • Windows Phone 7

Dave says that even for Facebook, let alone a startup, it’s hard to keep up with all these devices. The wurfl project maps devices to capabilities (e.g. does it support JS? what screen resolutions?), which Facebook is using and feeding data back into it.

The popularity of WebKit makes it easy to target multiple devices at once, and this is apparent in the way PhoneGap works to let you target multiple devices in the one go.

Assorted Questions

Dealing with IE6?

Decided not to support chat on IE6, but generally try to support older browsers as well, simply by way of the numbers.

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

HTML5 in Kiev

I’ve been in Kiev, Ukraine, this week, where I was fortunate to attend several events. The developers in this country and this region are super-talented, and I’m glad I was able to meet many of them directly.

Casual Connect

As with CC Seattle, there’s a big focus on social games right now. They are not only better for distribution – the viral nature – but often more profitable due to revenue sources which have no/little relevance in a single-player context. Namely, status-improving virtual goods; status-improving level advancement by way of automating/bypassing the grind; and, controversially/riskily, improving player capabilities.

I gave the following presentation on HTML5 Gaming. Fortunately, the HTML5 Game Jam we ran a couple of weeks earlier provided great evidence that it’s here and real, and I was able to make use of that in the examples. (I also came up with the idea of an iFrame player for these slides; so you can click on some screenshots to replace them with an iFrame showing the game. This is raw and needs more work, e.g. a big play button for starters.) All this emphasises the importance of micropayments/in-app payments for the social gaming segment.

The biggest concern game developers have with HTML5 is graphics capability. Handling a hundred avatars real-time on the screen at once, that kind of thing. I hope to work with a few of them to get some useful data and feedback for the browsers.

HTML5 Game slides