Linking is one of the things that I think Android got right over iOS. Google -- web company that they are -- smartly realized that their mobile OS platform needed to borrow metaphors from the web and attempted to do this with their Intent/Activity architecture.
The challenge here is the execution -- it's Java-heavy and unwieldy compared to <a href=...>, but the basic structure is there and allows for interesting interleaving of Activities from one app into another. I haven't yet seen a lot of discussion or adoption of Open Intents, but I think it's an interesting approach. It does, again, seem to suffer from an inheritance of Java's heaviness, and that may be a fatal flaw.
Whether this approach succeeds in sustaining rich-client apps as web apps mature remains to be seen, but I do think it points to the fact that OP's criticism was a concern in the minds of Android's developers at the earliest stages.
While linking to other apps in Android is absolutely trivial and mostly painless (even considering it's java), the more tedious part is to implement the intent service itself. The "<a href=" example is the wrong one, since the call itself is practically a one-liner in java, whereas implementing the equivalent of a "Hello {{name}}, how are you since {{last-visit}}?" response would cause a hell of a lot more headache.
The API is solid though, the linking is done at a very low level, and to be honest when you get the hang of it, it's hard to let go of that awesome feature of the OS. I strongly support the use of RESTful IntentServices and ContentProviders, even if you don't open them to other apps, it's specifically the part that the Android OS got right. Opening them up for other apps to link to is a one-liner config change afterwards.
Agreed with most of your points except "mostly painless." Consider that an anchor tag is both presentation and event handler -- basically all necessary application logic -- in one line, and intuitively understood in its integration with URLs. The "one line" to start Intents in Android (usually at least two, and likely more, depending on how much other data you need to put in the Bundle or Extras or URL objects) is only the execution part, usually buried in the event handler which itself is attached to a View object which itself was defined in a layout.xml or some other visual declaration.
It isn't a fair comparison, linking from one app to another is (as far as I can think of) completely useless if the other app can't call back with data. That is adding a significant layer of necessary complexity that simply isn't possible to do at all with <a>.
Not sure I follow -- I was isolating the case of simply launching an external Activity, analogous to clicking a hyperlink to a separate webpage. Just adding data to an Intent (similar to the way you'd add arguments on URL params) can require several extra lines, plus, again the fact that you still haven't accounted for setting up the event handlers, the View object that responds to the click, etc.
I'm not knocking Android -- I'm an Android dev. The point I'm trying to make is that building out an ecosystem of interconnected links is hard. The web accomplished this by making the markup for those links very very simple. The total amount of code and setup for one Android application to launch another is far more complex than writing one anchor tag. This is at least a barrier to more widespread adoption of something like Open Intents, etc.
I didn't mean to imply that you thought Android web intents were poor, I just don't think that <a> is a relevant analog. My point is that the nature of links are not the same. There is no way for a website to pass data back to you and the links are completely static. Generally if the links have url params then they link is generated by some serverside template renderer and its disingenuous to compare just the output from that program to the source from another program.
XHR requests are much more of an analog to Intents than <a> links are, and they are a similar order of complexity.
90% of my use cases when I launch an external Activity (email, maps, sharing, etc.) I don't get data back, so I guess from my POV anchors are good analogies.
And how is Ajax not precisely an example of a website passing data back? It's all just servers responding with json or xml or html, whether it's a GET from an anchor tag or data from an Ajax call. I just don't make that distinction -- it's all HTTP to me.
My point was that Ajax (XHR) is pretty much the same thing as launching an Intent, and it is pretty much as complicated as launching an Intent.
I would hesitate to say that Ajax and Intents are precisely the same since with Intents app gets paused and waits, with Ajax the user will often expect the website to still be functional while the Ajax call is still working. If you click the up arrow on a comment you wouldn't expect the Reply button to not work until the Ajax request has called back.
That said, I never meant to indicate that there was a big difference between an XHR request and launching an intent; I was merely trying to point out that an <a> tag is notably different in functionality than both a ajax request or an intent launch.
Not useless, certainly. It's routine for an app to fire up a web page or document viewer. Or if you're an app with some form of content generation you can hook the "share" intents to push to facebook/google+/etc... without the need for feedback.
Obviously feedback is an important feature, but one-way links are very useful low hanging fruit.
Besides, you can put html code in textviews, webviews and their ilk, make the links clickable and the app will silently create the corresponding intents.
The only aspects I can think of right now that are lost in the translation are webpage roots and local # anchors. There might be a lot more, though.
Yes, it means it spread through social contact such as word of mouth, and people mentioning it on social networks, or just seeing others use the product and becoming interested.
How does iOS handle multiple apps registering for the same type of URL? In Android, I get a popup asking which app I want to use for this action, and an option to make that the default for future actions. Is there something similar on iOS?
You get a popup asking which app to use. I don't think there is a "save as default" because that would necessitate a way to manage those defaults, which would expose the underlying mechanism to users, something Apple is generally averse to doing.
The reality is that it doesn't get used a whole lot. Browsers, Dropbox, and other apps of that nature tend to provide the data while miscellaneous apps consume it.
Sure, you can open other apps and target applications with different link types, but you can't interleave functionality with nearly as much ease as in Android.
Any time you click a web link from an email, or a YouTube link from Safari you see this: the current app is backgrounded and there's no simple way for the two workflows to interact. This is a major difference between the two OS's and one advantage for Android, imo.
Also possible on Android is for apps to register themselves as link targets for certain domains. For example http://www.github.com addresses can optionally open in the github app.
You can specify your app as a receiver for as many authorities as you'd like, by the way, or even register your own schema. You can also declare your app as a content provider, which means that your app/service becomes a data source, just as the contact list, or the photo repository, and make that data available to others, defining your own private permissions, etc.
My app FairyPreview for instance (https://market.android.com/details?id=com.fairyteller.linkpr...), is registered as an authority for the myriad link minimizers out there, so whenever you click on a minimized link in the Twitter app or anywhere apart from a browser, it will suggest my app for a faster preview instead of taking hours to load a webpage designed for a desktop browser hiding behind an unknown bit.ly link, itself disguised as a t.co, for example.
It's not perfect and it's very old, the code is from 2009, my very first attempt at playing with the cross-app link system, but it works pretty well still. I'm strongly thinking about opening the source code, since I don't make any money out of it (free, no ad, maybe 50 downloads :P), and there's plenty of improvements I'd love to do but don't have the time these days.
I never tested this in particular, but since it uses HttpURLConnection, the following of redirections is done under the hood - I guess it would be the same limit as the default browser?
I'm definitely glad you like it, it means I'm not the only one ;)
I'll see what I can do about the share button & opening the source. There's definitely tons of improvements to be made.
We keep having the same debates over and over. We've seen this before on the desktop. It started with apps that had to be written for both Windows and Mac. Then the web came along and, as bandwidth increased, many apps were able to be run as web apps, simplifying code maintenance and giving developers the ability to easily target multiple platforms. Apps that benefit from linking work better as web apps. Some types of apps, however, run better as native apps: things like games and Photoshop. So we ended up with both.
Mobile will follow the same track: we'll end up with both.
The reason why this conversation is coming up again is that so many applications that are web applications on the desktop are more commonly accessed as native apps on mobile. For example, on iOS I use a native client for IMDB, my bank, Mint, Wikipedia, and so on. But on the desktop I use web sites for these services. There has been a shift back to native on mobile.
I agree that we'll end up with both but perhaps more importantly is that the difference between web and mobile will blur together even more.
I think the real reason that you see apps on mobile devices is that an app puts an easy to use branded icon on the "desktop" instead of requiring the user to open a browser and navigate to the site. I don't think it has anything to do with lack of access to capabilities (e.g. Mint doesn't need access to my camera).
Try this thought experiment: What do you think would be the reaction from users and developers if Apple simply renamed Safari's "Add link to home screen" option to "Install App"?
I never said anything about "lack of access to capabilities". Native applications, in the vast majority of cases, are just better in every way than the similar web versions. They're faster, cleaner, and more capable. If both are being offered, it makes no sense to choose the web version.
My company makes an iOS-compatible web application with no plans for a native client right now. We use some JavaScript[1] to remind users to add us to their homescreen. But if we had the resources, we would build a native client -- it's a no brainer.
This 'issue' only matters to developers. My mom or sister or any other non-developer would never make any of these claims. For them, it's all on the Internet. A web page is a web page and an app is an app. The thing that matters most is the connection to do something.
There's room for both and I get so tired hearing these pointless arguments..
I believe native and browser-based apps can and will coexist.
As a web developer, I've had my share of frustrations with the browser and I certainly would welcome a more flexible and feature rich alternative for some use cases.
To give an example, I can see native development overturn browser dominance in the manufacturing of Content Management Systems. For years these apps have been tied to browser technology and their usability and features have been limited because of it. Sure it makes them easy to deploy (all you need is a browser), but in exchange you get crappy wysiwygs, lack of remote access (ftp, ssh), image editing that sucks and a string of other annoyances that we've simply learn to accept out of convention.
But when you think of it, there's no reason it should be like this. Organizations typically only have a handful of people that require access to the admin panel. You could simply have them install a native client that communicates with the server via http, exactly like the browser does, but offers a much more elaborate API. The added bonus would be the possibility to easily delegate various other tasks to other tools (Unix style).
Other normal web users (consumers) can continue to access the frontend (as opposed to the admin panel) via browsers.
I'm not sure I agree. Since I discovered Google Apps, I forgot about Microsoft Office.
Google Docs is always there. It may be a crappy experience on my Android, but I have access to content I wouldn't otherwise. Collaborative editing and sharing is really easy too - I don't have to ask other people to buy iPhones / iPads / Androids to get them up to task. They only have to have an email on which I send an invite. And sure you can make a better native app and I would appreciate one on my Android, however I remember how this one time I forgot my phone and borrowed the iPhone of a friend to access a really important document.
On the whole, web apps are more accessible. Native apps are a nice bonus to this experience, however if the core is not web-based, then it loses a lot of value.
"""On the whole, web apps are more accessible. Native apps are a nice bonus to this experience, however if the core is not web-based, then it loses a lot of value."""
Well, that can be easily solved with native apps that also have a web counterpart, for desperate times (i.e in the middle of Tahiti without your laptop/mobile phone/tablet).
Webapps need to better handle offline usage and poor network conditions. Until then, apps still have a huge leg up on mobile devices.
Mobile devices are battery constrained. Radios to provide data feeds are a big factor in battery drain. Interpreted languages increase battery drain. And network coverage is far from universal, to say nothing of download caps and cell network performance concerns.
Apps are preferred today because they're more responsive, they drain less power and they're generally usable offline and in dodgy network conditions. The web has many advantages over native applications, but until it gets better for mobile users, users are not going to get past the more-immediate shortcomings to care much about those advantages.
And given that we seem to have reached a point where potential battery life past 1 day of solid use is traded off for greater performance during operation, I don't see the battery/network situation changing much any time soon.
By the same argument, though, apps will be obsoleted as soon as the next battery technology arrives, because, let's face it, installing apps, updating and uninstalling is a ghost long dead. As soon as Apis to access camera, microphone etc come to the browser, who would choose to program native?
> installing apps, updating and uninstalling is a ghost long dead.
So, when not installing native apps (which takes time) we add - in the case of e.g. the iphone - webapps (links) to our home screens. Which is faster than installing a native app. After that we 'endure' a longer loading time every time we start the app. And we still have to remove the icon from our home screen when we're done with it.
Mind you, I see the advantages of web apps; but this does not seem like any different from the native app use case; it seems a bit worse to me actually.
> who would choose to program native
Performance junkies? graphically intensive app-developers (games?). Sure, we may have an 'opengl'-component to use in our webapps; but why the extra overhead?
Web app icons don't make sense as you 'd soon end up with thousands of them. I imagine future phones will just have a voice-recognition-enabled search box instead of icon grids.
The same could be said about native apps. There are more than enough apps in the various app stores to fill numerous 'springboard screens'. On the other side we only use a small set of apps. Why would habits change when switching from native to web-based when the experience is the same?
Long caching headers can keep your javascript heavy web-app from being downloaded every time - the first time you hit the url it "installs" (by caching the files) and after that it loads in about the same time as a native app.
To add a splash screen during loading, create a 320x460 .png file, and then link to it in the header:
<link rel="apple-touch-startup-image" href="./startup.png" />
It's good to know; but the only thing I found (note: it was a quick google session) that comes close to this for Android is when using PhoneGap to build a 'native app'.
There will still likely be carrier restrictions on bandwidth, and general connectivity issues. Open wifi is far from ubiquitous and many carriers still have poor coverage (AT&T has no usable signal in many parts of my house), not to mention situations like wanting to play a game or use an app while on an airplane.
Some kind of hybrid model may evolve instead. You install an "app" that is little more than a data cache and a skin/UI for the phones browser. In a connected scenario you are using the app in "web app" mode. In a situation when it can't connect, there is enough intelligence to rely on a local data store or something. It doesn't cover all scenarios, but might bridge the gap a little better.
Aside from highly specialized tasks, or those leveraging media/interfaces that web apps don't yet have access to, I'd imagine that's quite possible; not unlike the situation on the desktop today.
I'm just not optimistic about that "next battery technology" arriving any time soon.
There are other ways to spend extra battery power.
If there weren't, 30+ years of Moore's law on the desktop (20 doublings, so let's say a speedup of about 1,000,000) would likely have led to desktop programs written in some scripting language.
There are advantages and disadvantages to both - web apps are available anywhere you can find an Internet connection and browsers connected to the Internet are in practice more readily available than your device filled with native apps.
I don't know about you, but the same phone travels in my pocket, so those apps are available to me 99% of the time. The available everywhere advantage of the webapp was a big deal because computers were heavy, and that's been diminished.
That said, some sort of standard interoperability between phone and laptop/desktop apps would be nice, and iCloud APIs seem to be a stab at that, but it's probably a pipe dream to hope that that will become universal. So maybe you're right.
You can certainly read emails on it, however if you want to write emails that are longer than a couple of words, nothing beats the 100 WPM a real keyboard gives you. And most things you do in your daily work are not feasible on a phone.
And sure, my laptop always accompanies me, however there are always emergencies and on my laptop I prefer web interfaces anyway. I haven't used email clients on my laptop ever since I discovered GMail.
it's also a lot easier for developers to make money from native apps (free distribution, no infrastructure needed) vs. web applications (requires a lot of traffic, infrastructure, servers, bandwidth, system administration, etc.).
I agree with the sentiment of the op, however, I dont think you can ignore the fact that so many people are willing to spend a dollar or two on an app whereas paying for access to a web site seems relatively rare (outside of the business world).
Nice. So that pretty much guarantees that only those SAAS apps that are operated by the largest corporations, and that harvest your personal data most efficiently, are the ones that dominate. Everything else is only that much more likely to disappear in an instant, taking with it not only all your documents, but the app's functionality itself as well. I really don't know what people like you are smoking.
I only smoke weed. But yes, outside of fairly niche markets, the largest corporations are dominating (Amazon AWS, Google Docs). It IS a lot more likely that any of these alternatives (http://www.makeuseof.com/tag/5-great-alternatives-to-google-...) will disappear with all your data than that Google Docs will. I'm not saying it's some awesome thing that big businesses can out price the little guys and I'm not saying that the profitable SAAS does not exist (Harvest, Github (most of Github's users don't pay a dime)). The simple reality is that most people get a fair amount of utility from free web services.
http://www.pinboard.in/ The price has now risen above that level because it is successful, but it started lower. I think it qualifies for your request because the higher price in this case just demonstrates that the model has worked in this case.
(Pinboard's sign up price rises with the number of users)
My opinion is that the whole discussion on this topic is totally worthless and it's even starting to get annoying: all we see is articles saying “apps are dead, we should build on the web” and nobody doing it.
Even Google's – which should be on the front line championing the web – mobile web apps are crap. The best mobile web app, the only one that actually made me want to use that instead of an app because it worked very well and not out of principle was Twitter, until last week, then they broke scrolling like everyone else and now I hate it. Runner up is Facebook.
Why don't we see more people actually making mobile web apps instead of just writing articles about how other people should make them?
"Visualize each of the apps they want you to use on your iPad or iPhone as a silo. A tall vertical building. It might feel very large on the inside, but nothing goes in or out that isn't well-controlled by the people who created the app. That sucks!
The great thing about the web is linking."
I'm not convinced. I see the "app" response to "linking" as being something like Windows 8 contracts. In fact, I wouldn't be surprised if iOS and Android have something similar to contracts in the next 2-3 years. At least I would hope so!
I think that there are applications that make more sense to implement as a traditional app, and that there are applications that make more sense to implement as a web app. I don't see this changing anytime soon. I really don't.
Agreed. Being able to pin specific app pages or features [edit]on WP7[/edit] is another example of apps moving towards a linkable page paradigm. Both have merits, and both have scenarios in which they're more suited to their particular environment.
Case in point being anything that requires encryption. I've seen .js implementations, but the web adds so many other threats not faced by apps that could completely undermine its use (depends entirely on the ability of the developer).
You got me. Microsoft totally copied this. Nevermind their history, stretching back 20+ years, of providing support for integrating one application with another. DDE? OLE? COM automation? Yeah, none of those things could possibly be considered precursors to something like contracts.
But no. Microsoft totally ripped off Android here. eye-roll
As a web developer, I think it is dying, but not in the way you immediately think.
Modern websites are starting to resemble full-fledged applications. Built using entire MVC frameworks atop the Javascript runtime that abstract the underlying primitives, just like their native brethren. Today, from a programmer's standpoint, there is little difference between building a native and web application.
Every new browser iteration just brings tighter integration into the underlying system. There are no real web-specific technologies being introduced. We are reaching the point where the web serves little purpose other than a clumsy virtual machine. The natural progression will be to go full on virtual machine, like Java attempted to do many years ago, where HTML/CSS/etc is just another application on that virtual machine.
The idea of pointing a browser to an address to open an application will stick around, but I think the web parts, a program that renders interlinking hypertext documents, is dying – though certainly not dead yet.
In the meantime Wikipedia is still the most useful product of the Internet and the biggest database of human knowledge. It's only surpassed in traffic by Google, Facebook, Youtube and Yahoo.
the web serves little purpose other than a
clumsy virtual machine
That clumsy virtual machine can bring you Facebook.com on every mobile phone, regardless of the platform. And if good native apps are now available for Facebook, well, we are talking about Facebook.
"""In the meantime Wikipedia is still the most useful product of the Internet"""
You missed the point.
There's nothing Wikipedia does that cannot be done in an native-gui mobile App.
It's just a list of articles, a way to search for them, and a system to edit them. Nothing web particular about Wikipedia, one can imagine a Wikipedia app for mobile and desktop OSs that achieves the exact same thing.
There is something Wikipedia does that is not usually done in a native-gui app, and that is provide destinations for hyperlinks. Part of its utility is that you can link to it from blog posts, from essays, from all sorts of stuff.
Which is the point of the OP. he’s comparing micro-walled-gardens to linkable web sites. If we are talking about a native-gui app or rich internet app that supports linking, you may have something.
Then again, you may not. It is incredibly annoying to me whenever I try to access an IMDB link on my tablet and it asks me to install its native app. I now no longer to go imdb links because I’m tired of the speed bump.
This is the web's biggest advantage, it is frictionless. You "install" Wikipedia the same way you use it, by typing its URL. I dont think native binaries can ever match that.
Only, I don't use Wikipedia "by typing it's URL". I just visit it that way. I use it by entering a query in the search box.
But with things like the App Store, or even apt-get and the like, native binaries can very much match that friction-less "installation".
One major benefit that the web has is that:
1) you don't mess with your system (when using a web app)
2) you get automatic updates (when the server code updates)
well, with the sandbox/app store model that mobile and native apps are going, the same can also hold true to them.
Is there a single point of the web that cannot be replicated in native-land? I'll take Apple's App Store as an example, but you can substitute things like the Android store, apt-get, whatever:
Easy discovery: App Store search, plus curation (same as web).
Easy, no mess, installation: see App Store / iPhone App Store.
Automatic updates: App Store updates
Use web technologies: no problem, just add a webkit view in the app.
Performance: better for native.
Integration: better for native.
Look and Feel: better for native.
Ubiquiteness: you can have the same app in your laptop / phone / tablet Plus a web interface as a last resort (for example: Evernote).
When laptops / smartphones / tablets were rarer, being able to access, say, your web mail, from anywhere with a connection without installing anything, made for a good proposition. Now, though? I, for one, only use the web Dropbox / Evernote / Gmail / Twitter interfaces as a last resort.
native binaries can very much match that
friction-less "installation".
That will never happen because of the various differences between clients. This is the magic of the browser - people bitch about cross-browser incompatibilities, however because of the browser's simplicity it gets as close to "frictionless" as possible.
And you won't replicate that unless you invent something that's for all practical purposes still a browser.
(you mentioned deb, try upgrading an Ubuntu box sometimes)
Is there a single point of the web that cannot
be replicated in native-land?
This is the wrong question to ask. You're not seeing the forest from the trees.
The web is great because of its extreme simplicity. Trying to replicate that would get you yet another browser-like technology, that's broken in new ways nonetheless, or it will make you deal with even greater complexity - I don't know about you but it was extremely painful for me to even get a Hello World installed on my own iPhone.
Either way, talking about "replication" is missing the point.
One major benefit that the web has is that
The benefit you mention isn't even the main benefit of the web. The main benefit is that the web is available everywhere for everybody, with no discrimination.
When you send a link to a friend, you don't ask him whether he has access to your App Store or not. The web's availability is implied (after all, that's probably how your friend received the link in the first place).
Ubiquiteness: you can have the same app in
your laptop / phone / tablet
Seriously? Ever attempted developing for iOS, Android, Symbian, WinMo 6, WinMo 7, Samsung Bada, Blackberry, OS X, Windows, Linux?
I for one have stopped using anything but the web GMail interface on any device that's not a mobile phone, because it's that good.
"""That will never happen because of the various differences between clients."""
That has happened already. I can install, say, Evernote on my Desktop Mac and my iOS phone with a few clicks (as fast as typing: evernote [ENTER] on the location bar of a browser).
"""The web is great because of its extreme simplicity. Trying to replicate that would get you yet another browser-like technology, that's broken in new ways nonetheless, or it will make you deal with even greater complexity - I don't know about you but it was extremely painful for me to even get a Hello World installed on my own iPhone."""
Hundreds of millions of people don't seem to have problem downloading and using around a billion apps on their iPhones. Same for Android from what I hear.
(And who said anything about developing for the platform? The "Hello world" thing you had trouble with is not about installing/using a ready made app from the store).
"""The benefit you mention isn't even the main benefit of the web. The main benefit is that the web is available everywhere for everybody, with no discrimination."""
Yeah. In a future where most people carry mobile devices/tablets etc, that could well change, in the same way where now you can't take Gopher access for granted like you once could among internet users.
"""When you send a link to a friend, you don't ask him whether he has access to your App Store or not. The web's availability is implied (after all, that's probably how your friend received the link in the first place)."""
Yeah. But I don't go to most web apps because of links send by friends. Why would I be expected to install apps because of links send by friends?
You know something else that is also ubiquitous besides Google Docs? A program able to read .doc files. Almost all computers have one installed --and that's of a desktop proprietary format, a rather expensive program, and pre-app store convenience for native apps and sandboxed models. Actually MORE people have Office installed than have ever used Google Docs. Imagine how easier it will be in the future, with application repositories and on demand native app installation.
"""Seriously? Ever attempted developing for iOS, Android, Symbian, WinMo 6, WinMo 7, Samsung Bada, Blackberry, OS X, Windows, Linux?"""
You said about developing? I said you can HAVE the same app. Somebody else will have to go to the pain of developing. Have you tried developing your own Google Docs? It's just as difficult.
Also, most of those platforms don't matter, only iOS, Android, Windows and OS X do, market wise. Consider a future where native app repositories cover those with ease and ample apps (some of the platforms are already covered).
You really think that browser apps will win because they also cater for Linux, Symbian and Bada?
> Only, I don't use Wikipedia "by typing it's URL". I just visit it that way. I use it by entering a query in the search box.
But with things like the App Store, or even apt-get and the like, native binaries can very much match that friction-less "installation".
Explain how? I just tested it, and Hacker News loads in a browser (not cached) in about a second. Please explain to me how a native app can be installed and launched that quickly (including the time to find the app in the app store, etc).
But surely the success and therefore usefulness of Wikipedia is down to the fact that it's available to everyone with a web browser? Apps are only ever going to have a tiny proportion of the target market, compared to the number of general web users out there.
That's what this is about. Of course you can do the same functionality that's made Wikipedia work in an app, but I don't think you'd ever get the numbers needed to make it useful.
In the model I was referring to, the browser doesn't go away. Only the built-in web does. Replaced by a more general virtual machine with reasonably low level access to the underlying system. We are, more and more, treating the web this way anyway. It is becoming a pointless abstraction.
There is no particular reason for HTML, CSS, etc. to be built-in components, but that does not mean the web has to go away completely. If your network location wants to load an HTML document, you can command the browser to fetch an HTML renderer over the network. But you can just as easily serve an application of another kind, depending on your desires and needs.
Normal people never cared about web browsers, but that didn't stop web browsers from spreading like a virus. Most of them don't even understand the concept. If you ask them what a browser is, they'll probably answer Google.
As an example, I love my e-Ink Kindle. The one big annoyance I have is that the browser on it is so awful that it is unusable. And it bothers me because book authors are often placing links to external references in the books I read.
And I just want to read those references. Maybe add a comment or two if it's a blog. Since I'm there anyway, maybe I want to recommend the book on Facebook or Twitter with, you guessed it, a link. Maybe I want to search on the web for other discussions on the topic. And so on and so forth.
It's not about love for the web browser per se. The browser is an awful virtual machine. Also the HTTP protocol is one of the featureless protocols in existence. The development model is scary sometimes as you've got to learn dozens of technologies, each specialized for a certain task, each broken in its own special way.
But developers bitching about this are missing the point. It turns out that the openness of the web is disruptive and simple form elements communicating over a simple protocol is all you ever need for 80% of the use-cases.
Quite the contrary, I'm seeing the web stronger than ever before. The one big problem I'm seeing however are walled gardens. Some day from now we'll look back and actually see what a big mistake this was. But the web as we know it will still be there. Because nothing can really replace it.
> Modern websites are starting to resemble full-fledged applications.
So more of the code is going to the VM on the client... this pendulum swings back and forth.
What about efforts like Amazon Silk and Opera mini that encapsulate all the client logic in the cloud? Sure they may suck now, but in the future they may be more mature and standardized... thus the pendulum could swing back.
I'm an app developer and I certainly don't think the web is dead. But I don't think apps are going to go away either. Both have their own use cases. And I think one of the biggest advantages of apps for developers has nothing to do with technology. It is the ecosystem. It is A LOT easier to make money with an app, sold through an app store, than it is to make money from a website. Especially on a mobile device where users don't want to type in lots of credit card information every time they visit a new website.
On Windows there was perfect integration between apps after Microsoft added linking and embedding using COM/OLE. 2D/3D hardware acceleration was standard. Linux as a competing OS implemented most of this also. Then came the web, and after years of standardization we now have hardware accelerated 2D & 3D, near-native performance (albeit using a completely new toolchain) and most of the standard desktop things. We have gained platform independence and ubiquity. Now we have to reinvent everything on mobile devices.... Granted, most of it is already there. But I sure would love to see most new mobile apps implemented in HTML5, to make them work cross device as much as possible.
"I wouldn't call COM/OLE "perfect integration between apps" at all."
Oh come on, it was so simple! All you had to do was set up a ProgID and/or a GUID in the registry (no! not HKEY_LOCAL_MACHINE, silly!, HKEY_USER! Oh wait, you're right, it is HKLM...) and then implement IUnknown in your app and the register the interface when you installed your app...hopefully with Windows Installer, which makes all of this a simple 15-step process. There's only like, 25 different registry keys to keep track of and 12 layers of interfaces to implement.
I think we've lost focus here. Web pages as apps are silly, but there are just things you can't do from a web page on a mobile phone, like interface with the camera, GPS, compass, local caching, etc... That's where apps come in (or should).
The only reason you can't do that from the web is because nobody's build the APIs yet. You can certainly do it from the web once they are available, and they are about to be:
These are all excellent points. I'm sure we'll get there, but there's going to be major differences in browser compatibility for a long time (3+ years, I think).
I've been using PhoneGap for a while now. It'd be really cool if similar API's were available without the native wrapper.
BTW, the browser caching link is helpful, but I experienced some limitations with what's currently available...
http://zikkir.net/tech/102558
- 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).
Linking is really the only feature I care about in the web. And it's not a negligible one. I'm tired of all the Flash animations, the AJAX updates or other fade-ins and shiny effects. It looks pretty, but I'm not connecting to a website to watch a fashion show, I'm really here for the content.
I wish we could go back to a more "HTML-only" oriented web. You still find some of those (usually with old Unix hackers or computer scientist) and they're amazingly enjoyable to read. Also, parsing them and running grep/sed/awk/... is a breeze. Am I crazy to ask for data I can manipulate easily?
That's what I thought of. The model of Intents is also a lot more powerful than simple web links, but Web Intents[0] are already on their way to fix that.
I think one potential answer to this is the ability for mobile/tablet apps to embed a browser inside the app. So you see this already with the twitter app on the ipad, when you click a link, it opens a browser in-app. The app makers don't reaaaally want you to leave, so the in-app browser is a nice compromise for them. And as a user, I like it. I don't necessarily need/want to leave the twitter app on my ipad. I just want to read the linked content real quick and jump back to the app. Works for me :)
Unfortunately, the browser experience can vary drastically depending on the app linking out. Plenty just dont at all. You see a link, but clicking doesn't do much but let you copy the text, if you're lucky to even have that. It's frustrating and makes me tend to avoid links in most all apps.
Take Flipboard, and otherwise beautiful app that is the gold standard for future blockbuster apps; when you decide to open a link to a full article you will get stuck inside an awkward hardy-useful piece of Safari. Even if you click out, you efffectively lose your place in the flow of what you were browsing. This is an example of bad integration from the browser. Don't even get me started on the apps that come with built-in browsers that feel like a toynrather than a tool.
I want to read the linked content not necessarily real quick and return back, and trust that the experience will be as good as a native app. In a perfect world all Apps would be web apps.
Regardless whether the author is right or wrong, "I don't care" is not a valid way to dismiss a counterargument. It's an effective way to resolve cognitive dissonance however.
Another thing I recently realized: if the trend is to store everything in the cloud. How long until we also store apps in the cloud? Oops, they are now web sites...
Deep linking is perfectly possible in apps. The !# hasbang is ugly, yes, but the HTML5 History API corrects this with the ability to pushState, replaceState and popState without necessarily having to deal with hashes.
Moreover, this style of linking matters most with publicly available data. For private data, such as the stuff I'm working on storing in the browser with IndexedDB, having a public link isn't necessary for data that's not publicly available. I of course want to support browser history/links in full (see http://warpspire.com/experiments/history-api/ for an example of what's possible) but my point is that when apps are personalized there is not always a need for a link that can be shared across the web.
If I wanted to prognosticate about our web-based future I'd look beyond vanilla hyperlinking and at Web Intents instead.
Apps are shaping into Native, Hybrid, and HTML5. Native will always own a) 3D & graphics, and b) frequent users. HTML5 is in the immediate future shaping to be a 'try before you download' the app. It will be dominant in one time use (web) apps. I am working on an HTML5 marketplace- PM me if you're curious
A friend brought up a good point the other day that the popularity of the iOS app store has actually pushed back on advances in web technologies on mobile devices. Because the sanctioned way to sell applications must go through Apple, less attention overall has been spent building mobile webapps. Also, since the hardware is also out of developer's control, there hasn't been a push to make native hardware available to the javascript.
Even with that, I do think that we're on the cusp of a big webapp revolution (again). With all these emerging JS frameworks (backbone, ember, derby, knockout, etc), and the modern and capable webkit powering so many mobile devices, developers will take note.
You know the people who make phone software are actually aware of this?
In Android, the concept of Activity and Intent serves to essentially promote this. Its not a solved problem by far, but work HAS been done in that direction. Rest assured, this work is only going to speed up from here.
After all, smartphones and tablets are marketed as consumption devices. The manufacturers would be hugely remiss if they didn't learn anything from the internet. And as we know, Steve Jobs and his industry descendants are anything but remiss.
This is not to say the OP are wrong. Web doesn't compete with apps, it supports them. The two are complementary paradigms, not competing.
It is easy for me to imagine a world that moves from the messy chaos of the web to the clean, self-contained, predictability of the app, and linking would be a mere ancillary concern.
Apps are the path of least resistance for the consumer.
Has it ever occurred to you that the next generation technology might harness the advantages of both apps and the web?
That's the way innovation occurs. Incremental improvements. Referring back to past implementations. Standing on the shoulders of giants. Learning from both the good and the bad of technology.
When people bring up the debate of Apps vs. Web, it's equivalent to saying "Facebook vs. Google+ - which one will people use in the future? You either get the Facebook like button or Google circles. One or the other, but not both."
Apps allow content provides to hide their data and only share it in a highly controlled environment. It's very unweb like, but appears that controlling a scare resource is profitable.
Yep, completely agree with the article. For me an important difference between the 'web' and 'apps' is that generally speaking nobody builds mobile apps out of generosity or egalitarianism, ie to give something to the world for free - mobile app developers are in it for the money.
However, the openness and non-proprietary nature of the web seems to encourage people to be generous and share content and services.
How many open source mobile apps are there compared to really great open source web/pc software?
>It pleases the money folk to think [...] That users are happy to live in a highly regulated, Disneyfied app space, without all that messy freedom.
Sadly I think those folks are right. Shiny things do appeal to average people above freedom, flexibility etc. Given enough people with both money and an interest in shiny things, apps will rule supreme.
Linking is nice but the real killer feature is that installing, updating, and opening a website happen at the same time. Apple, Google, and Microsoft can build their own linking mechanism, but I have to preinstall the app before the link will work.
Fixing that is not too hard. If you look at Mac OS X Lion, for instance, part of that already is in place (in a different domain). If you download a .xyz file and double-click it, the Finder will suggest looking for applications that can open .xyz files.
I think a logical extension would be that the system would automatically download free viewer apps instead. Add a seamless way to upgrade to the editor app, and you are all set (tangentially related: I think a thing like OpenDoc using that infrastructure could succeed in today's market)
Could they download and install these viewer apps in a fraction of a second or two, because thats what a browser does. The web works on the basis of progressive enhancement so all the browser needs to fetch is one Html file which it can display to the user while it downloads all other resources. I don't see a native code matching that.
"all the browser needs to fetch is one Html file which it can display to the user while it downloads all other resources."
If only. There are pages where that is possible, but typically, at the very least, browsers need to download some css, too (for example, google.com, on my system, does 9 http requests of which one fails). Even with inline css, a browser can discover, halfway through a file, that some css moves a div up top, floats it, etc.
Add to that 'not everybody' specifies image dimensions in the HTML and that Javascript that runs on page load may do DOM updates, and you get a much more complex model. Deciding when to start rendering a page is somewhat of a black art. If you wait until you are sure you have all information you need, the browser will appear slow; if you do not, you will have to restart page layout sometimes.
"in a fraction of a second or two"
Pages that load at that speed are rare. Again taking google.com as example, it loads almost 200kB here (most of it from cache, but that would not be much different in what I envision). When running from cache, rendering that simple page takes about half a second, I guess (FireBug reports 700ms and up, but it will have some overhead)
He means iOS apps, not desktop apps, right?
Desktop apps aren't "silos". The PC/Mac is a personal systems-integration device with mechanisms like pasteboards to transfer data between apps. Unfortunately iOS (so far) has very little of this.
I think apps are here to stay, but just like in the Chrome browser they might be simply links to a web-app. So the title should read "Why native apps are not the future".
that's all well and good. the key is that you can sell an app easily given a unified interface. that beats everything that is being done on the web, hands down.
We have to understand that apps make money and that this is why people will have people write more apps, which will fuel the economy and (us) entrepreneurs. That someone will switch off the web at some point is somewhat unlikely and when the time comes, probably secondary.
The challenge here is the execution -- it's Java-heavy and unwieldy compared to <a href=...>, but the basic structure is there and allows for interesting interleaving of Activities from one app into another. I haven't yet seen a lot of discussion or adoption of Open Intents, but I think it's an interesting approach. It does, again, seem to suffer from an inheritance of Java's heaviness, and that may be a fatal flaw.
http://www.openintents.org/en/intentstable
Whether this approach succeeds in sustaining rich-client apps as web apps mature remains to be seen, but I do think it points to the fact that OP's criticism was a concern in the minds of Android's developers at the earliest stages.