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.
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.
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.
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.
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..
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?
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.
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).
"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).
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.
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 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.
[+] [-] davesims|14 years ago|reply
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.
[+] [-] babebridou|14 years ago|reply
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.
[+] [-] dredmorbius|14 years ago|reply
Linking also lets me take whatever content an app is displaying, isolate the URL, and share that externally from the app.
Current apps are link roach motels: your links check in (o hai 4sqr), but they never check out.
[+] [-] zuppy|14 years ago|reply
More: http://wiki.akosma.com/IPhone_URL_Schemes#Registering_your_o...
[+] [-] themanr|14 years ago|reply
[+] [-] mekoka|14 years ago|reply
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.
This is a future I can definitely embrace.
[+] [-] bad_user|14 years ago|reply
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.
[+] [-] clintavo|14 years ago|reply
Mobile will follow the same track: we'll end up with both.
[+] [-] wvenable|14 years ago|reply
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.
[+] [-] equalarrow|14 years ago|reply
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..
[+] [-] roc|14 years ago|reply
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.
[+] [-] zerostar07|14 years ago|reply
[+] [-] bad_user|14 years ago|reply
[+] [-] MatthewPhillips|14 years ago|reply
[+] [-] beatle|14 years ago|reply
[+] [-] dwiel|14 years ago|reply
[+] [-] toyg|14 years ago|reply
Many SAAS companies charge the same as an app, but per month, so you can't really compare it with a one-off payment.
[+] [-] unknown|14 years ago|reply
[deleted]
[+] [-] king_magic|14 years ago|reply
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.
[+] [-] AndrewDucker|14 years ago|reply
[+] [-] Spearchucker|14 years ago|reply
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).
[+] [-] unknown|14 years ago|reply
[deleted]
[+] [-] jgroome|14 years ago|reply
[+] [-] randomdata|14 years ago|reply
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.
[+] [-] k-mcgrady|14 years ago|reply
[+] [-] mrich|14 years ago|reply
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.
[+] [-] dextorious|14 years ago|reply
And no, "2D/3D hardware acceleration" was not standard for the majority of Windows applications out there, including the Windows desktop.
[+] [-] IanDrake|14 years ago|reply
[+] [-] jlongster|14 years ago|reply
https://wiki.mozilla.org/WebAPI
[+] [-] rmc|14 years ago|reply
camera Not yet.
GPS Geolocation: http://dev.w3.org/geo/api/spec-source.html
compass Slightly related, gyroscopes & device orientation http://slides.html5rocks.com/#slide-orientation
local caching Loads of ways to locally cache things: http://slides.html5rocks.com/#offline-storage-title
2½ out of 4. Not bad
[+] [-] billions|14 years ago|reply
[+] [-] politician|14 years ago|reply
[+] [-] IanDrake|14 years ago|reply
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
[+] [-] arethuza|14 years ago|reply
http://picupapp.com/
[+] [-] marknutter|14 years ago|reply
- 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).
[+] [-] babarock|14 years ago|reply
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?
[+] [-] thetrendycyborg|14 years ago|reply
http://developer.android.com/reference/android/content/Inten...
[+] [-] k-mcgrady|14 years ago|reply
[+] [-] ch0wn|14 years ago|reply
[0] http://webintents.org/
[+] [-] djKianoosh|14 years ago|reply
[+] [-] hack_edu|14 years ago|reply
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.
[+] [-] richardburton|14 years ago|reply
[+] [-] DrJokepu|14 years ago|reply
[+] [-] Tichy|14 years ago|reply
[+] [-] tikhonj|14 years ago|reply
[+] [-] taylorbuley|14 years ago|reply
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.
[+] [-] billions|14 years ago|reply
[+] [-] jollyjerry|14 years ago|reply
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.
[+] [-] namank|14 years ago|reply
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.