Stories
Slash Boxes
Comments

SoylentNews is people

posted by janrinok on Saturday June 20 2015, @01:43AM   Printer-friendly
from the still-trying dept.

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

 
This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 2) by prospectacle on Saturday June 20 2015, @07:43AM

    by prospectacle (3422) on Saturday June 20 2015, @07:43AM (#198574) Journal

    You may be right about existing VMs. I don't know enough about them.

    Would JVM be able to run javascript efficiently so that the new system could be backwards compatible with old web pages. I'm assuming this proposed WASM engine will, once released, compile javascript to bytecode if the page contains javascript (and maybe do the same for several other languages), or run bytecode directly if the page contains bytecode.

    Regarding the "dream of java" that never works, I would argue that javascript has gotten far closer to realising this ideal than java ever did (or ever will). Of course it's far from perfect.

    Regarding platform differences, they definitely exist, and create all kinds of work, but people work around them. Many web pages will adapt to the resources available and some are even quite good at doing this. The size (and amount, and resolution) of what's displayed on the screen at once, the user input that's required (whether from touch, swipe, type, etc), the framerate, and layout might all be adjusted according to your screen size, effective processor performance, graphics power, input hardware, etc.

    Whether or not we have a bytecode interpreter for browsers is probably not going to affect whether or not the web remains the "Write once, run anywhere" plaform of choice, but it might make the performance better.

    I don't know if existing VMs would be better suited but I suspect one of the reason to make a new one (besides novelty and PR value) is to make sure it can be optimised to support existing javascript, DOM operations, etc.

    --
    If a plan isn't flexible it isn't realistic
    Starting Score:    1  point
    Karma-Bonus Modifier   +1  

    Total Score:   2