Slashdot Mirror
Native Apps Are Dead, Long Live Native Apps
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.'"
Well at the very least, you need a native developer to develop the software the web developer uses to developer his web software. I think.... but as a native developer, I'm not sure whether I'm making myself redundant in ten years time by not going all in training for web development.
Developers are simply scared of losing profits when their software can be manipulated and redistributed. The solution? Keep everything on their side of the fence. This is not a new idea. It just takes people some time to come up with reasonable sounding excuses.
Isn't that why an x86 emulator was made in JavaScript? Best of both worlds! Native code IN a browser.
I made an app! Shoutium
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.
"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.
Truly exciting things happen in native environments.
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.
Bram Stolk http://stolk.org/tlctc/
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 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
"the appeal of writing code that will run on a variety of different devices"
That's just it. Apple wants to limit your ability to do that.
"National Security is the chief cause of national insecurity." - Celine's First Law
If you're a native application developer, I suspect that you'd be absolutely miserable if you ever had to work on web apps full-time.
Web app development is challenging for all of the wrong reasons. Whether it's having to use horrid languages like JavaScript or PHP, or dealing with broken browsers like IE6, or dealing with shitty MySQL databases "designed" by people who didn't understand even basic relational theory, you won't find much enjoyable about it.
At least native applications are often built using real programming languages like C and C++. Even semi-native languages like Java, C# and, dare I say it, VB.NET, are much, much, much more enjoyable to use than JavaScript or PHP, or dealing with broken HTML, or fighting with stylesheets.
I'm glad I was able to retire without having to do too much web development. Everything about it was decades behind where native applications were at the time, and things still haven't changed.
web apps pump up the data costs and roaming rates starting at $0.015/KB make them cost a lot.
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.
------
"And may your days be long upon the earth."
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.
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.
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.
Hey KID! Yeah you, get the fuck off my lawn!
web apps still suck compared to the real ones.
Call me back when EVE Online or any other REAL game goes mobile or browserbased... Pffh!
Wait... EVE does have an ingame browser... hmm....
Native is where the cool stuff happens. I've been doing distributed web applications for school and it's so boring! On the contrast, experimenting with Unity3D never ceases to amuse me.
This isn't really about native apps vs web apps, but rather what technology to use to build the front end appearance and behavior of actual apps. Apps that use HTML/CSS/Javascript for this task, instead of Java or Objective C or whatever, are thus known as "hybrid" mobile apps.
In other words, PhoeGap etc. allow one to build a front-end interface in HTML5/CSS/Javascript, then package that up as an actual native application for various platforms (leveraging the platform's web browser under the hood). The frameworks usually allow you to take advantage of various native APIs that aren't normally accessible through a web browser (ie, that a normal web app can't use) and store data locally (ie, run the app offline), while reusing the same code across various platforms (and possibly as an actual web application version, as well).
The amount of "platform-native" programming required to implement the app on various platforms is thus minimal.
Also, some of the performance concerns are not as much of a problem as you might imagine, due to hardware-accelerated CSS3 transitions, etc. on various platforms. (Others actually convert Javascript to native code, obviating some of the potential performance issues.)
One approach might be to write a regular web app first, targeted at "modern" smartphones (primarily iPhone and Android), then convert that to a PhoeGap application that can be targeted as a native app for those platforms (and more, such as Blackberry and Windows Phone 7).
For more about this, see:
http://www.technologyreview.com/computing/37831/
http://www.appmobi.com/index.php?q=node/95
http://www.amazon.com/Developing-Hybrid-Applications-iPhone-JavaScript/dp/0321604164
My Firefox plugin uses a mix of native app & web to create mp3s. There's no reason not to when it's convenient. Even Microsoft is moving to html5 + javascript. It beats the heck out of VB.
Hi! I make Firefox Plug-ins. Check 'em out @ https://addons.mozilla.org/en-US/firefox/addon/youtube-mp3-podcaster/
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.
But do we really need to turn a text document format into an application framework again? Do we really have nothing better to do than recreate old Microsoft technologies?
Really, I haven't seen much good come from these "web apps". All I'm seeing are applications we already had being stripped down and made more resource heavy and inconsistent than ever before. Why do we have a billion different layouts for message boards and blogs? Why do we need a billion different icon designs and color schemes? Why do we need a billion different custom context menus? Why do we need to break everyone's back button? Why do we need a billion different video players? Why does this site look different in that browser? Why do none of these buttons look like the buttons I usually see? Why do these scroll bars, forms, and other widgets behave differently from the widgets I usually see? Why does that menu drop down on hover and this one when I click? Why do we use hover when there are so many touch screen devices out there? Why do some sites steal my middle click so I can't open things in new tabs? Why do various google sites use spans with onclick events when they're made to behave exactly the same as a standard link? Why do none of these GUIs follow the conventions of my platform? Why is it normal for an article of text and an image or two to use up a few hundred megabytes of memory? Why is it okay for Google Docs to make my CPU cry when it does less than MS Office 2000? Why are simplistic based painting applications on a Core2Quad less performant than Photoshop 7 on an old G4? Why is any of this normal?
Why did we accept this as the platform of choice going in to the future?
There are web apps, and local apps. But these days local apps are increasingly done with managed code.
It's been years since I've had a job where unmanaged code was permitted. I won't claim there aren't still some around, but they're fading into the background of development and for good reason.
So it is true, native apps are dying, but it has nothing to do with the web.
I've been working on an iPhone app called Phresheez, where the majority of the content is display via built-in web view in the native app. That let my partner in development make the Android version easily. Actually, he got the Android version working before I got the iPhone. And that was over 3 years ago.
It's proved to be an excellent way to manage the app. We still do a lot of native work (accessing sensors, custom features, in-app purchase, etc.), but the majority of user interaction takes place via a web view. It "talks" to the native app (via a delegate method on the iPhone, I don't know the Android details) and vise-versa.
The really wonderful part is that we can 'upgrade" the web part of the app at any time. As soon as the user restarts the app, they have the updated web app inside it. Our web app updates on a very regular cycle (a few times a week) versus the native apps which have been updated every few months as necessary (more on the Android than the iPhone, mainly due to easy of update with Android vs. iPhone). /. where the old is news again... :)
... 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.
Appcelerator seems to be an awesome compromise between the two... develop in a language webdevs are familiar with (Javascript) across many different hardware platforms (iOS, Android, Blackberry etc). It's not web dev, it's Javascript [runtime?] compiled to Objective-C (and Java for Android etc). It's a bitch to learn but once you get the hang of it it's super easy to throw together an app in no time. http://appcelerator.com/ (their docs aren't the most accurate, it's best to read the kitchen sink code).
http://xamarin.com/
Native apps and web apps are like desktops and laptops. Laptops are more convenient and portable, but are harder to upgrade and generally less powerful. Laptops have advantages, but they aren't going to replace desktops anytime soon. Instead they will coexist until technology advances enough that laptops can replace desktops. Web apps are more portable and convenient; but native apps are faster and offer greater flexibility. They will coexist until computers are fast enough to run web apps at native speeds. Then the only native apps will be the OS and browsers. That is still a long time off. So stop worrying about it.
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.
He said "extend an embedded Web browser to provide access to native APIs".
He'll need ya on staff permanently fixing goatse sized security holes.
The Christian religion has been and still is the principal enemy of moral progress in the world. -- Bertrand Russell
Fwiw: I've only ever used the web browser to read slashdot. Native rss readers appeal to me but I enjoy slashdot in all it's quirky splendor. I've used native email clients, but I keep coming back to webmail.
Photo editing, video editing, I use native, but even tv and mp3 playing is acceptable to me with web services. Despite the downsides of not "touching the metal" -- as an iOS dev said having the same discussion at WWDC -- I tend to lean with what works best for the job, and the web -- in one shape or the other -- is getting the job done more and more each day.
Too bad most web apps suck ass. Also, developing web UIs seems to be massively time and effort consuming. I know our company spends about 10x the effort making sure our web facing UIs work than actually generating the data that the web UIs serve up.
Went to a talk on this at IO this year, here is Google's take on it.
[alk]
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.
Try to do RSA 1024 and AES 256 in a Phonegap Application with JS algorithms. You will have lot of fun there, specially waiting to the encryption / decryption happens. There is some things you still need to use Native for. Another example is trying to use a X509 certificate in the phone keychain and connect to the valid IP that this certificate was issued for.
For basic apps it is ok to work under the premises of general abstraction libraries (HTML + JS + CSS -> Webview -> Objective C) , but there is other places where the applications might need some more encryption and privacy protection than standard - i.e. Bank applications and more private access applications.
We're told how great these web based apps are, and darned if some or most of us buy it. We get the computers running fast, so we come up with apps that slow it down. It's the latest form of software bloat. The time may come when we look back fondly on those Vista basic machines foisted on us a few years back.
The shepherds did so well protecting the flock that the sheep no longer believed that wolves existed.
O RLY?
That's a native app.
That's a native app.
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.
you don't consume digital content, that's an idiotic idea.
Then what's the general word for doing something with digital works other than creating them? What word covers viewing, listening, playing, etc. without being specific to a single medium?
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?
Funny may not give karma, but +5 Informative never made anyone snort coffee out their nose.
Whether it's having to use horrid languages like JavaScript or PHP,
JavaScript isn't a bad language. It's not a great language, but it's much better than it's given credit for.
PHP is, however, a pretty bad language. Maybe it's gotten better recently, but it's not a great choice -- especially when, on the server, you have options.
or dealing with broken browsers like IE6,
That does suck. Last time I did web development, it took something like an hour a week. But that's really not bad, in the scheme of things.
We also eventually decided to drop IE6 when we noticed how little of our traffic included it -- we targeted at least IE7, which was much better in that respect.
or dealing with shitty MySQL databases "designed" by people who didn't understand even basic relational theory,
In this case, you're in the same boat as with PHP -- that is, you're working with legacy code developed by shitty developers. You find the same shit everywhere.
Or you can use languages that are actually enjoyable on the server side, and work with designers who actually do understand databases.
At least native applications are often built using real programming languages like C and C++.
I'd prefer JavaScript to C++, but then, I hate static types. But I'm confused that anyone in their right mind would prefer C to JavaScript. C, really?
Even semi-native languages...
What do you mean "even"? I mean...
like Java, C# and, dare I say it, VB.NET,
Are you really saying C and C++ are more enjoyable than the above?
And people are taking you seriously?
I could see the argument that they are more "powerful", in some sense. More efficient, certainly, in the hands of someone who knows what they're doing. But more enjoyable?
I enjoy not having to debug segfaults anymore. Let's start with that.
or dealing with broken HTML,
How is this any worse than, say, dealing with a broken GUI widget?
or fighting with stylesheets.
This is probably the worst part of web development right now, so I do agree with you there.
But I'd still rather fight with stylesheets than fight with manual memory allocation in C and C++, or with making Java, C#, and VB.NET programs actually cross-platform -- or even be sure they work on everyone's machine. There are far fewer popular browsers than there are ways people will fuck up Windows.
Everything about it was decades behind where native applications were at the time, and things still haven't changed.
Oh, they have changed.
There are aspects which are decades ahead of native apps now, but there are also aspects which are decades behind.
Don't thank God, thank a doctor!
I read similar arguments when java applets arrived, or flash, or webstart... Cant wait to read why native apps are dead when HTML 6.x arrives :)
The point is, there are plenty of use cases where web apps are the thing to do instead of going native - and a whole lot of situations, where you just don't want a web app.
I think also one has to remember that browsers didn't start as runtime environments but as rendering engines.
Will there be more web apps coming ? Sure
Will there still be native apps ? Sure.
For me, beside platform native look & feel, the beauty of native app is ability to read/work with info, news, etc. while offline. Try working with any of these web apps while on trans Atlantic flight.
:: There is no light at the end of a tunnel. There is a tunnel after a tunnel : Thom Y.
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 cause a developer can code in it doesn't mean he/she likes coding in it.
Finally where did bytecode go, between native and web it's supposed to be a compromise for this kind of situation?
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; Don't repeat yourself.)
In a modern US business you are almost certainly regulated by some cluster of Republican-sponsored laws advantaging multinational corporations over small family businesses. I'm always subject to some combination of HIPAA, GLB, SOX, or FDA regs no matter what I do.
Those regulations preclude running any unsupported operating system. My clients can't run win98, DOS, or WinNT anymore... but many apps I wrote for those platforms more than ten years ago are still running today, because I wrote them as web apps.
If you are the kind of person who obsesses on shadow borders and microscopic differences in fonts, a presentation layer person who cares little for actual content, web apps suck. If you are the kind of person who analyzes a problem and designs an optimally efficient and durable solution, the web is your friend! Do you want to rewrite your apps every single time the client desktop gets a major patch? I don't have to. The continuing trend towards browser standardization means my apps look prettier every day, without me doing anything but writing to W3C standards. And the stuff I wrote ten or more years ago still runs securely and perfectly, because I didn't do any techniques that called for any browser specific hacks at all and I used no client-side code more complex than the simplest javascripts. We intensively maintain a small group of servers and on the clients we just accept every patch Microsoft, Apple, and our AV vendors push down the pipe and call it a day.
Recently I wrote a cron-like interface to iNotify on linux, to drive some backend server processes. I wrote it in C, with no GUI and no end-user interface other than a text file. Server apps like that are why native apps will never die - but for client GUI presentation it's wise to use the web whenever possible. The return on investment is fundamentally better, because you don't have to rewrite all your apps simultaneously as you upgrade every desktop due to HIPAA or FDA. We have over 400 apps - and no app upgrade cost when we implement a new desktop.