13 ms·

Poll: HTML 5 or Native mobile development ?

80 points by linux_devil 13y ago

Which one will you prefer for mobile application development and why?

neals 13y ago
HTML 5, cross platformness. We wrap it into a native container though.
- sidcool 13y ago
  Can you elaborate on the 'Wrapping it into a native container'?
  - zebra 13y ago
    Take a look here: http://phonegap.com/ http://phonegap.com/ This is a free open-source wrapper.
    - neals 13y ago
      Yes, we also use StageWebView with Adobe Air.
sidcool 13y ago
If facebook's HTML5 fiasco is any lesson, I would rather go with Native.
- Antwan 13y ago
  fb.html5isready.com
  - kayoone 13y ago
    While thats pretty nice, it still proves that HTML5 is indeed not ready
    - dpedu 13y ago
      Really? On my Nexus 7 this runs much smoother than the official Facebook app - ignoring missing features of course.
  - tim333 13y ago
    Just tried that on ios7 and it crashes every 20s or so. Not that that really proves anything
  - easy_rider 13y ago
    fastbkapp will receive the following info: your public profile, friend list, email address, custom friends lists, messages, friend requests, News Feed, relationships, relationship interests, birthday, chat status, notes, work history, status updates, education history, events, groups, hometown, interests, current city, Photos, religious and political views, videos, website, personal description and likes and your friends' relationships, relationship interests, birthdays, chat statuses, notes, work histories, status updates, education histories, events, groups, hometowns, interests, current cities, photos, religious and political views, videos, websites, personal description and likes. hmm, nah.
    - nobleach 13y ago
      So will the native facebook app. Of COURSE the fastbkapp will receive that info.
      - easy_rider 13y ago
        OF COURSE. That does not mean I want to give ALL that to ANOTHER third party.
- nobleach 13y ago
  The native app didn't help much. The biggest deal with the HTML5 app was adding DOM content as the user scrolled. They were experiencing memory leaks. The native app may have fixed that part, but their backend API service was still sucking pretty badly for months after that. Even now, on an iPhone4, the performance of the native app kinda sucks. It's better on a 5 or 5s, but still fairly slow to get a JSON stream, parse it and build dynamic views.
jon-wood 13y ago
A bit of both - we have an HTML 5 application used internally, and an iOS app we distribute to customers. HTML 5 is a big win for letting us get new releases out fast, and not having to battle with native APIs that we don't usually, but native wins out if you need something polished.
deleted 13y ago
[deleted]
mathijs 13y ago
We prefer native 99% of the time. Performance of HTML is easily outmatched by native on both iOS and Android, and the multi-platformness of HTML is usually limited if you want to adhere to UX guidelines and conventions that are platform specific.
forcer 13y ago
it depends on what the mobile application will do. E.g. for more performance heavy apps native is the way to go. See reasons why: http://speedcheckerapp.com/NativeApps.aspx http://speedcheckerapp.com/NativeApps.aspx
- davidw 13y ago
  "It depends" is the only sensible answer. How many people do you have to work on it? Can you get both iOS and Android programmers? How does it fit in with the rest of your company and its goals? What is the purpose of the application? How solid are the specs - in the sense of knowing exactly what the app should do, or is it more a MVP type of thing where you're trying to see what the problem space is like?
lini 13y ago
We do Cordova/PhoneGap development - the best of both worlds. HTML 5 wrapped into a native iOS/Android app. We still use plugins with native code though (Java/ObjC), for receiving push notifications and accessing the camera.
fijter 13y ago
I've created native iOS apps, native Android apps, HTML5 apps and I've used wrappers (Titanium Mobile and PhoneGap) over the last few years and these are my findings: - Native apps take a lot of time to build, especially when you are a web-developer without in-depth knowledge of the extensive frameworks available to the native platforms. - Wrappers work, but are not nearly as great and snappy as native apps; They might contain a lot of hard to fix bugs as well and are harder to debug if they tend to crash. - HTML5 only apps are not available in the market/store so no free advertising, you can't access things like the camera with HTML5 only, you therefore need a wrapper. My vote goes to native development; Although it's more work and code to write it's much faster and stable if done correctly. You've got more freedom and bugs can be solved. A native app just feels right, where a HTML5 only app won't give you the best user experience you can get, no matter how much time you put into it. If you need a flexible, big, cross-platform app without a lot of budget to build at least 2 native apps a HTML5 app with wrapper would be a decent option, but for anything else (especially the more simple apps with just 2 or 3 different views) you should go with native.
- corresation 13y ago
  you can't access things like the camera with HTML5 only Just a small point of clarification, you can access the camera on Android using the Camera API. You can access accelerometers / gyroscopes and location in both Android and iOS.
  - whereareyou 13y ago
    A file upload form field also accesses the camera in iOS and Android.
- fungi 13y ago
  > HTML5 only apps are not available in the market/store where exactly does the cut off line exist? native/html5 is kinda gray.
  - efdee 13y ago
    Native/html5 sounds like a wrapper job.
SkippyZA 13y ago
Native will always perform better. I personally use Cocos2dx HTML5 which then can be compiled to native iOS and Android code, and can be run in a browser.
oe 13y ago
Why not both?
darklegend 13y ago
I also prefer native apps. We have heavy use of API functions and that kills ever HTML5 app
juanjolainez 13y ago
In my company (www.reportest.com) we made our SDK native. It performs better but, on the other side, HTML5 is much much quicker to develop.
- rimantas 13y ago
  Can you expand more why it is quicker? You have to do so much reinvention of the wheel with html that I really don't get how can it be quicker.
eksith 13y ago
It makes sense to me to use both to a degree. The frontend and UI will greatly benefit from using HTML5 while stability will depend a lot on the native aspects.
TeeWEE 13y ago
HTML5 is designed to run in a browser which is always on. Native development is designed so that the user can switch betweens apps easily, without having an app to be slow. Also with native you have access to the full device api such as sensors. HTML5 is closing the gap, but Native increases the gap every few months. Mind the gap.
- thenerdfiles 13y ago
  1. Close tab/window. 2. Use Page Visibility API[0] to throttle app. I'm frankly just unclear on why so many of us are answering the question "What works...?" when clearly the question is "Which do you PREFER?" [0]: http://www.w3.org/blog/news/archives/3351 http://www.w3.org/blog/news/archives/3351
