Beyond App Stores: Weaving Apps into the Web | Hacker News Reader

Beyond App Stores: Weaving Apps into the Web

blog.gaborcselle.com

37 pointsgaborcselle33 comments

Take a look at open web apps / chrome apps / phonegap / the Firefox OS project (I work on the latter). The line between apps and websites is getting thinner by the day, and getting very close to being non existent.

Also the 'apps are an island' comment is quite specific to iOS, Android has a very elegant system for allowing apps to interact with each other, one which the web is adopting (web intents/activities).

The basic premise is the wrong way round, web apps will adopt native functionality (web api's) and native performance (which already good enough for most use cases), they will (and can often already do) work offline.

'Native' apps are almost by definition going to have to be rewritten for every platform and will never have the same introspection and interconnectedness as the web.

Which platform do you think is going to fix its disadvantages first? seems obvious to me.

Both iOS and Android allow apps interacting with each other. iOS has URL schemes, Android has Intents which are obviously far more elegant. There are tricks you can play to have apps intercept web page visits on Android [1], but other than that, web apps are disconnected from native apps.

[1] Intent Filters: http://developer.android.com/reference/android/content/Inten...

That's ... one way to characterize Intent Filters. They enable, more or less, exactly what you talk about in the article, as I mentioned in my other comment.

I think the key question is where will the consumers go? Android is more open than iOS, but devs continue to build for iOS first b/c that's where all the users are at, especially the paying users.

I only know a little bit about the Firefox OS project, but if you give control to the OEMs, won't you run into the same problem that Android has with fragmentation?

On one hand, I don't want to be naive. Everything on the desktop has moved into the browser. That happened a lot faster than I though. Everything in mobile is moving 2x the speed of desktop, so will everything move onto a browser in mobile eventually too? The key difference between the desktop and mobile is that there isn't hardware ubiquity. Every computer has a keyboard and a mouse. But the hardware buttons aren't standardized across Apple and Android. The home button is crucial on the iPhone and same with Android. Would either of those platforms ever cede control over that button to a browser? Otherwise, you've got to put that functionality on the screen which takes up space.

'fragmentation isnt a problem, its a fact'

We will never convince the entire world to settle on a single device, Androids biggest 'problem' is a large part of why it is completely dominating the mobile market (although I dont disagree that OEM customisation can be annoying).

Apps dont have control over the home button on iOS / Android, I dont reallyknow what you mean 'cede control' (unless you are thinking Firefox OS runs inside Android / iOS as an app? it doesnt, its a full OS)

>The line between apps and websites is getting thinner by the day, and getting very close to being non existent.

For a very small subset of "apps". There are still plenty of things that would be hard or impossible to do in a web app.

I disagree with the 'very small subset', especially when we are talking about advancements going forward. There is very little to nothing that wont be possible to build using web tech.

I don't like apps anymore. Why would I want Hotel Tonight (for example) on my iphone from a trip to Dallas two months ago. The constant updating, notifications, etc. Apps are a mess. I don't have a solution but I do know I'm tired of apps.

Exactly, Mobile Apps (not games) are rapidly becoming the CD-ROMs of the modern times. Too much waste of space and resources for such a minimal use.

I only use email/rss and twitter apps. Everything else I always try to do in the browser.

"let mobile browsers download small apps and execute them within the browser window"

If you want to know how this turns out you only have to look at the evolution of browser plugins (applets->flash,silverlight,unity,etc) that has taken place for the last 20 years. We could also decide to skip all that and just concentrate on moving forward the HTML spec and tools to make better mobile web applications.

Automatically downloading and executing binary code from the web. What could possibly go wrong?

Isn't NaCL supposed to in part solve this?

Take out that automatic nonsense and I think he makes a good proposal. A URL can currently load a local app rather than a page in webkit. Only in this case, there would be some markup that would tell the browser to check for the installed app, perhaps the browser would present some unobtrusive indicator that a hybrid app was available to download. Just keep the address bar and the rest of the browser chrome there, swap the webkit frame out with the app's window, let the app access some of the history APIs, and you'd have a good portion of this figured out.

Thanks for seeing the value in my (somewhat avantgarde) argument.

I'd be happy with the app availability indicator as well. The native app would still remain within the confines of the browser, so that you could easily navigate away. People don't install apps today because it takes time to download them, and the browsing experience is interrupted by switching to a different app.

Ah, I misunderstood your proposal. This would actually be a great update and is pretty plausible.

Like, a streamlined way of installing an app and the ability to launch it with some URL the first time. Relatively easy, not a platform threat.

The internet doesn't need more confirm/deny dialogues.

The proper solution to this problem is for content providers to build a properly responsive site. Allowing apps to access browser cookies isn't going to fix anything - the reason that a native app doesn't open to the place you left off on the web is not because it's technically impossible, it's because app developers don't give a damn. Giving them more tools isn't going to change this.

Allowing apps to access browser cookies is a solution to the problem that apps and websites are disconnected and don't know about each other's state. That's a different aspect than the one you're talking about.

Yes, you can build responsive sites, but what you can do in the browser is limited, especially when it comes to flaky connections that are still very typical. To take the example in the post a little bit further: Imagine you're on the train and are reading a multi-page New York Times article. Train goes into a tunnel. Trying to load the next page will result in a connection error. Native apps can know about your network state and can pre-cache content you're about to read next.

web apps can know about your network state and can pre-cache content you're about to read next. (http://www.html5rocks.com/en/mobile/workingoffthegrid/)

Last I checked, implementations of offline caching were unusably buggy. Has this improved?

Its rarely straighforward, but definitely usable

It works. LocalStorage API is pretty solid and widely supported, if you're doing some simple buffering to handle connectivity issues it's awesome, except that it prompts the user for permission to store data. WebSQL is solid where it's implemented, and IndexedDB is solid where it's implemented but unfortunately there isn't a lot of overlap (screw you apple). and AppCache works great, but figuring out how it works in the first place is annoying as hell.

we can call them "applets"!

Over time, we'd discover that this sandboxing platform is more useful for running server processes on co-located tablets.

This would be pretty neat, but file it under "things that will never happen on iOS in a million billion years."

In iOS 6 there is a way to open your native app with the same content as the current webpage.

https://developer.apple.com/library/safari/#documentation/Ap...

Yes you can, but that opens a different app and takes you away from Safari and its browsing history.

I don't know how else to put this but local, compiled apps run faster than web apps. And the problems laid out in the article are indicative of development choices, for example not being able to pick up where one left off in a local app as opposed to in a browser app in the NYT example.

Running a compiled app instead of a web page, as laid out in the post, would have that benefit.

The central theme of the post is that the local app and the webpage are disconnected - the fact that you can't pick up where you left off in the other is not a development choice.

The analogy of native apps being an island is a good one. But I'd argue that native apps is a pretty fucking big island ;) Check out this chart - http://www.emarketer.com/Mobile/Article.aspx?R=1009155

People use apps on their phones, not the web. Mobile web is a subpar experience. LTE will fix some of the speed issues. HTML5...well that's going to take a lot longer than people think. Cool technology but ANY lag with a gesture makes the touch interaction feel broken.

I've been thinking on this problem for the past 4 months. Seems like you're pretty passionate about it too. It's a big problem for users, and companies are sitting back and ignoring it. I have lots of theories as to why. Would love to meet up in person and share thoughts.

I think it would be far more useful for Android Browser/Chrome and iOS Safari to support special tags for rendering apps in their native style. Ideally have it be the same set of tags and Android and iOS figure out how they want to render them.

>My proposal would be to let mobile browsers download small apps and execute them within the browser window

Is this a sick joke? Besides the fact that the browser can trivially redirect to the exact app in the app store, I'm already annoyed that ABC wants me to download their god damn app everytime I accidentally click on one of their articles on Google News.

Not only that, but if the user has the app installed they're already prompted to open the same content with the app instead of the browser if they want.

This problem is already solved. This is very, very common in Android apps and I understand it is a new feature in iOS6 as well.

I guess if this is absolutely necessary, the browser could output a new header for domains that are declared in the .ipa/.apk that would notify the server that they have the app installed... and then they could force the app to open with a regular redirect. But that still majorly SUCKS to users who already have that choice anyway. If anything this gives the publisher more control of forcing me to use their app which I absolutely do not want.

Most publishers that have terrible apps also have terrible sites. Apps that get very little usage today are hardly going to get better if users don't start using them. Building an easier onramp for apps is going to increase app usage and cause publishers to build better apps.

That's pretty much the opposite of what I want. And what they want regardless of whether or not they know it.

Firefox OS is going to continue to open peoples' eyes to web apps and make people wonder why they scrambled around wasting so much money to make native news apps that do nothing but render a webkit view anyway. As another person has pointed out, there are very increasingly few things that webapps can't do that native apps can, especially on mobile where they're unprivileged anyway.

Reply on news.ycombinator.com