Hacker News new | past | comments | ask | show | jobs | submit login

I posted this comment in another thread about apps, but too late for it to really get any responses:

- app discoverability sucks ass

- apps require updates

- app development is unnecessarily tedious and must be done x number of times for x platforms

- iOS apps need to be approved by Apple, and you have to play the game by their rules if you want to charge money for them

- apps lack basic features of browsers - no universal find, no back/forward buttons, no bookmarking of pages or states, no organizing apps into tabs, etc.

Let's be honest: not counting games, the vast majority of the native apps out there would work just fine (or better) as websites. Add API's like access to the camera and there's even less reasons to develop a native app. Apps will be relegated to games and highly sophisticated interfaces, which if I had to guess probably represents around 10% of all the apps out there (heck, most of the games out there could probably be done in the browser).




"app discoverability sucks ass"

Discoverability sucks ass. Period. Unless you already have a strong network, or lots of advertising dollars, the chances of anyone finding your software, of any kind, is low.

"apps require updates"

While that is true of some implementations, there is no reason why apps cannot be downloaded on each execution. You could even use a URL bar to show the network location of the app, if you want to.

"app development is unnecessarily tedious"

A modern web application is no better in this regard. In fact, most of the recent frameworks that have sprung up to solve the problem of building web apps all seem to be loosely based on the same ideas from OpenStep that are used in popular native frameworks.

"apps lack basic features of browsers - no universal find, no back/forward buttons, no bookmarking of pages or states, no organizing apps into tabs, etc."

I mentioned it in an earlier discussion, but it seems worth repeating: The web browser is just another platform API. There is no reason why, say, CocoaTouch could not include those things by default for all apps too.

The whole web vs. native discussion is pretty silly because it all comes down to a few specific implementations that we keep pointing to, when anyone can change the state at either end of the spectrum on a whim.


"A modern web application is no better in this regard"

Due to the web's open and standards-based nature, all you have to deal with is compatibility problems, which are resolved over time. I 'll take that over having to build for 6 different APIs, in 6 different languages in order to reach everyone's phones.


What are you talking about? PHP back end, HTML pages, CSS style sheets, Javascript to make it all run, and all this on a per browser type and version basis.


html css and javascripts are standards across the industry (despite minor differences per browser vendor). That is the huge advantage of the web. PHP is just one backend, which really could be replaced by anything else. Are you telling me native apps don't need server backends?


>despite minor differences per browser vendor

Minor? Keep in mind, it's not just per browser vendor. It's per version, per browser vendor. This is handled better today with the score of libraries you have to add in any web project but the problem is still there and will likely get worse before it gets better.

>That is the huge advantage of the web.

What? Objective-C is a standard. Cocoa is a known entity. So already I have one language and one API compared to three languages. If I include Android then I have two languages and two APIs vs three completely different and unrelated languages.

>PHP is just one backend, which really could be replaced by anything else.

Unless you replace it with JavaScript, that's yet another language I need to write and maintain. Not to mention, after all this effort I still can't consistently (if at all) provide an interface as nice as I can with an App.

> Are you telling me native apps don't need server backends?

Some do, not all. But of the ones that do, much of what you would need to do is just handled by the framework (e.g. storing data in the cloud, syncing, game serving and coordination, all handled by IOS SDK with no backend work on my part).


1) No, it actually gets better over time, and with jquery (which is still javascript) the problem is already solved. Still, you use the same language that you learnt 10 years ago

2) Learn a whole language and a whole api for one of the ~10 different mobile platforms vs 1 single language for every browser? That's a huge advantage. Seriously how much time you have to waste on learning different frameworks that do the same thing (display an app on a touch device)?

3) The backend problem is the same for both native and web apps; and PHP won't ever make your website snappier than an app because that's a browser problem.

"three completely different and unrelated languages."

What does that even mean? It's a stack of 3 complementary and orthogonal technologies that don't overlap. Don't you need to learn about layout and properties files when you do iOS development or android development or x development?

For me it all comes down to developer happiness, that is, achieve maximum effect in less time. That's why i m a webdev diehard and will never endeavor on proprietary closed frameworks.


>It's a stack of 3 complementary and orthogonal technologies that don't overlap.

Irrelevant. I need one language to describe the data, a completely different language to specify how to lay it out and a third completely different language to do any dynamic work (which is a lot these days). In e.g. iOS I can do all this with Objective-C.

>For me it all comes down to developer happiness, that is, achieve maximum effect in less time.

Agreed.

>That's why i m a webdev diehard and will never endeavor on proprietary closed frameworks.

That's why I'm not and hopefully will never have to be.


We are obviously in different camps. Yet, regarding the first point, it's not irrelevant. Can you layout apps in ios or android without learning about layout files, property files or what else?


