Why apps are not the future
scripting.com
scripting.com
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.
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'm just sad there isn't a Share option (so I can send the link to ReadItLater, Gmail, ...). If you do open the source, I'd love to help with it.
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.
Heavy.
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.
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.
XHR requests are much more of an analog to Intents than <a> links are, and they are a similar order of complexity.
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.
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.
Obviously feedback is an important feature, but one-way links are very useful low hanging fruit.
More: http://wiki.akosma.com/IPhone_URL_Schemes#Registering_your_o...
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.
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.
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.
No installed/downloaded app can go viral in the same way a web app can. The barrier to entry is vastly different between the two.
This is how angry birds became extremely popular.
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.
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.
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).
Mobile will follow the same track: we'll end up with both.
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.
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"?
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..
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.
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?
Only thing left is browser "splash screen"/loading image customization and the experience could be near native.
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" />
Thanks for the info!
I'm just not optimistic about that "next battery technology" arriving any time soon.
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 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.
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.
Many SAAS companies charge the same as an app, but per month, so you can't really compare it with a one-off payment.
The business model is often completely different for the web. We pay with our eyeballs (ads) and our thoughts (click data).
(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?
You're right in general (I was surprised at the jump from free to lowest paid tier for Dropbox), but fastmail.fm is <$5 per year.
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.
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).
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.
the web serves little purpose other than a
clumsy virtual machine
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.
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.
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.
It's success when it was created, and maybe now, yes.
But how about a future where everything has a mobile phone and/or tablet, but fewer have or care to use a web browser?
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.
The web is too big and too valuable for it to ever make sense to create a device that can't use it.
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.
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".
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?
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
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
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 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?
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).
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.
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.
And no, "2D/3D hardware acceleration" was not standard for the majority of Windows applications out there, including the Windows desktop.
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.
It was perfect I tell you!
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
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 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).
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?
http://developer.android.com/reference/android/content/Inten...
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.
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.
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.
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.
Apps are the path of least resistance for the consumer.
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."
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?
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.
How about the freedom from baby-sitting your OS install and the flexibility to just use a nice, polished app and go on with your REAL work?
Just be smart and make profit with the app fever while you can.
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)
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)
http://iphonedevelopertips.com/cocoa/launching-your-own-appl...
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.
They are not the future indeed. They are the present.