Native Apps Are Dead, Long Live Native Apps 168
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.'"
When all you have is a hammer... (Score:5, Insightful)
Re:When all you have is a hammer... (Score:4, Insightful)
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?
Re: (Score:3)
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...
Re: (Score:2)
Re: (Score:2)
I have several of those near my home computer.
Re: (Score:2)
Re: (Score:2)
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.
Re: (Score:2)
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.
Re: (Score:2)
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 :) )
Re: (Score:2)
I think most "webapps" for smartphones (actually locally installed HTML/JS/CSS with native wrapper) don't really need a back-end server.
Re: (Score:2)
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.
Re: (Score:2)
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 ?
Re: (Score:2)
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.
Re: (Score:2)
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
Re: (Score:3)
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#/
Re: (Score:2)
Java? Makes it about as much web as x86 assembly then.
Re: (Score:2)
Re: (Score:2)
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.
Re: (Score:2)
Not if they are web apps.
Web Or Native it doesn't matter (Score:3, Interesting)
Re:Web Or Native it doesn't matter (Score:5, Interesting)
"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...
Re: (Score:2)
I didn't say "easy", I said easier. And you seem to be measuring "difficult" based on keeping track of a bunch of changing APIs and syntax.
Making sure your Javascript code works on every browser and platform is not as much "difficult" as "tedious". Writing a fast, efficient Javascript engine with generational garbage collection and a just in time native compiler is "difficult".
I have a lot of respect for a good auto mechanic who knows how to work on a huge variety of makes and models, but I still think it
Re:Web Or Native it doesn't matter (Score:4, Interesting)
Re: (Score:2)
Native is more sexy (Score:2)
Re: (Score:2)
Like cannibalism!
lowest common denominator (Score:5, Insightful)
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)
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.
Re: (Score:2)
Write once, debug everywhere
That's what phonegap is for... it's like the jquery of mobile.
Re: (Score:2)
i thought jquery mobile was the jquery of mobile? :P
Re: (Score:2)
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
Re: (Score:2)
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.
Re: (Score:2)
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.
Re: (Score:3)
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
Re: (Score:2)
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.
Re: (Score:2)
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
Different UI conventions (Score:3, Informative)
Re: (Score:2)
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".
Re: (Score:3)
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.
Re: (Score:2)
"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.
Or do both... (Score:2)
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.
Re: (Score:2)
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
Re: (Score:2)
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
Ever heard of MVC? (Score:2)
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].)
Re: (Score:2)
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
Way I see it... (Score:2)
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.
Re: (Score:3)
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
Alternative to "consume" (Score:2)
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?
Re: (Score:2)
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.
The Native App Will Never Die... (Score:5, Interesting)
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.
Re: (Score:2)
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.
Re: (Score:2)
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?
Re: (Score:2)
Don't include Xbox 360 / Windows Phone 7 in your mobile application plans?
I mean... you're missing out on, what, two users?
If not for Xbox 360, then for which set-top device should one develop? Nintendo blanket refuses all home-based businesses [warioworld.com], and Sony's signup page [scea.com] has been down for two and a half months straight.
Re: (Score:2)
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.
Re: (Score:2)
Some major misconceptions here.
It's never been faster. There have been huge performance improvements over the past few years.
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.
Re: (Score:2)
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.
Re: (Score:2)
Djfjfnfjfigogog
NO CARRIER
Re: (Score:2)
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
Re: (Score:2)
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
the only problem is... (Score:2)
Makes since (Score:2)
Re: (Score:2)
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.
Re: (Score:2)
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
Battery life (Score:3)
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.
Re: (Score:2)
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.
Re: (Score:2)
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.
Re: (Score:2)
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.
Re: (Score:2)
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.
If you assume... (Score:3)
... 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.
Re: (Score:2)
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.
Re: (Score:2)
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.
Re: (Score:2)
On your smartphone.
Huh? (Score:2)
Dan Yoder
Who?
CTO at Border Stylo
Again, who?
Native Apps Are Dead
Oh, that again, whatever...
Jobs pushed this once.... (Score:2)
Google's take (Score:2)
Went to a talk on this at IO this year, here is Google's take on it [youtube.com].
Web apps are native apps (Score:2)
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.
Re: (Score:2)
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.
Native app vs native app (Score:2)
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.
Re: (Score:2)
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.
Oh For Gosh Sakes! (Score:2)
Re: (Score:2)
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.
Look at all the angles first! (Score:2)
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
Re: (Score:2)
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.
Better to be redundant than totally miserable. (Score:4, Interesting)
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.
Re: (Score:2)
As a web developer, I agree with you.
As a web developer, I recently used some Javascript magic to... drum roll please... make a box with text in it appear in a corner of my application display. Of course, the contents of the box have to be saved to the web session so that the box can be re-drawn and then the text in the box re-written from the web session. This took a while. Even after all these years, a dialog beyond [Confirm] [Cancel] has to be custom built using Javascript (or you can import one from
Better to learn your tools than be miserable. (Score:3)
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
Re: (Score:2)
Re: (Score:2)
Web UI development is challenging for all the wrong reasons. Whether it's having to deal with inconsistent widgets across browsers, or dealing with users whose browser settings break your page, you won't find much enjoyable about it.
At least mobile applications allow you to either use their rich interfaces for run-of-the-mill layouts, or (better yet) create your o
Re: (Score:2)
At least web applications allow you to create your interfaces using a real presentation language like HTML and CSS.
We've had that for a long time in managed land - WPF & Silverlight on .NET have XAML which, unlike HTML, was designed as an UI markup language from grounds up. Java has a bunch of third-party solutions similar in concept as well. Finally, for "pure native", there's Qt Quick and its QML.
Re: (Score:2)
C'mon guys. We're all programmers here. Our lives already are absolutely miserable for any reason you can imagine.
Aw, poor ickle baby.
Now shut up and stop whining, you're almost certainly better off financially, physically and emotionally than 95% of your fellow citizens.
Don't worry dude! (Score:2)
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.
Re: (Score:2)
Re: (Score:2)
And you have lots and lots of webdevelopers who don't know anything about how to do webdevelopment properly.
No thank you.
There are people who do webdevelopment right, but it isn't taught anywhere. :-(
Atleast not that I've seen.
Re: (Score:2)
People without proper education can't recognise a decent framework when they see it.
So a lot of the time they choose wrong. :-(
Re: (Score:2)
How many native developers will be working on browser teams, though?
While I don't personally believe everything will move to web apps, a lot is. Some of it for good reason, some of it because CEOs and other stupids thinks it's a good idea... so it's happening.
But hasn't it always been like that in IT? If you cling on to one old platform and aren't willing to learn new technologies, you're eventually going to become irrelevant?
Re: (Score:2)
They did rescind that in the 14 months since the article was written. Now you're perfectly free to write code that works on a variety of devices. And if you write code that runs poorly on a variety of devices, you'll be savaged in the reviews (as Safari Books Online was, with their Phonegap app release http://blog.safaribooksonline.com/2010/11/24/ipad-app-safari-to-go-update-november-24-2010/ [safaribooksonline.com]). They came back and rewrote it native, and people are much happier.
Re: (Score:2)
All that we need is to run this x86 emulator... on a x86 machine. Inside a browser.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Mostly because of old browsers, this is not the same problem as on smartphones.