Hacker Newsnew | past | comments | ask | show | jobs | submitlogin
The mobile app is going the way of the CD-ROM: To the dustbin of history (venturebeat.com)
78 points by evo_9 on Nov 9, 2011 | hide | past | favorite | 80 comments


No. Somebody please stop this guy. After reading this I feel about him like the machines must have when they sent the Terminator back in time to kill Sarah Connor.

Web apps are to native mobile apps as Java apps are to native desktop apps: ploddingly slow with clunky non-standard UIs—a degraded, lackluster experience.

With some notable exceptions I think they can be a pragmatically motivated stopgap step (in regards to either bottlenecks in time or money) on the road to building a full native app. But saying simply that because they cost less time or money to produce as a sole justification for creating them, and ignoring all their shortcomings, is like suggesting everyone buy a circa-1998 Samsung flip phone instead of an iPhone simply because you can get one on eBay for $5. It doesn’t matter, because the flip phone sucks and the iPhone doesn’t—economics aren’t the only factor to consider.

If you need any more proof, remember what happened when the iPhone originally launched and there was no support for building native apps. Apple’s professed solution was for app functionality to be provided by mobile-optimized web apps. There was literally a sustained caterwaul by developers and users alike for the ability to create native apps on the platform, so much so that Apple did a complete 180 on their original stance.


> ploddingly slow with clunky non-standard UIs—a degraded, lackluster experience

That sounds like the arguments I used to hear from desktop devs back when web apps start to appear.

Sure web mobile apps kind of suck right now, but theres hardely any frameworks, established processes or documentation on how to build them properly. It's still in alpha stages.

When building mobile apps has matured and if they still have the performance and UI issues, then I might agree. But right now thats like saying a kid won't have a good job because of his grade 5 scores.


>But right now thats like saying a kid won't have a good job because of his grade 5 scores.

Conversely, would you say that a kid in grade 5 who has bad scores is going to have a great job when he grows up, just you wait and see? We can only judge the mobile web as a platform (if one can even say that it is one platform and not many) by what it offers on mobile handsets today, not by what we hope it will one day become. Also, we can't judge it by hoping that one day, all the mobile browsers will conform to the WC3's standards, because we know how good a job today's desktop browsers do at quickly becoming standards-compliant.


Here's the fact: The web is a computing paradigm that was not designed for mobile.


A mobile device is just another client. The web was designed to be agnostic in that regard, was it not?


"When you have a hammer everything looks like a nail"

The web is just another computing paradigm with its own strengths and weaknesses. It's not the be all and end all of mobile.


no it was not. hence the need for "mobile" versions of websites and various hacks to make the web work on mobile devices.


that's not the web's fault... that's the fault of most developers doing the web wrong, refusing to separate content from presentation.

If mobile users only need service-type apps, the web can provide that. Programmers just have to write the screens.

The Web is a dumb terminal. You fill in a form, press XMIT or the equivalent, and get the next screen. Just because someone decided that the content needs to be jammed in a 900px table cell doesn't mean the web can't do mobile too.


How does that follow? That's saying that the mobile clients don't implement everything, not that http isn't agnostic.


So? The web was not designed for video. It wasn't designed for dynamic interactivity either or applications at all, actually. Yet here we are.


I think the current popularity of web apps over desktop apps is driven by two different motivating factors: social and centralized storage.

The nature of the Web makes it well suited to building social apps on top of it. It would be hard to build social apps on an application layer that didn’t transcend physical platforms, because then there would be platform-induced delineations between the social groups that could congregate.

But the other motivating factor is that web apps by definition are a centralized container for the data you put into them. You use Freshbooks and you can access your invoices from anywhere. I think this will become far less important as cloud-storage-on-the-desktop services like iCloud mature and largely eliminate this advantage of web apps. Given this, don’t you think think we’ll actually start seeing a resurgence of non-social desktop apps that would previously have been built on the Web for centralized storage reasons?


Web apps beat native apps because there's no install step, no upgrade step and hyperlinks provide the ultimate way for different apps to communicate with each other.


Agreed, but I would generalize it a bit more and say that web apps reduced the barrier to consumption considerably over desktop applications.

In most cases, mobile apps are close enough to web apps in regards to barrier of consumption to make the difference moot, and when you add the native advantage, the result is a net positive consumer experience for mobile apps.


Web apps are fine for lightweight, data-driven tasks. For tasks that require richer interactions they are still decidedly inferior. This may change as HTML standards and compliance evolve but it's not crazy to suggest that a well-written native app will always be one or two steps ahead.