eonil 13y ago
Always goes only for native. Here're why I don't go HTML5. (1) Access to low-level and platform-specific features. Whatever I do, I always eventually need it as program gets specialized, and always be frustrated on non-native platforms. Usually cross platform stuffs lack this or needlessly painful even they offer it. Also you still have to write platform specific code even they support it. (2) Freedom of development. From native, it's relatively easier to build up HTML5 stuffs on top of it. (or whatever…) So I still can utilize HTML5 stuff if I really need it. Reverse is mostly impossible. (3) (Though that's arguable, what's native?…) Compatibility. Native development on C/C++ level always offer best compatibility. There's no computing platform doesn't support C/C++. Emscripten extended this even to HTML5. HTML stuffs are available only on browsers and a few specialized platforms. (4) Legacy. I always discover a mostly ideal implementation exists on native platform where HTML5 people are making efforts to bring. This includes better toolset for code writing and debugging. (5) Future. (I imply HTML5 == markup+CSS+JS). No serious major browser vendor really loves HTLM5. Because that limits their platform features. That's why they're adding WebGL and C/C++ support or whatever non-HTML stuffs from native world.
- nicholaides 13y ago
  > There's no computing platform doesn't support C/C++ Does that include Android devices?
  - brodney 13y ago
    NDK on Android supports C/C++. http://developer.android.com/tools/sdk/ndk/index.html http://developer.android.com/tools/sdk/ndk/index.html
  - CCs 13y ago
    Dropbox uses C++ as a cross-platform language for iOS and Android: http://www.youtube.com/watch?v=S5rXCvu9-NM http://www.youtube.com/watch?v=S5rXCvu9-NM
camus2 13y ago
what kind of app? that's the question you should be asking yourself first.
ghaven 13y ago
How about kivy (http://kivy.org/#home http://kivy.org/#home) for something of a middle ground? It's a python graphical framework making heavy use of opengl via an optimised cython interface. It has fairly powerful access to the android api through pyjnius (which gives direct access to java classes) or pyobjus on ios (which is less mature but has the same idea). On the plus side, since it's native to the device (albeit with a different interface), you can do pretty well for speed through the already optimised graphical interface and through optimising your own apps with cython or even C modules if necessary. Other pros include pyjnius/pyobjus for api integration as above (some of which is already abstracted as python modules), and neat perks like the ability to mostly develop on desktop without an emulator. On the other hand, it has some of the same disadvantages as html5, such as non-native widgets. So by no means a perfect solution, but an interesting contender.
- AbsoluteDestiny 13y ago
  The biggest downside I found with kivy is the amount of time it takes to launch the app as it has to set up the python environment et al. If that's improved with newer versions of kivy I might go back to see what it can do.
  - ghaven 13y ago
    That's still a problem unfortunately, though less so than it used to be so your perception might depend on when you last used it. If you're interested, you could try perhaps FlatJewels from the play store. It's a simple game with a fairly quick loading time (except the first run, which is always slower). I don't know if the author put effort into specifically optimising its start time, but it's probably fairly representative of what's currently normal.
  - mlangdon 13y ago
    The other standard downside of kivy is the mandatory giant app footprint. Hello World is going to set you back 25mb on Android.
    - deleted 13y ago
deleted 13y ago
[deleted]
meerita 13y ago
I would say native. But i need to know what the product is to take this choice. I always prefer hybrids apps since I can take the best of both worlds.
sourabh86 13y ago
It depends on what kind of application you are developing:- Go Native if- 1. Need to access platform specific features example camera,gs,etc 2. Need performance intensive app 3. There is enough time for you to develop native app and can afford different native app developers (if planning to go cross platform) 4.You already know java/C#/Objective-C and it's a pain for you to learn HTML5 HTML5 if(you have some knowledge of HTML5/CSS and...):- 1. You need to build something quickly and cross platform 2. You can't afford different native app devs. 3. Performance is not that big an issue 4. You have/are a designer who can quickly conceptualize and build prototype using HTML5/CSS
dgesang 13y ago
Neither, but Air.
viodek 13y ago
Black as well
d0m 13y ago
Html5, because easier to prototype and iterate. Clearly native once you have the right idea and funding for it.
- rimantas 13y ago
  How it is easier? At least on iOS you can prototype extremely quickly and almost without writing any code: drop your views on controllers, wire them up and there you have it.
  - DougWebb 13y ago
    An HTML5 app is a lot easier to make cross-platform than writing separate native apps for each platform. It depends on the type of app though; running inside a browser is definitely a step away from native APIs, even when you have pass-through access to them.
    - rimantas 13y ago
      Wait, we were talking about prototyping an reiterating, not cross platform development. And even for cross-platform I wouldn't be so sure about "a lot". You may get initial version faster, but all the tweaks and ironing of the cross-platform kinks can eat a lot of time and make a lot of hairs grey.
ohwp 13y ago
Native, but with the use of C# (Xamarin / Mono). And I don't think native takes more time. Debugging is much easier with native apps (imho).
- _random_ 13y ago
  Single language (one of the best as well), yet native look and feel.
DanielBMarkham 13y ago
I'm sticking with HTML 5. Of course, I don't have a deployed production app, just stuff I've fooled around with. If I had real customers on the other end, I could very well go the other way. The problem here is walled gardens. From a strategic standpoint, frankly, I've had my freaking fill of vendors trying to lock down platforms and own everything in them. So I'm all for sticking with HTML5 and letting the performance issues work themselves out over time.
ragebol 13y ago
I'm using Xamarin.iOS and Xamarin.Android for a modest app. I've already spent about half a year on the Android version, with special care to have all logic in a separate layer. The iOS version had catched up in 2 weeks, from scratch. We hired a second guy for that, who had no C# experience (but more on iOS) just before I went on a 2 week holiday I just got back from. Needless to say: Xamarin is the perfect mix of cross platform and native for us.
tomasien 13y ago
It 100% depends on the use case, if there is a ton of interactivity in your app then native is far better. If your app is primarily informational, HTML5 is generally easier for most folks. Hybrid approaches can be nice: build the interactive sections natively and then display the results in a web view so you can re use things from your mobile website, if that use case makes sense to your product.
WA 13y ago
I tried to make a simple calendar with swipe gestures with PhoneGap and Sencha. The performance was horrible on my iPhone 5 (!). Wouldn't use HTML5 again, except maybe as a wrapper for some static HTML5 content without much user interaction (exactly the kind of app that Apple doesn't like btw) However, here's an idea: I recently bought the Impact.js game engine. It comes with Ejecta, which is a hardware-accelerated "browser" for iOS that supports only the canvas-element. If you can manage to implement your HTML5-app in canvas only, this might be an alternative for apps that feel almost native. However, it might be too troublesome to go down that path.
omeid2 13y ago
I think it is a question of complexity, for simple Apps HTML5 is definitely the way to go, easy to iterate, more freedom and prospect of being around (no chance of being pushed out of business for some vague policy issue -- App Store rejection or pull off -- or no risk of being forced to pay portions of subscriptions to a 3rd party). With that being said, HTML5 still can't compete with native Apps when it come to performance and stability. tl;dr: Is your project process or data intensive ? native : html5. Edit: Rephrasing.
Sephiroth87 13y ago
HTML wrapped apps are just lowering the bar for great native apps; also, I've seen so many web designers that now think that they can develop an app that's almost embarrassing, it only works when you want an app that's basically a mobile website
uptown 13y ago
I'm mid-way through developing a Phonegap/Cordova app that's a fairly basic turn-based game that uses the Canvas to render the game board. So far I haven't found any limitations with the needs of this app imposed by going with the wrapper. Certainly it's not the right solution for every type of app, but in the right circumstances I'm convinced this is a perfectly acceptable approach.
rimantas 13y ago
Many there comment that developing with HTML is faster. This is true only and only when you are not familiar with the native language and frameworks. Really, native SDKs have solved pretty much all the common problems. With native you implement the functionality of your app, and don't have to invent views management, list views, notifications, events management, gesture recognisers, etc. There was a post (by sencha, iirc) where they brag how they managed to make html version of FB faster. I was reading and shaking my head: you get all that ingenuity out of the box with native. Two lines of code: register the class/nib for reuse and dequeue cell when needed. Hook in NSFetchedResultsController and there you have it: extremely fast and memory efficient solution. Good luck replicating capabilities of autolayout with flexbox (with rotation support). Good luck replicating capabilities of Core Animation with CSS/JS animations. How about localisation? How about accessibility? How about getting anything like Core Data? Meanwhile in HTML5 land the debate goes on what is the best way to deliver responsive images. Where does this notion, that mobile apps should be developed with web technology comes from? I don't see similar push for desktop apps. Is this all just because of all the web devs seeing the increasing usage of smartphones and proclaiming that html is the better way, because they are too lazy even to investigate what native really offers? I know both stacks extremely well and the answer is very clear to me.
- imissmyjuno 13y ago
  > Is this all just because of all the web devs seeing the increasing usage of smartphones and proclaiming that html is the better way, because they are too lazy even to investigate what native really offers? Another possibility is: browsers are advanced enough to allow web apps to be possible, and as such, options other than native apps become available. Products requirements vary, and so do the devices you deploy to. There are a myriad other reasons one may weight the options and decide to develop a web app other than being lazy. > I don't see similar push for desktop apps I dunno. I use a number of web apps on a regular basis, Rdio being the closest thing to a native app I've used (I run it via Fluid to remove some cognitive gaps). Also, what about Chromebooks? Google's been aggressively pushing that. I think it just may be that more apps get developed for mobile, period, and as such the degree of interest in mobile web apps seems higher (which is ironic given how much easier it is to develop smooth web-based UX for desktop).
