Comment by dheera | Hacker News Reader

Comment by dheera | Hacker News Reader

More stuff the web can't do that native apps can do:

* Request stuff from arbitrary URLs without a CORS proxy

* Open TCP and UDP sockets

* Be in the play store/app store AS a web app (home screen installation isn't enough; people still search for your thing in the app store, so even if the other problems aren't issues for your app, you still have to wrap your web app in a dummy native framework and upload it if you want users to discover you)

* Scroll like a native app without Safari's stupid rubber band scrolling the entire app at very erratic times

* Barometric sensors

* Background geolocation, background anything really

* launchActivityForResult so you can work with other native goodies

* Intent resolution for native actions

* Geolocation when the user has inadvertently blanket-blocked Geolocation for all of Safari instead of per-webpage. Thankfully Chrome comes pre-approved on Android and you can't accidentally make this mistake as a user

* Face tracking and other OpenCV-based stuff (it's been done, but JS is still not fast enough on mobile to handle these jobs)

* Display long lists of styled content and scroll without stalling

Still though I think touch gestures is really the killer missing feature. There isn't any canonically-supported way to do things like a simple Android ViewPager or pinch-to-zoom. You end up implementing a bunch of spaghetti code to do these things even in the best frameworks (Meteor, Phonegap + Polymer, Angular et al.). And then you find out the way your spaghetti code reacts is a tad different from the way someone else's spaghetti code reacts to the same gestures. This stuff really needs to be standardized on a OS, browser, or at least JS-framework level.

I'm not saying that native apps > web apps isn't true, but…

> * Request stuff from arbitrary URLs without a CORS proxy

CORS isn't a proxy; it's a browser policy/algorithm that allows a site the opportunity to say "yes (or no), other websites may (or may not) make AJAX requests here". The native app (unless you've informed it somehow, or it has done something malicious) doesn't have the user's cookies, whereas the browser does, and needs to be a bit more cautious.

> * Open TCP and UDP sockets

There are websockets, which aren't the same, I'll admit. Frankly, I'm not sure I want my web pages to be able to arbitrarily open TCP/UDP sockets. (I don't really want my native apps to be able to on whim, either…)

> * Barometric sensors

You mean like current air pressure? Are there common devices out there with these? (None of my computing devices have anything like this, for example.) (and what would I want this for?)

I think the parent knows exactly what CORS is and you're misunderstanding.

There's no fundamental reason browsers can't be configured to not send the user's cookies when making XHR requests, and in fact there's already a mechanism for a webpage to ask certain kinds of CORS requests to be "anonymous":

    The "anonymous" keyword means that there will be no exchange of user
    credentials via cookies, client-side SSL certificates or HTTP authentication

https://developer.mozilla.org/en-US/docs/Web/HTML/CORS_setti...

Because of this arbitrary technical limitation, if a webpage wants to make a request to to an arbitrary URL equivalent to what a native app could ("anonymous"/cookies-free, of course), it'd have to make an AJAX (or WebSockets) call to an intermediary server running native code to do so, which is what the parent is referring to as a "CORS proxy".

--

> > * Open TCP and UDP sockets

> There are websockets, which aren't the same, I'll admit. Frankly, I'm not sure I want my web pages to be able to arbitrarily open TCP/UDP sockets. (I don't really want my native apps to be able to on whim, either…)

Sure, whatever, you don't want arbitrary native apps being able to open arbitrary TCP/UDP sockets, but you're missing the point. We both agree that it should be possible to, somehow, download an FTP client and somehow configure security settings so that it can work, right? (Restricted ports and filesystem or chroot or whatever.) There's no fundamental reason browsers can't have the same security framework so that you can open an FTP client web app and somehow configure browser security settings so that it can work, right?

--

> > * Barometric sensors

> You mean like current air pressure? Are there common devices out there with these? (None of my computing devices have anything like this, for example.)

According to XKCD, "a lot of new Android phones" have a barometer sensitive enough to "actually see the pressure difference between your head and your feet."

https://what-if.xkcd.com/64/