The question is: besides games, how many apps really use richer interactions than what's already possible using web technologies?


All multimedia content creation apps. Think DJ apps, music creation, audio editing, video editing, 3d modeling, image editing and illustration, etc. Basically everything that makes computers creative tools instead of information management devices. I don't see web versions of any of these seriously challenging native any time soon. Hell, even spreadsheets and word processors are still better in native.

I don't understand why this has to be an either-or thing. I know it's easier for us to think in black and white terms but I don't see why web and native can't coexist for a long time.


From your comment it becomes clear: At the moment "web" is primarily a data display platform. Not surprising, given its pedigree. Input techniques are quite limited... Especially responsive ones we've become used to on mobile. Sounds like a good project to work on..


Those are all desktop apps, though. Mobile apps - like the ones referred to by the article - are rarely for content creation.


Not yet, but these things are converging. There are already fledgling implementations of a lot of these tools available for iPads.


There _is_ an install step to almost all web apps, and it generally involves having to fill out a boring form, clicking through from a confirmation email, and trying to remember a username and password every week for the rest of the app's useful life.


This is unique to applications that wish to store users' data in a central location.


I suspect we have different definitions of 'unique' and/or 'application', because this sounds to me like someone saying the need for tyres is unique to cars that have wheels.


Perhaps. Do you consider a Paint or Paint.NET clone to be an application? A calculator? A clock/weather app? A game where you throw birds at pigs? These are all samples of potentially native applications that do not require login and can be implemented as web pages.

How about services that already require you have an account? You have to log into a Twitter or Facebook or Linkedin client even if you install it as a native application.


I don't care that native apps require work to install. We've already accepted that as a premise. What I'm saying is that web apps have setup costs too, and therefore saying you don't have to install them is disingenuous.

If all you require to get through the day is an online paint clone, a calculator, a clock/weather app and a game where you throw birds at pigs, more power to you - I'm glad you've been able to shave a few seconds off your day.


install once is often easier than navigating to a URL on a phone each time. Many users like apps due to one click launch


When you find a web app you like, you can put it front and center on your Home screen. Just open the web app on your iPhone or iPod touch, tap the plus sign, and then tap “Add to Home screen.” A Web Clip will be added to your Home screen automatically for easy, one-tap access.

http://www.apple.com/webapps/whatarewebapps.html


not sure about android, and 80% of users will not do this (like they do not use bookmarklets). Also many web apps require you to re-login after a certain period, which adds even more pain compared to apps.


"many web apps" do. But they don't have to. That's a choice the developer makes. That's super easy to fix, too.


Agreed. Like Google+ and gTalk etc? This is clearly the UX standard ahead yes?


> Sure web mobile apps kind of suck right now, but theres hardely any frameworks, established processes or documentation on how to build them properly.

Your argument assumes that building good web applications is merely a function of tools. It's not.

We have a performance-per-watt wall, plus a heat wall, plus a weight wall in mobile hardware.

There is a reason that Apple is pushing C-based development without as much as a garbage collector, it's not just the stubbornness of Jobs. It's because a dynamic language with state-of-the-art VMs struggles hard to do basic smooth animations on current-gen mobile hardware, and will continue to struggle, for at least the next five releases of Nitro.

You're going to need something like a battery revolution to build the mobile web app panacea that you want.


It is a function of tools. iPhone App have smooth animation because they run on Open GL accelerated graphics, yes. But so could Android apps. The difference is that the iOS SDK allows you to `pushViewController:animated` and that's it.

In the (pretty far I think, unfortunately) future, an SDK/Framework/Library à la jQuery will propose the same tool to run Web GL animations.

We need a UIKit/CoreAnimation for the web. The technology is not there yet, but it's going to be.


That sounds like the arguments I used to hear from desktop devs back when web apps start to appear.

It's also like the arguments made against Java 10 years ago. :) I agree with you - it's not yet clear whether web technologies will significantly replace native for mobile or not. Even if they eventually end up doing so, that appears far enough out that I can't imagine making any decisions based on that right now.


"used to"?

I certainly haven't stopped making this argument for web vs. desktop apps, as it has yet to be solved. If it even can be solved (mainly the UI/UX issues; performance probably will eventually approach "good enough" for a given app.)


That sounds like the arguments I used to hear from desktop devs back when web apps start to appear.

And it still holds true in many cases. Microsoft Outlook, in many ways an example of both great and horrible desktop software, still holds the email client majority: http://www.campaignmonitor.com/stats/email-clients/

Web apps are great when you get along with the designer's UI decisions. When you have a fast network connection (that's improved with specific web apps and offline modes, but it's by no means generally applied). When the servers are working well.

