SoylentNews is people
SoylentNews
Mozilla's Project Electrolysis aims to allow tabs and user interfaces to run in separate processes. It has been activated by default in recent nightly builds:
In current versions of desktop Firefox, the entire browser runs in a single operating system process. In particular, the JavaScript that runs the browser UI (also known as "chrome code") runs in the same process as the code in web pages (also known as "content" or "web content"). Future versions of Firefox will run the browser UI in a separate process from web content. In the first iteration of this architecture all browser tabs will run in the same process, and the browser UI will run in a different process. In future iterations, we expect to have more than one content process.
Developer Will Bamberg says the change will bring stability and security improvements. "There are three main reasons for making Firefox run content in a separate process: performance, security, and stability, Bamberg says. "The goal is to reduce 'jank' -- those times when the browser seems to briefly freeze when loading a big page, typing in a form, or scrolling. "In multiprocess Firefox, content processes will be sandboxed. A well-behaved content process won't access the filesystem directly; it will have to ask the main process to perform the request." Bamberg says "well-behaved" content processes needs to access much of the network and file systems. This would be much more restricted under the changes.
Former CEO of Mozilla Brendan Eich has announced a project called WebAssembly that could replace asm.js:
It's by now a cliché that JS has become the assembly language of the Web. Rather, JS is one syntax for a portable and safe machine language, let's say. Today I'm pleased to announce that cross-browser work has begun on WebAssembly, a new intermediate representation for safe code on the Web.
What: WebAssembly, "wasm" for short, .wasm filename suffix, a new binary syntax for low-level safe code, initially co-expressive with asm.js, but in the long run able to diverge from JS's semantics, in order to best serve as common object-level format for multiple source-level programming languages.
Who: A W3C Community Group, the WebAssembly CG, open to all. As you can see from the github logs, WebAssembly has so far been a joint effort among Google, Microsoft, Mozilla, and a few other folks. I'm sorry the work was done via a private github account at first, but that was a temporary measure to help the several big companies reach consensus and buy into the long-term cooperative game that must be played to pull this off.
Original Submission
(Score: 2) by kaszz on Saturday June 20 2015, @07:18PM
Adding another virtual machine (VM) that will interpretate bytes as opcodes just like Java. Why would that be a good idea? It will throw everybody a lot of security and obfuscation issues.
Isn't the intention from start that HTML is used to present content. Javascript fixes things that can't be done with HTML, like making a page respond to user actions without involving the server it came from. And Java VM is there for when you need advanced stuff that is in essence a binary downloaded and run directly in the browser.
So if Javascript is the problem. Let's not worsen the situation by having yeat another obfuscating binary VM but rather replace Javascript with a decent scripting language that has a better structure like pre-declared variables and works consistent across platforms? and get away from this recursive patching of previously done "oops".
(Score: 0) by Anonymous Coward on Saturday June 20 2015, @07:56PM
Do you even understand what this is about?
but rather replace Javascript with a decent scripting language
How many of the browsers in use are going to run that new scripting language natively with even the same performance as Javascript?
So you take your new scripting language whatever it is and compile it to Javascript "asm", since that's what browsers are running faster and faster (whether you or I or everyone else likes it or not).
Enjoy.