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: 5, Insightful) by SomeGuy on Tuesday April 02 2019, @08:42PM (13 children)

    by SomeGuy (5632) on Tuesday April 02 2019, @08:42PM (#823771)

    allowing developers to bring existing desktop applications to the web.

    Are we still beating this dead horse? It has been shown over and over and over again that desktop applications stuffed in to a freaking web browser are SHIT. Faster? Great, the UI will still be wonky half-assed shit, it will conk out at every little network hiccup, and it brings back that old mainframe time-shared badness.

    Oh, but vendors love this shit because instead of making a single software purchase, now they can keep you on a subscription for your entire life.

    Starting Score:    1  point
    Moderation   +3  
       Redundant=1, Insightful=4, Total=5
    Extra 'Insightful' Modifier   0  
    Karma-Bonus Modifier   +1  

    Total Score:   5  
  • (Score: 0) by Anonymous Coward on Tuesday April 02 2019, @08:53PM (1 child)

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

    It is amusing that this is what will drive the adoption of open hardware / software. "Suckers, I OWN my phone!"

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

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

      do you have root access to your phone?
      if they answer is no then you do not own your phone.
      you may have paid for the hardware and you might be a user of your phone but it belongs to whomever controls the OS

  • (Score: 5, Interesting) by arslan on Tuesday April 02 2019, @10:07PM (3 children)

    by arslan (3462) on Tuesday April 02 2019, @10:07PM (#823815)

    Us geeks may agree, and there's lots of technical reasons for it. Unfortunately, the masses disagree and the proof is in the pudding. Desktop apps provide a much poorer experience than web apps.

    Here's some of the stuff that desktop apps suffers from from a UX perspective:

    • You can't "link" from one desktop app to another seamlessly. No switching between content apps (word/excel) and functional apps (email)
    • You need to go through "install" phase with many needing a "wizard" which shows how complicated it is. And then you need to "uninstall" (Technically web apps "install" in the browser cache, but from a UX perspective it is not visible)
    • You get your access regardless of which device as long as the browser is supported, in stateful webapps you can even continue where you left off when you switch devices. In our age of waste and consumerism this is unfortunately very appealing for non-techies which represent the masses.

    There's probably a bunch of other factors.

    Now I see lots of whinging about why we need to move apps back to desktop but yet no actual desktop apps that addresses the UX factors that causes the web apps to take off..

    • (Score: 2) by deimtee on Wednesday April 03 2019, @03:14AM

      by deimtee (3272) on Wednesday April 03 2019, @03:14AM (#823941) Journal

      You get your access regardless of which device as long as the browser is supported, in stateful webapps you can even continue where you left off when you switch devices.

      This is the important one. I don't have any devices/apps that do this unless I sync them myself because I don't like the privacy implications, but I can see how useful it is to people I know who do have them. Ongoing messaging that follows from laptop to desktop to phone and back again. Reading/playing anything on any device and it automatically picks up where you left off, no matter which device you use. Look up somewhere on the desktop and the map and route is automagically on your phone.
      Yeah, that level of integration would be sweet. Shame you can't do it without dropping your pants for google/facebook/microsoft/apple.

      --
      If you cough while drinking cheap red wine it really cleans out your sinuses.
    • (Score: 0) by Anonymous Coward on Wednesday April 03 2019, @05:16AM

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

      you make some good points
      I look forward to the day when all Ubuntu apps are 'snap' packages
      perhaps the year of the linux desktop is not as far off as we thought

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

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

      jami [jami.net] addresses some of this stuff, in a way, at least. you create your app account and it is published to the etherium blockchain. you can hop from one device to another using your same account. you can find other users via opendht and the eth blockchain. it's not released as a flatpak or appimage (even more windowzy and simpler) yet, i don't think. For distros with a binary package for it it's super simple.

  • (Score: 1, Informative) by Anonymous Coward on Wednesday April 03 2019, @05:06AM

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

    or get turned back into shit

    look at gmail

    it was awesome as a replacement for pop or imap email fricking awesome

    then after a few years google decided to screw with the interface making it crap

    what can you do

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

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

    vendors love this shit because instead of making a single software purchase, now they can keep you on a subscription for your entire life.

    The application I develop was available in two modes. Hosted in the cloud. Available to be installed on the customer equipment. (let me stroke myself for a moment about that capability. It was an accomplishment. A single SETUP.EXE. Next, I Agree, Next, Next, (pause), Finish. Server is up and running with no reboot. Connect to web based control panel and configure database connection. App is then running. Ah . . . I feel better now.)

    Surprise: market demand. Despite that it costs more to have it hosted by us, where we take care of backups and all upgrades are automatic -- customers overwhelmingly voted for that with their wallets and budgets.

    Are we still beating this dead horse?

    Let me tell you a few advantages of a Web Application. Even if you host it in house within your own organization on your own servers. (Which as I mention in previous paragraph doesn't seem the popular option. Except when IT is wanting to extend its fiefdom.)

    1. Web apps are Zero Install.

    This is a big thing. Back in the 80's and 90's, and early 2000s, our apps were desktop applications. You run a SETUP.EXE on every workstation. When there is a software upgrade, IT generally has to go run the SETUP.EXE on every workstation -- despite that it is designed to be so simple that the end user ought to be able to do it. They don't. Or won't. Or maybe just can't.

    Or by the 2000s, more sophisticated customers might manage this centrally by grope policy.

    2. Web apps are Zero Maintenance.

    With a web app, you may never have to visit workstations, or use grope policy to distribute software upgrades. But, software updates still happen. Maybe state or federal mandated changes. New features. Etc.

    If you are hosting it in the clone, you don't even deal with maintenance. You come in Monday morning, and the previously announced new version is just there as promised. As easy as an upgrade to Gmail. You do nothing. It just happens.

    Obviously customers have made it clear that the costs of Software As A Service are worth it -- at least to them. It's always there. It always works. Help is a phone call away with knowledgeable staff in the US. Our support is well regarded in our particular business, and we use NPS scores. Support is part of the appeal of or products.

    3. You don't have problems with the Technology

    In the olden days, when apps were desktop apps, many support calls were not about the application (how do I set up this particular payroll situation?) but about the technology: Jane Can't Print!

    Support people have to deal, to some degree, with the customer's IT, and whatever equipment they use. Etc.

    With a web based app, printed pages materialize as a downloaded PDF as soon as you click the Start Report button. Even printed forms, like tax forms, checks, etc. And the text ALWAYS hits the boxes on the printed paper form -- EVERY TIME -- no matter what kind of printer the end user is using. Which is great for me the developer.

    4. Platform and OS are not an issue

    Back in the day, our system was on Mac Classic and Windows. Needless to say, being the only one on Mac made us king of the hill there, in the 80's and early 90's. But by the mid 90s we were Windows only.

    It was always my ambition to not be beholden to Microsoft. Web apps just need a browser. I don't ware what OS the end user has. Even an iPad will do.

    In summary

    Commercial web applications are going to the web for a reason. Not only do the vendors and developers love it, the customers do as well. No customers want to go back to desktop apps. Everything just works. It is a reality.

    Web apps are here to stay.

    We finally have the non-monopolist controlled application execution platform and it is the web browser. Now I only hope Google doesn't end up monopolizing it.

    --
    People today are educated enough to repeat what they are taught but not to question what they are taught.
    • (Score: 1, Interesting) by Anonymous Coward on Wednesday April 03 2019, @06:20PM (3 children)

      by Anonymous Coward on Wednesday April 03 2019, @06:20PM (#824183)

      Sure, except the masters control the registrar, dns system and can exert pressure on the centralized datacenters. I'm rethinking desktop apps because of these factors. I want enemy/parasite proof applications. Decentralized, anonymizing, etc. This wasi might be the way forward.

      • (Score: 2) by DannyB on Wednesday April 03 2019, @08:50PM (2 children)

        by DannyB (5839) Subscriber Badge on Wednesday April 03 2019, @08:50PM (#824237) Journal

        There may be applications where what you describe is important.

        I don't see most commercial applications that way.

        One vendor is happy to take our money for domain names. Another vendor is happy to take our money for TLS certificates.

        As for enemies / parasites, there are things you do. Progressively limit failed login attempts. Especially if from an IP range not normally used by that user. Keep your attack surface area small as possible.

        --
        People today are educated enough to repeat what they are taught but not to question what they are taught.
        • (Score: 2) by Pino P on Thursday April 04 2019, @03:46PM (1 child)

          by Pino P (4721) on Thursday April 04 2019, @03:46PM (#824531) Journal

          One vendor is happy to take our money for domain names.

          I think AC's point is that external actors, be they state actors or competitors, will pressure that vendor to stop taking your money.

          • (Score: 2) by DannyB on Thursday April 04 2019, @04:18PM

            by DannyB (5839) Subscriber Badge on Thursday April 04 2019, @04:18PM (#824563) Journal

            I see your point there. If we could be independent of IP addresses and domain names, we would.

            Heaven knows I made a big effort to be completely Microsoft free in my particular product.

            As for competitors playing that way: two can play that game. Or there may be other legal remedies, tortious interference with business, etc. That is not my direct concern. The technical matters are.

            I don't see any reason we would be of interest to state actors.

            Someone pressuring a vendor to stop taking our money would have to be able to effectively pressure ALL of them. There are competitors.

            At this point, this speculation seems to be getting really off into the weeds.

            --
            People today are educated enough to repeat what they are taught but not to question what they are taught.
    • (Score: 0) by Anonymous Coward on Sunday April 07 2019, @04:57AM

      by Anonymous Coward on Sunday April 07 2019, @04:57AM (#825653)

      1: People seem to have gotten used to "apps" and "app stores". These usually update automatically.
      2: Yea, zero maintenance until some dickhead web developer forces you to change to a different browser, throw out your entire machine, or breaks functionality with no way to keep running the "old" versions that worked.
      3: The last time I checked, Adobe Acrobat Reader was still a desktop application and printers still required drivers. Most web applications don't even allow for printing (print a script-infested HTML page and get garbage).
      4: As long as the OS is Windows 7/10, the latest MacOS, or the latest Linux and all of the latest malware/misfeature updates. Apparently nothing else exists. Ok, congrats on at least not being Windows only.

      In summary, there is a lot of stuff desktop applications can do that that a web application can not. Web stuff has its use, but some things will always need a desktop application, at least if you want to do it the non-insane way.