Go native, HTML5 is going to lag for a while

"But ender7," you say, "both Mobile Safari and Chrome have great support for HTML5."

Yes, they do. Sort of. Except for the crippling bugs in many of their implementations. Some of these bugs render the APIs in question essentially useless on mobile. Or just a giant pain in the ass to work around. Or have performance issues so large that they are impractical for non-toy purposes.

How quickly these bugs (and perfomance issues) get fixed will have a huge effect on HTML5 vs. native adoption. So far, this seems to be happening at a rate of "meh". For example, iOS 6 finally fixed the bugs in its HTML5 History API that prevented anyone from using it in a real product. But they did fix it. It only took...a few years.

But we all need early adopters.

Sure HTML5 isn't ideal yet. Writing multiple apps for separate platforms to do the same damn thing on different devices isn't ideal either, though. Unless you want to take one on principle I think its almost too context dependent to bother wage a conversation over it.

I think that the conclusion of this blog post is all too broad and so circumstantial that the title seems a tad silly. It amounts to something that everyone already knows. He gives an NB in the middle of the article that amounts to "of course if your app works well with HTML5 then you should use HTML5," and before that he mentions that native apps have more functionality (sensors/webcam/etc).

If you like the idea of a native web and you can make your app practical today in HTML5 then I think you should. On the principle of it I agree with the actually-pretty-butchered[1] Gandhi quote, "Be the change you want to see in the world."

~~~

For more talk on the topic see Paul Irish's post from the other day. It's not a rebuttal, more of a plea for HTML5 instead of native, but I found it and the comments interesting:

https://plus.google.com/u/0/113127438179392830442/posts/fR3i...

~~~

[1] From a NYT article: The closest verifiable remark we have from Gandhi is this: "If we could change ourselves, the tendencies in the world would also change. As a man changes his own nature, so does the attitude of the world change towards him. ... We need not wait to see what others do." http://goo.gl/S29tx

Although it even rings true for desktop browsers not being able to perform as optimally in regards to some HTML5 features work, Apple can and could do more to improve HTML5 support but won't for the foreseeable future until it works out how it can control and monetise HTML5 (which it can't and never will).

People are quick to point out Facebook ditched web and went native because of HTML5 limitations which I believe is a lie. It's been rumoured that Facebook is going to be deeply embedded into iOS 6 like Twitter got in iOS 5 and one of the requirements would obviously be to have a native application.

The Facebook app I believe was slow because of one key issue: 37 requests, 491kb. That was the problem, of course that many requests and large size is going to be slow for users on congested 3G networks.

Case in point of just how well a web app can run is LinkedIn's iOS app. It works the same way as the Facebook app used too. It has a Node.JS backend and uses a web wrapper to load it in, they even wrote up a blog post about how they squeezed every ounce of performance out of the web UIView and I think it works well.

I'm not one to believe in conspiracy theories without solid facts, but in my opinion the move to native by Facebook was a strategic one on Apple's end. Apple knew Facebook were the poster-child for HTML5 web applications that could run without relying on the almighty iPhone operating system, so throw them an integration bone and ask them to go native in hopes that others do the same and ditch HTML5 as their first choice for an app and many people will follow.

http://arstechnica.com/science/2012/09/pong-gets-a-physics-b...

Everything is set up for HTML5 to take off. Google doesn't really care about "app markets" so they are strongly incentivised to disintermediate the app stores via a triple threat of native speed JS (V8/Native Client) in Chrome, the Chrome Web store (listing of websites really) and the relatively free and open Android market (this is Microsoft's 80-90s strategy against Apple all over again).

Microsoft wants people to get off Obj-C Apple native app programming and onto HTML5 with Windows 8 - and they, along with Mozilla, have aggressively been pushing into native mobile HTML5.

Apple doesn't want HTML5 to win (flash wars aside). They need to keep apps locked and native since anything else will erode their competitive advantage (which neither Mozilla/Google/Microsoft care much for - since they don't do hardware).

HTML5 will come.

