Hacker News Reader

Comment by Sanddancer | Hacker News Reader

Apple was pushing for "apps" to be web apps when they first released the iPhone as well [1], with Steve Jobs going as far as to say that native apps would potentially "damage the phone system". It wasn't until after the iphone was jailbroken, and people kept insisting on more powerful development choices that they started on their app store. People have been saying that webapps are the future for a decade now. At this point, I have to say it's never going to happen.

[1] http://www.apple.com/pr/library/2007/06/11iPhone-to-Support-...

View on HN

Fair points. I think it's more nuanced. Native apps are great and necessary for many scenarios. However, there are a ton of native apps that could be just as functional as a responsive web site. Sure there were issues with discoverability which the app stores helped with in the beginning (now I think it's just as hard to get noticed in the store as it is on the open web).

I don't think "web apps are the future of mobile". But I do think there is a better separation of native apps and mobile/responsive web apps.

What's more -- a significant number of apps ARE a wrapper around a UIWebView or something like it.

We've studied this and found that ~85% of the free apps on the Google Play store use a WebView (I like the term "mobile web app"): http://adamdoupe.com/publications/large-scale-study-of-mobil...

There's a big difference between an app that 'uses a WebView' to render specific pieces of content or clicked links, and an app that is basically a thin wrapper around a WebView. Can you clarify whether your ~85% number is referring to the former or the latter?

Sure! The short version is that I don't know.

We were looking for instances of insecure WebView usage, so from a security perspective small piece vs. entire app doesn't matter too much (and is difficult to measure, especially when looking at 1.1M apps).

However, some of the other numbers from our analysis can be useful to draw a picture of WebView usage.

We statically looked for uses of WebView, and 85% of the 1.1M apps used a WebView.

Of those 998,286 apps:

- 97% enable JavaScript (which is off by default)

- 36% use the JavaScript Bridge Interface (which is a fairly good indicator of heavy WebView usage)

- 94% implement a shouldOverrideUrlLoading method of the WebView (another good indicator that the developer is using the WebView for something non-trivial)

- 27% implement an onReceivedSslError method of the WebView (indication that the developer is using the WebView for something non-trivial). (Sadly, 29% of the apps that implement onReceivedSslError intentionally IGNORE all SSL errors.)

So I guess the takeaway is that 85% is an upper bound, the real number of WebView-only apps is absolutely lower, however it's clear that WebViews are significantly used in mobile apps.

As far as I'm aware, mobile doubleclick ads need a WebView with Javascript and shouldOverrideUrlLoading(). I'm not sure about others.

How do you account for apps that only use the WebView for showing ads with the various ad toolkits out there?

In our study we didn't differentiate (from a security perspective, if you are vulnerable because you use a WebView when showing ads, then you are still vulnerable), so I don't have data for that.

It would be interesting data, although determining WebView for ads statically might be tricky.

> there are a ton of native apps that could be just as functional as a responsive web site

That is probably true but most would require 10x the development effort at least and be obsoleted much sooner.

And then users don't want generic lowest common denominator applications; users want software to make the best use of the platform.

If we turn the web itself into an actual developer (and user) friendly platform, then we could probably start making better use of it as an application delivery vehicle. To enable this, I've been furiously working on this OS-in-a-browser concept for the past 3+ years: https://linuxontheweb.appspot.com

"This site relies upon cutting-edge web technologies that only Chromium-based browsers have implemented."

This might as well be Java.

> This might as well be Java.

Chromium specific certainly isn't as good as open standards, but it isn't as bad as Java. Once chromium is ported to something it doesn't face legal uncertainty.

Everyone that follows the Java license never had any issues.

Only the two companies that tried to screw Sun had any issues with it.

If you write a free application that runs on Java on the raspberry Pi you (probably) owe Oracle nothing. If anyone builds a console around that raspberry Pi, Oracle probably is owed money because the device is no longer a general machine. That is very different than chromium or anything else that is license compatible with your typical Linux distribution.

Whether or not someone owed damages is immaterial to the problem of trying to get everyone an appropriate license who might want to run your software in contexts you haven't imagined yet.

I've seen this anecdote given as rationale, but you can't say that the "web app" model on iPhones failed when Safari doesn't give you the needed functionality to make web apps.

