HTML5 is for the web, not for mobile apps(terlici.com)
terlici.com
HTML5 is for the web, not for mobile apps
http://www.terlici.com/2013/01/02/html5-is-for-the-web.html
13 comments
This isn't even an argument in my opinion. HTML 5 is just fine for most common apps. I've published a couple over the years with Phonegap and was able to get completely native performance from them. Where you have to go native is for super high OpenGL performance things and access to hardware features not yet available in the browser. The problem is that most web developers making mobile web apps don't put in the time and care to really make their projects shine.
I agree. For something where your competition is a million other startups trying to do photo sharing, you need to go native to compete in the user experience. But if you are doing specialized mobile apps for a delivery company or something, html5 may be more pragmatic.
I think the only worthwhile argument is the native look and feel which is extremely hard to emulate using HTML5 (although not unfeasible, see http://pattern.dk/sun or sencha's fb client)
But on the other side it is also very costly to build multiple versions of an app on different native technologies and there HTML5 has an obvious advantage.
Speed is not much of an issue for most of the apps, hardware accelerated CSS can give extremely interesting results (again see http://pattern.dk/sun or FB client)
But overall I agree that doing well with HTML5 requires a good level of expertise.
But on the other side it is also very costly to build multiple versions of an app on different native technologies and there HTML5 has an obvious advantage.
Speed is not much of an issue for most of the apps, hardware accelerated CSS can give extremely interesting results (again see http://pattern.dk/sun or FB client)
But overall I agree that doing well with HTML5 requires a good level of expertise.
This has been discussed to death, but I'd like to add an approach that I haven't seen brought up before.
An HTML5 app/site can be a great MVP. You can build and iterate quickly and even launch it first as a mobile web site. Once you're happy with everything, you can use PhoneGap to turn it into apps. And later you can always build platform-specific native apps. It won't be the perfect experience at all stages, but it can be a more appropriate process for smaller teams. Plus, you can reach a large audience very quickly.
An HTML5 app/site can be a great MVP. You can build and iterate quickly and even launch it first as a mobile web site. Once you're happy with everything, you can use PhoneGap to turn it into apps. And later you can always build platform-specific native apps. It won't be the perfect experience at all stages, but it can be a more appropriate process for smaller teams. Plus, you can reach a large audience very quickly.
And there was an article yesterday about samsung developing their own platform, a new one from blackberry and one from the makers of ubuntu.
If they take off who could afford native versions for all those in addition to android, iOS and windows phone?
A funny thing about that notion.
Blackberry OS, Ubuntu and Samsung Tizen all treat web apps as first class citizens providing JavaScript APIs to access native functions.
(Chrome OS, WebOS, Firefox OS, and Windows 8 also do this and I think Windows Phone 8 does too)
Blackberry OS, Ubuntu and Samsung Tizen all treat web apps as first class citizens providing JavaScript APIs to access native functions.
(Chrome OS, WebOS, Firefox OS, and Windows 8 also do this and I think Windows Phone 8 does too)
I totally agree. If you are developing an app for a corporate customer Native may be the obvious choice. But for the purposes of an early stage startup a Web app has so many advantages that it becomes not a matter of choice anymore. From a startup perspective what you really need is testing and validating ideas, trying different things and maintaining the growth as much as possible. Even using things like Phonegap or app store distribution becomes an obstacle for that purpose.
Besides, we don't even prefer native applications on our PCs anymore. MS Office is undoubtedly superior to Google Docs but most of us rarely run Word in these days.
Besides, we don't even prefer native applications on our PCs anymore. MS Office is undoubtedly superior to Google Docs but most of us rarely run Word in these days.
> Besides, we don't even prefer native applications
> on our PCs anymore.
...and I use my gmail accounts to feed my Thunderbird.
I hate having to sign out/sign in every time I need to switch from personal to professional google account.
I hate having to sign out/sign in every time I need to switch from personal to professional google account.
[deleted]
The author conveniently left away the most important benefit of HTML5 apps: at least in theory, you only need to write the app once to support multiple platforms.
With native, you have to re-implement your whole logic (and redo significant parts of the design) for every smartphone platform you want to support, which is a major cost point.
Of course, you will not get perfect UX on all platforms with an HTML5 app without major tweaking, but still the total amount of work is reduced.
With native, you have to re-implement your whole logic (and redo significant parts of the design) for every smartphone platform you want to support, which is a major cost point.
Of course, you will not get perfect UX on all platforms with an HTML5 app without major tweaking, but still the total amount of work is reduced.
> at least in theory, you only need to write the app once
> to support multiple platforms.
> With native, you have to re-implement your whole logic
The problem with mobile HTML5 is that the frameworks aren't nearly as sophisticated as their native counterparts. There's nothing that even touches UIKit on the web. Things as simple as drawing a UINavigationBar-style gradient prove to be unbelievably challenging. On a technical level, it's completely doable, but it requires a lot of time, effort, and designer time. Multiply this out by all the little niceties like animations and embossing all of the buttons and you've got a big job ahead of you.
All the technologies are in place to have a native-quality HTML5 app -- we have canvas to draw pixels however you want. We have WebGL to do any 3D rendering. We have blazing fast JS engines. We have hooks for things like location and camera roll access. The problem is that it's really hard to justify the investment of building out a UIKit-quality framework for the web. Apple and Google can spend hundreds of millions of dollars on their frameworks because it means they'll sell more devices/services. But it's really hard for someone to justify doing so for the web, where there's no ROI for your platform.
All the technologies are in place to have a native-quality HTML5 app -- we have canvas to draw pixels however you want. We have WebGL to do any 3D rendering. We have blazing fast JS engines. We have hooks for things like location and camera roll access. The problem is that it's really hard to justify the investment of building out a UIKit-quality framework for the web. Apple and Google can spend hundreds of millions of dollars on their frameworks because it means they'll sell more devices/services. But it's really hard for someone to justify doing so for the web, where there's no ROI for your platform.
My comments from the article:
> I’ve developed apps both native and not native for all platforms, and html5 apps don’t deliver faster results. Developing in javascript is not faster, in fact making a complex app takes about the same time or even more.
This is really a matter of opinion. Obviously if you approach an Objective-C developer and ask them to build you a HTML5 app it will probably take more time, but for someone such as myself who doesn't know and doesn't want to learn Objective-C it will be faster to use HTML5 and Javascript.
> Learning native technologies takes time, but that is a time well invested in something that you will use over and over again to deliver results.
Again, this is really just an opinion rather than fact. If you want to learn and write your app in Java, Objective-C, C# and whatever the Ubuntu phone will use then go ahead. However, I quite happy to write my apps once in HTML5, knowing that there will be some issues, but that I can get it done a lot faster than writing once for each platform.
> HTML5 does not look and behave like native app, never
This really isn't an argument any more. I agree that to make stuff look like native components (and as pointed out by other commenters to behave) is harder in HTML5, however take a look at apps such as Path or Foursquare. They don't look like native apps at all either. Making things look native isn't necessarily something you should be striving for.
> I’ve developed apps both native and not native for all platforms, and html5 apps don’t deliver faster results. Developing in javascript is not faster, in fact making a complex app takes about the same time or even more.
This is really a matter of opinion. Obviously if you approach an Objective-C developer and ask them to build you a HTML5 app it will probably take more time, but for someone such as myself who doesn't know and doesn't want to learn Objective-C it will be faster to use HTML5 and Javascript.
> Learning native technologies takes time, but that is a time well invested in something that you will use over and over again to deliver results.
Again, this is really just an opinion rather than fact. If you want to learn and write your app in Java, Objective-C, C# and whatever the Ubuntu phone will use then go ahead. However, I quite happy to write my apps once in HTML5, knowing that there will be some issues, but that I can get it done a lot faster than writing once for each platform.
> HTML5 does not look and behave like native app, never
This really isn't an argument any more. I agree that to make stuff look like native components (and as pointed out by other commenters to behave) is harder in HTML5, however take a look at apps such as Path or Foursquare. They don't look like native apps at all either. Making things look native isn't necessarily something you should be striving for.
> I quite happy to write my apps once in HTML5, knowing that
> there will be some issues, but that I can get it done a
> lot faster than writing once for each platform.
Source: I am long-time web developer before turning to full-time iOS programmer.
HTML was created to markup the structure of large texts…
Of all of the potential arguments against HTML n, this is by far the weakest. What HTML was created for is utterly irrelevant in 2013.
Of all of the potential arguments against HTML n, this is by far the weakest. What HTML was created for is utterly irrelevant in 2013.
Authors Response:
"However, I quite happy to write my apps once in HTML5, knowing that there will be some issues"
If those issues ruin the user experience, I wouldn't be happy. Laggin app on a powerful device with very few other things running is such an issue which often happens on HTML5 apps and if you go to a less powerful device it becomes worse.
Not sure what you were looking at but Foursquare looks like all other native apps on both iPhone and Android, so your example does not stand.
The idea is to build apps that use familiar controls and UI patterns. This helps new users find their way around quickly with almost no learning curve.
"However, I quite happy to write my apps once in HTML5, knowing that there will be some issues"
If those issues ruin the user experience, I wouldn't be happy. Laggin app on a powerful device with very few other things running is such an issue which often happens on HTML5 apps and if you go to a less powerful device it becomes worse.
Not sure what you were looking at but Foursquare looks like all other native apps on both iPhone and Android, so your example does not stand.
The idea is to build apps that use familiar controls and UI patterns. This helps new users find their way around quickly with almost no learning curve.
I love using HTML5 instead of using apps which require installation etc. I really hate installing app for every darn site.
Oh well, where's Hacker News App? It would be great idea to do it for every imaginable mobile platform. What are you guys waiting for?
Oh well, where's Hacker News App? It would be great idea to do it for every imaginable mobile platform. What are you guys waiting for?
> Oh well, where's Hacker News App? It would be great idea
> to do it for every imaginable mobile platform. What are
> you guys waiting for?
No benefits to making an app in HTML5? This is a joke.
The biggest one for me is choice for the consumer.
They can use any device so long as it's browser conforms to HTML5 standards.
The biggest one for me is choice for the consumer.
They can use any device so long as it's browser conforms to HTML5 standards.
Yes, if you have 100 developers then by all means create native versions for every device, but as a single developer there is no other way for me to provide my app on PCs, phones and tablets other than HTML5. If you're making a one-off game it might not matter for the user that they can't play it on their other devices, but when you provide a service that needs to be available on the go and accessible anywhere, you really don't want to alienate your customers with "only available on iPhone".
I'm building an HTML 5 app as a side project right now, and I intend to target mobile with it, in addition to browsers. I'm a professional web developer, so it makes sense for me.
There are a few wrappers that will translate HTML 5 calls to native calls when run on a mobile phone. The one I'm working with, CocoonJS, actually provides pretty good performance. Granted, you need to be building your app as an HTML 5 canvas, but if you're doing a game, you're likely to be using one anyway.
As far as missing capabilities go, CocoonJS is getting pretty all-encompassing. For example, I can access the camera of the phone. I can do in-app purchases, and use native ad platforms. I can access the accelerometer and detect orientation changes.
Perhaps missing the "real" UI of the phone does make it feel a little foreign, but in my case, I'm not particularly worried. Most games I've played on my Android phone don't use them either, even when they're fully native.
I would say if you have the resources, or you need to use every drop of performance you can get, go native. In my case, that's not necessary and saves me from having three codebases.
Use the right tool for the job. That tool will change based on your audience and needs.
There are a few wrappers that will translate HTML 5 calls to native calls when run on a mobile phone. The one I'm working with, CocoonJS, actually provides pretty good performance. Granted, you need to be building your app as an HTML 5 canvas, but if you're doing a game, you're likely to be using one anyway.
As far as missing capabilities go, CocoonJS is getting pretty all-encompassing. For example, I can access the camera of the phone. I can do in-app purchases, and use native ad platforms. I can access the accelerometer and detect orientation changes.
Perhaps missing the "real" UI of the phone does make it feel a little foreign, but in my case, I'm not particularly worried. Most games I've played on my Android phone don't use them either, even when they're fully native.
I would say if you have the resources, or you need to use every drop of performance you can get, go native. In my case, that's not necessary and saves me from having three codebases.
Use the right tool for the job. That tool will change based on your audience and needs.
This is a horrendously presented argument with close to no interesting content. Aside from being voted up by people with an HTML-axe-to-grind, what's the point of this?
One particular point that gives me a laugh -
No matter how much you optimize your app, it will always be slower than a native one, and the users will feel the difference.
This is a broad claim that is unsupported. Both native and web apps are layers of abstraction over OS rudiments. There is nothing stopping both from offering identical performance, however HTML usually falters simply because people layer on abstraction over abstraction, where they take the simplest approach with the native app.
One particular point that gives me a laugh -
No matter how much you optimize your app, it will always be slower than a native one, and the users will feel the difference.
This is a broad claim that is unsupported. Both native and web apps are layers of abstraction over OS rudiments. There is nothing stopping both from offering identical performance, however HTML usually falters simply because people layer on abstraction over abstraction, where they take the simplest approach with the native app.
I always thought of all this native fad to be temporary. Can't we expect with browsers to mature and device performance to improve, to have a platform that's more than good enough to build mobile apps in the future? Anyways, I'm hoping that the crowd regains some common sense and starts advocating the web over these damn fenced gardens.
Write your business logic in C# and just build the View for every platform with native components. Sounds like the ideal tradeoff for me!