9 ms·
HTML5 Is An Oncoming Train, Native App Development An Oncoming Rocket Ship
- siddhant 16y agoThe 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.
- jpeterson 16y agoCouldn't disagree more. I switched to Twitter web and Gmail from desktop counterparts several months ago, and haven't looked back since.
- siddhant 16y agoWell, 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.
- jace 16y agoWhat 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.
- siddhant 16y agoSparrow (http://sparrowmailapp.com http://sparrowmailapp.com). Its quite literally, a godsend.
- keyle 16y agoYeah but $10? Where did try before you buy go?
- loire280 16y agoThat'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. I hope demos are a feature they're working on.
- tofumatt 16y agoThere's Sparrow Lite, an ad-supported free version that's set to release in the Mac App Store but hasn't been approved yet. Seems they're working on a non-Mac App Store version too. http://blog.sparrowmailapp.com/post/3197243085/sparrow-1-0-is-now-available-on-the-mac-appstore http://blog.sparrowmailapp.com/post/3197243085/sparrow-1-0-i...
- ptomato 16y agoGive 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.
- halostatue 16y agoMailplane 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).
- cglee 16y agoPostbox
- junkbit 16y agoChromeDeck 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/hbdpomandigafcibbmofojjchbcdagbl https://chrome.google.com/webstore/detail/hbdpomandigafcibbm...
- kenjackson 16y agoJust depends. The more of the app's data and interaction is cloud based, the better web apps will be.
- MrScruff 16y agoI would say that on the desktop web apps are 'good enough' for me to prefer them over desktop apps for several reasons: - high performance hardware - mouse and keyboard - larger screen - consistency of experience on work/home machine On mobile, as I see it there is no contest. Web apps make no sense.
- arethuza 16y ago"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]. :-)
- joakin 16y agoI 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.
- arethuza 16y agoThanks for the feedback. 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.
- loewenskind 16y ago> 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. You're not the only one.
- gte910h 16y agoHas richer interactions? Yup Works across the 3-5 computers I use daily? Not really well. Really the only desktop app which does any of this well, is perversely google chrome.
- fingerprinter 16y agoI think it varies greatly. 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).
- inkaudio 16y agoOn 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. Apple first supports Web Apps in 2007 http://www.apple.com/pr/library/2007/06/11iphone.html http://www.apple.com/pr/library/2007/06/11iphone.html News about the app store coming 2008 http://news.cnet.com/8301-13579_3-9798932-37.html http://news.cnet.com/8301-13579_3-9798932-37.html
- blub 16y agoIt'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.
- dasil003 16y agoIt's not all about capabilities. 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.
- loewenskind 16y agoIt'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...
- steverb 16y agoYou version. Move the old version to url/oldversionnumber and tell that client that they can keep using the same old same old at that url.
- boucher 16y agoThis 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.
- u_fail 16y agoAm 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.
- pdelgallego 16y agoYou are not the only one. > 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.
- marknadal 16y agoIt 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.
- steverb 16y agoTrue. 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. And then there's the same old update headache.
- adriand 16y agoFrom 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.
- leoc 16y agoIt's odd not to at least mention Native Client and WebGL in this context.
- deleted 16y ago[deleted]
- nerdyworm 16y agoHaven'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.
- bad_user 16y agoI 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.
- lukifer 16y ago> Another limitation is that you cannot automatically put the focus on an input field, unless it originated as a response to a user action. This is actually an intentional limitation of all mobile versions of WebKit, and it's driving me nuts too. See: http://discussion.forum.nokia.com/forum/showthread.php?127724-javascript-set-focus-to-input-text-box http://discussion.forum.nokia.com/forum/showthread.php?12772... 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. :(
- lukifer 16y agoI'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.
- Me1000 16y agoThis is because of artificial limitations placed on browser apps by iOS. Think about it, Facebook, one of the largest photo sharing WEBSITE has a native app. Why? Because you can't upload photos on iOS. iPhone OS 2 comes out, native apps get a full SDK with supporting frameworks. The browser gets "touchStart" events. Apple simply doesn't want people writing browser apps because they dont make money nor lock users in.
- lukifer 16y agoI 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.
- Me1000 16y agoI 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
- olalonde 16y agoMG Siegler is such an Apple fanboy it's not even funny. (regardless of this article)
- alttab 16y agoAlso 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.
- toddmorey 16y agoLegitimate 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.
- edw519 16y agoLet’s be honest: right now, most HTML-based mobile apps are a joke when compared to their native counterparts. 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.
- dkarl 16y agoIn 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.
- judofyr 16y agoAs a user, I can use an "iPhone" HTML-based app on my Android.
- wvenable 16y ago> 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.
- badmash69 16y agoOP's analogy could be right but did he consider that You are more likely to be hit by an oncoming train than by an oncoming rocket !! HTML5 will rule !!
- swix 16y agoGod... 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.
- mckoss 16y agoI agree. BTW, re animations is this what you're looking for? https://developer.mozilla.org/en/CSS/CSS_transitions https://developer.mozilla.org/en/CSS/CSS_transitions
- swix 16y agoUm, 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.
- ern 16y agoTo torture the analogy: trains have been ridden by billions of people, rocket ships by around 500. Less exciting experience, but far more accessible.
- Tichy 16y agoAt 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.
- wvenable 16y agoCocoa 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.
- Tichy 16y agoAndroid 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...)?
- extension 16y agoWeb 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.
- wayneblozz 16y ago"Windows has some particular flaws that ultimately brought it down..." Not sure what you're talking about here. Has Windows been "brought down"? I'm pretty sure that most businesses out there are running Windows desktops and Windows in their back office.
- wayneblozz 16y agoWhy did my comment get marked as dead? Please advise.
- jonpaul 16y agoI wrote a popular article about this: http://techneur.com/post/3068783134/customers-demand-native-for-mobile-apps http://techneur.com/post/3068783134/customers-demand-native-...
- ddkrone 16y agoWhy 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.
- swix 16y agoYeah 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
- aufreak3 16y agoThe 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".
- stcredzero 16y agoNative 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.
- rodh257 16y agoI 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.