SoylentNews is people
SoylentNews
Mozilla Extends WebAssembly Beyond the Browser with WASI:
Mozilla’s WebAssembly started as an experiment, almost a question: is it possible to run arbitrary code in a browser without breaking the browser sandbox? A side benefit would be faster web applications that would outperform current web technologies, allowing developers to bring existing desktop applications to the web.
[...]Since its initial launch, WebAssembly has been adopted by all the major browsers, with support from Mozilla, Google, Microsoft, and Apple, who’ve all contributed code.
Best thought of as a definition of a virtual machine, WebAssembly works with the browser’s JavaScript engine to run code at speeds that compare well with native code. Instead of JavaScript’s byte code approach, it takes code written in familiar languages like C and C#, and converts it first to an assembly language-like bytecode before a final compilation as binary. WebAssembly executables are compiled before being delivered to browsers, making them a compact and efficient way of adding complex functionality to web applications.
[...]Experiments with WebAssembly outside the browser are all very well, but if it’s going to be a tool that supports cross-platform as well as cross-browser development, it needs to have new standards built around it. Mozilla recently announced the start of such an effort, with the first release of WASI: the WebAssembly System Interface.
You can perhaps consider WASI as the boundary between system level code running on the host platform and applications running in user mode.
Where WebAssembly works as an implementation of a virtual processor, WASI goes a step further and offers developers an entire conceptual operating system. With a virtual processor, there’s only one target architecture, and the JavaScript engine can handle translation between its implementation and ARM, Intel, Power, or whatever hardware you have. WASI does the same, offering WebAssembly programs its own low-level implementations of common OS functions, that are then translated into OS calls via the host JavaScript engine. Target WASI in your code, and you’re able to produce applications that run identically on macOS, on Windows, on UNIX, and more, even on mobile operating systems.
[...]It’s also important to note that you won’t be writing code that accesses the WASI interfaces directly. Instead, these will be what’s implemented in the WebAssembly equivalents of the standard libraries we use in most common languages. That way we’ll know that if we’re running a C application in WebAssembly through WASI a printf command will write to a console, no matter if it’s on Windows or UNIX. WASI implements the interfaces for WebAssembly compilers and the underlying JavaScript engine handles the actual system calls to whatever OS it’s running on. You don’t need to install the appropriate standard libraries for each target OS for your code, and you only need to compile once.
[...]There are already three implementations of WASI, Mozilla’s own implementation and a polyfill that will allow anyone to experiment with WASI in a browser. Perhaps the most interesting from a developer standpoint coming from edge delivery network Fastly. Its Lucet WebAssembly compiler is now also a runtime, with an open source release on GitHub. Currently used in Terrarium, Fastly’s experimental edge service, it’s seen as a fast alternative to JavaScript running on Google’s V8 engine.
In a blog post, Pat Hickey, a senior software engineer at Fastly, describes Lucet as able to “instantiate WebAssembly modules in under 50 microseconds, with just a few kilobytes of memory overhead. By comparison, Chromium’s V8 engine takes about 5 milliseconds, and tens of megabytes of memory overhead, to instantiate JavaScript or WebAssembly programs.”
(Score: 4, Insightful) by Anonymous Coward on Tuesday April 02 2019, @08:44PM (5 children)
It's not just Javascript. This jumped out at me:
How many times do we need to make this same mistake? Yeah, sure, this time the VM will be secure. That's what they said for:
- ActiveX (well, sorta, this wasn't VM iirc so it's the worst offender on this list)
- Java (Sun then Oracle applets and web start, not JS)
- Flash
- Silverlight
It's a shame that the CxOs at Netscape didn't allow Eich (let's elide the political stupidity--this is a tech discussion) to deliver his Scala-like vision for web scripting. Instead what we got was an abomination of a language that isn't OO, isn't functional (functional as in Haskell or Scala), is sorta kinda procedural but not really, is really just a steaming pile of dung that's somehow Turing-complete in an academic sense.
(Score: 1, Insightful) by Anonymous Coward on Tuesday April 02 2019, @08:48PM
Steaming pile of dung that's somehow Turing-complete in an academic sense.
If only academics were less concerned about Turing, and better at sensing dung!
(Score: 4, Insightful) by arslan on Tuesday April 02 2019, @09:50PM (1 child)
Unfortunately, this thing takes it a step further, it allows you to develop in different languages making it even more accessible to create bad code to be pushed to browsers.
(Score: 2, Funny) by Anonymous Coward on Tuesday April 02 2019, @11:54PM
Right now it's only Rust and C/C++. Hopefully they'll add support for more languages in the near future. I can't wait for it to support JavaScript so I can node.js it like a boss.
(Score: 2) by DannyB on Wednesday April 03 2019, @02:56PM
The real flaw here was NOT having a good, cross compatible JavaScript with the ability to draw good snappy interfaces and graphics. Something that modern browsers have fixed. If browsers had this from the start, there would not have been any (real or perceived) need for ActiveX, Java, Flash or Silverlight.
ActiveX -- everyone said this was flawed from the beginning. It allowed executing native code on a Windows machine. The server would deliver a native code blob to the browser and ActiveX would execute it. Oh, but it is digitally signed! -- protested Microsoft. So nobody would use it for malware -- because you can see who signed it. Of course that doesn't mean anything when anybody can get a code signing certificate and the malware signers are simply a drop in the ocean. If depending on code signing is your security model then you're
doing it wrongMicrosoft. But this is the company that created the nightmare of executable emails -- without even reading them first.Java Applets -- seemed good: sandboxed, or required code signing (see previous) to escape sandbox. Because it could interact with JavaScript, the malware could be hidden in JavaScript which merely used a Java Applet to do native operations (read / save files, etc).
Flash -- if all it were allowed to do was draw fancy accelerated graphics and create UIs for the user it would have been, just OK. (Because many browsers on some OSes didn't have Flash making Flash sites only work on the mostly Windows part of the web).
Silverlight -- Microsoft's attempt to take over Flash and make it Windows only. When it was introduced, it was clearly already too late. Clear to some at least, including me.
Every performance optimization is a grate wait lifted from my shoulders.
(Score: 2) by Bot on Thursday April 04 2019, @12:20PM
I agree, this is a binary software package infrastructure, so it should behave like one, explicit execution and digitally signed. What will happen instead is, "you download minified js already, stfu and exec this too).
OTOH if they ported something like picolisp to webassembly so it could run with DOM access and js interoperability it would be fun.
Account abandoned.