Mobile apps share the same advantages and disadvantages, but they're multiplied tremendously. I lose my mobile signal in most stores I go into, for example, and on an awful lot of secondary roads throughout the Northwest.


Outlook? The "majority" email client? Really? From your source:

"The fine print

The email client a person is using can only be detected if images are displayed. This can give an inflated weighting to email clients that display images by default, such as Outlook 2000 and the iPhone. It will also provide a lesser weighting to those that block images by default such as Gmail and Outlook 2007. Those email clients that aren't capable of displaying images, such as older Blackberry models and other mobile devices cannot be included in this study."

Outlook isn't nearly the majority email client, it's just the one most likely to not block img bugs.


Outlook isn't nearly the majority email client, it's just the one most likely to not block img bugs.

Do you have anything to support that claim?


Agreed. And for some apps, where you need to work offline, native is great. But for apps that require a network connection to work, I don't see the point of a native app.


I realize you're referring to Swing Java apps, and I won't argue on their behalf for a second. However the SWT library is a dream of a native toolkit experience if you're writing a client app in Java. It's fast, does a good job of working across a wide variety of platforms (Win32, Cocoa, GTK, and I think Motif), and is extremely well documented.


Web apps don't have to be as "good" as native apps to succeed. They just have to be good enough. Remember that web mail exploded in popularity in the late 90s. Do you remember what the experience was like on Yahoo Mail in 1999? Full page refreshes on dial-up modems to see a single email. Yet people swarmed to Yahoo Mail, Hotmail, and the like.


The problem here is that these articles are very extremist. There are many native apps that can easily be done as web apps (cost and time effective), but not all of them. You can't choose one platform and just say it's the best choice overall.


One significant difference between Java apps and web apps is that, unlike Java, the platform vendor has huge incentives to keep improving your runtime (the browser).


Get used to these kinds of comments. There's a large contingent of people on HN who don't understand that higher level languages (say, Java) are not a complete replacement for C/C++. The same people are behind the "HTML5+Javascript ought to be enough for anybody" mentality.


Yahoo has just announced Yahoo Cocktails, a set of tools for developers to use that make web apps look and behave more like native apps. Mozilla is working on tools to help developers sell web-based apps to mobile device users, enabling them to make profits just as developers in the iTunes App Store or Android Market can now do.

Yes, we can finally relegate this obsolete dinosaur to the dustbin of history once we faithfully replicate every aspect of it.


Just like how DVDs fundamentally do exactly the same thing as VHS tapes, with a couple of minor differences?


DVDs didn't have to struggle to become as good as VHS. They started out better.


Moreover Yahoo as the dinosaur slayer !


I don't think we'll be replicating the "can only run on only one OS" aspect of it, among others.


I'm sympathetic to what he's saying. It is painful to develop lots of separate platforms.

But I work making games. And so this promised land is still way over the horizon. We're only just getting to the point where a HTML5 game can be notable as anything other than a tech demo on the desktop. It'll be another few years before we reach that point for mobile.


Indeed.

But a lot of mobile apps are not like games. They are adaptations of web sites for a particular mobile device. This is where what he is saying surely makes a lot of sense. Really, apps like twitter should be able to be done with HTML5.

But more involved applications like games make sense to be native applications.


But even games are written in standardized frameworks like OpenGL and DirectX, with DirectX being the winner at the moment. Unless you're talking about Flash games where, uh, Flash is the standardized framework.

It seems that standardized frameworks aren't the problem, performance is. So what's your take on hardware acceleration, canvas, and WebGL?


Agreed.

There are always going to be classes of applications that need every bit of performance they can squeeze out of their host platform, and will be written native to that platform.

Web apps are very useful things, but this "native code is dead" line has been touted before and it was wrong then too.


Everything will be relegated to the 'dustbin of history' given a long enough time period, it's a completely meaningless statement.

CDs were quite useful for many years, before they were replaced by newer, superior technologies. Mobile apps are currently the best way to deliver the best user experience on mobile devices.

In the future this may change, but that should not be particularly surprising to anybody given how quickly technology improves.


“There’s always some stuff around the edges that won’t work perfectly, but compared to writing in seven different languages, it works.”

Write once, run anywhere. Why didn't anyone think of this before?


What are those 7 languages, anyway? The guy has a strong point he can make without exaggerating. If you want to capture > 90% of the mobile market, I think you only need Objective C and Java.


If you want the rest of the smart phone market, you'll need a C++/QT app, another Java app, and a .Net app. Conveniently, you can #include lua.h in all of these (except maybe BlackBerry) and end up only writing the UI code in the native language.


