Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
Android IOS Programming Software

Native Apps Are Dead, Long Live Native Apps 168

Posted by Soulskill
from the netcraft-confirms-it-then-denies-it dept.
cardoni writes "Dan Yoder, CTO at Border Stylo, offers insights on the current state of simultaneous iPhone / Android development using PhoneGap and his thoughts on the debate over native apps versus Web apps. Quoting: 'One problem with the debate is that it’s a false dichotomy, since you can embed a Web browser within a native application. And, conversely, you can extend an embedded Web browser to provide access to native APIs. The two alternatives have not been mutually exclusive for years now. And, focusing on the strengths of native applications ignores the benefits of Web applications. For example, there’s the appeal of writing code that will run on a variety of different devices, ranging from mobile phones, to tablets, to laptops, even to gaming consoles. Virtually every major device platform now sports a Web browser, and it can often be discreetly embedded within a native application. To boot, much of this code can be tested using a Web browser, which enables more easily automated testing. It’s also easier to find Web developers than it is to find native developers.'"
This discussion has been archived. No new comments can be posted.

Native Apps Are Dead, Long Live Native Apps

Comments Filter:
  • by flyingsled (1475035) on Monday June 27, 2011 @05:27PM (#36590258)
    Everything looks like a nail. Web apps are nice and play in a certain application space. Same with Native apps. Saying that one is "better" than another isn't fair since the apps themselves are different, with different constraints (how do I access a file on the users local filesystem seamlessly from a web app?). If I was going for "I'm going to write an application to conquer the world" approach, I would probably want it to run on iPhone and Android, so a web app is probably a good option. However, if I know my application is fixed to one piece of hardware (the newest iPhone for example) a native app is better since I can access more of the hardware with a native application.
    • by pushing-robot (1037830) on Monday June 27, 2011 @05:43PM (#36590466)

      Exactly. If your app uses basic business logic and you want to maximize your audience, write a web app. If you need the best possible performance, write a native app.

      Next thread: The debate over stacks versus queues continues. Which will win?

      • by jd2112 (1535857)

        Next thread: The debate over stacks versus queues continues. Which will win?

        I'm working on a 'First In-Random Out' queuestack. That should settle that argument...

      • by Darinbob (1142669)

        Though the "basic business logic" may not always apply. If the basic business logic uses that that's local to your device and stores the results local to your device then it's pointless to do it all on the web. Why? Only yuppies who demand to be mobile would keep their data in the cloud, and they only do that so they can flash their thin phones at their peers as opposed to trying to get real work done.

        Native apps are usually a win if you're not doing data-entry to a server somewhere.

        • by Lennie (16154)

          Did you even read the summary ? I guess not, this is Slashdot after all.

          Because many "native apps" are actually wrappers around an embedded browser with the "web app" (locally installed JavaScript/HTML/CSS) having access to the native API.

          This because then you can just use an open source wrapper and distribute to all the devices, Android, iPhone and all the other smartphone systems.

      • by gbjbaanb (229885)

        or.. as I think we should be thinking: if you want a GUI, make it web GUI but connect it to a back-end native server. Best of both worlds *and* you can hire someone cheap to write the web GUI who will actually enjoy doing it (the deluded fools :) )

        • by Lennie (16154)

          I think most "webapps" for smartphones (actually locally installed HTML/JS/CSS with native wrapper) don't really need a back-end server.

          • by gbjbaanb (229885)

            ok, but "back-end" doesn't have to mean a remote server (or cloud) system. It can be locally installed, the important distinction is keeping the GUI and the business logic separate, and not munged together like the worst 'monolithic' GUI apps Windows used to be famous for.

            • by Lennie (16154)

              Yeah, I know. :-)

              But if you have a the HTML/JS/CSS which is already mostly crossplatform, why would you want to write your backend for each and every platform again ?

        • if you want a GUI, make it web GUI but connect it to a back-end native server. Best of both worlds

          Absolutely not the best of both worlds. When you are supporting multiple platforms, you want all of your back-end code to be shared between the various ports but, if you don't want users to hate your application, the one bit that wants to be specific to each system is the UI. Using the web browser gives you no advantage over using something like WxWidgets: you still have access to a subset of the native UI elements and have difficulty tailoring your UI to the native user interface guidelines.

    • by Ruke (857276)

      Specifically addressing "How do I do _X_ seamlessly from a web app?", it's really quite easy to do if you're going the "Native Web App" route with something like PhoneGap. Phonegap comes with a lot of API functions for commonly used native functionality (file access, contacts, geolocation, etc.), and it's trivial to map any native code to a Javascript function. (For example, I've written an HTTP_GET shim for communicating with my server for a cross-platform PhoneGap app I'm developing, because JSONP is a te

    • I came off a project not long ago which involved a web app-running browser embedded in a native app. There was even a decent reason why: Users could pre-enroll online or walk-in at a dedicated station. Either way, the same steps had to be preformed at least once, before the rest of the application (which was native because it involved special hardware) did the rest.

      All I can say was, it was...er, an experience.

      To begin, the Web application was powered by Java while the Native application was run by C#/
      • by hitmark (640295)

        Java? Makes it about as much web as x86 assembly then.

        • I should clarify that. I meant Java as far as the technology stack goes. So, Richfaces, JSF, served up by Tomcat, backed by Java classes.
      • by Lennie (16154)

        You clearly have no idea of what this article/summary was about or some people have created some horrible solution to a problem that might (at first glance from your text) does not even exist.

  • by zbobet2012 (1025836) on Monday June 27, 2011 @05:28PM (#36590262)
    "It’s also easier to find Web developers than it is to find native developers." A good programmer shouldn't really care what level he is working in, best practices etc. are fundamentally the same. Every decent programmer I know has dabbled in everything from assembler to javascript, at the very least. The good ones have written large applications in both or more. Making this a useless dichotomy, because whatever the application a poor programmer can drag an entire team or application down on his own.
    • by Dahamma (304068) on Monday June 27, 2011 @06:10PM (#36590738)

      "It’s also easier to find Web developers than it is to find native developers." A good programmer shouldn't really care what level he is working in, best practices etc. are fundamentally the same. Every decent programmer I know has dabbled in everything from assembler to javascript, at the very least.

      Let's face it - it's easier to find a web developer because web development is easier. I'm sure a lot more primarily C++ programmers have used Javascript than vice-versa. A significant number of "web developers" come from an artistic/graphic design background and have probably never even used a compiler. And that's not a knock on web developers any more than you'd knock a pediatrician for not being a pediatric surgeon...

    • by Ruke (857276) on Monday June 27, 2011 @06:22PM (#36590874)
      While that's fine in theory, there's still the matter of experience on a platform to take into account. While a good programmer will be able to implement HeapSort in both Javascript and C, there's still the matter of whether he's familiar with Interface Builder's delegation system, or if he's got the DOM box model down pat. A good programmer should be able to pick up these skills in (relatively) short order, but some times you just want someone who's already an expert.
      • A good programmer doesn't need to care about those things. A good UI designer does, and a good programmer may also be a good UI designer (although that's very rare), but the two requirements are distinct. Some people write books, some people illustrate books, and some people do both, but that doesn't mean that the ability to draw is essential to an author, or even that you'd want to employ a good author to do illustrations.
  • Truly exciting things happen in native environments.
  • by Bram Stolk (24781) on Monday June 27, 2011 @05:29PM (#36590282) Homepage

    Well... running on many platforms sounds nicer than it actually is.
    You tend to end up with an app that is tailored to the lowest common denominator of the platforms.
    If you want to shine, you will want to go native.

    • Also with web apps (Score:5, Insightful)

      by Sycraft-fu (314770) on Monday June 27, 2011 @05:38PM (#36590386)

      It really does become the "Write once, debug everywhere," thing. Unless you are using very simple HTML and pretty much no interactivity, at which point you are a web site not a web app, you are going to have to have a shitload of "gotchas" and different cases. Not just for major different platforms like Android, Windows, etc but for different browsers.

      Now if you want to do all that, well and good, but be serious about the amount of effort it takes and the amount of time savings, if any, over doing things native.

      For complex applications, there isn't a "Just write it once," way of doing things.

      • Write once, debug everywhere

        That's what phonegap is for... it's like the jquery of mobile.

      • Exactly. To some extent, this difference between web apps and native apps is becoming the difference between Google's offering and Apple's with the cloud. Apple has iCloud coming out, but isn't going to be offering much in the way of web apps to access it (they have said that they'll be bringing some of the MobileMe web apps back later in a new form, but won't have them at launch). In contrast, Google's cloud platforms all have web apps built for them.

        The advantage of Apple's approach is better fit and fini

      • Wow. Ten years ago, this comment here on Slashdot would have been argued to death. "CROSS PLATFORM CROSS PLATFORM!!"

        I agree with you by the way, I just remember all the fuss back then.

      • In the context of mobile app development, though, it's much simpler - we're basically talking about WebKit on iOS and WebKit on Android. The difference is much smaller than your typical desktop test suite of IE, Firefox, Chrome and Safari.

    • Those exec fools at RIM (BlackBerry) and Windows (WP7) think that if they gave us some crazy "modern" non-native development environment then somehow developers will cheer.

      They should gave us straight C to low latency audio, straight C to OpenGL and straight C to input, that is it. With all this we can optionally compile JavaScript, Python, browser you name it... but without native access no serious dev. will even try to download their "innovative" SDK.

      And please stop selling us Java, we know enough a
      • So far, every mobile platform that started with the premise of "high-level tools only" for development, has gained support for native code. I have little doubt that newcomers will follow soon.

        • by Octorian (14086)

          And with the PlayBook, RIM went to the extreme of this. Made the tools so high-level that no one (except the developers who write things we install Firefox plugins to block) will want to use. However, that's just step 1. Step 2 is going to be releasing a full native SDK that will allow people to actually write real code in C/C++ (or obviously port any libraries we want on top of that). Step 3 will be compatibility layers for existing mobile Java flavors (BB and Android). Of course the PlayBook uses a Q

  • by pjlehtim (679236) on Monday June 27, 2011 @05:29PM (#36590292) Homepage
    Android and iOS have very different UI conventions. TFA mentions the problem but then ignores it. By using PhoneGap (or any of the other similar products) you still need to build two different apps if you want to get good results. Just look at PhoneGap's featured apps examples. Almost every single one of them is written for iOS. If you bring them to Android users wont accept them as native. They will feel wrong. I wrote a post about this very problem into my blog few weeks back: http://www.androiduipatterns.com/2011/06/differences-between-android-and-ios-ui.html [androiduipatterns.com] Benefit of PhoneGap etc. is that you can use web technologies to write the apps. It is a false hope, though, if you expect to "write once, run everywhere". Juhani
    • by Kalriath (849904)

      Plus they forget to mention that if you just wrap your PhoneGap web app with a web view, it'll get on Android Market fine but Apple will reject it out of hand for being a "web clipping".

    • by PCM2 (4486)

      Just look at PhoneGap's featured apps examples. Almost every single one of them is written for iOS. If you bring them to Android users wont accept them as native.

      And then, don't most Android handsets have custom vendor skins? Web apps won't ever blend seamlessly with every Android UI. And the user experience on Android 3.x is fairly distinct from Android 2.x, too. Any development tool that really aims to help your apps be more "cross-platform" will let you target different platforms, not shoehorn the same UI into all of them.

      • by Lennie (16154)

        "don't most Android handsets have custom vendor skins?"

        And why ? really, no why ? Just because of carrier and brand recognition and differentiation.

        No thanks, not interrested.

  • I think the way I like to see it is a common data access and back-end processor and then exposing things via APIs so that the front ends can be written in native/web/smoke signals, whatever you want allowing you to take advantage of the target devices best capabilities.

    • by tepples (727027)

      I think the way I like to see it is a common data access and back-end processor and then exposing things via APIs

      So you're trying to choose a language in which to write this "common data access and back-end processor", so that the application can run even if offline. Would it be written in C# so that it can run on Xbox 360 and Windows Phone 7? Would it be written in Objective-C so that it can run on a Mac or an iPhone? Would it be written in Java so that it can run on Android and BlackBerry? At that point, why not just use JavaScript and hit every current computer, every current phone, and every current game console b

      • by Octorian (14086)

        This is one interesting thing about mobile development. Each platform pretty much dictates a programming language of choice. If its a language you don't mind working in, then its not a problem. But that's not always the case. Personally, I seem to know a lot of sysadmin-types who tend to be stuck-up jackasses about their own little personal language hatreds or preferences, and these opinions tend to be formed completely in a vacuum from target platforms. (Of course, since you can develop in pretty much

        • This is one interesting thing about mobile development. Each platform pretty much dictates a programming language of choice. If its a language you don't mind working in, then its not a problem. But that's not always the case.

          Finding a language unpleasant to work in isn't the problem as much as the fact that I would prefer to write an application's logic layer once and then write platform-specific presentation layers on top of that. It has worked for me in the past, where I've quickly ported a PC game to Game Boy Advance homebrew by writing a new view for the model. But this fails when platforms lack a common language in which to write the logic layer. (See Multitier [pineight.com]; Don't repeat yourself [wikipedia.org].)

          • by Octorian (14086)

            That's also a big problem, because sometimes there is a common language. But the lowest-common denominator version of the language and API is extremely primitive. For example, Android, BlackBerry, and "those other J2ME-supporting phones" (not sure what you call them) can all be developed for in Java. Except...

            - J2ME is based off Java 1.3 (I think), with an extremely primitive API
            - BlackBerry is J2ME-derived, but compensates by adding a lot of useful classes to its API (that obviously don't work on normal

  • The way I see it, a web app is a new kind of application. It is its own niche where doing certain things is easier or more convenient. We'll need native apps for the forseeable future any time we want to access local hardware or integrate with the user's desktop/mobile device environment. A web browser is just way too much of a sandbox for a lot of applications. Sometimes apps need to interact with each other in ways that apps running in different tabs of a web browser just cannot.

    • by PopeRatzo (965947) *

      The way I see it, a web app is a new kind of application.

      Unfortunately, the more the big companies try to push everything into a web app, the worse it's going to be for those of us that want apps to make stuff instead of apps to consume stuff.

      Web apps are to native apps what 1970s TV was to 1970s cinema.

      And this comment is one that only a handful of people will understand because I haven't worked hard enough to make my point clear.

      I don't mind the growth of web apps, but I've noticed a certain stagnation to

    • by Lennie (16154)

      I don't know if you read the summary, but this is about using webtechnologies with a native wrapper (preferable existing open source wrapper like PhoneGap) which gives the webapp access to the native API.

      The native wrapper has the same API on all smartphone platforms, PhoneGap currently supports 6 platforms. Why do this ? Because you don't want to write your application in all the different languages of all the platforms.

  • by FlyingGuy (989135) <flyingguy.gmail@com> on Monday June 27, 2011 @05:40PM (#36590420)

    and the reason is that with all the utility of HTML / CSS / JavaScript it is still brittle

    DOM is getting even more bloated, inefficient and slow. CSS is out of control and when put to the extreme it is like reading RegEx that you didn't write that has 400 expressions in one string. That coupled with differences in even handling the box model between IE and everyone else is enough to drive a sane person over the edge, especialy with the kludges in CSS that were glued on to handle those problems.

    JavaScript is supposed to be the language used to manipulate the Document Object but it was so poorly implemented that jQuery was required to make it reasonably useful.

    For those reasons people keep writing native apps that work correctly the first time out of the gate.

    • by drolli (522659)

      Yes, thats right. The simplest way to write a cross-platform app is to write as must as possible in ANSI C and then bind it using appropriate glue code to the different platforms.

      • by tepples (727027)

        The simplest way to write a cross-platform app is to write as must as possible in ANSI C

        Xbox 360 Xbox Live Indie Games and Windows Phone 7 require all applications to be 100% pure .NET IL. ANSI C does not compile to this target. So what's the simplest way to write a cross-platform app that includes Xbox 360 or Windows Phone 7 among its target platforms?

      • The simplest way, arguably, is to write it in C++ - at least you get a more or less decent object model that way, and can automate memory management with smart pointers, string handling with string wrappers etc. And every mobile platform today that has a C compiler also has a C++ compiler.

    • by Bogtha (906264)

      Some major misconceptions here.

      DOM is getting even more bloated, inefficient and slow

      It's never been faster. There have been huge performance improvements over the past few years.

      CSS is out of control and when put to the extreme it is like reading RegEx that you didn't write that has 400 expressions in one string.

      CSS's syntax has barely changed since its very first version 15 years ago. Its readability is like Perl - some developers make an unholy mess, others produce very readable code.

      Th

      • by FlyingGuy (989135)

        DOM More efficient? Oh please, FF on Windows with 1 tab with /. open it is 100 +/- Megs of Ram ??? You call that efficient?

        FF on OpenSuse with my gmail table my /. tab and a search tab ( google ) open and it is using 400 megs of ram? Efficient? Really?

        Yes and that syntax is horrible and it is worse then Perl and Perl sucks sweaty donkey balls.

        Really then why are we still writing kludges to deal with all the differences?

        I guess we have different definitions of what useful means, I mean really different.

        • by tm2b (42473)
          Not to mention the fact that networks NEVER, EVER go djfhgytirkd
          Djfjfnfjfigogog
          NO CARRIER
        • by Lennie (16154)

          Actually, HTML5* does solve most of the list of issues you mention.

          Just have a look at this page:
          http://diveintohtml5.org/forms.html [diveintohtml5.org]

          For certain environments, like public websites, you might want to add a javascript-file which does the same for old browsers, but this isn't a shortcoming of HTML/JS/CSS specifically.

          I've never looked into this, but I'm pretty sure you can't use OpenGL on your old Atari either. As the OpenGL-specifications didn't exists when the Atari was created.

          * HTML5 and other specification

          • by FlyingGuy (989135)

            No, it doesn't.

            ALL checking is done in the onSubmit() event. In the meantime the user can input whatever garbage they want in whatever field they want and until the submit button is hit the crap just lays there.

            I was momentarily overjoyed when I read the spec and then immediately tried some of this and found it to be garbage.

            If I have a field that I want a monetary value typed into the filed should refuse to accept ANYTHING but the numbers 0 through 9 and the appropriate decimal indicator for that localiza

  • web apps still suck compared to the real ones.
    • It's kinda strange to compare "HTML5 + JavaScript" to VB. VB is just the language - it can only meaningfully be compared to JS alone. Even then, what, exactly, do you find wrong about it? Aside from the fact that it's strongly typed (which is not a flaw by itself), it's a fairly modern language; miles ahead of Java. for example.

      As for HTML, when comparing it to something like Silverlight, the only point on which it is ahead is portability.

      • Basically their both being used as easy to write front ends to databases, which is why I compare them. VBs syntax is just plain clumsy. Using Regular Expressions and doing database access is just plain more trouble, for example. Maybe it's just because I come from a Java / C++ background instead of a Basic background though.

        HTML5 can do anything flash and Silverlight do. I don't know if Silverlight performs better since I haven't had to write anything where performance was an issue (I can count on my en
  • by firewood (41230) on Monday June 27, 2011 @06:12PM (#36590764)

    Software people sometimes forget physical limitations. Web apps require more CPU cycles for the same work (even if just to run a JIT compiler), more CPU cycles will consume more of the user's battery life, and battery energy density isn't getting that much better over time.

    • by caywen (942955)

      I'll be truly happy when javascript jockeys finally discover the benefits of compilation and stronger typing and stop treating the rest of us developers like we don't understand some brave new world or something.

      • by tepples (727027)

        I'll be truly happy when javascript jockeys finally discover the benefits of compilation and stronger typing

        So I've compiled a native application. How do my users execute it on their appliances? They can't because it hasn't been digitally signed by the appliance's maker. JavaScript applications, on the other hand, don't need to be signed by a third party to be deployed.

        • That is because Javascript is sandboxed. You can also sanbox a compiled language.

          Anyway, I disagree with the GP, compiling a web language isn't that important. Type safety is.

          • by tepples (727027)

            That is because Javascript is sandboxed. You can also sanbox a compiled language.

            Only with either a JIT or hardware memory protection. And as of right now, there isn't much demand among users for a sandbox like Google Native Client (which uses x86 segmentation), so makers of appliances haven't implemented it yet.

            compiling a web language isn't that important. Type safety is.

            But is JavaScript type-unsafe? As I see it, every value is a boolean, number, string, array, object, or undefined, and the conversions among these are safe and well-defined.

  • by sgage (109086) on Monday June 27, 2011 @06:24PM (#36590900)

    ... that Web access is going to continue to be cheap, fast, and always-on, then web apps and the whole cloud thing makes some sort of sense. Though there are still privacy and security issues.

    But I don't assume that Web access is going to continue to be cheap, fast, and always-on. I sincerely hope that I'm wrong.

    • by darjen (879890)

      If you're a popular commerce site like Amazon or Ebay, you will need to be connected to the web either way, even if you write a native application. The only reason I see a real need to write a native app is for games, audio editing, or photo editing. If you're a blog, content, or shopping site, I would focus on polishing your web app and leave it at that.

    • They're talking about offline web apps. Basically, imagine a bunch of HTML5 & CSS packaged into a native app which simply creates a fullscreen browser widget and loads that HTML into it. Oh, and exposes non-UI-related native APIs (filesystem access etc) to JavaScript running in that browser.

  • Dan Yoder

    Who?

    CTO at Border Stylo

    Again, who?

    Native Apps Are Dead

    Oh, that again, whatever...

  • Remember when Steve Jobs stood on stage and told developers they did not need to code native apps, because the iOS would ship with an awesome web browser? Didn't go too well, and they were forced to release native app support. Then Rubenstien left Apple to help build WebOS at Palm, that also did not support native apps. They may die someday, but it will not be any time soon.
  • Went to a talk on this at IO this year, here is Google's take on it [youtube.com].

  • Sorry, I just don't see "web apps" as being any kind of meaningful term. It's not an application model, it's a deployment model, which is a different thing. The bits come down through some channel and execute on your system. Some bits execute remotely, but that's been happening for decades.

    • by Lennie (16154)

      Please read the summary again, this isn't about webservices. This is about locally installing HTML/JS/CSS on your smartphone. Why would you want to do that ? Because you can use the same code on many different types of smartphones.

  • FTA:

    One problem with the debate is that it's a false dichotomy,

    O RLY?

    since you can embed a Web browser within a native application.

    That's a native app.

    And, conversely, you can extend an embedded Web browser to provide access to native APIs.

    That's a native app.

    The two alternatives have not been mutually exclusive for years now.

    Whatever. If it runs in a plain old web browser, it's a web app. If it uses platform-specific native code it's a native app. Duh.

    • That's a native app.

      You have a funny definition of a native app, when it applies to something that's 1% C/C++/Obj-C (and even that you don't write yourself but use a pre-made wrapper), and 99% HTML/JS.

      For all practical purposes, from developer's point of view, these are web apps. They only become "native" when they are packaged prior to submitting to app stores.

  • That's not how you use that bloody phrase! No one in the tech world seems to comprehend that the meaning is "The [old] king is dead, long live the [new] king". In this case, the title should be "Native apps are dead, long live web apps". Does it never occur to anyone that the way it is used here makes no sense at all?
    • It surely occurs to me, but I'm quite used to popular english sentenses making no sense. Some times I discover why (thanks for the explanation), but often I don't.

  • There are security issues making the webbrowser able to do all stuff as a native code. There is no way to protect against malicious code on a website in such cases, this is the current argument in the security world about webgl. Javascript and such has very tight restrictions on what it can do.

    Purely native code can run as the coder wishes, with full access to the hardware, if one doesn't need that then go ahead.

    One last thing, Javascript and the like are relatively horrible languages to code in, just caus

    • by Lennie (16154)

      You did read the summary, right ? This is about locally installed HTML/JS/CSS on your smartphone which has some access to the native API, not some random website which you can't reach when you don't have a working wifi-connection/data-connection.

"Ignorance is the soil in which belief in miracles grows." -- Robert G. Ingersoll

Working...