A smartphone today can talk to all sorts of other devices:
TV remotes over WiFi, watches and headphones over Bluetooth,
health-sensors and car stereos through dock connectors, and
TVs over AirPlay. All this is beyond the reach of HTML apps.
That's almost the entire point of PhoneGap and similar frameworks, exposing these via APIs. He's confusing using HTML/CSS/JS for UI in a "native" app with making a web app.
You're right that things like PhoneGap give access to native features. However, the Native-API-implementations in these frameworks are
1) typically significantly behind the native OS (release date)
2) tend to have less-than-feature-parity
So, often you're stuck writing your own native bridge, or tweaking the portability framework's version, which is time wasted (IMO) vs writing to the native framework. As an example, just try and write a PhoneGap app using Bluetooth: The Android implementation is incomplete, and the iOS version is non-existent.
Also, there are a tonne of performance issues you run into with the HTML/CSS/JS + Framework + Native solutions. As a thought experiment, consider how you'd build Instagram in one of these frameworks.
1) Image filters in HTML/CSS/JS land? Slow.
2) Thousands of images in a continuous virtual scrolling window in HTML land? Slow.
3) Fetching a binary blob (the image) from the OS, and throwing the resulting blob back-and-forth to web-land (for example, to use HTML5 offline storage) ... hellish slow.
Compare that to native... it's just one example of where the theory of HTML for UI and native for logic breaks down when you start to push the platform a little outside it's comfort zone.
I don't know the challenges of building a web-based Instagram, however I am a long-time user of Flickr, with which I manage a huge collection of personal photos.
The Flickr web interface definitely needs a modern browser (Chrome or the latest Firefox), otherwise it will choke from time to time, however that's to be expected when you're basically playing around with 10,000 photos. For me it does a spectacular job, more so than some native apps I tried (granted, I never tried Adobe Lightroom).
Thousands of images in a continuous virtual scrolling
window in HTML land? Slow.
You can use the same tricks you'd use in a native app, such as loading only the thumbnails that are currently visible in the user's window.
You are criticizing HTML5 far too broadly. Yes, it may not be the best choice for building a game, or a photo heavy app. But it's good for building mostly text based apps, which represent the vast majority of the (mostly crappy) native apps out there.
I suppose with Node installed, and HTML used for the interface, these speed issues will be resolved. But perhaps (I do not know) iOS prevents installing this tool.
That´s really wrong! Facebook still uses a lot of HTML5 in their new App! But they fixed a lot of bugs, mainly removed a lot of concurrent UIWebViews. For more information, take a look at:
Facebook did a lot of harm to the reputation of HTML5 with that app. Sometimes it took a few minutes to render comments for a photo or an user profile or a few items on a news feed. Of course, DOM/CSS/JS is slower than native - but it doesn't have to be THAT slow. Especially for what seems like a relatively simple things. I suspect they overengineered it a bit.
Facebook used not only one WebView but many of these. Each WebView did fight against the others for CPU time. This was the main Problem and got fixed with the new App. Mainly by removing the Timeline-WebView.
