161–170 of 318 posts
Earlier quoted context omitted.
Sorry, for sounding this stupid. Does this imply you can now do web programming with C++ instead of Javascript.
Yes. You can build WebAssembly bytecode from C++ and it will run in the browser like JavaScript.
Next we'll get to a webassembly-only VM that will replace the OS. All 'apps' will run on this VM instead of being native, and most will be cross platform. They'll talk to each other via messaging (using Javascript semantics) instead of bytes-over-pipes as they do today. An integrated globally available, namespaced data store API might replace the filesystem. Each app+version will be accessible by a distinct URL. 'My…
Add metrics and advertising obsessed companies into the mix and the only result could be a complete clusterfuck. The major issue with web apps is that the customer (or depending on the company bag of meat that watches the ads) has no control over the app or the data. They will be abused by the company in all sorts of creative ways. And yes, those VMs could be local-only, but why would Google, MS or Mozilla want that?…
I assume the ads would be at the messaging system, so even if a variable contains 'iphone' the ads start to appear.
Joking aside, we need a better security system because we never know if an arbitrary compiler is not embedding a malware payload.
Next we'll get to a webassembly-only VM that will replace the OS. All 'apps' will run on this VM instead of being native, and most will be cross platform. They'll talk to each other via messaging (using Javascript semantics) instead of bytes-over-pipes as they do today. An integrated globally available, namespaced data store API might replace the filesystem. Each app+version will be accessible by a distinct URL. 'My…
Replace “WebAssembly VM” with “JVM” and you will see how it’s already available, and why it won’t catch on.
Earlier quoted context omitted.
I have been thinking about why we have ended up here, and why not just native apps. The obvious answer is that it makes applications portable, which is great. The other key component I think is delivery. You don't ever install anything, it just exists when you ask for it. That is something native applications have never done, and not even something like JVM has done even though it addresses portability too. It is als…
The answer is that browsers provide something that users desperately need and no operating system has ever provided: a sandbox strong enough to run completely untrusted code. The success of browsers is an indictment of the entire field of operating systems research. They have either failed to recognize the need or simply failed to deliver that kind of security. For one example take WebGL. For decades OpenGL had been…
I would say that the browser most certainly has the biggest attack surface of any software in regular use. Your average browser is insanely complex. In fact, it is the only piece of software on my computer that scares me.
Multiple JITs, font rendering, parsing, layouts, compression, image handling, sound and of course about a billion edge cases because somewhere along the road we decided that faulty code is OK. Everything with tonnes of state that interact in ways that can't ever be fully tested or verified (because of an almost infinite variety). Let's also not forget that a large part of that is done at the very bleeding edge of CS research. I wouldn't trust anyone to do that in a safe way.
To me, a kernel seems simple in comparison.
Earlier quoted context omitted.
How many threads do you think the browsers will allow on a single page?
Currently quite a lot, more than 10 with the current stable Firefox release, here's a test page: http://pmav.eu/stuff/javascript-webworkers/ (Web workers are around since ca. 2010 so this is not very new)
People might not like it but i really think native apps are going to die once everyone figures out how to optimize this crazy web stack.
I disagree. When people start using native languages like C++ for the Web, they will quickly realize they could have just used C++ to begin with.
Earlier quoted context omitted.
I have been thinking about why we have ended up here, and why not just native apps. The obvious answer is that it makes applications portable, which is great. The other key component I think is delivery. You don't ever install anything, it just exists when you ask for it. That is something native applications have never done, and not even something like JVM has done even though it addresses portability too. It is als…
Most users spend >80% of their time in the browser. It's probably that simple. If you have a thing and you need users, are you really going to deliver it as a Qt app? Unless you're bitcoin, it's hard to think of a case. I'd say "or a game," but many are webapps. And at this point some of the hollywood-grade games might figure out a way to be coming to browsers soon. Unreal did it.
Earlier quoted context omitted.
What about packing up web assembly into a single file container like runtime designed to run server side web applications? This .war (Webassembly ARchive) file could include the application and all dependencies in a single installable that is JITd on load. Might be useful for the next generation of "serverless" cloud runtimes.
I see what you did there. I’d be all for this, honestly, except that the existing containers (yes, even Jetty) are too heavyweight for this use case. What you really want is a stripped down server runtime that loads and starts your application’s archive, fires it up on a (possibly random) local port and opens a stripped down Chromium instance that loads the app from that port. Of course, that sounds a bit like Electr…
Earlier quoted context omitted.
As many as is needed. And as many processors as are needed. As someone who writes browser based 3D games, I need more power!
A web page should probably not be allowed to use unlimited amounts of computing power without asking for permission first.