Question is will OnLive-esque video streaming win out in the end. I'll bet it'll be a mixture - with streaming for really hard core things and HTML5 for basic casual games/CRUD apps/low latency stuff. We might even go all video - I don't really know.

But it's gonna be awesome!

1. Ask for UDP to be exposed to trusted web apps installed by the user. This will let the P2P community race ahead without having to wait for WebRTC to get released and then fixed.

2. Ask for TCP to be exposed to trusted web apps installed by the user. This will instantly enable things like SMTP clients running in the browser without the need for WebSocket proxies/proprietary gateway servers.

3. Ask for POSIX to be exposed to trusted web apps installed by the user. This will lead to an explosion of database innovation in the browser. IndexedDB is design-by-committee. Insist on proper POSIX not the FileSystem API. Borrow from the Node API. Impedance mismatch is crippling browser storage.

4. Low-hanging fruit: ask for LevelDB to be exposed directly (http://code.google.com/p/chromium/issues/detail?id=128865). Most of the browser vendors are using LevelDB underneath IndexedDB, and just exposing LevelDB directly would already be a huge leap forward. No need to wait for the many IndexedDB bugs to get fixed by browser vendors.

Browser vendors are trying to do too much. Innovation needs to move from top-down to bottom-up. Browser vendors need to provide just basic access to bare metal and let OSS do the rest. UDP, TCP, POSIX would be a great start.

    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.

If you do believe that HTML5 will eventually be production ready, even if not for another 2 years, ask yourself this: when that time comes, do you want to be the guy with 2 years experience or the guy with none? When the industry is ready, 'HTML5 developers' are going to be all anybody wants and they'll want them all right now. If you want to jump on a moving train carriage then you have to start running towards it very early...

The Web and technologies have operated in a disruptive manner with respect to an established platform, and the mobile revolution was about the platform moving to serve modern, networked users. The is counter to silo'd interests attempt to constrain and integrate the web into proprietary formats and platforms (See: everything from active-X/flash to the current mobile platform wars).

However it should be fast enough for ebook production, if the typography is done right.

Why can't you get the same performance with WebGL shaders? Yes, WebGL GLSL adds some security checks, but apparently they only add about 5%. The article here seems to assume there is a huge difference - I'd be curious to know what that is based on.

Is it new shader models not present in WebGL GLSL? If so, specific examples would be appreciated.

edit: expand the question

To me the real issue is will Apple & Google keep holding their browser perf because hybrid mobile dev could hurt their profit & often breaks UI guidelines.

There are also things that OS-specific apps are likely to be better at for many years to come: Apps that operate in the background without using a lot of battery power, and interactive apps that manipulate and organize information and benefit from the richest and most responsive user experience that is integrated with OS features for information and device resource sharing.

OS innovation hasn't stopped. App development for iOS, Android, and Windows 8 hasn't even fully probed what those OSs can do for app developers in creating apps that work together. And the OS developers have not stopped improving their app APIs. They all have different approaches to interaction and application architecture, especially inter-app communication and cooperation.

So not only will we see a continuation of platform-specific apps, we will see a lot of innovation in what those apps can do on different platforms, and a richer expression of the differences between platforms.

"Write-once run everywhere" has zero value to the end user. They want the best Facebook/g+/Twitter/whatever experience possible on the platform they use.

The conclusion is sound though. Companies that build mobile apps using HTML5 in 2012 will almost certainly face the fate of companies that built web apps using Java applets in 1998.

This is true for most developers. I don't think it's true on the leading edge of HTML 5 development, but it's true that the existing MVC libraries really aren't there yet, and if anything, are asking the wrong questions.

It'll be awhile before HTML5 application development is a viable option for your average dev team just wanting to get a product out the door.

And for overflow: scroll areas, even using iScroll or your own implementation runs into simple bugs, such as: quick swipes make the document scroll no matter what you do!

Those of you surprised that HTML5 may not soon (if ever) be the holy grail have been drinking too much cool-aid.