Please create an account to participate in the Slashdot moderation system

 


Forgot your password?
Close
typodupeerror
×
The Internet

W3C Recommends WebAssembly To Push the Limits For Speed, Efficiency and Responsiveness (w3.org) 128

Posted by msmash from the moving-forward dept.
The WebAssembly Working Group has published today the three WebAssembly specifications as W3C Recommendations, marking the arrival of a new language for the Web which allows code to run in the browser. From a report: WebAssembly Core Specification defines a low-level virtual machine which closely mimicks the functionality of many microprocessors upon which it is run. Either through Just-In-Time compilation or interpretation, the WebAssembly engine can perform at nearly the speed of code compiled for a native platform. A .wasm resource is analogous to a Java .class file in that it contains static data and code segments which operate over that static data. Unlike Java, WebAssembly is typically produced as a compilation target from other programming languages like C/C++ and Rust.

WebAssembly Web API defines a Promise-based interface for requesting and executing a .wasm resource. The structure of a .wasm resource is optimized to allow execution to begin before the entire resource has been retrieved, which further enhances responsiveness of WebAssembly applications.

WebAssembly JavaScript Interface provides a JavaScript API for invoking and passing parameters to WebAssembly functions. In Web browsers, WebAssembly's interactions with the host environment are all managed through JavaScript, which means that WebAssembly relies on JavaScript's highly-engineered security model.
This discussion has been archived. No new comments can be posted.

W3C Recommends WebAssembly To Push the Limits For Speed, Efficiency and Responsiveness More

W3C Recommends WebAssembly To Push the Limits For Speed, Efficiency and Responsiveness

