I’ve been wondering about this for a while and haven’t really found a great answer for it. From what I understand, WASM is:

  • Faster than JavaScript

  • Has a smaller file size

  • Can be compiled to from pretty much any programming language

  • Can be used outside of the browser easier thanks to WASI

So why aren’t most websites starting to try replacing (most) JS with WASM now that it’s supported by every major browser? The most compelling argument I heard is that WASM can’t manipulate the DOM and a lot of people don’t want to deal with gluing JS code to it, but aside from that, is there something I’m missing?

  • bignavy@programming.devEnglish
    6·
    1 year ago

    The most compelling argument I heard is that WASM can’t manipulate the DOM and a lot of people don’t want to deal with gluing JS code to it, but aside from that

    But other than that, Mrs. Lincoln, how was the play?

    You’ve gotten several other answers that are true and correct - the pain of implementation at this point is greater than the pain points that WASM solves. But this is also a non trivial one - most of what Javascript should be doing on a webpage is DOM manipulation.

    At some point, WASM will either come out with a killer feature/killer app/use case that Javascript (and all the libraries/frameworks out there) hasn’t figured out how to handle, and it will establish a niche (besides “Javascript is sort of a dumb language let’s get rid of it”), and depending on the use case, you might see some of the 17.4 million (estimated) Javascript developers chuck it for…what? Rust? Kotlin? C? C#? But the switching costs are non-trivial - and frankly, especially if you still have to write Javascript in order to manipulate the DOM…well, what are we solving for?

    If you’re writing a web app where one of the WASM languages gives you a real competitive advantage, I’d say that’s your use case right there. But since most web applications are basically strings of api calls looped together to dump data from the backend into a browser, it’s hard to picture wider adoption. I’ve been wrong before, though.

    • Lucky@programming.dev
      41·
      1 year ago

      I’d imagine one of those killer features is using a language with a solid standard library. Npm dependencies are notoriously complex because js as a language is missing basic functionality that is standard in other languages. Just a few years ago the Internet broke because “pad left” was pulled by it’s maintainer, that simply doesn’t happen in other languages

      From a maintenance perspective npm is a nightmare. From a security perspective it is worse. Being able to build your entire website using a language that eliminates most dependencies, and the ones you take on don’t pull in a zillion dependencies either, is absolutely a killer feature

      Of course that isn’t the full story and using js still has it’s advantages as people have already pointed out. If wasm closes the gap in those areas then it would absolutely be worth the switch

    • computergeek125@lemmy.worldEnglish
      1·
      1 year ago

      But other than that, Mrs. Lincoln, how was the play?

      I’m amazed at how much you described in a single sentence there

    • lemmyvore@feddit.nlEnglish
      02·
      1 year ago

      Even if WASM gets some amazing feature, like super-fast DOM manipulation, it would still be used via API from JavaScript. WASM is a subset of JavaScript that mainly consists of low level operations. It’s not exactly nice for writing code. It’s like assembler in this respect — very fast, very efficient, but we still tend to prefer a higher level language.

      • AnarchoYeasty@beehaw.orgEnglish
        2·
        1 year ago

        Ok but no one is talking about hand writing wasm. You write wasm with a language, such as rust, which already has great web frameworks such as yew (which replaces react) as well as leptos (which replaces solid.js). Leptos is already faster than react vue and svelte

  • Mandy@beehaw.orgEnglish
    41·
    1 year ago

    So I gotta have to break out the xkcd comic again? Cause I will

  • livingcoder@programming.dev
    1·
    1 year ago

    From my experience JS is primarily used to manipulate the DOM. I haven’t looked into it, but if you’re correct that WASM cannot manipulate the DOM then your question, to me, is tantamount to “Why aren’t people using forks to eat soup?”.

    I would love a staticly-typed, compiled language to come along and replace JS. If anyone is aware of how I can write Rust in place of JS, please let me know. For now, I suffer/enjoy JS.

    • nous@programming.devEnglish
      1·
      1 year ago

      There are quite a few web frontend frameworks for rust now that are reasonably mature. Though you might still find a few rough edges they are usable for projects now.

      All of these can work without you needing to write any JS code. Though there is JS glue code involved, it is generated and you don’t need to worry about it.

      But the JS eco system is still quite large and hard to completely avoid.

  • fiat_lux@kbin.social
    0·
    1 year ago

    How will we be making WASM-based UI accessible for people using screen readers, screen zoom applications, text to speech and voice input users, etc.?

    The Web is hostile enough to people with disabilities, despite its intent, and developers are already unfamiliar with how to make proper semantic and accessible websites which use JS. Throwing the baby out with the bathwater by replacing everything with WASM in its current form seems about as good an idea as Google’s Web Environment Integrity proposal.

    • AnarchoYeasty@beehaw.org
      1·
      1 year ago

      JS has little to do with accessibility. Most web accessibility comes from the Dom and aria attributes as well as semantic tags. You can do all of that with wasm too.

      Are you asking about how it will work with wgpu based applications? This will work the same as it does on desktop applications. The program calls out to libraries that support talking to screen readers. I know rust the language with the best support for and ecosystem around wasm libraries like this already exist and ui frameworks like egui already have some support built in.

  • nous@programming.devEnglish
    0·
    1 year ago

    Faster than JavaScript

    For pure computation, using the right language it can be faster. For a general website that needs to manipulate the DOM the performance is about the same as what popular JS frameworks can do (and can be faster than popular ones like react). But there are faster JS frameworks that react already available and people are not flocking away from react to these other frameworks. So speed is not a big enough issue here for people to want to move to a new language with WASM.

    Has a smaller file size

    Not sure this is true. Maybe for a single function. But for a general application? I don’t think so. WASM tends to be a bit larger than JS code I think as you often need to ship more code, where JS can rely more on things built into the browser. But we are at a point where this difference is not a huge concern any more either. So is not really a point for or against WASM here.

    Can be compiled to from pretty much any programming language

    This is a huge misleading point. Even if you could do it from any language not all languages have a ecosystem that is useable for it and a lot of languages require large runtimes that need to be shipped with the WASM bundle (making the points above far worst).

    Can be used outside of the browser easier thanks to WASI

    So can JS? And native code? So I don’t really see what this statement is meant to be arguing for? It is irrelevant when talking about websites using WASM in the browser.

    So why aren’t most websites starting to try replacing (most) JS with WASM now that it’s supported by every major browser?

    Why should they start using it? They all have existing code, their devs already know JS. What major advantage would WASM give them over what they currently have? The points above I have already gone through and are not a big enough reason for this change outside of niche use cases. JS is good enough for most use cases and people that are already working in the web browser side of things already know it. There is little reason to make the switch to WASM as even in languages like rust, which likely has the most mature eco system, still has a vastly less mature eco system for web dev than JS.

    There is no line that needs to be passed that will cause floods of people to start adopting it and start converting everything they maintain over towards it. If there is a good enough reason to adopt this technology then it will be done very gradually over many years if not decades. People wont suddenly throw out everything once some line is crossed without some extreme and unconditional benefit to doing so.

    • jim_stark@programming.dev
      0·
      1 year ago

      What about maintainability of large code bases? JS even with TS tacked isn’t so great or at least not as good as Rust.

      • nous@programming.devEnglish
        2·
        1 year ago

        Yes, that is a good reason to use languages like rust overall. And one reason we are seeing quite a few web frontend frameworks being written in rust now. They are maturing quite fast and there is quite a bit of effort being put into them. But i believe most of this is coming from rust devs (that may have touched frontend tech before) wanting to use it in more places rather than JS devs wanting something more maintainable.

        There is quite a lot you can do in languages like JS to help mitigate the maintainability issues as projects scale up in it. TS is one such thing that helps quite a lot and when employed well improves things quite a lot - enough of a difference that it makes the jump to a completely different language and tooling that moving to rust would involve become less attractive. There is still benefit of rust over TS, but also a much bigger cost than switching from JS to TS.

        Some will see the switch as worth it, though more for newer/greenfield projects. Or those coming from backend already written in rust and thus already familiar with the language. Over time these types of projects and situations will grow - but that happens very slowly over time and not just because some line gets crossed by the technology. It also wont cause it to take over everything, but will just get a small market share of everything being written now.

        This is also why we have so many different backend languages rather than one that everyone uses. If one language cannot take over that why would it work for the frontend? At best more websites will start suing other languages over time and slowly erode JSs market share in the web frontend space.