Or C#, thanks to the MONO guys...


I can think of 6 frameworks: iOS, Android, WP7, Blackberry, Palm OS, Meego.


It pains me to say, but MeeGo is a dead OS, at least on phones. Nokia has already said they'll ditch it even if N9 sells well.

Palm OS is obsolete too, they now use a version of webOS.


Ah yes. Write once, mediocre everywhere. Let's strive for that!


Javascript working on multiple platforms (browsers) isn't quite a new concept is it?

Sure IE6/7 had poor JS performance but IE7 is nearing death and performance of on mobile browsers is increasing rapidly (as well as CPU performance).


The performance isn't an issue, but Google Docs still isn't anywhere near the quality of Keynote or Word. iCloud will remove the advantage of instant synchronization, so there aren't many upsides (as a user) to avoiding the native app that adheres to your platform's interface guidelines.


Web apps were a natural bridge into the "cloud" world but now that we've all gotten good at decoupling our UIs from our backend and building all our web apps like a service native apps can just as easily be natural clients of the cloud.


Ultimately, whoever writes the checks gets to decide what to strive for. If you can afford to hire a developer for each platform, great. Otherwise HTML5 is a compelling alternative.


Wasn't someone from Wired who said that mobile apps were going to replace web apps, and so the web as dead ??

And now, we have Yahoo saying "no no no, web is the way to go, look at us !!".

Quite frankly, this type of discussions sucks and are totally irrelevant. Let the market decide, don't be a palm reader, as you might end up with your palm in your face.


I think a couple interesting things are happening.

It's becoming more obvious to everybody that good mobile applications are not cheap. This isn't news, but I think the fact that it's widely understood is new within the past year or so.

Also, supporting multiple platforms tends to linearly multiply costs.

Also, good web based mobile apps are getting "more possible" with new technologies so there are reactions kind of like what this author seems to be saying is a done deal. The idea that mobile apps are dead is totally absurd. I mean, ask anyone on Android who's used maps.google.com on their phone (which is totally amazing) whether they have uninstalled the Google Maps app - it's just not happening.

There are two things that are important that the author seems to be ignoring - first is the fact that developing a good mobile web based app isn't easy or cheap either. The costs of supporting a gajillion mobile device web browsers and form factors won't multiply directly with the number of platforms out there, but there will be many, many platform/browser/form-factor specific bugs and annoyances to deal with. Second is the fact that regardless of how awesome canvas / mojito / etc. all get, afaik there is no model in the future where mobile web-based apps have an ability to do something like interact with the local data sitting on the device in other formats (like people / calendar) or with other devices that the mobile app developer can take advantage of (bump / beam). Rich interactions like that can let the mobile app developer build a much cooler experience.


Sometimes i wish more people would care more about making good products rather than the next buzzword middleware stack which solves everything.


Calling the internet a "buzzword middleware stack" is underplaying the fundamental differences between the web and native apps.

Even now making a web app as opposed to a native app does not necessarily preclude quality; as mobile web browsers and technologies mature, web apps are going to afford developers more and more quality.

If I wanted to make a quality app to reach even just both Android and iPhones, I would effectively have to implement it twice--first in Java and then in Objective-C, using different libraries throughout. With a web app, I could write it once. Of course, maintaining browser compatibility and overcoming potential shortcomings of current browsers probably means it would take me longer to write the web app to a similar level of quality than either the Android or iPhone app; however, it would almost definitely not take longer than both put together. Thus, I would have more time to add quality to my web app--and less maintenance headaches--than I would just supporting both Android and iPhone natively (not to mention other platforms like Blackberry or Windows Phone).

Ultimately, I think it's the people who just want to make quality products that can reach a large audience who should care about web apps.


Desktop apps eventually got replaced by web apps because it is more convenient to access the app from anywhere - from any computer, not necessarily because web apps were easier for developers. Now with mobile apps developers are hoping for the same thing to happen again but this time, users don't have the same pull - they always have their phones with them. I'm not going to log onto a mobile terminal at the library to check my email or run some app. To look at it from the other side, if omnigraffle was always available to you as a native app, as your app with your settings, with all of its slickness, would you want a web based alternative?


The guy talks about tired analogies, whilst making one that looks positively sleep deprived in his headline and conclusion!


I would love to see browser become the primary interface for everything interweb (speaking as a web app developer). But this article would be more believable and reassuring if native mobile browser makers would make with filling the native functionality gap already. I mean access to contacts, cameras, mic, phone, bluetooth, file system, everything. They don't even offer all those yet on the desktop. The browser vendors are so far behind their own potential.

