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: 2) by DannyB on Wednesday April 03 2019, @08:45PM (2 children)
No JavaScript also? Or just no ajax?
Without ajax you can still use JS to have a significantly better interactive experience. Tabbed panels. Sections that can show and hide. (Yes, I know that today some of this can be pure CSS.) Enabling / Disabling some controls or panels based on the state of other controls. Popup dialogs in browser (done with pure html / css / js).
With ajax: grids that can page through groups of rows without refreshing the entire page.
Autocomplete fields. As you begin typing into a certain field, it can suggest autocomplete possibilities much like Google does.
The lower I set my standards the more accomplishments I have.
(Score: 2) by Pino P on Thursday April 04 2019, @03:23PM (1 child)
What we can do in pure CSS and HTML5 forms we do in pure CSS and HTML5 forms. What we cannot we do our best to design out of the design.
If users want "Popup dialogs in browser", then why do web browsers have a pop-up blocker?
From a JavaScript abstainer's point of view, having to refresh the entire page in order to make any view changes that pure CSS alone cannot make is an acceptable tradeoff for the abuses that adtech has made of JavaScript in the past and looks to make of WebAssembly in the near future. Instead, we engineer to make "refreshing the entire page" painless by caching subresources.
(Score: 2) by DannyB on Thursday April 04 2019, @04:12PM
When speaking as a commercial web developer:
Adtech is irrelevant. We don't run ads in our commercial product.
JS malware is irrelevant. We don't run any malware in our end users' browser. It's strictly business. They are paying for our product to do something faster, easier, more efficiently, and cheaper than they could do it any other way. That is what comes above all else, including abstaining from JS.
Popup blockers are irrelevant. We don't open popup windows. When I said pop up dialogs, I mean it looks like a popup dialog, but is purely markup within the page. The dialog or window may be movable and resizable, but it is pure HTML, CSS and JS within the page. No popup window was used. No native browser dialogs were used.
Sometimes modal dialogs make sense in a UI to bring up an error message, or momentarily expand upon something the user wants to see. Or to fill in some details about something that the dialog then collapses back down into.
Are you a JavaScript abstainer as a commercial web application developer? I would think those are almost mutually exclusive these days.
The lower I set my standards the more accomplishments I have.