Actually yes. I can't speak to Android but on iOS you can just drag the controls where you want them to be. Or you could just do it all in code. You don't have to learn anything but the language and the APIs if you don't want to.


"there is no reason why apps cannot be downloaded on each execution"

Not everyone has access to unlimited data plans or fast connections.


And yet we do this for websites. You hit up Gmail and your browser pulls down all the Javascript, CSS, HTML, and images that you need to "run the app". This is not fundamentally different from downloading a native app. The web content is granular so you don't have to download everything up front, and your browser caches to avoid fetching unchanged resources constantly, but these techniques could in theory be applied to native apps as well.


there is no reason why apps cannot be downloaded on each execution

It would make it much slower to open an application each time. After all, vast majority of applications don't do this, so there must be a reason why.


It wouldn't be such a bad idea if:

1) it only downloaded a new version of the app when it changed (easy with ETags);

2) apps were lightweight (hard on current mobile platforms).

If platform vendors and application developers cared, it would be easy to make most applications weigh a few hundred kilobytes. We could then do exactly like what Web apps such as Twitter do natively.


I don't see why it needs to be any worse than loading a web application. It is the media assets that make any application large, and they are going to be the same size no matter how you package your app.


With a webapp, you only download the images for the page that is being shown, not all the images for all the pages.


There were a small number of great CD-ROMs back then. The Voyager Company did as much as was possible given the crappy hardware that existed.

Anyhow, I could come up with an equally harsh assessment of web apps as you did of native apps:

* web app discoverability sucks (seriously how much money is spent on SEO?)

* web apps constantly change on you or disappear when the shop is bought out

* web app development can be a multilayered nightmare of browser bugs and code shims