radex 13y ago
tl;dr: If you can, go native all the way, but if it makes a lot of sense from biz perspective to support platforms other than iOS, HTML5 is not as bad as it seems. I recently made an app for http://productivemag.com http://productivemag.com (for iOS and soon Android) using web tech, but I also have experience in native iOS/OSX dev. I use Cordova as a wrapper around HTML5. My conclusions: - HTML5 is great for custom UI and prototyping. You can do that right in your browser, no compilation needed. And Web Inspector is _awesome_. Experimenting with UI in ObjC (or Photoshop, IMO) is PITA, but Web Inspector makes it super nice and easy. - Native is great for using native UI. I had to recreate not just the appearance, but the behavior of a lot of elements. It takes a lot of time to get right. - I don't know about Java and Android, but ObjC is a poor language. I used CoffeeScript for the project and it was a far superior experience. - Debugging JavaScript on Android sucks - Debugging JS on iOS is pretty good, but it's still more painful than using Xcode's debugger. OTOH, JS is harder to _really_ break. If there's an error, _something_ won't work, but the app won't crash. Not always true with ObjC. - interfacing with native capabilities is hard. iOS's WebView doesn't expose direct access to the JavaScript VM, so the bridge between two worlds is based on callbacks. Async is much uglier and more error-prone. - Cordova sucks balls - you can get pretty damn close with how fast and smooth the app works with CSS&JS, but you can never quite get there. Lots of little bugs and quirks, which are hard to fix. - it sucks not to have control over how things are rendered. You can make wonders with `-webkit-transform: translate3d(0,0,0);`, but it's not perfect.
- aferreira 13y ago
  Would just like to add to this answer that, as of Android 4.4, the WebView is based off of Chromium, enabling you to perform remote debugging with your chrome web developer tools (basically everything you can do on a website you can now do on a WebView). I'd still pick native any day. Control > ease.
  - radex 13y ago
    That's true, but sometimes things work just fine 4.4 and only break on the undebuggable Jelly Bean or older ;)
wsc981 13y ago
Native, using Xamarin. Native apps still give users the most optimal UI. Using Xamarin work can be reduced, because a big part of the code can be shared between platforms. Code for all platforms is written in C#. Xamarin still gives developers the option to wrap libraries written in e.g. Java or Objective-C for use in the apps.
jpsim 13y ago
Here's what I've tried (mostly just for kicks) and my thoughts: 1. Native (iOS/Android) 2. Native (iOS/Android) with some content in webviews 3. PhoneGap (iOS & Android, cross platform, same app) 4. Xamarin (iOS) 5. RubyMotion (iOS) I recommend 1 & 2 if you have the resources (time to learn native iOS/Android or an experienced developer available). A good approach is to write all the structure/navigation natively and individual content in webviews. LinkedIn's mobile team uses this technique exhaustively. Xamarin and RubyMotion (4 & 5) are both great 2nd choices if you dislike the Objective-C / Java languages or your team is well versed in C#/ruby, but you'll still have to learn the SDKs. There isn't much you can't do in these frameworks that you could do "natively", since you're still hooking into the native runtimes (loosely speaking). Xamarin is a bit more stable than RubyMotion, imho. I'd stay away from PhoneGap if possible. My main takeaway is that "write once, run everywhere, sdk agnostic" is a pipe dream. You'll be disappointed when you're investing tons of time in the last 10-20% of development, working with fringe cases on different platforms. If you find yourself considering PhoneGap, consider whether or not being on the App Store is necessary at all, or if you can get away with a standard web app through the browser.
albertoavila 13y ago
My vote goes for native, i've built a series of wrapped html applications and the experience always is awful, as soon as you try to target something other than an iOS device you get tons of hard to fix bugs, awful performance and a bunch of weird glitches. Going native takes only some more time at the beginning, but as every technology you can only get better at it with time, I would totally recommend avoiding wasting your time with hybrid solutions (Cordova) and go straight native (I know i wish i had).
nailer 13y ago
Which one is 'native using JS?' Apple introduced JavaSciptCore in iOS 7. I don't care for ObjC so JS calling native UI from a familiar language sounds good.
chrisdevereux 13y ago
Intestesting that the poll results (currently) only give a slight edge to native, but the comments are overwhelmingly pro-native. I can see two possible reasons for this: 1) Native developers are the more opinionated of the two. 2) People who actually have experience to communicate prefer native
- Cookingboy 13y ago
  Right, I think there are just overall more web developers than mobile developers out there (one has been around for much longer), and people who have had real experiences building mobile apps are still in the minority.
