esailija

Do you have any reference for that? You can already technically use whatever you want and wasm will not remove the need for high level languages also having to supply a (multi megabyte) runtime as there is no direct mapping to wasm instructions unlike with C++ or C.

> Runtime for a few selected implementations should be very well be packaged or installed along with the browser itself. Failing that, it should be cached.

Web Assembly isn't related to this. You can standardize on a new language VM that browsers should ship, like was attempted with Dart. What Web Assembly enables is more efficient VM with better interop to Web APIs than currently is possible, but the most prohibitive thing will not change (having to ship multi megabyte VM along with your application code).

Frameworks are all or nothing, that is how they are different. Or does it make sense to have a codebase that has a mix of angular, react, backbone and ember for instance? Of course not. They are nothing like libraries in this regard.

jQuery is not a framework, it's a collection of helper functions for the DOM.

They use frameworks that they themselves invented specifically for their use cases, they didn't take someone else's framework because they know it doesn't make sense just as the author claims.

Duplication is preferable to using the wrong abstraction.

I don't see how it can be feasible to use it for implementations of other languages that don't directly map to webassembly like C. You would have to ship a runtime for the other language along with your application code. The runtime will be either huge with long startup time or small but too slow to be feasible.

This is a common confusion somehow. The programming language has nothing to do with the APIs provided by an environment. JavaScript can do all those things now, as long as you run it in an environment that provides APIs to do those things (node.js, electron etc). The browser is not that environment. When you write a keylogger virus in C, you are relying on the APIs provided by the environment to do it, they don't come from the C language.

The permission to read a file's contents in a web app is given by either dragging the file from your desktop to the web app or choosing it with file picker. To save a file, a web app will have to ask the user to do a save as dialog.

This permission model has pretty much always existed it was just extremely wasteful because you had to first send the file to server and then send the contents back. The new web file apis therefore don't add any new security issue but add massively better ux.

To me this is much smarter model than something like "can I have full access to your fs yes/no? Btw this app doesn't work if you say no". I think you are thinking of this stupid model when you say "what could possibly go wrong with that?" but if you don't, please elaborate.

If you consider custom elements, how is it different from any other way of building ui?

You can run web apps fully offline since like 2011. The only difference is that the initial "install" is 100kb instead of 100mb.

Upvote is already backed by the arguments the upvoted post contains. Downvote is not backed by those arguments. They are not symmetrical at all and there is no bias.

They are very different. The explanation for +1 is in the post you are upvoting. Thats why nobody ever has to ask "why the upvotes?'.

Even without extensions, those things are possible or will soon be possible[1] on the web out of the box (except tray icon but persistent notification with actions can be done to achieve something similar).

1. https://github.com/whatwg/mediasession#use-cases

FWIW there is a standard in the works (Media Session [1]) that will enable various use cases[2] for web app users to control with media keys, headphone buttons, from lock screen, notification area, ducking for phone calls etc

1. https://mediasession.spec.whatwg.org/

2. https://github.com/whatwg/mediasession#use-cases

These seem to be mostly about undecorated generators. 3. Is a legit difference but it is actually a syntax error to do yield 1 + yield 2. So that is fixable in a backward compatible way.

Yes but with this you lose the powerful features I just mentioned: automatic resource cleanup[1], cancellation, yield handlers.. don't you?

1. https://github.com/petkaantonov/bluebird/issues/1014

coroutines with generators are more powerful (cancellation, automatic resource cleanup when the generator terminates etc) and have worked for a long time out of the box. The only difference is that you write `yield` instead of `await` and `decorator(function*` instead of `async function`

This alone doesn't prove anything since Apple doesn't give 3rd party apps same capabilities as its own apps.

There are probably hundreds of new APIs that have come after 2012 or whatever the year was when the ball was dropped. Those were just "from the top of my head" not something to be nit picked.

I didn't also literally mean that they are currently implemented by all of those browsers today. My point is that I expect them to be implemented browsers other than Safari sooner or later as they have strongly signaled. Safari has not signaled anything about them. Or if they have, provide evidence of it and I will apologize.

> filesystem is proprietary chrome tech, dropped from standard track

That's not the file system API I am even referring to. I am referring to https://w3c.github.io/filesystem-api/ which is edited by Mozilla.

> rtc is fair, and in development

For iOS Safari? WebKit having WebRTC is completely different from iOS safari having it.

> In fact Safari has often been the best mobile browser

There are no other browsers on iOS. When you are using Chrome it is using UIWebView (in other words, it is forced to be a crippled Safari due to anti-competitive policy). Although recent Chrome will be using WKWebView which means at least it's same as Safari. The UI around the browser is not the browser.

> Few users cares for logging into some website from mobile Safari just to get a subpar experience over a native app (or a hybrid app),

Few users could tell any difference between native app and web app running in a browser that has modern appy capabilities, provided there is same quality of implementation. The only thing that can make the experience subpar is precisely the lack of capabilities.

No, those are web standards implemented by other browsers like Chrome, Firefox and Edge.

But that "app" doesn't have any real capabilities so what's the point other than bookmarking websites?

There's no background sync, proper offline, no notifications, no (usable) indexeddb, no rtc, no file system, no media sinks, no media sessions ... these are from the top of my head.

You have a point that long time ago Apple was the one pushing the browser as application platform but today is not the same as the long gone past.

Edit: The can-i-use about "web audio" is misleading about Safari. The web audio is prefixed there with "webkit" is not the same as the standard API.

Edit2: Noticed it's not about "web audio" at all but html5 audio. That's an API from 2010 that doesn't really do anything for apps such as games or audio editors. The newer Web Audio API is used for this and that's what I am referring to.

> Chrome just doesn't feel and look elegant and smooth

I bet this feeling comes from the "smooth scrolling". Development Chrome currently has it, I really cannot imagine why didn't they do it earlier it's so trivial to do for major benefits.

I would be surprised to see any web standard that makes iOS Safari better for "appy web apps" (web apps that are more like native apps rather than documents and forms) implemented, as that eventually just makes Safari an alternative AppStore without reviews.

Of course I would love it because as a developer this is the dream but I am very skeptical that Apple will do it.

Which means you can actually use it in 20-30 years

They want developers to go against their best interests and only develop apps for a very small portion of users. They don't want to compete fairly with developers, making some capabilities inaccessible to developers while keeping them accessible to themselves. If you as a developer are ok with this, it must be some kind of stockholm syndrome.

Apple hates developers so many developers hate apple, that enough reasoning for you?

SNI sends the server name in plain text