"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.
> How quickly these bugs (and perfomance issues) get fixed
> will have a huge effect on HTML5 vs. native adoption.
I am moving however to Objective-C and Cocoa world. It is so clean and tidy compared to the mess the web technologies stack is. And no matter how great support for HTML5 will be, no matter how performant it becomes—it will be well adopted and very performant mess. We can bring in frameworks and libraries, duct-tape things together, but we are long past the point where we could get rid of all the ugly heritage.
My feeling is, that web technologies will be used mostly for the content leaning apps, and for "apply" the native will be a clear choice.
Then there is this "cross-platform development" thing. Well, not sure about this one. I guess we are bound either to have mediocre solution for all, or bite the bullet and do native for each platform if best results are desirable.
Not sure about how well their mobile counter-parts actually support HTML5, but at least you have a choice for a non-system-supplied browser.
On iOS you are, as you say, SOL because Apple has literally crippled the options you have down to one: The one they supply and update, once a year.
But these Updates won´t affect UIWebViews :( (hybrid apps)
Especially egregious given Steve Jobs' memo about not supporting Flash on iOS.
Some choice quotes:
>New open standards created in the mobile era, such as HTML5, will win on mobile devices (and PCs too). Perhaps Adobe should focus more on creating great HTML5 tools for the future, and less on criticizing Apple for leaving the past behind
It's been two and a half years since that, and still HTML5 has major issues. Given Apple's engineering prowess, I doubt that HTML5 is a priority for them, or else they would've had a great implementation by now.
They know that all the apps in the App Store serve as excellent lock in against Android, Windows Phone and RIM. Why make it easier for people to switch instead of dragging their feet with a small update every year?
Well, noticed how Android's own web browser is even worse in HTML5 than Mobile Safari? And this is Google, the guys that really like mobile html5 apps.
Fact is, it's not that easy to make a good mobile browser --heck, it's not that easy to make a good desktop browser.
Still, desktop HTML5 leaves a lot to be desired. Forms support is lacking, the audio side is neglected, SVG still lacks features and is not properly accelerated (even the latest IE that just got it is better in this regard), the client side storage didn't pan out well, typography is still crappy, etc. And this is for the desktop, that doesn't have the battery, memory and performance concerns of the mobile.
And it holds true for Safari, Chrome AND Firefox.
So, in case you're thinking Apple is doing something especially malicious here, well, they are not.
The stock Android browser fell behind in late 2010. If you follow PPK of quirksmode.org you know this (e.g., the following article was authored just before stock android fell behind: http://www.quirksmode.org/mobile/browsers.html). After that article he really began hating all over Android due to the fall-behind.
Basically, Google mostly abandoned the stock browser because they wanted to focus everything on Chrome for Android. They accomplished this last year, and it fixed virtually all the HTML5 complaints that have been leveled against Android. Chrome is only supported on Android 4+. Android 4+ devices are on track to become the best-selling Android phones of all time, such as the S3 which singlehandedly outsold the iPhone in August. In a year Android 2 & 3 will have negligible market share, as Froyo does today (15%).
Android with Chrome is at least as good as the iOS browser -- probably better. So this isn't a problem here.
Source for that? Last I heard Samsung hadn't actually released any stats.
You mean it outsold the iPhone in the month before the announcement of the NEW iPhone, that everybody interested in one expected and hold off for?
Doesn't sound that big of a feat...
"Android's browser"? Care to elaborate on which browser that is?
The one built from source? Which version of the source would that be? Or would it be Chrome? Or Firefox? Or Opera? Or Dolphin? Or Maxthon? or MIUI browser? Or the one included with TouchWiz? In which case, which version of Touchwiz?
And how is it "even worse"? You mean it doesn't behave like Mobile iOS Safari so that sites specifically tailored for iOS-devices doesn't work out of the box on Android? What a shock that is, eh? It's almost like I write sites specifically for MSIE, and they don't render correctly in Firefox. Haven't we heard about this story once before?
I'm not debating the correctness of your statement, but when you start out with something as mindblowingly pointless as "Android's browser is even worse" it's hard to take the rest of your point seriously.
Actually you are.
> but when you start out with something as mindblowingly
> pointless as "Android's browser is even worse" it's hard
> to take the rest of your point seriously.
It is not pointless. Don't pretend to be silly as not to understand what "Android browser" is.
In that case, I challenge you to pinpoint what browser I'm writing this comment from. It should be obvious. It is the Windows-browser.
(And before you start debating how that sounds ludicrous, take a step back and realize how Android is more like Windows and Linux than iOS when it comes to software-choice, not to mention versions and revisions and forks)
However I believe that apps still have to use the built in rendering engine when using the WebView control.
I'm not sure whether this is a strategic or technical decision from Google but I suspect the latter. Changing the WebView engine would have a major effect on compatibility for existing apps.
I'm hopeful that Firefox OS and Firefox for Android will be able to exert competitive pressure in the HTML5 app space, but it will still be a long, hard slog.
And I can see a good argument for blocking the open Web being in Apple's interests, but again, historically they've been going as fast as anyone else. They might not move as fast as I'd like, but they're not lagging.
I've seen a couple of posts from people comparing iPad's Safari with IE6 (although, Safari has been improving in past few releases...) so not sure which is the favorite browser for people on iPad.
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 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:
 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.
The business of running the appstore is not the reason they will never fully support cross-platform mobile development.
The real reason is websites that run as apps break Apple’s strangle-hold on their walled garden. Apple's business model is to sell devices via a tightly controlled channel (read few middlemen) at a high-margin; getting paid up-front when the device is purchased. Those high-margins are partially possible because of the value ascribed by customers to the uniqueness of variety & volume in the appstore combined with it's friction-free nature.
WORA is a pipe-dream. Has always been. Always will be. Meanwhile developers continue to suffer because there are enough 'popular' platforms that they have no choice but to do cross-platform development. Sadly, this is just reality; I do not believe there will ever be a silver bullet.
Selling phones (and tablets) that can do amazing and powerful tasks is what makes Apple money. That's why they have invested so much into creating the iOS SDK, to enable developers. It is a fantastic platform, elegant and powerful that leverages their hardware.
If Apple could have gotten that same quality of software with web apps, why wouldn't they have chosen that as the platform and immediately have had millions of web devs ready to build for their mobile OS?
What the HTML5 evangelists fail to admit, is that HTML5+JS+CSS is a damn mess. We've been hearing for 10+ years how web apps are the cross-platform silver bullet. It's not.
Can you give a link to that blog post? I took a quick look at LinkedIn's corporate and developer blogs but couldn't come across it.
This presentation from LinkedIn's Director of Engineering is worth watching too: http://www.youtube.com/watch?v=hMd45Ij2DYQ
Also see this piece from Venturebeat: http://venturebeat.com/2011/08/16/linkedin-node/
The first link is the one I referenced in my comment RE: Node.JS and heavy HTML5 optimisation. Other people who haven't seen them might find them interesting as well.
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.
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.
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.
But simply saying "They removed HTML5 and all works a lot better" is very wrong.
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).
You're absolutely right about open platforms and protocols being about lots of people taking risks and building hugely valuable things. My point was that when the core OS is innovating like mad, you need to be close to those OS's to build the best apps... The innovation on the desktop slowed to a crawl years ago, and the majority of innovation has moved to the browser and web-app layer. In mobile, however, there's a LOT of innovation still happening right at the OS level w/ Android and iOS, and so all the frameworks that exist above the native SDK's are going to lag, and not take best advantage of the innovations being released at the OS layer.
The speed of mobile OS innovation will invariably slow (like it did on the desktop), but until then, philosophy about open platforms aside, iOS and Android show no signs of being displaced as the real mobile OS / platform drivers... and so, native's going to lead HTML5 / other "open" platforms for a while.
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
1) There's definite overhead on the API itself, e.g. the slow shader compilation times due to the verification, translation, etc. That'll get better over time, but it'll never match the desktop; I personally think a caching approach will be a big win here, but no one has done it yet.
2) You don't have geometry shaders, hardware tessellation, hardware instancing, and a number of other features you get on the desktop with modern hardware. You also don't get the ability to render to multiple targets at once (critical for performant deferred shading).
3) There's significant 'extension lag' as it isn't as simple as just implementing an extension on one chip and coding for that; it has to hit a certain level of penetration before it'll be ratified for inclusion in WebGL, then it has to be made safe and implemented.
Those are the core things holding WebGL performance back (IMO), excluding other browser bits that may get in the way, which aren't relevant to this discussion directly. A lot of this will go away over time, but I honestly have no idea how any of that will happen.
(Disclaimer: I work on graphics stuff for Mozilla, but don't work much on the WebGL side of things; mainly write demo code there)
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.
Exactly, and if Mr Enduser X can get it on his weird platform because it runs HTML, that's a massive piece of value to him.
Also, while he wants a good experience, he wants it to be free too and the cost in building and maintaining multiple codebases for client libraries would certainly get passed on to him one way or another.
Before there were Web apps, all software makers wrote apps for multiple platforms. Porting to a platform has a cost, but, for a successful software company, not a relatively large cost. Even unprofitable platforms are likely to be supported by some software makers as a way of erecting barriers to entry, or to speculate on the future success of that platform.
Users will expect all the features of their platform to be well-supported in their apps.
I think you meant: Before there were web apps, most software makers wrote apps for Windows.
Because that's what actually happened.
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.
Are you just talking out of your ass? Have you actually built an application using Ansca Corona, Ruby Motion, or Appcelerator Titanium? Have you built a published native and Phonegap app to the Android or iOS store? Well, I have done all of these - and I even speak about it at conferences. I can safely say you have no idea what you're talking about or you are pushing a hidden agenda.
1. If you are delivering information that wants to be accessed everywhere, write a Web app
2. If your users want the richest interactive experience, write platform-specific apps
3. For everything else, use proprietary multi-platform app SDKs.
What is "everything else?"
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.