[Boldewyn]

Well, we have a scenario rather close to the one described in the article on mobile: Browsers for text content and apps for specialized stuff, that can incorporate web views, if needed, and access the net. (Yes, I’ve read the second-to-last sentence.) In a nutshell, it sucks.

To start with, I don’t buy the premise “Okay, so web browsers are awful for applications.” The statements before are way to generic to prove anything.

“[...]resource hungry beasts with millions of lines of code” falsely connects those two properties.

“[...]use several gigabytes of RAM, even when just displaying document-like content” might also be rooted in advertisers packing megabytes of rubbish in an iframe or web devs loading tons of unneeded web fonts. So, that’s bad engineering on the server side, not the browser’s.

“[...]that reimplements much of the features of an operating system on top of a real operating system” Chromebook anyone? Yes, that’s actual, ready-to-be-bought devices out there right now, that do exactly this. And lo, the problems are somewhat contained.

The conclusion also does not show any solution to the non-problem discussed above. “Imagine something like xdg-open.” I don’t need to imagine that, I have it right before me available in the terminal. And packing another service discovery on top of the stack is, to come back to my opening words, not so different from the closed-world app stores. Even Ubuntu has such a thing. And guess what? For people without technical knowledge keeping everything in the browser is way more efficient (work-wise, not performance-wise) than explaining arbitrary switches in context from browser to some app to some other app and back to the browser.

Security: “I’m no expert [...but...] doesn’t seem to be completely unrealistic.” The devil’s in the detail, as virtually everyone who works on browsers’s JS engines can tell you. A runtime, that downloads arbitrary binaries from the web to be executed, sounds in every regard like a bad idea, even if you put it in a full virtual machine. The two-word argument against this is basically “Flash exploit”.

Platform independence: The author might be too young to remember Java’s “write once, run everywhere” claim, that turned out to be not so fully true. And turning the current state of almost full platform independence in the browser for some proposed, from-scratch infrastructure will become exactly that disaster, that Joel Spolsky warned about 15 years ago in the context of the Netscape rewrite (http://www.joelonsoftware.com/articles/fog0000000069.html).

“But one thing is certain: the web platform we have today is already bloated, does not suit our needs and severely limits innovation.” No. It is not certain. Browsers today run on low-profile smartphones. Bloated web platform? Most of these things are opt-in, and many clever people build fallback strategies in new specifications to enable _everyone_ to become part of the web. Limiting innovation? Quake runs smoothly in the browser. Who would have figured that 10 years ago?

All in all, to me it seems the post is written by someone, who hasn’t yet fully groked the web.

[Slartie]

I'm not sure that "a decade-old game runs smoothly" would qualify as an innovation, rather than as a showcase of the exact problem the author was hinting at. Just getting stuff shoehorned into the browser that we already had running perfectly fine outside of it is not "innovation".

What about truly new stuff that nobody has seen before, neither inside browsers nor in native applications?

[Boldewyn]

In 5 years, that’s my rough prediction. So long it will take for the browsers (with significant market share) to catch up with existing native features to combine them with the web. Then we have enough instances out there to use reliably:

- canvas + 3D support

- asm.js / WebAssembly: a way to run performant byte code

- WebRTC: Video chat, file transfer P2P

- APIs closer to the hardware like vibration, ambience, speech, ...

- stuff, that’s being developed but I don’t know yet, because the field has become so huge now. Small glimpse: http://caniuse.com/

And for developers it’s a single platform, together with distribution channel.

Apart from that: Truly innovative stuff happens on the web regularly. For example, look no further than Facebook (or Reddit, Imgur, Twitter, whatever you like). A software (in the broader sense), that allows billions of people to connect with each other and share thoughts. Imagine that in the age of SMS, phone books or snail-mail! You will see, that it’s fundamental to make something like social networks, the browsers had first to evolve from the bunch of hacks, that they were in the 90’s.

Another example of the power of browsers: FirefoxOS. A complete smartphone OS powered by web technologies on a thin Linux layer.

So my point is: the “truly new stuff” is partly already out there, you just have to look. And partly it will hit your devices, when the browsers are evolved enough. It’s a continuous process, and not a single “wait, there’s more...” (which doesn’t surprise the least, when you think of the _huge_ numbers of devices out there).

Edit: Formatting.

[black_knight]

Surfing on a smart phone is a real pain. Pages take longer to load than in the 90s and contrary to the 90s you can't start reading before it all has loaded.

Java tried to be C++, but run on every machine. That turned out to be difficult. But I don't think the author is thinking of Java. I guess he more has in mind domain specific languages, which are abstract enough in nature to be executed faithfully on any system with given capabilities.

Security also goes hand-in-hand with this form of abstraction. If the language can only express safe actions, the program will not be malicious. In pure languages, such as Haskell, one can use type-guarantees to enforce these restraints. One could imagine a virtual machine with this kind of typing.

[JadeNB]

> If the language can only express safe actions, the program will not be malicious.

Because 'safe' is not well defined, I can't argue rigorously against this, but it seems like the sort of thing that falls afoul of Rice's theorem (https://en.wikipedia.org/wiki/Rice%27s_theorem): for most reasonable definitions of 'safe', you can have a proveably safe language or you can have a Turing-complete language, but not both.

[black_knight]

Rice theorem is not really applicative here. It is a beautiful theorem, but it has to do with what we can compute, while "safe" has to do with what one can access.

A function taking Integers to Integers in a pure language cannot do I/O, and thus is "safe" to run, in the sense that I can be guaranteed it does not contain a trojan making my computer into a peer on a botnet. This is true, even if I allow it to compute any computable function.

Computational expressiveness and "safeness" are in a sense orthogonal. And just as I don't think it is always appropriate for any function to do I/O, I am not convinced all functions should be able to perform any computation. But that's a different discussion.

Regarding definedness of the term "safe", I would say it is defined by your threat model. It not an absolute term, but dependent on context.

[Boldewyn]

Of course, if the language of a program is stripped down, the interpreter can be made much safer. But then, we gain nothing from trying to shove down the users’ throats other platforms compared to, say, WebAssembly, which _will_ be shipped in almost all browsers in a year or so.

Just look at the long history of people trying to bring Python in the browser, or the fight to get Java applets _out of the browser_ again.

Basically I read the article as “scrap that web thing, and just begin from scratch”. And this is not a worthwhile path to go for many reasons.

[JadeNB]

> A runtime, that downloads arbitrary binaries from the web to be executed, sounds in every regard like a bad idea, even if you put it in a full virtual machine. The two-word argument against this is basically “Flash exploit”.

Not sarcasm, but an honest question: barring the argument "even full virtual machines have bugs", to which one might as well retort "even multiply heavily tested browsers have bugs", why isn't it safe to run such a program in a virtual machine? It seems that most of the pain of Flash exploits comes from the fact that Flash doesn't run in a (proper) sandbox.

(I'm not a web developer, so I could easily be talking nonsense.)

[dsfsdfd]

I would have written something similar, had I not been so lazy. Good Job, well put