From the article: "I experienced minimal complications when using Safari on both the iPhone and iPad"
minimal complications is a euphemism for "Any normal user would throw the thing against the wall in frustration."
To me this is just further demonstration of the failure of HTML5 on mobile. It's been, what, 4 years we've been in the "HTML5 will save us all" hype bubble?
Don't get me wrong; I am building a webapp and aspects of HTML5 have made my life far easier than if I were still in 2008. If I had hair I'd still be pulling it out due to the complexities of CSS (even with things like LESS) and subtle browser differences would turn the rest of it gray. But the current state of HTML+CSS+JS on the desktop is pretty good; compared.
We appear to be years away from a similar state in mobile. Between Safari's problems with no JIT support within apps and the fragmentation of Android, coupled with the monstrosity known as IE on WP7 (and WP8 and Win8), it is just not possible to use "HTML5" to build a great mobile experience (and reach a large audience).
My history in working with the W3C (I worked on HTML 3.2 and 4), and my understanding of the asymetric competitive nature of the major players (Apple, Google, Microsoft) makes me believe this situation is not going to radically improve anytime soon.
The upside is dev tool vendors who can help ease the pain should do pretty well (e.g. things like Xamarin (C#) and MoSync (C/C++/JavaScript))...
Android fragmentation is a reason not to use HTML5? That's about as backwards a statement as I can imagine - web apps are the great savior that abstract away all the device fragmentation. And windows phone's incompatibility as a sticking point? That's an easy one to overcome: nobody writes windows phone apps either. I don't have any experience with mobile IEs quirks, but if it's as bad as you make it sound, just sniff the UA and tell the user it is not compatible. Until I see a windows phone show up in my server logs, I'm not going to worry about it.
Overall, web apps as a platform have made a lot more growth than native mobile apps have aince the advent of the smartphone. There's no reason to look at the state of html5 now and say "it'll never work". Sure, there are some things that native is better for, but html5 is a very useful tool and can give a great user experience in a lot of cases, and it's only going to get better.
Unfortunately, in practice, the fragmentation extends into browser incompatibilities. I have first-hand knowledge of this, to the extend that a broken WebKit from Android 2.2 had been forward ported to Android 2.3 on one of the mobile devices we tested.
Android is a good reason to not use HTML5, to be honest. It confuses me deeply that Apple has provided far more HTML5 webapp functionality that Google has- Google ought to be encouraging webapps whenever possible.
> web apps are the great savior that abstract away all the device fragmentation.
I'm not sure if you are trying to be serious or not with this. Do you really believe this is true today? That you can build a mobile experience using HTML that compares to that of a native app?
Certainly there are SOME cases where it makes sense. But for MOST apps, it simply does not. For example, let's say I wanted to build an app that used location and could run in the background. How, exactly, would I build a "web app" that worked across iPhone, iPad, and say 75% of Android devices?
And how is whatever you come up with "HTML5"?
WORA has always been, and always will be a pipe dream. HTML5 gets closer but, unfortunately, due to the dynamics of mobile the target is moving further away.
You can't build web apps that run in the background and expect any sort of browser compatibility, and you know it. That's why you picked that example, despite the fact that I freely admitted in my original comment that there are use cases for which a native app is a better choice. If you are bound and determined to hate the web, good for you.
Yep. My money is on Xamarin. There's a huge opportunity for somebody to make native app development less painful and they seem to be the only player with the experience and talent and tech to make this happen.
I agree, to a point. I primarily work on mobile html5 apps. You actually can make an experience that compares to native in some cases. For example, I created the App.net client http://shrtmsg.com which I believe is on par with the native apps. If you target "latest and greatest" browsers, the subtle browser differences thing isn't that big of a deal.
What I don't get is how people direct their disappointment with the state of html5 towards "html5" as though the idea was to blame, or the idea has failed.
If you want to know why html5 is slow to roll out on mobile it should be blatantly obvious: there is almost no competition. Whereas on desktop competition is fierce. On iOS competition is outright disallowed. On Android it is allowed, but it is harder to get people to switch than on desktop. So this is why we see the "once a year" browser updates on the 2 major platforms.
Have you actually used the html5 site? If not, why are you commenting on it? As far as html5 sites go on mobile, it works really damn well. The only issues I have with it are more a problem with the Grooveshark service as a whole (mis-named songs, incomplete albums).
> To me this is just further demonstration of the failure of HTML5 on mobile. It's been, what, 4 years we've been in the "HTML5 will save us all" hype bubble?
Everyone is moving away from HTML5 (Facebook, etc.). Grooveshark is only moving toward HTML5 because what they do is fundamentally illegal and the app stores have shut them out.
As that article states they couldn't or may have not wanted to pay the cost for streaming EMI's music. Heck there is a ton more money to be made when your not paying the content owners who without their content there would be no Grooveshark. THe masses would care less for it.
In 2012 I am surprised a court ruled in their favor as with Youtube it's focus wasn't just popular music, same goes for justin.tv. THough with Grooveshark their M.O. is access to popular music and now you can get all the music you want for free whenever you want through your mobile device.
I wonder how much longer it will last? Megaupload anyone? Well i'm going to cancel my Spotify subscription and use this instead!
I tried using Grooveshark's html5 web app the last few days.
I thought I might be able to cancel Spotify in which I use everytime I drive (few times a day). Using Grooveshark's web app in the car is NO REPLACEMENT for Spotify, as a playlist doesn't play contiguously and if it does there is a one to two minute delay between each track. Other times between tracks while driving I've had to fidget with the play/pause button to start tracks.
Spotify is the clear winner and I'm happy paying subscriber!
minimal complications is a euphemism for "Any normal user would throw the thing against the wall in frustration."
To me this is just further demonstration of the failure of HTML5 on mobile. It's been, what, 4 years we've been in the "HTML5 will save us all" hype bubble?
Don't get me wrong; I am building a webapp and aspects of HTML5 have made my life far easier than if I were still in 2008. If I had hair I'd still be pulling it out due to the complexities of CSS (even with things like LESS) and subtle browser differences would turn the rest of it gray. But the current state of HTML+CSS+JS on the desktop is pretty good; compared.
We appear to be years away from a similar state in mobile. Between Safari's problems with no JIT support within apps and the fragmentation of Android, coupled with the monstrosity known as IE on WP7 (and WP8 and Win8), it is just not possible to use "HTML5" to build a great mobile experience (and reach a large audience).
My history in working with the W3C (I worked on HTML 3.2 and 4), and my understanding of the asymetric competitive nature of the major players (Apple, Google, Microsoft) makes me believe this situation is not going to radically improve anytime soon.
The upside is dev tool vendors who can help ease the pain should do pretty well (e.g. things like Xamarin (C#) and MoSync (C/C++/JavaScript))...