(Obviously that's not an authoritative reference, but I think it's sufficiently addresses your question, and it's a fun article.)

> (and what would I want this for?)

What a great question, I'd love to know too!!

What you characterize as an "arbitrary technical limitation" is there for a good reason, unfortunately: even anonymous requests made by the _browser_ are not equivalent to anonymous requests made by the _server_ the web page came from.

That's because the browser and the server have different routing tables. Or to put is more simply, the browser can see the stuff on your LAN, behind your firewall, while the server can't. The point of CORS even for anonymous requests is to prevent web pages from being able to exfiltrate stuff out from behind firewalls, so you don't have random data leaks just because someone in an organization visited some random website. (Yes, you also need them to not download and run random binaries, not have any unpatched exploits in their browser and OS, etc... security is hard.)

Now obviously native apps _can_ exfiltrate stuff out from behind firewalls. Which means that if you really care about your LAN's security you have to assume or enforce that none of the phones connecting to it have any sketchy apps installed...

Note that there is in fact discussion about having a concept of "installing" a web app that you trust sufficiently, which would relax the browser security sandbox such that you get more of the capabilities you're talking about here.

IMHO the true point of a web app is to replace the native app and kill the need for developing every app twice (Android + iOS), as well as moving toward the vision of putting ALL apps "in the cloud" and fully OS-independent.

In order for this to happen, those web apps need to have every capability a native app can have, including access to the local area network, if you want to do "things that native apps do". What if I want to write an HTML5 SSH client so that I don't have to rewrite it twice for iOS/Android? An SMB client? A custom streaming protocol? An HTML Arduino IDE that can flash code over the LAN?

Ideally, a web app could simply have a manifest of permissions, present this list to the user at an appropriate time, and the user decide whether or not to grant them. Opening arbitrary TCP sockets should also be a permission, just like native apps need to add this to their manifest. Native apps already ask for permissions when installed; web apps should be required to do the same, and in return, be granted the same set of capabilities.

The idea that "web apps should be restricted" is at odds with the vision of using web apps to realize a true cross-platform app programming ecosystem.

Yes, this is why people are talking about having "installable" web apps. It sounds like you clearly agree that some sort of explicit user opt-in is needed to get out of the sandbox, which is good; I've seen some people argue that this is too high a bar.

Now it might happen that this will effectively happen as a result of convergence and standardization of browser extension APIs. It'll be interesting to see what happens there.

That said, the manifest of permissions idea is fundamentally broken in at least two related ways:

1) Most users have no rational basis on which to decide whether to grant the permission or not. In fact, I would argue this is all users, due to issue #2:

2) The permissions are either overbroad, such that pretty much any app that wants to do anything interesting asks for them (this is the "all my apps on want to be able to read my contacts and browsing history" syndrome) or there are so many of them that the list becomes way longer than any user would ever read at install time.

You example of a permission for opening arbitrary TCP sockets is an excellent case in point. As a standalone permission, what fraction of users do you think would understand what is actually being granted? Even if you restrict to computer professionals, I suspect that most would not understand the implications without a somewhat lengthy explanation of what the permission actually allows. And even then, in practice it would be rolled into some other more broad permission that would likewise not indicate the security implications of granting it.

http://robert.ocallahan.org/2011/06/permissions-for-web-appl... has some more in-depth discussion of the issues with this model.

> Native apps already ask for permissions when installed

Yes, and in practice everyone just grants whatever permissions are asked for without really even reading.

You're right, there's a really good point here that I didn't acknowledge. The way I think of it is that the browser's security model, while not particularly secure from an academic or theoretical standpoint, is extremely widely deployed, widely studied, and well-understood, and in that very pragmatic sense is very well-trusted. Hence, every little thing that affects the security surface area must be exquisitely scrutinized, necessarily resulting in slow advancement in any such features.

> * Request stuff from arbitrary URLs without a CORS proxy

I think OP probably means a proxy server on your domain which can make arbitrary requests to a third party, in order to get around CORS restrictions:

  browser <--[XHR]--> my-server <--[HTTP]--> third-party

> CORS isn't a proxy;

I don't think the GP was implying that.

If you don't control the upstream content you don't necessarily control the CORS settings. Hence the need for CORS proxies to work around an ideal introduced by the major browsers in the last few years.

In the real world you may well have the right to access third party content, but in many cases you require them to expend engineering resource to perform the very simple task of enabling a simple set of headers, so end up having to proxy content.

Take Chromecast for example - it takes CORS to the extreme requiring it set on HLS manifests and .ts video files, meaning any proxy solution has to take the full cost of proxying the full video content. MP4 files don't have this restriction, nor do any browsers.

To me it very much feels like the web is splitting into two - Sites that you stumble upon and want completely sandboxed, and those you come back to repeatedly and provide enough value for you to click "yes, have my location"..