- kronholm 13y ago
  Maybe it's due to the phrasing of the question. I certainly prefer native (ok semi-close-ish native, I use Titanium), but I _will_ in the future prefer to be using HTML5, once it's ready. HTML5 isn't ready yet in my opinion, as it takes too much effort (read: hours, money) and many workarounds to get a polished, fast and responsive app out of it to rival native. Sure it's awesome for fast prototyping, but it's still too hard to get "dat native feel".
- yesplorer 13y ago
  and 3) nothing is stopping anyone from upvoting the two
asdasf 13y ago
Why is this an either/or question? Do you prefer native or html for PC apps? It depends on the app, I prefer whichever is appropriate for the application in question. This is just as true with a pocket sized computer as it is with a laptop or desktop computer.
moctebain 13y ago
I prefer native apps, but the solution depends of the problem
felxh 13y ago
Not having much experience with developing native mobile apps, I can only say what a pain it is to develop non trivial HTML5 apps that need to support a wide array of browsers. Your initial euphoria of 'oh wow I could make this thing for [insert browser of you choice] in less than [x amount of time]' is quickly mitigated when you try it on other browsers. Different browsers _will_ vary greatly in performance for different approaches and at least one browser _will_ have a bug. Fixing these performance issues (and not killing performance on other browsers again) and finding workarounds for bugs will then take 80% of the entire development time. Having said that, things have improved the last years, especially when you don't need to support older android versions (> 4). However, performance will always be suboptimal and I found that people who claim the opposite simply have a lower bar for what good UI performance means - as harsh as it sounds. There is also a great number of tips and knowhow on how to make 'blazing fast' HTML5 apps, which people are quick to point out. Many of these help, but they don't always work for all browsers and they potentially limit you in what you can achieve (my favourite: don't use images. But what if the whole point of my app is to work with large images!?)
- arnorhs 13y ago
  > Not having much experience with developing native mobile apps, I can only say what a pain it is to develop non trivial HTML5 apps that need to support a wide array of browsers Multiply that pain with 10x and now you know what it's like to develop native apps. (Disclaimer: Grass is always greener etc)
  - subsection1h 13y ago
    How many native mobile apps have you developed? I'm curious because your GitHub repos are all JavaScript projects.
enscr 13y ago
The question leaves room for ambiguous response & misinterpretation of results. You ask : which one will you 'prefer' to use. From a personal standpoint, my preference would be html 5, however from a logical standpoint, my preference would be native. This should be split into two polls: 1) Which one would you want to use ideally 2) Which one do you end up using
mingabunga 13y ago
Bit of both. We did an HTML5 app with Cordova/Phonegap as the wrapper and worked very well - it is fast but took quite a lot of optimization. Only problem is some things are not supported in mobile browsers (eg position fixed) so menu behavior could be quirky, so we've rewritten to use html5 content with native menus/nav bar/slider and this works the best.
nkoren 13y ago
HTML5. My (Meteor & D3-based) application is primarily aimed desktop browsers, and it already very nearly works out of the box on mobile -- there are a few D3 touch events that need to be revisited, and a new layout that is friendlier for smaller screens; otherwise we're done. We don't need to access low-level hardware, and the idea of doing Native re-implementations of Meteor's bidirectional data bindings or D3's force-directed graphs is, frankly, ridiculous. So we're going HTML5 all the way.
- CCs 13y ago
  Looks like a cool project! Is Elon Musk involved? :) http://www.podaris.com/ http://www.podaris.com/
  - nkoren 13y ago
    Thank you! This is actually for my prior startup (probably too profitable to call a "startup" at this point, actually), http://www.futurescaper.com/ http://www.futurescaper.com/. But Podaris is shaping up to be HTML5/JS from top to bottom as well. Unlike Futurescaper, it doesn't need a smartphone incarnation, and the alpha version works surprisingly well on tablets, pretty much out of the box. No Elon Musk involvement. Yet. :-)
ketan_anjaria 13y ago
There's only one real answer to this. How many HTML 5 apps do you use on your phone on a daily basis? Compare that to Native...
BigBalli 13y ago
HTML5 (hybrid). Especially in today's world it's unacceptable (for most projects) to take 5x time to whip up a simple view. However, native/hybrid/html5 all have their place int he ecosystem. A "best" can only be determined if in a given context (i.e. specs).
tinganho 13y ago
Those who have tried to create an HTML5 based app and native. And who don't get the right "native" feeling on the HTML5. There is a lot of tips and trick to get the native feeling. I just think that you should give HTML5 a chance and not out rule it.
dave1010uk 13y ago
From my experience, clients generally prefer native, as the quality is so much better. Looking more closely, however, agencies / freelancers pitch HTML5 apps at a considerably lower cost than native. I've seen them come in at half the cost. What would the result be if you got 2 developers, 1 with 5 years experience building HTML5 apps and 1 with 5 years building native apps, and gave them 3 months to create an apps for Android and iOS?
thenerdfiles 13y ago
I'm confused on this question. If someone asks you, "Between a BMW that needs repair (without a sunroof) and a functional Dodge Saturn (with a sunroof), which will you prefer?" you don't answer "Well, the Dodge Saturn, because work tomorrow morning." The question is not asking "What works?", but you're all giving that kind of answer. Is it possible to ask indeed what this question is asking? Can we detach the "I need to launch YESTERDAY!" attitude from these types of questions? [MOAR EDIT:] Add in the qualification to the BMW/Saturn analogy that you're planning a road trip. [EDIT:] To emphasize, the question asks, "Which will you prefer..." rather than "Which do you prefer..." It seems like the OP is trying to sideline the "functionality of today" question, which frankly given the rapid rate of growth[0] and adoption altogether[1], "what works today", "APIs available today" is largely negligible. [0]: http://www.w3.org/wiki/Closing_the_gap_with_native http://www.w3.org/wiki/Closing_the_gap_with_native [1]: http://www.w3.org/2013/11/w3c-highlights/ http://www.w3.org/2013/11/w3c-highlights/
Edmond 13y ago
This really depends... if you are building a consumer app, native is probably better given that you typically need access to device features...but for business apps, with few exceptions I say HTML5 hands down.
nighthawk24 13y ago
Depends on what features you want to build. If you do need access to the phone's native APIs, you WILL need to make a native app. HTML5 works great for first versions and specifically if everything can be done over back-end API. HTML5 first, Native later. To make available more seamless "native" experience to the user.
cnp 13y ago
OMG: the pain of doing a mobile HTML5 app and having it work across the entire spectrum of Android and iOS devices. OMG.
bookwormAT 13y ago
I think many people forget that "native" is a very abstract term. "Native Android" means you are developing a single app that runs and adapts to tens of thousands of different hardware and software configurations. It would be much more native to make an app only for the Samsung Galaxy devices, and then another app only for HTC Sense. Which is what iOS and Windows phone developers do. If we say HTML5 is a very abstract/cross platform solution, and iOS is very native approach, then Android is definately something in between. And I would say it is much more "cross platform" then it is "native".

