In every one of those comparisons, the new technology offered a fundamentally new potential that the old technology lacked. Even in 1965, people could appreciate automation. Even in 1988, people could see the potential in putting a computer on every desk. Even in 2002, people could see that web apps were accessible wherever the web was accessible, instead of needing to be installed separately on every computer where you wanted to use them.
What do HTML-based apps offer the user that native apps don't? They're easier to create and update, and they offer an inferior user experience. It may be an exciting new paradigm for developers, but from a user's point of view, it's just a cost/quality trade-off. The only distinction that is meaningful to users is installed app versus web app.
> They're easier to create and update, and they offer an inferior user experience.
No, they're not. Good web apps have never been easier to create but what they offered was extremely easy distribution. What Apple did on the iPhone was make distribution almost as easy as going to a web page, knocking out HTML-based apps best advantage.
If you account for the requirement to reliably maintain per-user state, native apps pull into the lead. In most cases, they can store state on the device with no extra work from the user, whereas web sites require tedious signup to remember even the most trivial personal settings.
Also, don't discount the joy many consumers get from shopping and owning things.
Seems like the article is about HTML5-based mobile web sites vs. native apps, not HTML5-based-apps vs. native apps. (It generally fails to define what it means, but I'm guessing they mean web sites given the reference to Apple telling developers to make HTML5 apps for things they won't let into the store. At least on iPhone, not-in-store equals not-an-app.)
Lower cost of development and lower cost of maintenance translate into more (and better) services for end users. It's unlikely that web apps are going to compete with "sovereign" apps on a phone like email or an RSS reader. But for a niche or transient application (like say, making a flight reservation or looking up your order status on a web site) the web apps probably are a better experience.
This has always been true on the desktop as well, until recently - you wanted a local email client and text editor, but you were fine using the web to access Wikipedia. (That's changing now, of course.) It's not sexy but _most_ web services / sites are transient, not sovereign, software and will likely translate better to a web app than a native app.
1996: Let's be honest: right now, most Java applets are a joke when compared to their native counterparts.
That's still true, and it's a better analogy. HTML5 in 2010 and Java applets in 1996 both promised portability at the cost of a nonstandard UI.
For HTML5 to become prominent, it needs to offer something to users that iPhone apps don't. Users don't care about portability or ease of multiplatform development.
HTML is the UI, and it's hardly "non-standard". If anything, HTML is the most widely used interface style in the world.
I do agree that HTML 5 apps should not be trying to emulate native desktop or mobile apps. Instead, they should be what they really are: native browser apps.
<...Users don't care about portability or ease of multiplatform development.
CONSUMERS dont care about this - enterprise and medical applications should.
When you access an app/session from one device and seamlessly transition to another device and the same session, then the beauty of such a system will have impact on efficacy of certain tasks.
The consumer use of the iphone and android mobile devices will be strong and lasting - but to make significant impacts on how things are done in other verticals will not only be important - but also highly profitable for some.
The author mainly focuses on mobile devices. I would like to add that even on desktop, native apps feel way better than their web based counterparts. Switching from Google Reader to NetNewsWire, from GMail to Sparrow, Twitter web to Twitter desktop app, SoundCloud web to SoundCloud native app, are just some examples. Ideally, data synced on the web, with clients on the desktop seems like an ideal possibility to me. Or maybe its just me who thinks this way.
Well, you should use whatever rocks your boat. Personally, I think its a little weird that Twitter Web consumes a lot of CPU as compared to the Desktop app. As for GMail, I find switching between labels (on the web interface) very slow, if you have a ton of labels/emails. So instead of setting up Gears or something, I just started using a native app.
ChromeDeck is pretty great. It's an HTML5 TweetDeck app in the Chrome Web Store that feels almost native. Multicolumn layout for your lists, inline video / photos, and desktop notifications with sound.
https://chrome.google.com/webstore/detail/hbdpomandigafcibbm...
What native app do you use? I use Apple Mail since IMO it has the best IMAP support of the lot, but archiving and filing under labels is a pain. Apple's way is to use drag and drop, which doesn't rock my boat.
Mailplane rocks. It's more of an SSB than a pure native app like Twitter for Mac, but it has a lot of nice little integration points with Mac OS X.
It's not cheap, but it's well worth the price (its also due for a paid upgrade soon, IMO, as I have not paid anything beyond the first version three years ago).
That's an unfortunate side-effect of the Mac app store. It's too bad, because functional demos was one of the nice things about the Mac software ecosystem.
Give it a few days, that was literally only released last night, and they're still waiting for the ad supported version to be approved. Up until then it was in open beta.
"On mobile, as I see it there is no contest. Web apps make no sense."
Do you say that because of the expectation that to use a web app you have to have a working Internet connection?
[NB I'm not trolling, I'm genuinely interested, my current close-to-launch side project is a service that allows you to build data-aware HTML5 webapps for mobile devices - these work perfectly well offline]. :-)
The biggest argument for mobile apps tends to be their ability to interact with the phone. For example, my Gmail app will tell me in my notification bar that I have a new email, and Tweetdeck will tell me when someone replies to one of my tweets. To my admittedly limited knowledge of mobile phones this cannot be done by a web app.
I still wish you good luck, as most apps in wide use on the iPhone and Android simply shouldn't "have" to exist (apps for news sites, shopping carts, etc) because they can be done just as well, if not better through a web app. If you succeed, I might be able to buy my grocery shopping on my phone on the bus to work rather than being told I can't because I use Android and can't use the iPhone app.
I would say that the main points are performance, access to hardware apis, and - the most ignored one - ease of install.
There is no familiar way for users to install a web app (unless they are a bit tech savvy). My uncle adds favorites to its home screen to go to web pages, he knows that, and its impossible for him to think that a website is a website and if you add it to the home screen "turns out" to be like an application.
If a clearer interface was provided in the mobile phones, something like identifying webapps with a meta tag, or something, so that the phone could know and offer the user to install the app, the barrier for mobile webapps adoption could be lowered a lot.
I agree that "installing" an offline web app on something like the iPhone is a bit odd - largely because there is very little you have to do. You can just install it as a Bookmark or on the Home Screen (where it can have it's own logo etc. - like a normal app).
I'm more targeting getting structured (or semi structured) data onto a mobile device, possibly make the content editable and allow changes to be sync'ed back to the server to be shared with others or collected via an export or API.
e.g. I can take an Excel spreadsheet, turn it into an offline HTML 5 app, allow users to edit the data, sync all the changes and export it back out as a modified spreadsheet.
No, I say it because none of the points I mentioned are relevant on mobile. At the moment I'm never without good Internet access. The biggest advantage of web apps is the idea that wherever you have a modern browser and a net connection you get the same experience. But that isn't true on mobile since most sites have dedicated mobile interfaces which aren't as usable as their desktop equivalents due to hardware constraints. In addition, since I'm never without my mobile, a native app is by definition always available, negating much of the advantage of the ubiquitous web model.
On the other hand, I do expect my native apps to either sync or act as a client for net based services.
At the moment I use precisely zero web based apps on mobile with the exception of gmail, which I resort to only when searching since the iOS mail client search is useless.
Thanks - I misunderstood the point you were making.
On the point of interacting with the hardware, at least on iOS, you can get location data into your webapp and there are cunning ways of getting access to the camera.
Web apps have been "oncoming" for over a decade now. The buzz was the same in 2000, but instead of HTML5, it was DHTML or Java applets or ActiveX that was going to completely replace traditional shrink-wrapped software.
The web is a phenomenal success. It has created a massive new ecosystem and changed the social order of the world. It also catalyzed the collapse of the Windows empire, something that had been looking for a way to happen for a while. But that doesn't mean the web will replace Windows as the One True Platform.
Windows has some particular flaws that ultimately brought it down, the most significant being, in my opinion, its model of app distribution and installation. All of the new platforms adequately address this issue.
But the new native platforms also have a fundamental advantage over the web. They are designed from the ground up to support applications that can take full advantage of the latest hardware capabilities and present ideal user experiences. The web was not designed for applications at all and only by hiding the mountain of legacy cruft under layers of hacks has it even approached what native apps can do.
The web has its strengths -- it makes it super easy to publish gobs of content that is accessible to anyone, anywhere, anytime. It's very good at universal, generic interaction. But it always has and always will lag behind in rich, client-specific functionality. As fast as new capabilities can be finagled into browsers, new features, uses, and form factors will come to devices. You may be able to imagine some future in which widely deployed browsers can do any given thing, but you have to account for change across the whole technology spectrum. It's not just about possibilities, it's about pace.
There is no need to force a dichotomy. We have native apps, we have the web, both have their place and neither are going away any time soon. If you're a developer, learn them both and choose the technologies that are right for each individual project.
Desktop apps got their lunch eaten by the web based purely on the deployment and portability benefits, the UX still lags behind to this day. Granted the app store model mitigates the installation pain, but portability is non-existent, so my hunch is that HTML5 will pick up steam over the long-term as mobile browser support and developer knowledge coalesces.
Interestingly I think a lot of apps could go HTML5 today, were it not for subtle issue of web pages being awkward on mobile. Bookmarks and google searches just don't have the immediacy they do on a computer, so the very fact that native apps are easier to get to is a significant hurdle in terms of user behavior, even if it is possible to develop a excellent mobile-browser-based UI.
It's possible Apple, Google, et al could parlay this into a longer dominance of native apps, but that raises two questions: do they really care enough to attempt to sabotage HTML5? and will developers put up with the hassle of the fragmented mobile landscape? It's unlikely any of them would cripple their mobile browser ala IE6 because web is important one way or another, but if everything shakes out to an iOS/Android duopoly then developers may decide the pain is worth it. So no bold predictions from me, but it's definitely an interesting question.
I'd argue that portability is a non-issue. iPhone developers know that to make sales to iPhone owners, their applications have to visually and functionally integrate seamlessly into that environment. The same is true for Android owners. Anyone writing a portable HTML5 application is at an extreme disadvantage. And the fact is, the effort necessary to make an excellent mobile browser based UI that integrates seamlessly with multiple platforms is more work than simply rewriting the app for multiple native platforms.
That depends on how many platforms there are. If it's just Android and iPhone then the native apps just need a few perks to make it more attractive. On the other hand, if there are 5 reasonably balanced platforms that all support HTML5 well, then you are automatically cutting your market size by 80% which is a tougher call.
> And the fact is, the effort necessary to make an excellent mobile browser based UI that integrates seamlessly with multiple platforms is more work than simply rewriting the app for multiple native platforms.
Today. But HTML5 will steadily improve, standardize, and develop a rich open source tool ecosystem. This will never happen with proprietary native platforms. Sure Apple can go the Microsoft route, and sink an incredible amount of money into it's dev tools in order to create a superficially better experience, but if web development is anything to go by, developer tools are something that thrive on open collaboration; very few people would say that .NET is generally superior to open source web development frameworks for example.
It's not as straight forward as you describe. The "instantly and globally released" nature of web apps is both an advantage and a disadvantage. What if I have a client that needs to keep the only interface for some reason? It's easy to just not upgrade, provided you have that option...
Most commericial web sites already deal with this issue - they have new/beta features that are initially only visible or available to a subset of users. Google Apps lets you choose if you want the new or old version... it's not impossible to let users stay with a static implementation, but it's just generally not worth the trouble.
Conversely, native apps suffer from the problem that once you deploy a package out the store, you have to support it (unupgraded) for the foreseeable future. That creates its own bucket of issues.
Oh absolutely; but when did I describe it as straightforward? If it was such an obvious slam dunk win it would have happened faster and Microsoft would not have been caught with their pants down. The gist of my point is that over time, you have a cross-platform, no-install environment that clearly has a ton of disadvantages, but it cleans the clock of superior established platforms simply due to a little less user friction.
This argument is often advanced by people against automatic updates, but I would suggest that its such a small minority of situations and people that its not worth considering unless you operate in a very specific niche.
Am I the only one that thinks that mobile browser development is possibly not moving as fast as it should. I mean dual core phones with over a gig of ram are being released and these webapps performance are still bad.
Steve has created a new revenue stream for Apple, not only on developers fees but mainly in app purchases and percentage of sales. WHY would he give that up ? So while he is telling everyone how much he loves HTML5 and is promoting it, there are no intentions for apple to ever promote web apps other than lip service. Its really up to developers to stop this developer lock in, and refuse to build native apps. Build for the web, and do whats best for the future of mobile. Other than games and few apps that rely on hardware, most are just layouts calling webservices in the back end.
> Its really up to developers to stop this developer lock in, and refuse to build native apps.
Well, many developers has found that is easier to make money on mobile apps, than with their web counterparts. Why would they give that up? Is again a conflict of interest.
I hope the web will came back stronger after the native apps crisis, till them I will try to make money in both ends of the spectrum.
It is a lot easier for a corporation to mandate an API, slap it into an SDK, and kick it out the door with guns-blazing full hardware accelerated support.
It is another thing to create an open standard that seamlessly and securely interoperates with absolutely any browser on any device.
The great mistake of the author is that he assumes it is a spec contest. Native apps will always have a slight advantage, but "having to have one or two developers per platform" is the exact reason why the web will win out.
They aren't at war because they don't have the same goal. Native apps will never be able to be universally distributed across platform or device. Period.
True. Which is why the Netflix app is basically just an HTML app with a thin native wrapper.
When native means only iOS then it make sense to just write a native version instead of a mobile web app, but when it means having to write a version (or two) for iOS, one for Android, one for Blackberry and one for Windows Mobile 7 then it makes a lot more sense to write a mobile HTML version that works on all of them.
On a side note, despite the native app hype, Apple initially did not support third party native apps. Apple has always supported web apps on the iphone.
It's not hype if it works. Web apps are hyped because they over-promise and under-deliver.
If I had a penny for every comment on HN that said how web apps are going to take over the world... finally someone woke up to the reality and wrote a TC article.
Haven't we seen this movie before? At one point the web was a complete joke to the average user and now we have an incredibly diverse ecosystem of web applications.
I think that applications that require high performance will always require a native app, but for the simple business applications out there mobile web apps will certainly do just fine. The devices will get faster, the designers will work out the user interface issues, and the programmers will make it easier.
The next five year will be dominated by native mobile apps, after that I really don't think we are all going to continue to pay the expense of developing on multiple platforms.
God... I LOVE HTML5 and Javascript/CSS etc, I wrote a couple of PhoneGap based apps, and to be fair I think 70% of the apps in the apple app store (Not counting games) can be created using just HTML5, most are simple list/todo/map/location apps and so on.
I want to write only in HTML5 to be fair, why? Deploy to multiplatform with small changes, no Objective-C or Java headache ;-P , but... it just feels as if it's not quite there yet, we are missing a little bit of performance in JavascriptCore, for animations (CSS the accelerated transitions work quite well) heck you can even achieve smooth parallax scrolling with some (mostly) css tricks on mobilesafari/UI WebView.
Now what's really missing here is a standard animation container, instead of doing CSS-sprite animations by creating loops that modifies background-position on elements (which will awlays be slower) there should be some other thing that lets you generate an animation (As a sprite or whatever) then play it accelerated in the DOM or Canvas... instead of using javascript to do everything.
Canvas performance is still horrible, but perhaps when apple comes around add adds more natively hardware accelerated stuff for the canvas and so on we could do some neater stuff.
Whats my point, you can develop the vast majority of "apps" with no problem what so ever for iPhone/Android with HTML5, you do need a "FrameWork" to deploy to the appstore, such as PhoneGap, but in the end it's basically javascript/css.
Games on the other hand is harder, we're still missing a standard animation container, performance amongst other things. Add WebGL on top of this and you can probably come up with some cool stuff, not sure if WebGL is supported on the latest iOS/Android?
For me, Javascript/CSS/HTML is the UI future of apps, the backend can be whatever, Java/Python/PHP/C++, but for UI stuff, Javascript/CSS just tastes damn good and gives you a lot of freedom... my 2 cents.
Um, well thats fine and thats what I am using, the problem is that only a few are hardware accelerated (Opacity, translate3d) are the ones I know are hardware accelerated in iOS at least.
What I want is some sort of container format for making animations, so I don't have to "hack" with background-position for a running animation as an example, sort of like GIF is a container for animations but obviously we'd need some sort of container that we can interact with... using javascript :P if that makes any sense.
I would build my app in HTML5 for the iPhone if image uploading was possible (on iOS Safari all file input fields are disabled).
Considering that this feature is crucial for my project's success (i.e. the ability to take a photo and upload it with geolocation), a web app for the iPhone is the same as not having one in the first place (or worse, since it is crippled).
And for example, another limitation is that you cannot automatically put the focus on an input field, unless it originated as a response to a user action. Why is that? There are instances where I just want the user to start typing immediately after a page loads (typing itself is hard enough, finding the input element and tapping on it is an extra chore that I could do without).
HTML5 and other browser technologies are fine, if only phone makers would not put stupid limitations on what you can do with it.
The official explanation I've seen is that it would be jarring to the user for the page to automatically zoom and/or scroll by popping up a keyboard when the user isn't expecting it. This might make some sense for websites, but unfortunately has a side effect of crippling web apps. :(
Legitimate question: Would Apple allow you to put the lightest possible wrapper around an HTML5 app and charge for it through the App Store? Or would the review board tell me that I should just make the app available through the browser instead? I ask because customer expectations are set up to make it far easier to charge for a native application. Even if that isn't your primary source of revenue, charging a dollar or so for the application could help recoup development costs.
Gmail is by far the best email client I've used. I actually like tweetdeck online version...
But I still use a native chat client and IRC client. I still prefer an office application (LibreOffice) to Google Docs.
I personally think more and more web apps are going to push the boundaries and we'll see more things like Tweetdeck, but I also see a real native need..things like music players and video players etc. I prefer Google reader b/c I have the same experience on everything (including my iPhone and Nexus S).
If I had to wager, and ironically, I do (my job after all), I think there is going to be an uneasy balance struck where some people make hard stances and only write native apps or only support this platform just as they've always done IF there application is more than something that pushes data around. But if their app is very much something that pushes data around (like JSON or something) I see it going the route of Tweetdeck/Gmail.
I see this for a couple of reasons but mostly about 1. distribution model and 2. shoestring budgets. eople
Now, mobile is a bit of the same as desktop, but more or less lagging by a generation. I don't see anything non-native winning in mobile for quite some time (as it didn't in desktop for what, 20 years?). Mobile is quite young and needs time to grow up. That is part of the reason why I think we are going to see at best three dominant platforms: iOS, Android and something else (not convinced it is windows, meego or anything we've seen yet).
No easy answers here and people are going to be second guessed quite a bit no matter their decisions in this realm. Heck, we've seen it with Nokia today. People are calling for Nokia to adopt android instead of doing their own thing. Well, doing their own thing could be the best or the worst thing for them, but no matter what they choose, it will be open for questioning (no easy choices).
Also states "But the fact that very few, if any, choose to go HTML5-only is telling" and then "Facebook is seemingly all-in on HTML5 (at least going forward)" which seem contradictory statements.
How can it be telling when no one uses HTML5 completely, and then you follow it with an example of the hottest thing in tech since Windows going all HTML5. Doesn't make sense.
I'm currently developing an HTML5 tablet app for iPad and Android, and so far the biggest limitations are coming not from the HTML5 spec, but WebKit itself. Specifically, there is no way to programmatically trigger focus on form fields, and input fields for some reason do not respond to ontouch events.
Still, I consider it a good gamble long-term. Even though I'll have to degrade gracefully for devices that don't support multi-touch or CSS 3D transforms, it's still less work than trying to maintain two codebases, and I get to use the dev stack I know best.
I tested it on Android, and its WebKit also lacks programmatic focus on input elements. Didn't test the ontouch problem. Mobile Firefox does the right thing.
The funny thing is I intend to package my app in native wrappers and distribute on both App Store and Android Market, so Apple does stand to make money. But, they still lose exclusivity, and it's unfortunate that they have a strong disincentive against improving HTML5 as an app platform.
I dont mean to comment on your situation specifically… I'm simply pointing out you're at a disadvantage:
1. Mobile Safari isn't feature complete
2. Apple has no incentive to make it feature complete
From the perspective of a small (web-focused) dev shop that is getting lots of RFQs for mobile apps, I think there are really two main reasons why our clients and prospective clients want to have a mobile app developed. Either they:
1. Have something (a website, a business, a city department, whatever) that they want it to be "on mobile", i.e. they need a mobile app just because they need to cover the mobile angle. However, the mobile app itself is not usually the core revenue strategy, it's just part of the bigger picture.
2. Or, they want to sell a mobile app that is not suitable for building with HTML5. I.e. the app is the revenue-generator, and it must be performant/integrate closely with native hardware/etc. (such as a game).
I think we can satisfy the people in category 1 by building HTML5 apps, and using Phonegap if they want them to be available in app stores.
I think we can satisfy people in category 2 by developing native iOS apps for sale in the Apple App Store, since from what I can tell, this is the only App Store that really generates money.
People who want native apps on non iOS devices, for whatever reason, are probably people we get a subcontractor to handle, or even take a pass entirely.
I saw someone post on a show your web app type thread the other day telling the developer to make his website an iphone app and sell it for 99cents. At first I was going to comment that it really didn't need to be an iphone app, and that it was fine as a website but then I thought about it and really thats the only way you'd get people to pay for the service.
Apple have trained people to pay 1 or 2 dollars for mobile applications, and thats great - but if you said to someone you need to pay a dollar to use this website they'd leave straight away.
So now you have the situation where it's in both the developer AND Apple's best financial interests to make native applications - how is the web on mobile going to come forward? What incentive does Apple have to make HTML5 run great on their devices when they earn a chunk of native app sales? Additionally, if they threw resources at it, they'd probably end up contributing a bunch of code back to Webkit which would immediately be used by their biggest competitor.
At the end of the day, the distinction seems rather stupid. What is "native" anyway? We are all using frameworks, Cocoa, Android or HTML5. We are not using assembly code, after all.
So if the capabilities of the "HTML5" framework get better, the distinction will fade away. WebGL is on it's way, and so are javascript interfaces to the mobile hardware.
Cocoa and Android are the native APIs of the platform. HTML5 is an abstraction on top of Cocoa and Android; it should be obvious that it's not at the same level. HTML is the least common denominator across all platforms and is a sandbox on top of that. The distinction is a lot stronger than you make it out to be.
Android is not the native API, at least the Java API is not. What magic capabilities are there on these devices that are forever beyond the reach of JavaScript? Does Cocoa expose all possibilities of the phone to the developer (I don't think so...)?
Native app development is not only difficult, it’s expensive.
These days, if you’re going to do native apps, you at least have to support iOS and Android. That means at least two developers for each different language, and preferably more.
Cocos2D may well be shaping up as a good cross-platform environment supporting both iOS and Android. Add some more GUI libraries, and it would be dandy for non-game apps. (Javascript)
The Unity 3D engine could be leveraged like this as well.
The one thing that really surprised me in this whole "web/native" debate is the new concept of "installing" web apps (just links?) from the "Chrome web store" ... while all along hearing things like "installation is a big hurdle for most people, web is the way".
Why does Siegler comment on technology he doesn't understand? The holy grail of mobile development would be a minimal runtime that would work on all the mobile platforms which developers could use to factor out the common base of their applications. Something like a native webkit with some kind of sandboxed privileges giving the illusion of a native OS. Currently the only thing that comes close is html/javascript and I know android has a way of bridging Java and Javascript code and wp7 also has the same capability except with C# and Javascript. WebOS is all basically javascript so there is nothing to worry about there and I can't comment on iOS but I'd be surprised if they didn't offer similar capabilities.
I think at this point it's a little too soon to make comments like Siegler. The space is still young and developers are still figuring out the proper way to do cross-platform mobile development.
Yeah there are ways to bridge Javascript and Objective-C, like PhoneGap does, but it's not "automatic", you'd have to code each method by method etc ... blegh I hate this, this should be transparent! :P
2007: Let’s be honest: right now, most native mobile apps are a joke when compared to their desktop counterparts.
2002: Let’s be honest: right now, most web apps are a joke when compared to their desktop counterparts.
1999: Let’s be honest: right now, most Windows apps are a joke when compared to their Apple counterparts.
1993: Let’s be honest: right now, most client-server apps are a joke when compared to their multi-user counterparts.
1988: Let’s be honest: right now, most PC-based apps are a joke when compared to their mini-computer counterparts.
1983: Let’s be honest: right now, most mini-computer-based apps are a joke when compared to their mainframe counterparts.
1978: Let’s be honest: right now, most on-line CICS-based apps are a joke when compared to their batch counterparts.
1965: Let’s be honest: right now, most computer-based apps are a joke when compared to their pencil and paper counterparts.