>> * Barometric sensors >You mean like current air pressure? Are there common devices out there with these? (None of my computing devices have anything like this, for example.) (and what would I want this for?)

Most modern phones have a barometric (yes, air pressure) sensor included. Having semi-accurate altitude data helps the GPS receiver obtain a faster location fix, but it can be used for other things as well.

> Are there common devices out there with these?

Most Android devices since maybe late 2012 have had one. It's used for enhancing GPS lock, and whatever developers can dream up. All I've heard about it being used for is a distributed air pressure sensor network used for weather prediction, tracking, etc. [0[

0: https://www.pressurenet.io/

Yes. The barometric sensors in the iPhone 6 and most high-end Android phones of past 2 years are sensitive enough to determine +/-1 floor of building movement, among a whole lot of other things. Very useful if you're writing a hiking app, want to determine if the user is in an airplane or not, trying to do vertical geolocation in a vertical city like New York or Hong Kong (subtract user's barometric reading from the weather station and you'll have it accurate to +/-a few floors), and a whole lot of other endless possibilities.

Of course you don't want web pages opening TCP and UDP sockets. The web isn't for writing apps it's for publicly editable documents with hyperlinks.

> Scroll like a native app without Safari's stupid rubber band scrolling the entire app at very erratic times

This is defeatable, either with `-webkit-overflow-scrolling: touch;` or other techniques.

> Background geolocation, background anything really

You mean, Service Workers?

> Display long lists of styled content and scroll without stalling

I could be wrong, but I think this is a Safari-specific concern. Android Chrome has never had this problem for me. In older versions of iOS, Safari was not able to execute Javascript while scrolling which could be perceived as "stalled" rendering. I'm not sure if that's what you mean, but Apple has been gradually working to allow JS execution during scroll. But they're so behind (in years) that I wonder if there are still some cases where the execution can't keep up with the scroll.

I've definitely had problems with this. There's a lot of bloat that comes with the DOM, especially if you use a framework like Polymer or Angular. Even something as simple as a material-design text entry field requires a horrific amount of CSS bloat to accomplish internally, and if you multiply that by, say, 1000, you're in for trouble.

Polymer and Angular 1.x do come with a lot of bloat. I wouldn't call a MD text entry field "simple". Material Design was released ahead of web technologies really being able to manage it well, at least on mobile.

Polymer itself is 47KB. If you add the web component polyfills (16KB), that's 63KB minified and gzipped. I tend not to consider the polyfills because they're not Polymer and are a stop-gap that goes away over time.

Perspective is important :) Putting 1000 material design inputs on a page isn't something a sane web app would do. The same is true for a native app.

Re. "bloat" of components. I think it's important to remember everything something like paper-input is doing for _you_. As a developer, I no longer have to think about: validation, animations, a11y, keyboard, knowing all the MD spec configurations, labels, underlines, colors, fonts, typography, margins, composability, x-browser interop,... Sure, if you were implementing your own input, you could cut corners and/or leave out what you didn't need. However, if you were creating a highly reusable, highly configurable element, you'd be implementing the same amount of "bloat" yourself.

> Putting 1000 material design inputs on a page isn't something a sane web app would do.

Why not? What If I want to make a material design spreadsheet app? Just a random idea, but again, the people who make basic OS-style UI elements shouldn't be judging what a "sane" app should and shouldn't do. This limits creativity.

> However, if you were creating a highly reusable, highly configurable element, you'd be implementing the same amount of "bloat" yourself.

Sure, if I implemented it in JS. Implemented natively, a MD paper-input consumes very little resources because it isn't a nested div hell with CSS and a shadow DOM.

What would be more awesome is if there were a way to, using HTML and JS, "ask" the browser to call and insert a native element and be able to interact with it. On iOS, it should be an Apple-styled element, and on Android 5.x, it should be a MD element. They should be the genuine native element inserted right in place, not a DOM hell designed to "look" like the native thing.

I would conjecture that any app that's doing thousands of inputs will probably use virtualized lists so performance is predictable. And you can do that with JS too :D.

The web is crap at long lists in general. Try to build something like Mail on iOS or OS X, which shows you all of your email in a big list: the best you can do is infinite-scroll solutions like Yahoo! Mail, which are horrible on every browser.

* Offline mode:

If you have large amounts of structured data and high performance requirements for it... well, good luck.

Reply on news.ycombinator.com