For example iPhone Safari does not do push notifications, an essential ingredient if you want web apps, whereas Chrome on Android does. With Chrome on Android you can do Facebook's Messenger without installing anything. And while iPhone Safari led the way with some useful additions, like the possibility of specifying higher resolution icons for "Add to Homescreen", they dropped the ball on such improvements since iPhone 3G. In fact iPhone Safari is behind in implementing web standards. Apple also rejected Adobe's Flash and I concede that was for good reasons, but that left a huge void in how media, like video and games, could be delivered. You know, things like HTML5 Video and WebGL came after that. You also have to take into account that the first two models (iPhone 1 and iPhone 3G) had poor resolution, poor hardware and poor battery life by today's standards.

So you know, if Safari on iPhone 1 is the anchor by which you judge native apps, well of course native apps are better. You also make it sound like "the people" forced Apple to open their SDK. Oh come on, you can't be that gullible. An SDK was inevitable. What's the point of building your own OS if you can't lock people into its APIs? That's a lesson Microsoft taught us. The only reason for its delay was them taking the time to figure out how to control it. Do you remember when Google Voice along with other apps where rejected because they "duplicated existing functionality"?

You may not see it, but web apps have been winning for some time and there's no end in sight. When Google Voice was rejected by Apple, Google still delivered its functionality by means of a web app. When the Google Maps integration app was replaced by Apple with their own, which I might say it is inferior and unusable in my city, for a while iPhone users used Google Maps on the web, as it's very much usable.

All it takes for web apps on mobile phones to be more common is for the browser makers to implement the needed functionality. Right now the front-running in implementing web standards relevant for mobile phones is Google's Chrome and sadly not Firefox (though I hope that will change). And I must say it works well.

I think that one day, web apps by default could work, but before that can happen the web must see sweeping change.

The lackluster performance and high resource usage associated with web apps is a direct consequence of the complex patchwork nature of each component involved. Quite simply, the web was not designed to be used the way we’re using it, and evolving standards have made browser rendering engines horrifically complex (and in some cases convoluted).

What’s needed is a fundamental reimagining of HTML, CSS, and the DOM at minimum with little to no regard for legacy. In the 90s, we didn’t know what we needed but now the picture is crystal clear. Should we use this knowledge to design a new web, I’m positive that the result would be just as open as the web is now while performing tens or hundreds of times better — it’d likely be good enough to make web apps competitive with native apps under a far wider set of circumstances.

You'll have to explain why in details, not at a high level. In particular the fact that a replacement could perform "tens or hundreds of times better" is an extraordinary claim.

CSS has tons of problems, but almost every replacement for CSS that I've seen proposed would almost certainly have worse performance characteristics than CSS, optimally implemented, would. Most of them kill parallelism and kill opportunities for optimal GPU usage—they're proposed cures that are worse than the disease. The problem is mostly that browsers don't implement CSS as well as they could due to legacy, not that the technologies are fundamentally flawed (though this is not to say that they're not improvable, far from it).

To create a better architecture, you first need to have an in-depth understanding of what the problems in CSS actually are. Otherwise, you'll just trade one set of mistakes for another. (In particular, a CSS replacement that optimizes for Web developer productivity will not necessarily have acceptable performance characteristics—too often, people assume that "easy to develop in" implies "runs fast", which in fact these concerns are often in direct opposition.)

can't wait for servo "strict mode" css!!

> In the 90s, we didn’t know what we needed

Except the Web had already been invented at Xerox PARC and further explored at ETHZ using native technologies, so I guess some had already a pretty good idea.

If you reimagine HTML, CSS and DOM around web applications, you'll lose everything that make them great for their original purpose, which is rendering (non-fixed-layout) documents and structured content.

Surely there are some hiccups left in the design that come from its organic growth and could be smoothed out; but those are not as much as you would think, and most of that work has already been done in html5+ES6.

The end result is a platform that is great for zero-install distribution of web applications AND web documents. A new framework that centered only on the first goal would be severely limited, and a new one that served for both would look a lot like the current one.

Don't forget Facebook's HTML5 focus.

Reply on news.ycombinator.com