* you pretty much need to sell your soul to a bank or Paypal to sell anything on the web (let's see how Stripe works out long term before we declare victory there)

* many apps lack basic features like site-wide search, working back/forwards buttons, working bookmarking due to bad Ajax use, incoherent and inconsistent UI, etc.

Now, I happen to like web app development better than native app development, but I'm not a big fan of triumphalism in any of its stripes. Heck, the vast majority of websites out there would work just fine (or better) as paper brochures or a rolodex.

The web will continue changing and evolving and the browser will only be one of many ways that it will be consumed. Native apps will be integrated with web services more and more over time.

Apple has done a spectacular job of monetizing small apps, Google is building a good infrastructure for ad-sponsored apps, I wouldn't discount their long term potential.


"I happen to like web app development better than native app development"

I find the distinction to pretty blurry, myself. If you look at Cappuccino, you could practically search and replace a few tokens and have your code natively compile in Cocoa.

As web applications become more complex, proper separation of concerns, like MVC, starts to become important. Once you do that, as seen with Cappuccino and echoed in many other frameworks like SproutCore Backbone to name a couple more, the process starts to very closely resemble native development.

We now have the web browser playing double duty. We want it to be a hyperlink document viewer and we want it to be a platform for applications. Personally, I would like to see the browser be only a platform for applications and let the hyperlink document viewer be one of the many applications you can run in the browser.


    seriously how much money is spent on SEO?
Smart companies and individuals don't spend much money on SEO, as most white-hat practices require long-term focus and black-hat practices can get you erased from the Internet. You can't do anything unless you're doing marketing, however marketing must be part of the product and can't be outsourced.

With that said, web apps go viral faster than anything else, that's because there's no barrier to entry. You don't have to be a member of the iPhone users club to try out links.

    web app development can be a multilayered 
    nightmare of browser bugs and code shims
Compared to multi-platform development for OS X, iOS, Android, Symbian, WinMo 6, WinMo 7, Windows 7, Windows 8, Blackberry, Samsung Bada, Linux ; it's heaven like.

    you pretty much need to sell your soul to a 
    bank or Paypal to sell anything on the web
Except Paypal or a bank are NOT in the same market as you are. They also don't control the platform you operate on. They couldn't suddenly one day decide that your product should be part of the OS, making their own alternative.

If you're getting screwed by Paypal, you're only losing some money. However, if you're getting screwed by Apple, you lose your product and business model.


    Compared to multi-platform development for OS X,
    iOS, Android, Symbian, WinMo 6, WinMo 7, Windows 7,
    Windows 8, Blackberry, Samsung Bada, Linux ; it's
    heaven like.
You make this sound much worse than it actually is. iOS is where the money is and Android is up and coming. All the others can be either ignored and served with a (funnily enough) web site.

Then there are libraries / frameworks that abstract all these platforms away or allow you to use a language that you're experienced in: MonoTouch, PhoneGap, Unity, etc.

Now, libraries don't fix all the problems and sometimes you will have to deal with the platform but they do take care of a whole lot.


As a long-term investment, it's a bad choice though. I still make money from web apps built in 2007, and there's a pretty good chance i 'll keep making it with incremental changes in the following years. I doubt i 'd say the same if i'd started with phone apps in the pre-iphone era.


>web apps go viral faster than anything else

Yea, free ones. I don't care as much about how many people are using the thing as I do how profitable it is.


37signals.com


As randomdata pointed out, I think this goes more to proving my point than yours. They did a lot of work to get to that point. Contrast that with "Tiny Wings" that showed up and started making a huge amount of money.

I'll grant you that it's more effort today than it was with an App, but an App platform provides an easier method of discovery [1], an easy method for billing and even an advertising platform. With the web this is all on you and the web is more ad focused so you're probably more likely to be competing with free.

[1] Random chance with the user entering the right google keywords vs doing a category search in the app store and knowing you can see everything in that category.


Not a good example. 37signals had a huge following long before Basecamp. Their success in web apps was largely from leveraging that existing fan base. Most developers do not have the luxury.


Users determine what is successful, not developers

- Web app discoverability is much worse

- Updates is a minor issue for users

- App development is not the user's concern

- App store approval is a net win for users. It eases their concerns about malware.

- Browser functions are not useful in most apps and the add an extra layer of abstraction

Native app can be made into just fine web apps but that is not always good enough. The best apps are still native.


Web app discoverability is much worse

This is especially one of the glaring holes with web apps in relation to their native counterparts. There just isn't a central destination for users to easily assess and access them. If web developers can come together and make this happen on a greater and more open scale than what the App Store, Chrome Store, or any other restricted app directory is currently offering, then the web has a chance at reengaging those native app users. Until then, the web is a jungle.


Updates are a major issue. Most web-spoilt users don't even understand why apps don't update themselves. Browser functions are useful in most apps, hence the 'back' buttons in the top bar of most iOS apps. People are used to the web nowadays and expect similar functionality from the rest of the software they use.

Discoverability is a big problem. The chrome web store is an example, it's interesting, but it's only built into chrome, and we had too many failed "Web directory" projects in the past anyway. There are other routes, like facebook viral apps, but these are also siloed.


The typical user doesn't care about updates. Most iPhones I see have 15+ uninstalled updates. The response to every Facebook update shows that that the typical user will resist change. Why would silent updates be critical to these kinds of people? I can about what version they are on as a developer but they don't care.

The back button is useful to some apps, some of the time. Why should you show it all the time and confuse users? Native back buttons also allow you to show context; you can display information about where the back button takes you.


Let's be honest: Native Apps can be reverse engineered, the Web/Cloud don't. And reverse engineering is an important right.

When web applications have only limited APIs, limited call rates, and changing everytime I can only think that I can turn on my Apple II and continue to use the same applications as 30 years ago.

Again, don't compare Google Spreadsheet with Microsoft Excel, look at the Microsoft balance sheet.

If you're interested I've written more rants about this on:

- The Data Portability Fact Sheet: http://blog.databigbang.com/the-data-portability-fact-sheet/

- Google Search NoAPI: http://blog.databigbang.com/google-search-no-api/


Most interesting apps on my iPhone spend most of their time talking to web APIs, so that's a bit of a moot point.

Plus, for the client-side of things view source is a lot easier than decompiling a binary.


Moot point? If the APIs change your applications turn unusable. Look at what Twitter did with third party UI applications.

You are only one case. Can you summarize all the application that you use everyday for work? are they native or web applications?


* Website discoverability sucks ass; at any rate you can advertise an app on your website and ge the best of both worlds

* Websites require connectivity

* Web development is unnecessarily tedious and requires coding in multiple half assed languages and targeting different browsers and platforms (and scale)

* Most websites don't make any money at all regardless of which rules you play by, but you're playing by google's unknowable rules at minimum

* Websites lack basic features of apps, such as offering complete control over the user experience (e.g. Not wasting screen real estate on web browser cruft)

* Let's be honest, including games every website could be implemented as an app.

I actually agree with your post in many ways, but all your points can be turned around without even being clever or disingenuous. I think some things (e.g. Magazines and most content apps) should be websites not apps. Other things should be apps. A few things should be both. Websites need to devise ways to work offline (which magazine apps do, but suck anyway).

Let's take a simple example: Ken Rockwell sells interactive camera manual apps for iOS devices. Could this be a web site? Sure, but not much use when you're hiking or caving or doing a shoot on a building site huh? Also much harder to monetize.


half of these are problems with iOS apps that android solves (eg back button, autoupdate, open publishing).

others are also problems on the web (eg discoverability and tedious development on x platforms).




Consider applying for YC's Spring batch! Applications are open till Feb 11.

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

Search: