Facebook comes up a lot in these discussions and it's important to provide some context. Facebook's HTML5-first strategy pre-dated the launch of the original iPhone. In the first native mobile app they were simply rendering the mobile facebook site in a UIWebView. There are so many better ways to do HTML5 and HTML5/native hybrid apps these days. Check out the Basecamp app, for instance. It's every bit as good as Facebook's mobile app but it makes heavy use of HTML5.

Agreed. Check out this attempt with the Sencha Touch Framework from a couple years ago: http://www.sencha.com/blog/the-making-of-fastbook-an-html5-l...

This demo from sencha touch has always seemed dubious to me. I remember having coded extremely basic mobile web app with this framework and having had layency issues from almost day one. My guess is that what they are doing with their framework to get to this result is pretty far from a normal use.

I think if you develop from the ground up to be a mobile optimized web app you can achieve good performance.

I recently built this as a side project using Bootstrap and it feels similar to an app (or faster) on iOS 'saved to my homepage': http://moneytrackr.ca/

Then later I found out about the Ratchet framework, so I think the potential is there.

Agrees but it was written by the people who created the framework so I'm sure they're much more aware of how to keep it performant.

Then again, you don't need to be the creators of Cocoa Touch to build high-performance iOS apps.

This. Anyone can make native fast for your average app, it takes a top-notch JS developer to make a similar web-app fast.

This was the main critique of the original article - that Apple and Google are blocking the open mobile web in order for native apps to thrive.

Both Android and iOS are built around promoting apps. The web is a second class citizen.

On iOS I would go as far as to say a third class citizen, since Apple are blocking the fast Javascript engine in native apps. This makes the idea of having an app as a simple web-wrapper much harder to accomplish.

But if the systems were actually optimized for open web, then content producers could build 1 web-app, that could have important logic and graphic stored offline in an app container, while still being just as functional via direct web access.

This could work great for 90% of all the apps that are basically just glorified websites.

This of course is the main mission of FirefoxOS.

Third class citizen on iOS? Safari does have the fast JIT javascript runtime, but native apps don't - so it's somehow not good for the open mobile web but good for native apps? I fail to see the logic in that. If you have a pure web-app - which you can pin on your homescreen, you do have the full speed Javascript engine, just look at the financial times app (app.ft.com) for a good example.

Also - 'the mobile web' did not exist before the iPhone popped up. Now you have a blazing-fast mobile webkit used in Android, iOS and on more recent Blackberries, and have a quite decent mobile IE on windows phone. Each generation of mobile OS, the mobile browser performance improves massively, adding more and more features with every generation. But somehow they are blocking 'the open mobile web'?

Also - a browser is not the only 'web application'. You already have mail, RSS readers, calendar apps, twitter clients, ... in whatever form, webapp, native desktop app or mobile apps - they all exist. They're all using 'the open web'. I think inter-operability is more important than "it has to be html5". The open web is in my opinion: open API's and data format. And that is exactly what we have, a large amount of mobile apps are just a native more intelligent client for some web API or content for which a website is also available. Twitter, Facebook, Reddit apps, Kickstarter, ... all have 'native' apps - does that mean it's less open than using a web-browser? No - it's just optimized for mobile use, something that is very hard to do with pure html5. REST/JSON api's have taken over the open web. Native or web-apps are just front-ends for these api's - that's the direction it's moving in.

I don't see the problem really, web-browsing still is one of the killer apps of a mobile device - tablet or phone, and that's something neither Google, Apple, Microsoft, or any other large corporation will ever limit. Yes some apps are rejected for whatever reason, but there is competition to choose from if one of iOS, Android, Windows Phone, Firefox OS or Mobile Ubuntu makes choices in their rejections that conflict with your personal beliefs.

I don't think that's a fair critique, at least not about Google. They are pushing JS with V8 as far as anyone besides maybe Mozilla. They also have made cross-platform Chrome/Android/iOS toolchains and in general promoted the use of apps based on web technologies. It's pretty clear that Google wants web apps to be awesome also, it's just hard.

Google showing results that go directly to an App is an important piece of this whole puzzle: https://developers.google.com/app-indexing/webmasters/

That's a good thing though right? Isn't that how a URI/link should work?

I guess, but they really are just directing traffic to a an app rather than a browser. A subtle difference to sum, but when you take into consideration that that app would have probably been downloaded through their store, it keeps people in the same loop.