Comments Filter:

  • Security (Score:4, Funny)

    by WoodstockJeff ( 568111 ) on Friday December 06, 2019 @12:32PM (#59491786) Homepage

    In Web browsers, WebAssembly's interactions with the host environment are all managed through JavaScript, which means that WebAssembly relies on JavaScript's highly-engineered security model.

    So, it has no security to speak of.

    • Re:Security (Score:5, Insightful)

      by jellomizer ( 103300 ) on Friday December 06, 2019 @12:55PM (#59491918)

      Actually it is rather good for what it is. If you think about how many millions/billions of people are running Javascript code and how little actual hacks come from pure Javascript.

      Where the problems really come from, are plugins, and old ActiveX controls.

      If I am going to try to get into a system, I am not going in via pure Javascript.
      However JS does sometimes have problems around cross site communication and keeping information that is used for tracking which is a problem. But that is a bit different.

      • We just don't see it. We think it is normal that the browser is a huge slow resource hog.

        No need to hack the system when you csn already do all you like. Need some credentials? Secrets? Home address? Just ask the user. They will happily provide it for you.

        • Re: (Score:2)

          by tepples ( 727027 )

          Need some credentials? Secrets? Home address? Just ask the user. They will happily provide it for you.

          And this would be little different if instead of visiting a website, people expected to have to download and run a native, OS-specific executable to view each Internet service.

    • Re: (Score:2)

      by Dunbal ( 464142 ) *
      what could possibly go wrong

  • Layered layers on layers of layers (Score:4, Funny)

    by TechyImmigrant ( 175943 ) on Friday December 06, 2019 @12:36PM (#59491806) Homepage Journal

    Call me old school, but I find peace of mind by compiling my code to machine code with a compiler and running it on the CPU by directing the OS to load it into memory and point the program counter at it.

    • Why "directing the OS"? The OS is just another layer. So you have layer upon layers.

      • Sometimes I don't like when I'm messing with little microcontrollers or injecting code into a memory with a debugger port on a new, flakey CPU.

        But most of the time most of my programming is done with the help of an OS and I'm fine with that. The program ends up in memory and the CPU runs it directly by fetching instructions and changing state in response. A mentally tractable model of execution and causality in program flow.

      • Why "directing the OS"? The OS is just another layer. So you have layer upon layers.

        That's why the only form if input or storage on *my* system is sixteen toggle switches and a couple of pushbuttons. I took me three months to key in the Lynx browser, but now I'm up and running like a champ.

      • Are you stupid, or what?

        It's not the layers. It's when you do the same fucking thing twice over!
        It's called the "inner-platform effect". A software design anti-pattern. It pops up, whenever you design something to be so flexible, that it becomes a shitty limited version of the layer below.

        Nothing that browsers do can't be done with a CLI that only eats URLs, pure TCP/IP, and any full VM with access to the same hardware functionality and the same libaries rhe browser uses in the background.

        • This, this, this, all day long, this. Couldn't be better said.

        • Re: (Score:2)

          by tepples ( 727027 )

          Without an inner platform, how do you design an application to work on multiple competing, mutually incompatible platforms? Publishing an application as a macOS executable, for example, won't win you any users who don't already run macOS.

      • Re: (Score:2)

        by Shotgun ( 30919 )

        You yung-uns and yer new fangled operating systems. Why in my day, eight switches were good enough for anyone. AND WE LIKED IT!!

    • Well Mr Old School. That is all fine and good, until the fact that most programs today will be expected to be running on vastly different architecture systems, and accessing OS/Browser particular components (all in a slightly different way).

      • Re: (Score:2)

        by dfghjk ( 711126 )

        Since when?

      • The argument that web apps are inherently more portable is BS in practice. Nobody conforms to standards so everything is written to a target browser. You're just shifting the same problem somewhere else. This means everyone has multiple browsers they must have installed. All of which have their own quirks , foot prints and security holes. At my employer, users have three browsers IE to access one vendor system, Firefox to access another and Chrome for everything else. This is mandatory as the vendors only s

        • Re: (Score:2)

          by Merk42 ( 1906718 )
          I write all my stuff to standards, those 3 apps seem pretty poorly written.
          I could see IE if it's some really old dot-com-bubble era system, and Chrome for super bleeding edge, not that it excuses either. I've never even heard of one that only supports Firefox.

        • The argument that web apps are inherently more portable is BS in practice. Nobody conforms to standards so everything is written to a target browser.

          Nope.

          IE6 is dead...

    • Sockets with ports with protocols with ports with protocols with WebSockets.

      Anyone who thinks that is acceptable, is a textbook example of a retard. Not a mentally disabled person. A retard. And I'm not sorry and not saying no offense. Fuck those people. Actually, they *don't* even think. Just believe. Otherwise they would have realized it, about 5-20 seconds in.

    • Agreed. Simplicity and the ability to hold large chunks of the system in your head are key, and you lose that with the more layers you have duplicating each other.

    • Re: (Score:2)

      by Dracos ( 107777 )

      Layers is not the problem. Reflexively piling everything into the Javascript basket is ludicrous.

      Just give us a Python or Lua interpreter in the browser so we can use a better language from the start.

    • Re: (Score:2)

      by GrahamJ ( 241784 )

      Good luck convincing anyone else to run it on their CPUs.

      • Plenty of people do. They download it from my github repos and compile it.

        • Re: (Score:2)

          by tepples ( 727027 )

          I'm interested how you manage to get many users of Windows, Android, or iOS to install a compiler in order to build your application from source code.

          • I'm not.
            Those that care about the code I write already know how to do those things.
            I test it on Linux with GCC, Windows with MinGW and Visual Studio and MacOS with clang.

            Android and iOS are hardly the optimal platforms to run computationally heavy CLI applications.

    • Is your computer from 1996?

      • Is your computer from 1996?

        It's in a venerable line of computers that dates back way before 1996.

      • Re: (Score:2)

        by tepples ( 727027 )

        Is your computer from 1996?

        Even earlier. Nintendo's Family Computer is from 1983, and I have been paid to develop applications for it.

    • Sure, but which CPU are you compiling for?

      The x86 that most people run, or the ARM ones or ... well, who knows.

      that's why javascript is popular, to download the source and let the browser compile it for whatever CPU its running on. Then the browser points the program counter at the code and runs it.

      • >The x86 that most people run, or the ARM ones or ... well, who knows.

        It doesn't seem matter. You can gcc/clang your way to compiling normal C on any of those platforms and the same code will generally work fine.

        • Re: (Score:2)

          by tepples ( 727027 )

          Apple's anti-JIT policy forbids third-party compilers without first bouncing the executable onto a Mac to be signed with the user's Apple ID.

          • Indeed. So why no run it on the mac where you have a keyboard, a compiler, a shell and a filesystem that makes sense.

            • Re: (Score:2)

              by tepples ( 727027 )

              Because a lot of people with money expect to get (what they think are) simple things done on the go without having to carry around a keyboard and a larger than pocket-size display.

              • That's a use case that doesn't overlap with the application domain of my published programs. Entropy analysis, file format conversion, generation of controlled defect random numbers, things like that. Not something I would try on a phone. Just getting the data files on the phone would be a pain. Getting the results into a program like JMP for visualization would entail pulling it back off the phone.

                Phones are great for many things. But not the things I write code for.

    • Call me old school, but I find peace of mind by compiling my code to machine code with a compiler and running it on the CPU by directing the OS to load it into memory and point the program counter at it.

      Same here, I still use RANDOMIZE USR 32768

      • Call me old school, but I find peace of mind by compiling my code to machine code with a compiler and running it on the CPU by directing the OS to load it into memory and point the program counter at it.

        Same here, I still use RANDOMIZE USR 32768

        Seeding the RNG to avoid a side effect suggests that functional programming might appeal to you.

  • Great (Score:3)

    by ArchieBunker ( 132337 ) on Friday December 06, 2019 @12:44PM (#59491858)

    What can possibly go wrong with this scheme?

    • Re:Great (Score:4, Informative)

      by bluefoxlucid ( 723572 ) on Friday December 06, 2019 @12:48PM (#59491876) Homepage Journal
      Cryptomining becomes faster and less detectable because it chews less of your browser-driven CPU?
    • Disaster = Scheme.result

    • Faster than JS versions of everything already being done with JS. Sounds fine with me...

      UNTIL some persistent idiots creep features past the sane people so then we have API access to devices like USB, files, the OS etc. So we can save battery and speed up performance due to the high volume of user complaints....Actually, caused by tracking, marketing bloat, and multiple legacy frameworks all which use every resource you have free regardless how much you optimize.

    • Re: (Score:2)

      by Hentes ( 2461350 )

      I'm actually quite optimistic about WebAssembly. I don't think it's possible to stop the software world becoming entirely web-based, but with WebAssembly there's a chance that at least it won't be entirely Javascript-based.

      • It's cool as hell.
        I'm a guilty perl junky, and WebPerl (a perl interpreter compiled via emscripten) is a thing... So I can write client-side code in Perl.
        Which also means... when the ecosystem is fully developed- you'll be able to write it in... anything.
  • Comment removed based on user account deletion

    • Re: (Score:2)

      by Dunbal ( 464142 ) *
      Everything old is new again. It's like the human race is incapable of learning.

    • There's a translation layer between the stuff that rolls in, and the code that is executed.

    • Why would you need to check things out? Everything runs on HTTTPS now so it's all safe thanks to Google pushing for for it! /s

      • Comment removed based on user account deletion

      • HTTPS only insures that the connection between you and the site is secure. It does nothing to verify that the code on the site wasn't compromised or that the site isn't intentionally malicious. HTTPS doesn't make Facebook safer since the main group preying on Facebook users is Facebook.

    • this is just creating a bytecode spec so you don't have to compile from javascript and can compile outside the browser.

    • Re: (Score:2)

      by sosume ( 680416 )

      This is inside the web browser tab. The Javascript interpreter is used to execute this pseudo-assembly by directly manipulating the registers of the VM it's running in. So relax, nobody will take over your computer and nothing will be done which isn't already possible. You're still able to break execution and inspect what's happening.

      • Re: (Score:2)

        by tepples ( 727027 )

        This is inside the web browser tab.

        JS haters: "But I don't want any third-party code running in a web browser tab, especially not code specifically designed to leak my browser history to six dozen different surveillance organizations."

        The Javascript interpreter is used to execute this pseudo-assembly by directly manipulating the registers of the VM it's running in.

        Until a VM escape vulnerability is discovered in Chromium.

  • And only enable it, as needed, determined on a site by site basis.

    Honestly, despite what the proponents claim - I expect this is going to be all about making advertisements even more annoying and intrusive.

    • In that they can do the same things with JS. Including hacking your Intel CPU. Except slower.

      • While obfuscated JavaScript does make it harder, generally you can at least look at JavaScript and figure out what it’s doing - and most JavaScript out there isn’t obfuscated.

        • Eh. I'm a pretty accomplished reverse engineer.
          High-level code is easy to obfuscate to the point of being nearly impossible to figure out what the fuck it does. Javascript particularly. You can make that shit look like Brainfuck.

          Now assembly can also be obfuscated, of course... but that requires deep wizardry. Deep wizardry lacking from the skillset of 99.999% of people of people who can write code.
          And unless your deep wizardry extends to understanding how your high level code is compiled into assembly,

  • ... from the Internet in a mehdiocre VM?

    It's not giving any more security than competent kernel. Any useful amount of instruction firewalling would make it too slow. It's a fallacy.

    I wish browsers were just VMs with URL bars and pre-cached OS snapshots.
    One of them would be HTML5.
    A minimal Linux desktop with OpenGL & co would be another one.

    Then we could just do away with all this inner-platform effect insanity business, that has been the other hallmark of browser makers since they broke free from their

    • Because a binary in a VM would control everything you do with the browser, including snooping on your bank transactions in another tab.

      • Re: (Score:2)

        by HiThere ( 15173 )

        I think he just doesn't trust "webassembly" at all. Neither do I. Even if the specs turn out to be tight, you've got problems at the implementation layer, and I don't assume the specs will be good.

        OTOH, I keep JavaScript turned off most of the time. So I'm an outlier.

        • then I get it... but WebAssembly should make things more secure than javascript.

          • not really, just differently insecure. The problems will be there, maybe callable from javascript now, maybe new holes to exploit that weren't there before.

            The best bit is that webassembly breaks CSP (as it compiles to some "inline" style of coding, you cannot enable CSP with webassembly), so actually as of today, webassembly is way less secure than javascript.

            • At the moment. In general, there is reason to believe it'll be easier to police a fixed instruction set easier than a whole language compiled by the browser, and that will work whatever the original language.

  • I'm not really desiring of a huge performance increase in my browser.

    I mean really why should I be more interested in having advertisements make a mess of my browsing session that much faster?

    To wit, to be honest, I kinda like for my browser to be kinda slow, it slows down the speed at which the blocking advert windows can pop up over the content I actually desire to view.

    • I kinda like for my browser to be kinda slow

      Just press your Turbo button ?

    • would like to differ with you. Also, people doing that, that don't want to do it in Javascript would really like to differ with you instead of compiling to Javascript source code.

      • Re: (Score:2)

        by tepples ( 727027 )

        Then don't use a browser as a front end. Instead ship source code for the front end that the user can inspect, compile, and internally deploy.

        And please don't start a sentence in the subject and finish it with a fragment in the comment.

        • ... starting the sentence in the subject and completing it in the body. I find it calming and connective. Then don't use a browser as a front end. Instead ship source code for the front end that the user can inspect, compile, and internally deploy. I did this for decades. It's a pain to make things run on every possible client platform. And a waste of time when there is a universal container available and already deployed for the last 15 years. Also, a choice of said compatible containers. But I don'

          • Re: (Score:2)

            by tepples ( 727027 )

            I find it calming and connective.

            And other users find the style difficult to quote when replying to you.

            I don't understand what you mean by "that the users can inspect"... nothing about shipping native client software means they'll be able to see the source code.

            It does to people who treat source code unavailability as a disqualifying factor when procuring software, who appear to be at least a large fraction of Slashdot's user base.

            EXCEPT, you can always inspect javascript right now

            The GNU GPL has defined source code as "the preferred form of the work for making modifications to it" for decades. What you see much of the time nowadays when you inspect a popular website's public JavaScript code is minified, and minified code is not source code by

            • You can refuse to go to a website that doesn't publish it's source code if you want. There is nothing about -native apps- that are inherently more able to share source code (in fact if anything, it'd be the opposite). The point is... the browser is a useful container, very powerful, and super widely distributed. If you want to demand source before you use software running in your browser... it would STILL be easier to distribute through the browser than a billion native software repos. btw, I myself dis

              • Re: (Score:2)

                by tepples ( 727027 )

                You can refuse to go to a website that doesn't publish it's source code if you want.

                And there are extensions for that, such as LibreJS for Firefox. But it doesn't help when the website of a government or a public utility requires running proprietary script in order to work as advertised.

  • wasm hash IDs - metadata to ID a resource.
    Use Case:
    global caching. Browser managed common libraries pulled from a trusted source instead of the site itself. Now, we have privacy "free" hosting by google for web-fonts etc. and soon we likely will have runtimes for java (perl already has been ported) and instead of relying upon a URL to some CMS with nefarious motives, we can also indicate a hash ID so it's only downloaded and hashed once for any site that uses that resource.

    Bloated runtimes for languages wil

  • If you didn't cram a whole bunch of bullshit on a page.

  • Speed and efficiency? No, control (Score:4, Insightful)

    by peppepz ( 1311345 ) on Friday December 06, 2019 @02:06PM (#59492334)
    Remember when AJAX was introduced? It was supposed to speed up internet navigation by eliminating full-page reloads. It ended up turning HTML pages into buggy, inaccessible, unusable, gargantuan applications that result in fact slower than the dumb pages of old. Try disabling Javascript in your browser if you don't believe me.
    I say that WebAsm isn't about speed, efficiency and responsiveness: it's big tech companies pushing onto web users a model of development and engagement that they find interesting.
    The DNA of web but also of many web-related technologies could be traced in openness, interoperation, use of commodity protocols. This is why they prevailed, again and again, against the more closed and more business-friendly alternatives that were pushed by hardware manufacturers, software houses, and telecom companies: UNIX vs MULTICS, connectionless vs connection-oriented, TCP/IP vs OSI, Linux vs Solaris, the WWW vs The Microsoft Network.
    HTML allowed you to access information freely, no matter what hardware you were using: your experience would degrade gracefully with the limitations of your hardware and user agent. Compare that with WebAssembly, where the web is only accessible to you as long as Google bothers developing a JIT compiler for the processor architecture of your device.
    Sorry about this long rant, I'm starting to feel really old lately :-P .

    • Re: (Score:2, Insightful)

      by Waccoon ( 1186667 )

      I was recently redirected to Pintrest, only to find out the site does not load under Palemoon. All I get is a completely blank page. Looking at the page source, it is literally just a shitload of stuff in a script tag and no content in the body whatsoever. This "blank page" nonsense has been going on with various versions of Firefox for years, let alone Firefox forks.

      I can't wait for WebAssembly to take over, so now we have the privilege of going through this same farce, but with binary code instead of p

  • ...creating solutions for missing problems, why not spending some time to make the native UI elements a little richer ?

    In 2019, we are still piling tons of JS layers/frameworks/libraries/hacks to implement basic layout, searchable combos or simple tables with static headers/columns, to name just a few common brain teasers...

    Making this shit faster and more obfuscaded is surely the best way to improve the situation, good job folks.

  • ActiveX 2.0 already?

  • You can make one of three work well

    1. Modular

    2. Streamable

    3. Paralleliseable

    You can have your cake and eat it too !
    NOT

Slashdot Top Deals

This is the theory that Jack built. This is the flaw that lay in the theory that Jack built. This is the palpable verbal haze that hid the flaw that lay in...

Close