But: I think ChromeOS will be a big deal some day.


As a recent convert to moai (http://getmoai.com), which is a Lua-based cross-platform environment for game development, I have to say this: hogwash.

Cross-platform, easy to use, deliverable as a download for offline use, publishable on the web: a moai project already delivers what this guy is blowing hard about. Its not going away just because he says so. In fact, the future is here already - put your app on the cloud, let users decide if they want to install it locally or not.


> tools that make web apps look and behave more like native apps [will somehow help web apps kill native apps]

You can't kill anything by trying to imitate it.

Especially when you have constraints that ensure that your imitation will always be lagging behind in terms of features and performance.

Web and mobile apps simply offer different tradeoffs between reach, features, and development costs and, as such, have every reason to coexist.


You can knock apps all you like but what Jay Sullivan hasn't done is to give us a clear reason why we need Firefox as a mobile browser, or even why it's so much better than Chrome. Firefox was a breath of fresh air in a world that was owned by IE, but it seems to have lost a core focus. And ironically the one browser my friends keep talking about on mobile platforms is Opera...


The motivating factor I've seen is the fact that somehow, people got it in their head that in order to be legitimate, the "app" has to be in the App Store. This is one reason why we have a mobile app, which offers nothing we couldn't already do with jQuery Mobile. We're not using the accelerometer. We're displaying data.

But "being in the app store" is more important to our users right now.


It's easy when you split the app in frontend and backend, but how to tackle an app that has to run disconnected and survive phone reboots?


I feel like anyone who makes an argument that Node.js is "the future" is making the same case that a polluted natural environment is "the future". A horrifying vision of what could be reality unless we make it better.

Friends don't let friends make a career out of programming in JavaScript.


Really ? JS is an amazing language, much better then say PHP. And trust me, there are people building careers out of PHP. JS correctly used can do amazing things.


This article lacks anything serious to consider, and strikes me as far too close to being link-bait. Judging by the contents, its title is, at best, an ignoratio elenchi. It should have been entitled, "Mobile Web Apps Will Save Developers Time Compared to Native Apps".

The article espouses little more beyond the offerings and appeals of companies making yet-to-be-proven predictions about what the future of mobile apps will be, in an effort to secure and advance their business's goals and existence. These goals are not the goals of the users, who will ultimately decide what the best platform for mobile apps is--not on its technical merits, but on its ease of giving them the shortest and most pain-free path from want/need to procurement. The only mention of the users is in saying they can hardly tell the difference between a native or web app--and that completely depends on what type of app they are comparing.

Smartphone popularity among the general public skyrocketed as a result of the App Store. The mobile app didn't rise to such sexy heights because we developers were out there salivating over creating HTML apps for smartphones. It rose because consumers finally had a good way to find a fun or useful app with a simple search of a (usually) simple app name. No more remembering URLs. No more bookmarks. No more, "Was it .com or .net?" Just a simple tap-to-install process resulting in a recognizable icon they could flick to and launch with their thumb. The App Store and the mobile app model gave consumers a very easy to understand and re-use paradigm for finding and using apps.

I've enjoyed the development and rise of the web since I was a kid. I've been excited by web application development, watching web apps get ever closer to offering what can be done in a native desktop application in both features and usability. Plenty of web apps are better than their desktop alternatives (or don't have any).

However, the web still has not solved the biggest problems the App Store model solved for both developers and users--and users are what matters when it comes to keeping developers building and making money.

I doubt I'm the only user who frequently forgets the URL of a site, product, web app, or what-have-you that I want to find/use when I want to find/use it, and I've got a pretty good memory (though I suppose I'm not entirely objective). Users don't have to worry about that on their phones--where they more-often-than-not remember an app by not just its name, but its name in association with its icon. Problem solved.

Moreover, and more importantly, the web (in its desktop-based incarnation) has struggled in so many visible, obvious, and personal ways (for devs/companies) when it comes to the one thing that matters most--getting users to pay to use your shit. Users on the web have an implicit expectation that websites are free (hello newspapers?). And I think that's what made the web what it is today. With mobile apps, there is, imho, a much lower implicit barrier to payment than the web has ever been able to obtain for itself. Problem solved.

What's the web platform for making money? Oh, right ... we already know ... advertising. Everywhere. Yuck.


I bet that mobile apps will be overtaken by web apps in about 5 years.


If you want to make this true, go out and actually build a web app so bad-ass that what it does can't be outdone by a native application.

Until then, stfu.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: