Stories
Slash Boxes
Comments

SoylentNews is people

posted by martyb on Tuesday April 02 2019, @08:04PM   Printer-friendly
from the java++ dept.

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.”


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: 4, Insightful) by Anonymous Coward on Tuesday April 02 2019, @08:30PM (17 children)

    by Anonymous Coward on Tuesday April 02 2019, @08:30PM (#823766)

    No, it needs to have a wooden stake driven DEEPLY into it's heart.

    "Javascript" should never have been allowed to exist.

    Starting Score:    0  points
    Moderation   +4  
       Flamebait=1, Insightful=5, Total=6
    Extra 'Insightful' Modifier   0  

    Total Score:   4  
  • (Score: 2) by bob_super on Tuesday April 02 2019, @08:42PM (2 children)

    by bob_super (1357) on Tuesday April 02 2019, @08:42PM (#823770)

    javascript is how we broke out of HTML restrictions and opened up the door to such wonderful experiences as Facebook, Twitter, disqus, 4chan, Gab ...

    I'm low on wooden stakes, how about nuking from orbit with a side of spreading Ebola ?

    • (Score: 0) by Anonymous Coward on Wednesday April 03 2019, @12:38AM

      by Anonymous Coward on Wednesday April 03 2019, @12:38AM (#823875)

      javascript is how we broke out of HTML restrictions and opened up the door to such wonderful experiences as Facebook, Twitter, disqus, 4chan, Gab ...

      The web is great if cheap borked content is not a show-stopper. But for business GUI's meant for real work, it's a buggy time-drain.

    • (Score: 2) by DannyB on Wednesday April 03 2019, @02:42PM

      by DannyB (5839) Subscriber Badge on Wednesday April 03 2019, @02:42PM (#824094) Journal

      Please not to forget the final T in disqust.

      --
      The lower I set my standards the more accomplishments I have.
  • (Score: 4, Insightful) by Anonymous Coward on Tuesday April 02 2019, @08:44PM (5 children)

    by Anonymous Coward on Tuesday April 02 2019, @08:44PM (#823773)

    It's not just Javascript. This jumped out at me:

    WebAssembly executables are compiled before being delivered to browsers,

    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

      by Anonymous Coward on Tuesday April 02 2019, @08:48PM (#823777)

      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)

      by arslan (3462) on Tuesday April 02 2019, @09:50PM (#823805)

      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

        by Anonymous Coward on Tuesday April 02 2019, @11:54PM (#823862)

        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

      by DannyB (5839) Subscriber Badge on Wednesday April 03 2019, @02:56PM (#824101) Journal

      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 wrong Microsoft. 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.

      --
      The lower I set my standards the more accomplishments I have.
    • (Score: 2) by Bot on Thursday April 04 2019, @12:20PM

      by Bot (3902) on Thursday April 04 2019, @12:20PM (#824438) Journal

      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.
  • (Score: 2, Insightful) by Anonymous Coward on Tuesday April 02 2019, @09:54PM (6 children)

    by Anonymous Coward on Tuesday April 02 2019, @09:54PM (#823807)

    Amen Cubed! We need a GUI-friendly web standard. Trying to get HTML/CSS/DOM/JS to act like a normal desktop has repeatedly failed. New browser versions come out and the JS libraries flub up. The more desktop-like one makes it, the bigger the libraries, meaning more bugs and version dependencies.

    They had 2.5 decades to get it right and failed failed failed. GivvitupAlready. I'm sick and tired of diddling with web sh&t to get common familiar and true-and-tried GUI idioms that have been around longer than my kids. Yuuuge waste of time and money.

    • (Score: 0) by Anonymous Coward on Wednesday April 03 2019, @05:58AM (3 children)

      by Anonymous Coward on Wednesday April 03 2019, @05:58AM (#823982)

      Not to discuss any point but out of curiosity: why did You write 2.5 decades, when "25 years" is shorter, more understandable, conveys the same information and does not require a decimal?

      • (Score: 0) by Anonymous Coward on Wednesday April 03 2019, @07:36AM

        by Anonymous Coward on Wednesday April 03 2019, @07:36AM (#824004)

        He did because as everyone knows a float is so much more efficient than integers!

      • (Score: 0) by Anonymous Coward on Wednesday April 03 2019, @07:56AM (1 child)

        by Anonymous Coward on Wednesday April 03 2019, @07:56AM (#824007)

        Because greybeards who rant against JavaScript are mentally unstable.

        • (Score: 0) by Anonymous Coward on Thursday April 04 2019, @12:33PM

          by Anonymous Coward on Thursday April 04 2019, @12:33PM (#824451)

          Are you implying the rest of the human race is mentally stable?

    • (Score: 2, Insightful) by pTamok on Wednesday April 03 2019, @07:15AM

      by pTamok (3042) on Wednesday April 03 2019, @07:15AM (#824003)

      We need a GUI-friendly web standard.

      If only there were some existing standard that could be built upon or re-engineered that gives a standard transport mechanism for GUI elements across a network.

    • (Score: 2) by DannyB on Wednesday April 03 2019, @05:54PM

      by DannyB (5839) Subscriber Badge on Wednesday April 03 2019, @05:54PM (#824172) Journal

      Web apps are not desktop apps. They don't exactly the same UI.

      But millions of workers use thousands of commercial web apps every single day.

      --
      The lower I set my standards the more accomplishments I have.
  • (Score: 0) by Anonymous Coward on Wednesday April 03 2019, @12:44PM

    by Anonymous Coward on Wednesday April 03 2019, @12:44PM (#824047)

    And "web apps" should die, they should be called "websites". The more complex it is, the more it ties you to a subscription or vendor lock-in when no one else or nothing else supports it.

    who cares if the code runs; i want to know if it will demand payment.