In my opinion, it doesn't make any sense. We should keep separated tools that do different jobs, and make each one general enough that it can be used in every situation.
One of the newer features of Hello is tab sharing, which is niche but clever, and needs some sort of browser integration.
People use their browser (through webapps) for chat, mail, etc anyways, instead of using dedicated applications, so there doesn't seem to be much purity in that regard. And Hello is mostly build on web-tech the browser already has to support. Putting it there makes it more likely for people to quickly try it, and learn that browsers now can do cool new things with WebRTC.
But I don't think that should apply to the browser. Firefox already gives you extensions, which means you can add to it whatever you need.
Would you say the browser should come with a painter program by default? Maybe a file manager too? What about a specific program to print for a specific printer?
At what point should you stop reinventing the wheel?
Software takes up no space.
The browser should be a rendering engine, which is a pure sandbox, for client side applications. The client side applications will have access to standard local dbs, standard Dom and CSS renderers and standard method of running code through webassembly.
Webassembly with DOM access is IMO the final piece to do this. And then all OS device access will be done through this sandbox environment where there can be highly controlled access to things like mounted disks, etc. In this utopian future, all developers will be able to target any browser/OS with identical code and never have compatability issues. (And a choir of angels sing out in joy)
And wasn't that computing model all the range 40 years ago, with "big iron" (less powerful than my phone now) mainframes that lived far away and dumb terminals (essentially a keyboard and a screen with very little processing happening locally)?
Are we saying computing is so hard that people can't be trusted with a real computer? Everything needs to be on someone else's computer and you are only allowed to have a locked down browser locally?
I don't get this everything old is new again trend. And how enthusiastic today's kids are about their grandfather's computing model.
Portability (and not just between architectures--between operating systems as well).
> and now treating JavaScript as CPU op codes?
Web Assembly does not treat JavaScript as "CPU op codes".
I'll add that I think your confused about what I am saying. In the JavaScript world, the single page app is really just a pure client side app, no different than an app dedicated to Windows like Word. The difference is that it targets web standards for building applications, in a sense the browser is the operating system and application development environment that the OS used to provide.
The key is that it's a standard, and should work the same across platforms. The fact that it's on the web is just a delivery platform for the software.
Webassembly will bring the performance of these browser based applications to be on par with any native application. It's the write once run everywhere development that we've all wanted since the promise that Java made.
I do think that there is a benefit to this model over Java, which is that it's more flexible than Java was in allowing for design choice, and many more languages (in large part thanks to the LLVM).