Go native, HTML5 is going to lag for a while(blog.suthakamal.com)
blog.suthakamal.com
Go native, HTML5 is going to lag for a while
http://blog.suthakamal.com/2012/08/go-native-html5-is-going-to-lag-for.html
96 comments
> 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.
On Android, you can install updated browsers like Firefox and Chrome.
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.
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.
> On Android, you can install updated browsers like Firefox and Chrome.
But these Updates won´t affect UIWebViews :( (hybrid apps)
But these Updates won´t affect UIWebViews :( (hybrid apps)
Beginning with version 4.1, WebView is created from a recent snapshot of chromium before every major release. At least that is what Google Engineers said during the Android Fireside chat at Google I/O.
UIWebView on iPhone stinks pretty badly, too. Which, indeed, bears out the GP's point.
>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
Especially egregious given Steve Jobs' memo about not supporting Flash on iOS.
http://www.apple.com/hotnews/thoughts-on-flash/
Some choice quotes:
>Though the operating system for the iPhone, iPod and iPad is proprietary, we strongly believe that all standards pertaining to the web should be open. Rather than use Flash, Apple has adopted HTML5, CSS and JavaScript – all open standards. Apple’s mobile devices all ship with high performance, low power implementations of these open standards. HTML5, the new web standard that has been adopted by Apple, Google and many others, lets web developers create advanced graphics, typography, animations and transitions without relying on third party browser plug-ins (like Flash). HTML5 is completely open and controlled by a standards committee, of which Apple is a member
> If developers need to rewrite their Flash websites, why not use modern technologies like HTML5, CSS and JavaScript
>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?
Especially egregious given Steve Jobs' memo about not supporting Flash on iOS.
http://www.apple.com/hotnews/thoughts-on-flash/
Some choice quotes:
>Though the operating system for the iPhone, iPod and iPad is proprietary, we strongly believe that all standards pertaining to the web should be open. Rather than use Flash, Apple has adopted HTML5, CSS and JavaScript – all open standards. Apple’s mobile devices all ship with high performance, low power implementations of these open standards. HTML5, the new web standard that has been adopted by Apple, Google and many others, lets web developers create advanced graphics, typography, animations and transitions without relying on third party browser plug-ins (like Flash). HTML5 is completely open and controlled by a standards committee, of which Apple is a member
> If developers need to rewrite their Flash websites, why not use modern technologies like HTML5, CSS and JavaScript
>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?
>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.
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.
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.
Picking on one point: "Well, noticed how Android's own web browser is even worse in HTML5 than Mobile Safari"
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.
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.
>such as the S3 which singlehandedly outsold the iPhone in August.
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...
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...
> such as the S3 which singlehandedly outsold the iPhone in August
Source for that? Last I heard Samsung hadn't actually released any stats.
Source for that? Last I heard Samsung hadn't actually released any stats.
I remember the news was all over the tech-web, including HN. A quick Google will yield you multiple hits, but in case you are lazy (I know I am), here is one of them:
http://www.ibtimes.com/articles/380534/20120904/apple-samsun...
http://www.ibtimes.com/articles/380534/20120904/apple-samsun...
Well, noticed how Android's own web browser is even worse in HTML5 than Mobile Safari?
"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.
"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.
> I'm not debating the correctness of your statement,
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.
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.
> 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)
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)
Problem is, Android's stock browser is called... "Browser". So Android Browser is perfectly valid.
It's slightly more complex than that. Google has made an effort to make Chrome the default browser going forward. However this will only affect Jelly Bean (and to a lesser extent ICS as it is an optional install there).
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.
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.
> Sadly, Apple and/or Google have the power to retard the adoption of HTML5 as long as they like.
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.
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.
Realistically, though, Google have always seemed to view HTML5 as being a very good thing, since the Web is their bread and butter. Android seems to be more of a hedge against other vendors' platform dominance than an attempt by Google to lock everything down -- thus why Google actually exerts little control over Android distribution.
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.
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.
Not to mention Apple willingly holding the JIT from being used in the embedded browser.
Which browser is the shining beacon of light for HTML5?
Personally, I have high hopes for IE10 and its supposedly tight integration with Windows Phone 8.
I kind of like Dolphin browser on iPad; have been playing with it for sometime. It kicks Safari's ass big time, except for the no_file_upload option the web standards' way.
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.
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.
It´s mobile safari. I can´t understand, why chrome on android performes this bad compared to mobile safari. :( On desktop it´s the opposite. :?
"Early birds get the worm, early adopters get the shaft" to paraphrase my brother.
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
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
Lets get this straight, the limitations in performance on Mobile Safari are very much deliberate limitations. Do you seriously think a company like Apple who gets a pretty large chunk of app store sales is going to let something like HTML5, CSS3 and Javascript steal it's profits away? Fat chance.
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.
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.
Apple makes almost no money, in relative terms, from app store sales (about 1% in '10)[1].
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.[2] Sadly, this is just reality; I do not believe there will ever be a silver bullet.
[1] http://news.cnet.com/8301-13579_3-20008540-37.html [2] http://ceklog.kindel.com/2012/07/24/apps-must-be-cross-platf...
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.[2] Sadly, this is just reality; I do not believe there will ever be a silver bullet.
[1] http://news.cnet.com/8301-13579_3-20008540-37.html [2] http://ceklog.kindel.com/2012/07/24/apps-must-be-cross-platf...
App Store profit for Apple is a rounding error on their balance sheet.
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.
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.
"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."
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.
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.
Related HN discussion here: http://news.ycombinator.com/item?id=4153599
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/
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/
No worries Needle, check out these links.
http://engineering.linkedin.com/testing/continuous-integrati...
http://engineering.linkedin.com/nodejs/blazing-fast-nodejs-1...
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.
http://engineering.linkedin.com/testing/continuous-integrati...
http://engineering.linkedin.com/nodejs/blazing-fast-nodejs-1...
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.
The Facebook integration in iOS 6 (Beta 1 through 3) functioned perfectly well prior to the launch of the (non Web view) native FB application.
It's also unsurprising that FB would rather not benefit the Android platform more than strictly necessary.
HTML5 isn't ideal yet - but it is getting there (see link):
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!
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!
One way to help is to ask for lower level OS apis to be exposed by browsers, so that the open source community can do the rest:
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.
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.
(I wrote the original blog post.)
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.
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).
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 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.
Did you notice the enormous performance improvement in Facebook's app when they moved away from that type of solution to a native one?
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:
http://www.vasantkumar.ca/2012/08/native-vs-html5-why-facebo...
But simply saying "They removed HTML5 and all works a lot better" is very wrong.
http://www.vasantkumar.ca/2012/08/native-vs-html5-why-facebo...
But simply saying "They removed HTML5 and all works a lot better" is very wrong.
Nobody's said that though. Facebook has, in fact, replaced some web views with native code, and that has sped up the app tremendously.
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.
[deleted]
In a sense, PhoneGap apps are actually NOT Web apps, they are native apps built using Web technologies.
No; they're webapps embedded in web browser aka WebView. Refer http://phonegap.com/2012/05/02/phonegap-explained-visually/
No they aren't, they use hooks to native phone functions. You can't write once, run everywhere.
They're native apps written in HTML, CSS, and Javascript. That doesn't mean they're web apps.
They're native apps written in HTML, CSS, and Javascript. That doesn't mean they're web apps.
This. Also look at windows phone 8 and blackberry 10 to see how the web stack can be used for native mobile apps.
Saying HTML5 won't be 'production ready' for a while, and saying that HTML5 will never be production ready are two very different things, but I feel people conflate the arguments all the time.
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...
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...
I am guy with more than 10 years experience, I am on WHATWG list since prehistoric times, when HTML5 was still called "Web Applications 1.0" and I will gladly use it for web content, but for mobile applications I choose native.
When the time comes? Do you think that this would be a well defined time? Will someone declare it 'Production Ready' one day? It is going to be a very slow transition (painfully slow). Once most thing are transitioned, other technologies will be so far ahead that 'web applications' will no longer exists. Content web sites will always exist, but not applications.
I can't wait until unlocked bootloaders are the norm and the drivers are open source. The level of artificial stagnation on phones is disgusting and a joke to our profession.
Regardless of whether or not HTML5 is going to "lag", I think this article white-washes the evolution of the web as an open platform vis-a-vis the desktop/OS. Open platforms and protocols are the result of hard work and people taking risks and building value, not a result of stability in the platform.
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).
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).
(I wrote the original article.)
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.
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.
Let's face the reality. THe HTML5+CSS3+JS is over complicated. It's not going to stop lagging for the same jobs that native apps can handle well. Not even your computer is sped up 2x. Because native apps will always make it look bad.
However it should be fast enough for ebook production, if the typography is done right.
However it should be fast enough for ebook production, if the typography is done right.
Don't generalize. The reality is that for certain apps (esp. simple, data-driven ones a la ebooks), web is certainly not overcomplicated, and in many times can be nearly indistinguishable from a native app. And it is -- albeit slowly -- getting better.
> WebGL is cool, but [..] the kind of graphics performance a developer can get by writing straight OpenGL (taking advantage of sophisticated shader models on more recent devices) is astonishing
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
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
In current implementations, the shaders running through WebGL are identical to those that are not (outside of ES vs desktop changes). However, there are a couple problems:
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)
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)
I'm slightly amused by one Mozilla employee responding to a question posed by another Mozilla employee with a disclaimer that they work for Mozilla.
Couldn't agree more. We have seen this recently with the Facebook app switching to native. I think as time goes on, and as phones get more powerful, it will mean less of a difference, but for now it is better to stick with native. We decided this for our iPhone/Droid apps at http://trackmydrive.com and couldn't be happier!
The author is wrong, you can build up a HTML5 app and use everything that a native app does (using PhoneGap/Cordova & custom native bridges), so that is not the point at all in the HTML5 vs. native debate.
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.
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.
I do not believe this debate will ever be fully resolved one way or the other. That is, there will always be things Web sites/apps are better for: Delivering free-form, multimedia information, especially when frequently updated. Or for relatively simple apps that benefit from pervasive access.
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.
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.
> "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.
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.
That argument is a little circular. If a platform has significant market share, apps get ported to that platform. If not, it doesn't matter.
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.
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.
Before there were Web apps, all software makers wrote apps for multiple platforms.
I think you meant: Before there were web apps, most software makers wrote apps for Windows.
Because that's what actually happened.
I think you meant: Before there were web apps, most software makers wrote apps for Windows.
Because that's what actually happened.
If companies like apple would not restrict non-native apps to only use the slower JS engine I think a lot of performance issues would go away. HTML5 should almost always be enough for most usecases such as chats, shopping apps, award apps etc.
If an app is restricted speedwise to an IE 6 type of Javascript engine and HTML5 Apps heavily use Javascript. The problem aren't the Apps but the JS engine powering these apps.
I would say Go native, HTML5 is going to lag forever, since even on a modern desktops, the performance of HTML5 is way behind native apps. Besides that, HTML5 is an amalgamation of technologies that feels awkward to use for someone who has wrote native apps. I would like to see something like XUL added to HTML5, so you can write web interfaces in a more sane way.
Are we all forgetting why people build web apps in the first place? It's not about performance.
A lot of comments suggest that Apple and maybe even Google are deliberately keeping HTML5 performance subpar. I think this misses a key fact: Google has struggled for years to make native Android apps match iOS performance, even for simple things like scrolling a list. The fact is Apple set a standard with iOS that is incredibly hard to meet regardless of the technology.
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.
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.
Go native, HTML5 is going to lag for a while
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.
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.
the author doesn't think about the fact that small companies simply can't "go native". there isn't only facebook and google, out there.
What about things like Titanium or RubyMotion? They compile to native and allow you to have a "unified" code base.
I'm not sure about RubyMotion, but I can speak to Titanium as we use it to build our TripLingo language learning apps.
Appcelerator Titanium does not compile down to anything - rather it bridges a JavaScript runtime to the native layer: either iOS or Android. It's not as fast as coding in ObjC or Android Java, but we see performance which is very close to that of native and have the entire underlying native SDK available for use.
Appcelerator Titanium does not compile down to anything - rather it bridges a JavaScript runtime to the native layer: either iOS or Android. It's not as fast as coding in ObjC or Android Java, but we see performance which is very close to that of native and have the entire underlying native SDK available for use.
(I wrote the original article.)
These frameworks typically just allow you to wrap native methods with JavaScript... so you're not really writing to a single cross-platform code base. Morever, if you can build your app entirely in the HTML/JS/CSS side of things, you're golden... as soon as you start to bridge between the Native and JS layers, things get messy (and often very slow).
These frameworks typically just allow you to wrap native methods with JavaScript... so you're not really writing to a single cross-platform code base. Morever, if you can build your app entirely in the HTML/JS/CSS side of things, you're golden... as soon as you start to bridge between the Native and JS layers, things get messy (and often very slow).
What? You make no sense. In your original article you advocate going native for now and eschewing Web tech. Now you say that "you're golden" if you use Web tech? Then you top it off by saying bridging down to native is slow.....
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[1][2]. I can safely say you have no idea what you're talking about or you are pushing a hidden agenda.
[1] http://lanyrd.com/2012/lone-star-symposium-austin/stbht/ [2] http://lanyrd.com/2012/uberconf/stcdt/
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[1][2]. I can safely say you have no idea what you're talking about or you are pushing a hidden agenda.
[1] http://lanyrd.com/2012/lone-star-symposium-austin/stbht/ [2] http://lanyrd.com/2012/uberconf/stcdt/
Could you please either link to a copy of your talk, or some material? Or alternatively (if possible), just give the 3 sentence version of your talk? I'm just about to decide what to system to build a new project on, and I'm interested in your opinion.
...or go watch this video. It's a pretty decent (and balanced) overview of the dev options out there: http://www.infoq.com/presentations/Cross-Platform-Mobile
i'd be happy to google hangout with you to help ya'll. ping me on twitter at 'prpatel'
These technologies live in a very narrow space:
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?"
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?"
I've read all the Comments and at the time I'm writing this, I'm scratching my head because I don't see a single mention of Open webOS. Have all of you written it off or is it just too early to be on anyone's radar?
IMO there's too much uncertainty over WebOS. There's no real deployment of these devices (dwarfed by even Windows Phone at this point), the helter-skelter handling of killing it and bringing it back has scared people (thanks Apotheker for coming in an destroying WebOS and HP in general!), and a roadmap that hasn't unfolded yet.
I really hope Firefox Mobile addresses most of the HTML5 pain points and go live on Android and iOS. We badly need a neutral, open browser on mobile.
Why is Apple's App-Store App build with HTML? I really don't get it. Why did Apple favour HTML instead of Objective-C?
The biggest obstacle to using HTML, in my opinion, is horrible scrolling support on Android mobile websites. In general, Android's scrolling is ehh (not sure why they don't make it as good as on the iPhone), but on MOBILE SITES it's just really bad.
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!
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!
Thought it was about golang at first, got my hopes up for something that actually matters to me.
Or use Firefox.
Overrated they call it in sports, overhyped they call it in economics, overgeeked I call it in the hacker world.
Those of you surprised that HTML5 may not soon (if ever) be the holy grail have been drinking too much cool-aid.
Those of you surprised that HTML5 may not soon (if ever) be the holy grail have been drinking too much cool-aid.
[deleted]
Mobile apps will be preferred over web apps until mobile internet bandwidth is cheap and abundant.
going native is like going skinny-dipping. a lot of freedom and exquisite possibilities, but with it comes responsibility - and you can easily get yourself into trouble.
"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.