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?
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.
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.
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.
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.