80 points by linux_devil 13y ago

Which one will you prefer for mobile application development and why?

neals 13y ago

HTML 5, cross platformness. We wrap it into a native container though.

sidcool 13y ago
Can you elaborate on the 'Wrapping it into a native container'?
- zebra 13y ago
  Take a look here: http://phonegap.com/ http://phonegap.com/ This is a free open-source wrapper.
  - neals 13y ago
    Yes, we also use StageWebView with Adobe Air.

sidcool 13y ago

If facebook's HTML5 fiasco is any lesson, I would rather go with Native.

Antwan 13y ago
fb.html5isready.com
- kayoone 13y ago
  While thats pretty nice, it still proves that HTML5 is indeed not ready
  - dpedu 13y ago
    Really? On my Nexus 7 this runs much smoother than the official Facebook app - ignoring missing features of course.
- tim333 13y ago
  Just tried that on ios7 and it crashes every 20s or so. Not that that really proves anything
- easy_rider 13y ago
  fastbkapp will receive the following info: your public profile, friend list, email address, custom friends lists, messages, friend requests, News Feed, relationships, relationship interests, birthday, chat status, notes, work history, status updates, education history, events, groups, hometown, interests, current city, Photos, religious and political views, videos, website, personal description and likes and your friends' relationships, relationship interests, birthdays, chat statuses, notes, work histories, status updates, education histories, events, groups, hometowns, interests, current cities, photos, religious and political views, videos, websites, personal description and likes. hmm, nah.
  - nobleach 13y ago
    So will the native facebook app. Of COURSE the fastbkapp will receive that info.
    - easy_rider 13y ago
      OF COURSE. That does not mean I want to give ALL that to ANOTHER third party.
nobleach 13y ago
The native app didn't help much. The biggest deal with the HTML5 app was adding DOM content as the user scrolled. They were experiencing memory leaks. The native app may have fixed that part, but their backend API service was still sucking pretty badly for months after that. Even now, on an iPhone4, the performance of the native app kinda sucks. It's better on a 5 or 5s, but still fairly slow to get a JSON stream, parse it and build dynamic views.

jon-wood 13y ago

A bit of both - we have an HTML 5 application used internally, and an iOS app we distribute to customers. HTML 5 is a big win for letting us get new releases out fast, and not having to battle with native APIs that we don't usually, but native wins out if you need something polished.

deleted 13y ago

[deleted]

mathijs 13y ago

We prefer native 99% of the time. Performance of HTML is easily outmatched by native on both iOS and Android, and the multi-platformness of HTML is usually limited if you want to adhere to UX guidelines and conventions that are platform specific.

forcer 13y ago

it depends on what the mobile application will do. E.g. for more performance heavy apps native is the way to go. See reasons why: http://speedcheckerapp.com/NativeApps.aspx http://speedcheckerapp.com/NativeApps.aspx

davidw 13y ago
"It depends" is the only sensible answer. How many people do you have to work on it? Can you get both iOS and Android programmers? How does it fit in with the rest of your company and its goals? What is the purpose of the application? How solid are the specs - in the sense of knowing exactly what the app should do, or is it more a MVP type of thing where you're trying to see what the problem space is like?

lini 13y ago

We do Cordova/PhoneGap development - the best of both worlds. HTML 5 wrapped into a native iOS/Android app. We still use plugins with native code though (Java/ObjC), for receiving push notifications and accessing the camera.

fijter 13y ago

I've created native iOS apps, native Android apps, HTML5 apps and I've used wrappers (Titanium Mobile and PhoneGap) over the last few years and these are my findings: - Native apps take a lot of time to build, especially when you are a web-developer without in-depth knowledge of the extensive frameworks available to the native platforms. - Wrappers work, but are not nearly as great and snappy as native apps; They might contain a lot of hard to fix bugs as well and are harder to debug if they tend to crash. - HTML5 only apps are not available in the market/store so no free advertising, you can't access things like the camera with HTML5 only, you therefore need a wrapper. My vote goes to native development; Although it's more work and code to write it's much faster and stable if done correctly. You've got more freedom and bugs can be solved. A native app just feels right, where a HTML5 only app won't give you the best user experience you can get, no matter how much time you put into it. If you need a flexible, big, cross-platform app without a lot of budget to build at least 2 native apps a HTML5 app with wrapper would be a decent option, but for anything else (especially the more simple apps with just 2 or 3 different views) you should go with native.

corresation 13y ago
you can't access things like the camera with HTML5 only Just a small point of clarification, you can access the camera on Android using the Camera API. You can access accelerometers / gyroscopes and location in both Android and iOS.
- whereareyou 13y ago
  A file upload form field also accesses the camera in iOS and Android.
fungi 13y ago
> HTML5 only apps are not available in the market/store where exactly does the cut off line exist? native/html5 is kinda gray.
- efdee 13y ago
  Native/html5 sounds like a wrapper job.

SkippyZA 13y ago

Native will always perform better. I personally use Cocos2dx HTML5 which then can be compiled to native iOS and Android code, and can be run in a browser.

oe 13y ago

Why not both?

darklegend 13y ago

I also prefer native apps. We have heavy use of API functions and that kills ever HTML5 app

juanjolainez 13y ago

In my company (www.reportest.com) we made our SDK native. It performs better but, on the other side, HTML5 is much much quicker to develop.

rimantas 13y ago
Can you expand more why it is quicker? You have to do so much reinvention of the wheel with html that I really don't get how can it be quicker.

eksith 13y ago

It makes sense to me to use both to a degree. The frontend and UI will greatly benefit from using HTML5 while stability will depend a lot on the native aspects.

TeeWEE 13y ago

HTML5 is designed to run in a browser which is always on. Native development is designed so that the user can switch betweens apps easily, without having an app to be slow. Also with native you have access to the full device api such as sensors. HTML5 is closing the gap, but Native increases the gap every few months. Mind the gap.

thenerdfiles 13y ago
1. Close tab/window. 2. Use Page Visibility API[0] to throttle app. I'm frankly just unclear on why so many of us are answering the question "What works...?" when clearly the question is "Which do you PREFER?" [0]: http://www.w3.org/blog/news/archives/3351 http://www.w3.org/blog/news/archives/3351

eonil 13y ago

Always goes only for native. Here're why I don't go HTML5. (1) Access to low-level and platform-specific features. Whatever I do, I always eventually need it as program gets specialized, and always be frustrated on non-native platforms. Usually cross platform stuffs lack this or needlessly painful even they offer it. Also you still have to write platform specific code even they support it. (2) Freedom of development. From native, it's relatively easier to build up HTML5 stuffs on top of it. (or whatever…) So I still can utilize HTML5 stuff if I really need it. Reverse is mostly impossible. (3) (Though that's arguable, what's native?…) Compatibility. Native development on C/C++ level always offer best compatibility. There's no computing platform doesn't support C/C++. Emscripten extended this even to HTML5. HTML stuffs are available only on browsers and a few specialized platforms. (4) Legacy. I always discover a mostly ideal implementation exists on native platform where HTML5 people are making efforts to bring. This includes better toolset for code writing and debugging. (5) Future. (I imply HTML5 == markup+CSS+JS). No serious major browser vendor really loves HTLM5. Because that limits their platform features. That's why they're adding WebGL and C/C++ support or whatever non-HTML stuffs from native world.

nicholaides 13y ago
> There's no computing platform doesn't support C/C++ Does that include Android devices?
- brodney 13y ago
  NDK on Android supports C/C++. http://developer.android.com/tools/sdk/ndk/index.html http://developer.android.com/tools/sdk/ndk/index.html
- CCs 13y ago
  Dropbox uses C++ as a cross-platform language for iOS and Android: http://www.youtube.com/watch?v=S5rXCvu9-NM http://www.youtube.com/watch?v=S5rXCvu9-NM

camus2 13y ago

what kind of app? that's the question you should be asking yourself first.

ghaven 13y ago

How about kivy (http://kivy.org/#home http://kivy.org/#home) for something of a middle ground? It's a python graphical framework making heavy use of opengl via an optimised cython interface. It has fairly powerful access to the android api through pyjnius (which gives direct access to java classes) or pyobjus on ios (which is less mature but has the same idea). On the plus side, since it's native to the device (albeit with a different interface), you can do pretty well for speed through the already optimised graphical interface and through optimising your own apps with cython or even C modules if necessary. Other pros include pyjnius/pyobjus for api integration as above (some of which is already abstracted as python modules), and neat perks like the ability to mostly develop on desktop without an emulator. On the other hand, it has some of the same disadvantages as html5, such as non-native widgets. So by no means a perfect solution, but an interesting contender.

AbsoluteDestiny 13y ago
The biggest downside I found with kivy is the amount of time it takes to launch the app as it has to set up the python environment et al. If that's improved with newer versions of kivy I might go back to see what it can do.
- ghaven 13y ago
  That's still a problem unfortunately, though less so than it used to be so your perception might depend on when you last used it. If you're interested, you could try perhaps FlatJewels from the play store. It's a simple game with a fairly quick loading time (except the first run, which is always slower). I don't know if the author put effort into specifically optimising its start time, but it's probably fairly representative of what's currently normal.
- mlangdon 13y ago
  The other standard downside of kivy is the mandatory giant app footprint. Hello World is going to set you back 25mb on Android.
  - deleted 13y ago

deleted 13y ago

[deleted]

meerita 13y ago

I would say native. But i need to know what the product is to take this choice. I always prefer hybrids apps since I can take the best of both worlds.

sourabh86 13y ago

It depends on what kind of application you are developing:- Go Native if- 1. Need to access platform specific features example camera,gs,etc 2. Need performance intensive app 3. There is enough time for you to develop native app and can afford different native app developers (if planning to go cross platform) 4.You already know java/C#/Objective-C and it's a pain for you to learn HTML5 HTML5 if(you have some knowledge of HTML5/CSS and...):- 1. You need to build something quickly and cross platform 2. You can't afford different native app devs. 3. Performance is not that big an issue 4. You have/are a designer who can quickly conceptualize and build prototype using HTML5/CSS

dgesang 13y ago

Neither, but Air.

viodek 13y ago

Black as well

d0m 13y ago

Html5, because easier to prototype and iterate. Clearly native once you have the right idea and funding for it.

rimantas 13y ago
How it is easier? At least on iOS you can prototype extremely quickly and almost without writing any code: drop your views on controllers, wire them up and there you have it.
- DougWebb 13y ago
  An HTML5 app is a lot easier to make cross-platform than writing separate native apps for each platform. It depends on the type of app though; running inside a browser is definitely a step away from native APIs, even when you have pass-through access to them.
  - rimantas 13y ago
    Wait, we were talking about prototyping an reiterating, not cross platform development. And even for cross-platform I wouldn't be so sure about "a lot". You may get initial version faster, but all the tweaks and ironing of the cross-platform kinks can eat a lot of time and make a lot of hairs grey.

ohwp 13y ago

Native, but with the use of C# (Xamarin / Mono). And I don't think native takes more time. Debugging is much easier with native apps (imho).

_random_ 13y ago
Single language (one of the best as well), yet native look and feel.

DanielBMarkham 13y ago

I'm sticking with HTML 5. Of course, I don't have a deployed production app, just stuff I've fooled around with. If I had real customers on the other end, I could very well go the other way. The problem here is walled gardens. From a strategic standpoint, frankly, I've had my freaking fill of vendors trying to lock down platforms and own everything in them. So I'm all for sticking with HTML5 and letting the performance issues work themselves out over time.

ragebol 13y ago

I'm using Xamarin.iOS and Xamarin.Android for a modest app. I've already spent about half a year on the Android version, with special care to have all logic in a separate layer. The iOS version had catched up in 2 weeks, from scratch. We hired a second guy for that, who had no C# experience (but more on iOS) just before I went on a 2 week holiday I just got back from. Needless to say: Xamarin is the perfect mix of cross platform and native for us.

tomasien 13y ago

It 100% depends on the use case, if there is a ton of interactivity in your app then native is far better. If your app is primarily informational, HTML5 is generally easier for most folks. Hybrid approaches can be nice: build the interactive sections natively and then display the results in a web view so you can re use things from your mobile website, if that use case makes sense to your product.

WA 13y ago

I tried to make a simple calendar with swipe gestures with PhoneGap and Sencha. The performance was horrible on my iPhone 5 (!). Wouldn't use HTML5 again, except maybe as a wrapper for some static HTML5 content without much user interaction (exactly the kind of app that Apple doesn't like btw) However, here's an idea: I recently bought the Impact.js game engine. It comes with Ejecta, which is a hardware-accelerated "browser" for iOS that supports only the canvas-element. If you can manage to implement your HTML5-app in canvas only, this might be an alternative for apps that feel almost native. However, it might be too troublesome to go down that path.

omeid2 13y ago

I think it is a question of complexity, for simple Apps HTML5 is definitely the way to go, easy to iterate, more freedom and prospect of being around (no chance of being pushed out of business for some vague policy issue -- App Store rejection or pull off -- or no risk of being forced to pay portions of subscriptions to a 3rd party). With that being said, HTML5 still can't compete with native Apps when it come to performance and stability. tl;dr: Is your project process or data intensive ? native : html5. Edit: Rephrasing.

Sephiroth87 13y ago

HTML wrapped apps are just lowering the bar for great native apps; also, I've seen so many web designers that now think that they can develop an app that's almost embarrassing, it only works when you want an app that's basically a mobile website

uptown 13y ago

I'm mid-way through developing a Phonegap/Cordova app that's a fairly basic turn-based game that uses the Canvas to render the game board. So far I haven't found any limitations with the needs of this app imposed by going with the wrapper. Certainly it's not the right solution for every type of app, but in the right circumstances I'm convinced this is a perfectly acceptable approach.

rimantas 13y ago

Many there comment that developing with HTML is faster. This is true only and only when you are not familiar with the native language and frameworks. Really, native SDKs have solved pretty much all the common problems. With native you implement the functionality of your app, and don't have to invent views management, list views, notifications, events management, gesture recognisers, etc. There was a post (by sencha, iirc) where they brag how they managed to make html version of FB faster. I was reading and shaking my head: you get all that ingenuity out of the box with native. Two lines of code: register the class/nib for reuse and dequeue cell when needed. Hook in NSFetchedResultsController and there you have it: extremely fast and memory efficient solution. Good luck replicating capabilities of autolayout with flexbox (with rotation support). Good luck replicating capabilities of Core Animation with CSS/JS animations. How about localisation? How about accessibility? How about getting anything like Core Data? Meanwhile in HTML5 land the debate goes on what is the best way to deliver responsive images. Where does this notion, that mobile apps should be developed with web technology comes from? I don't see similar push for desktop apps. Is this all just because of all the web devs seeing the increasing usage of smartphones and proclaiming that html is the better way, because they are too lazy even to investigate what native really offers? I know both stacks extremely well and the answer is very clear to me.

imissmyjuno 13y ago
> Is this all just because of all the web devs seeing the increasing usage of smartphones and proclaiming that html is the better way, because they are too lazy even to investigate what native really offers? Another possibility is: browsers are advanced enough to allow web apps to be possible, and as such, options other than native apps become available. Products requirements vary, and so do the devices you deploy to. There are a myriad other reasons one may weight the options and decide to develop a web app other than being lazy. > I don't see similar push for desktop apps I dunno. I use a number of web apps on a regular basis, Rdio being the closest thing to a native app I've used (I run it via Fluid to remove some cognitive gaps). Also, what about Chromebooks? Google's been aggressively pushing that. I think it just may be that more apps get developed for mobile, period, and as such the degree of interest in mobile web apps seems higher (which is ironic given how much easier it is to develop smooth web-based UX for desktop).

radex 13y ago

tl;dr: If you can, go native all the way, but if it makes a lot of sense from biz perspective to support platforms other than iOS, HTML5 is not as bad as it seems. I recently made an app for http://productivemag.com http://productivemag.com (for iOS and soon Android) using web tech, but I also have experience in native iOS/OSX dev. I use Cordova as a wrapper around HTML5. My conclusions: - HTML5 is great for custom UI and prototyping. You can do that right in your browser, no compilation needed. And Web Inspector is _awesome_. Experimenting with UI in ObjC (or Photoshop, IMO) is PITA, but Web Inspector makes it super nice and easy. - Native is great for using native UI. I had to recreate not just the appearance, but the behavior of a lot of elements. It takes a lot of time to get right. - I don't know about Java and Android, but ObjC is a poor language. I used CoffeeScript for the project and it was a far superior experience. - Debugging JavaScript on Android sucks - Debugging JS on iOS is pretty good, but it's still more painful than using Xcode's debugger. OTOH, JS is harder to _really_ break. If there's an error, _something_ won't work, but the app won't crash. Not always true with ObjC. - interfacing with native capabilities is hard. iOS's WebView doesn't expose direct access to the JavaScript VM, so the bridge between two worlds is based on callbacks. Async is much uglier and more error-prone. - Cordova sucks balls - you can get pretty damn close with how fast and smooth the app works with CSS&JS, but you can never quite get there. Lots of little bugs and quirks, which are hard to fix. - it sucks not to have control over how things are rendered. You can make wonders with `-webkit-transform: translate3d(0,0,0);`, but it's not perfect.

aferreira 13y ago
Would just like to add to this answer that, as of Android 4.4, the WebView is based off of Chromium, enabling you to perform remote debugging with your chrome web developer tools (basically everything you can do on a website you can now do on a WebView). I'd still pick native any day. Control > ease.
- radex 13y ago
  That's true, but sometimes things work just fine 4.4 and only break on the undebuggable Jelly Bean or older ;)

wsc981 13y ago

Native, using Xamarin. Native apps still give users the most optimal UI. Using Xamarin work can be reduced, because a big part of the code can be shared between platforms. Code for all platforms is written in C#. Xamarin still gives developers the option to wrap libraries written in e.g. Java or Objective-C for use in the apps.

jpsim 13y ago

Here's what I've tried (mostly just for kicks) and my thoughts: 1. Native (iOS/Android) 2. Native (iOS/Android) with some content in webviews 3. PhoneGap (iOS & Android, cross platform, same app) 4. Xamarin (iOS) 5. RubyMotion (iOS) I recommend 1 & 2 if you have the resources (time to learn native iOS/Android or an experienced developer available). A good approach is to write all the structure/navigation natively and individual content in webviews. LinkedIn's mobile team uses this technique exhaustively. Xamarin and RubyMotion (4 & 5) are both great 2nd choices if you dislike the Objective-C / Java languages or your team is well versed in C#/ruby, but you'll still have to learn the SDKs. There isn't much you can't do in these frameworks that you could do "natively", since you're still hooking into the native runtimes (loosely speaking). Xamarin is a bit more stable than RubyMotion, imho. I'd stay away from PhoneGap if possible. My main takeaway is that "write once, run everywhere, sdk agnostic" is a pipe dream. You'll be disappointed when you're investing tons of time in the last 10-20% of development, working with fringe cases on different platforms. If you find yourself considering PhoneGap, consider whether or not being on the App Store is necessary at all, or if you can get away with a standard web app through the browser.

albertoavila 13y ago

My vote goes for native, i've built a series of wrapped html applications and the experience always is awful, as soon as you try to target something other than an iOS device you get tons of hard to fix bugs, awful performance and a bunch of weird glitches. Going native takes only some more time at the beginning, but as every technology you can only get better at it with time, I would totally recommend avoiding wasting your time with hybrid solutions (Cordova) and go straight native (I know i wish i had).

nailer 13y ago

Which one is 'native using JS?' Apple introduced JavaSciptCore in iOS 7. I don't care for ObjC so JS calling native UI from a familiar language sounds good.

chrisdevereux 13y ago

Intestesting that the poll results (currently) only give a slight edge to native, but the comments are overwhelmingly pro-native. I can see two possible reasons for this: 1) Native developers are the more opinionated of the two. 2) People who actually have experience to communicate prefer native

