HTML5 is for the web, not for mobile apps
terlici.com
terlici.com
> 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.
The point still stands it really pays of to learn native framework: the sole purpose for it's creation was to be used in web apps. HTML was created to markup the structure of large texts…Source: I am long-time web developer before turning to full-time iOS programmer.
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.
"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.
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.
Yep, in theory. And the further away from web page your app is the more tweaking you will need. > With native, you have to re-implement your whole logic
And with HTML you have to reimplement all the components wich framework provides — highly specialized and optimized for performance.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.
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)
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.
Who are those "we"? For the last couple of years I am using desktop apps to access Gmail…I hate having to sign out/sign in every time I need to switch from personal to professional google account.
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.
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.
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.
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.
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?
Did you check before writing that? There are 20 apps in AppStore for HN.
I had an idea to write one myself, because I was not happy with the offering at the time. Funny, but I ended up using http://hackerwebapp.com —but it only confirms the point, because HN is a website.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.
Write your business logic in C# and just build the View for every platform with native components. Sounds like the ideal tradeoff for me!