I wish firefoxos and available hardware could have the word-of-mouth momentum for friends and family installation that the browser had. I would do this, but alas, its much more difficult to install on a family member's phone than the browser was on their pc.

FWIW, Dave Fetterman, the Facebook's former head of dev relations who helped create the Facebook developer platform (developer.facebook.com), later led mobile at Facebook and was the one who made the call to go HTML5 and then made the call to switch over to native is back working on high performance HTML5 at famo.us as VP of Engineering.

There is still a future for for pure web apps that feel great. The framework will be released on Wednesday night.

disclaimer: I work at famous.

Sure, native apps have better performance on mobile. But the same thing is true on desktop, yet the web somehow stays popular on desktop. That suggests that the behavior of platform owners (Apple and Google) is the real reason for the popularity of apps on mobile, and performance is just a distraction.

Only in the last few years has SAAS applications really taken over native. Native has only been taken over so recently due to abundance in network latency and javascript engine improvements.

We've also been pushing for web app models as developers as a collective quite hard. Not so much with the mobile side of things (all got dollared eyes maybe?) We will likely see a push back into the web side of things once mobile browsers become less painful to use and more powerful in what they can do.

In other words, "decline of the mobile web", yea right. (don't forget half the article was about how we're spending more and more time in mobile web over desktop web.)

As lugg said, it took a long time for web apps to rival native apps in functionality, and there are still a lot of places where they don't (large files, graphics, etc). In ~3-5 years the class of web apps that are lightning fast on desktop now will be fast on mobile.

>and there are still a lot of places where they don't

This would be better phrased as "and there are still only a few places where they do". Google Docs, for example, is great for basic collaborative editing (as long as you don't mind the NSA reading it), but has a UI that it a total pain (especially the world's worst keyboard shortcuts, e.g. having ctrl-enter and shift-enter reversed, and completely lacks advanced features.

Isn't the whole performance discussion based on synchronizing versus not synchronizing? There's no reason to synchronize on a Desktop as one can assume there's wifi available.

I think that sync vs not syncing tends to be cyclical.

We all started using Gmail because synchronising to a mail server is annoying and PCs where slow. Ten years later machines have a fast internet connection, 1TB HDD as standard and, maybe an SSD. When you have to wait 10 seconds just to view an attachment syncing makes a lot of sense. But generating a thumbnail of that same PDF would be much better handled pre-emptively in the cloud.

The problem is believing that one approach is better for every function of an app. Few user machines will ever have a guaranteed large amount of bandwidth. This is just as true on desktop machines as mobile, but less acknowledged.

Since "desktop" as a platform includes laptops, which have pretty similar connectivity issues as mobile devices, that's really not true.

Gmail is faster than any native email client I have ever used.

The article is discussing a very different thing. It's not web vs native on technology alone, but on which platform users are spending their time (in a browser or in an app). There is a growing number of apps being built with web technologies for the app stores, and that will only grow as the tools get better there (disclaimer, I am very much invested in that space).

> Maybe a mobile browser with super-aggressive caching (like not even a HEAD request for JS and CSS)

appcache does something like this and is something that Firefox OS is pushing.

> a mobile browser with super-aggressive caching

ServiceWorker (WIP) will do this. Its a WebWorker proxy in the browser's request/response pipeline for a particular origin, with a new cache API built on local storage.

It can process page requests and responses with similar semantics to what a WSGI/Rack/MVC controller normally does on the server. It does away with bullshit 'offline mode' divining and encourages apps to work 'offline first'. https://github.com/slightlyoff/ServiceWorker/blob/master/exp...

The polyfill is actually a node.js headless implementation, which makes this look more and more like an isomorphic controller API. https://github.com/phuu/ServiceWorker-Polyfill

Jake Archibald's talk at Chrome Dev Summit, December. https://www.youtube.com/watch?v=Z7sRMg0f5Hk

Chromium bug. https://code.google.com/p/chromium/issues/detail?id=285976

> Facebook is an instructive example here. They tried for a long time to make their native app (for Android, anyway) just a wrapper over the mobile web client, but they could never get the performance all the way there. They went native and have seen great results.

Except that anyone who actually uses the Facebook apps knows that the performance is horrible in the native apps– jerky scrolling, lots of on-demand loading requiring you to wait for multiple RTTs on every click, etc. I would be hesitant use Facebook as an argument for anything other than the need to place UI performance on equal priority with marketing.

Facebook's mobile website doesn't want permissions to access camera, mic, location, and SMS. That's why I use that and not their stupid app, especially since it lets me switch between other sites as I like as well.