Cookingboy 13y ago
Right, I think there are just overall more web developers than mobile developers out there (one has been around for much longer), and people who have had real experiences building mobile apps are still in the minority.
kronholm 13y ago
Maybe it's due to the phrasing of the question. I certainly prefer native (ok semi-close-ish native, I use Titanium), but I _will_ in the future prefer to be using HTML5, once it's ready. HTML5 isn't ready yet in my opinion, as it takes too much effort (read: hours, money) and many workarounds to get a polished, fast and responsive app out of it to rival native. Sure it's awesome for fast prototyping, but it's still too hard to get "dat native feel".
yesplorer 13y ago
and 3) nothing is stopping anyone from upvoting the two

asdasf 13y ago

Why is this an either/or question? Do you prefer native or html for PC apps? It depends on the app, I prefer whichever is appropriate for the application in question. This is just as true with a pocket sized computer as it is with a laptop or desktop computer.

moctebain 13y ago

I prefer native apps, but the solution depends of the problem

felxh 13y ago

Not having much experience with developing native mobile apps, I can only say what a pain it is to develop non trivial HTML5 apps that need to support a wide array of browsers. Your initial euphoria of 'oh wow I could make this thing for [insert browser of you choice] in less than [x amount of time]' is quickly mitigated when you try it on other browsers. Different browsers _will_ vary greatly in performance for different approaches and at least one browser _will_ have a bug. Fixing these performance issues (and not killing performance on other browsers again) and finding workarounds for bugs will then take 80% of the entire development time. Having said that, things have improved the last years, especially when you don't need to support older android versions (> 4). However, performance will always be suboptimal and I found that people who claim the opposite simply have a lower bar for what good UI performance means - as harsh as it sounds. There is also a great number of tips and knowhow on how to make 'blazing fast' HTML5 apps, which people are quick to point out. Many of these help, but they don't always work for all browsers and they potentially limit you in what you can achieve (my favourite: don't use images. But what if the whole point of my app is to work with large images!?)

arnorhs 13y ago
> Not having much experience with developing native mobile apps, I can only say what a pain it is to develop non trivial HTML5 apps that need to support a wide array of browsers Multiply that pain with 10x and now you know what it's like to develop native apps. (Disclaimer: Grass is always greener etc)
- subsection1h 13y ago
  How many native mobile apps have you developed? I'm curious because your GitHub repos are all JavaScript projects.

enscr 13y ago

The question leaves room for ambiguous response & misinterpretation of results. You ask : which one will you 'prefer' to use. From a personal standpoint, my preference would be html 5, however from a logical standpoint, my preference would be native. This should be split into two polls: 1) Which one would you want to use ideally 2) Which one do you end up using

mingabunga 13y ago

Bit of both. We did an HTML5 app with Cordova/Phonegap as the wrapper and worked very well - it is fast but took quite a lot of optimization. Only problem is some things are not supported in mobile browsers (eg position fixed) so menu behavior could be quirky, so we've rewritten to use html5 content with native menus/nav bar/slider and this works the best.

nkoren 13y ago

HTML5. My (Meteor & D3-based) application is primarily aimed desktop browsers, and it already very nearly works out of the box on mobile -- there are a few D3 touch events that need to be revisited, and a new layout that is friendlier for smaller screens; otherwise we're done. We don't need to access low-level hardware, and the idea of doing Native re-implementations of Meteor's bidirectional data bindings or D3's force-directed graphs is, frankly, ridiculous. So we're going HTML5 all the way.

CCs 13y ago
Looks like a cool project! Is Elon Musk involved? :) http://www.podaris.com/ http://www.podaris.com/
- nkoren 13y ago
  Thank you! This is actually for my prior startup (probably too profitable to call a "startup" at this point, actually), http://www.futurescaper.com/ http://www.futurescaper.com/. But Podaris is shaping up to be HTML5/JS from top to bottom as well. Unlike Futurescaper, it doesn't need a smartphone incarnation, and the alpha version works surprisingly well on tablets, pretty much out of the box. No Elon Musk involvement. Yet. :-)

ketan_anjaria 13y ago

There's only one real answer to this. How many HTML 5 apps do you use on your phone on a daily basis? Compare that to Native...

BigBalli 13y ago

HTML5 (hybrid). Especially in today's world it's unacceptable (for most projects) to take 5x time to whip up a simple view. However, native/hybrid/html5 all have their place int he ecosystem. A "best" can only be determined if in a given context (i.e. specs).

tinganho 13y ago

Those who have tried to create an HTML5 based app and native. And who don't get the right "native" feeling on the HTML5. There is a lot of tips and trick to get the native feeling. I just think that you should give HTML5 a chance and not out rule it.

dave1010uk 13y ago

From my experience, clients generally prefer native, as the quality is so much better. Looking more closely, however, agencies / freelancers pitch HTML5 apps at a considerably lower cost than native. I've seen them come in at half the cost. What would the result be if you got 2 developers, 1 with 5 years experience building HTML5 apps and 1 with 5 years building native apps, and gave them 3 months to create an apps for Android and iOS?

thenerdfiles 13y ago

I'm confused on this question. If someone asks you, "Between a BMW that needs repair (without a sunroof) and a functional Dodge Saturn (with a sunroof), which will you prefer?" you don't answer "Well, the Dodge Saturn, because work tomorrow morning." The question is not asking "What works?", but you're all giving that kind of answer. Is it possible to ask indeed what this question is asking? Can we detach the "I need to launch YESTERDAY!" attitude from these types of questions? [MOAR EDIT:] Add in the qualification to the BMW/Saturn analogy that you're planning a road trip. [EDIT:] To emphasize, the question asks, "Which will you prefer..." rather than "Which do you prefer..." It seems like the OP is trying to sideline the "functionality of today" question, which frankly given the rapid rate of growth[0] and adoption altogether[1], "what works today", "APIs available today" is largely negligible. [0]: http://www.w3.org/wiki/Closing_the_gap_with_native http://www.w3.org/wiki/Closing_the_gap_with_native [1]: http://www.w3.org/2013/11/w3c-highlights/ http://www.w3.org/2013/11/w3c-highlights/

Edmond 13y ago

This really depends... if you are building a consumer app, native is probably better given that you typically need access to device features...but for business apps, with few exceptions I say HTML5 hands down.

nighthawk24 13y ago

Depends on what features you want to build. If you do need access to the phone's native APIs, you WILL need to make a native app. HTML5 works great for first versions and specifically if everything can be done over back-end API. HTML5 first, Native later. To make available more seamless "native" experience to the user.

cnp 13y ago

OMG: the pain of doing a mobile HTML5 app and having it work across the entire spectrum of Android and iOS devices. OMG.

bookwormAT 13y ago

I think many people forget that "native" is a very abstract term. "Native Android" means you are developing a single app that runs and adapts to tens of thousands of different hardware and software configurations. It would be much more native to make an app only for the Samsung Galaxy devices, and then another app only for HTC Sense. Which is what iOS and Windows phone developers do. If we say HTML5 is a very abstract/cross platform solution, and iOS is very native approach, then Android is definately something in between. And I would say it is much more "cross platform" then it is "native".