What's stopping WebAssembly from effectively replacing JavaScript?

Comments

• bignavy@programming.dev ⁨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.

  source

  • Lucky@programming.dev ⁨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

    source
  • lemmyvore@feddit.nl ⁨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.

    source

    • xigoi@lemmy.sdf.org ⁨1⁩ ⁨year⁩ ago

      How is WebAssembly a subset of JavaScript? Aren’t you confusing it with asm.js?

      source

      • -> View More Comments
    • AnarchoYeasty@beehaw.org ⁨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

      source
    • coltorl@programming.dev ⁨1⁩ ⁨year⁩ ago

      I don’t know what you mean by WASM being a subset of javascript (maybe you mean AssemblyScript?). You can still program in higher level languages like C and have it compile into WASM as one would compile C to assembly.

      source
  • computergeek125@lemmy.world ⁨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

    source
• nous@programming.dev ⁨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.

  source

  • jim_stark@programming.dev ⁨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.

    source

    • nous@programming.dev ⁨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.

      source

      • -> View More Comments
  • kicksystem@lemmy.world ⁨1⁩ ⁨year⁩ ago

    Indeed. Who runs into the speed and size limitations of Js itself nowadays? Even freaking Office365, Google apps and observability dashboads run fairly smootly on Js. Not saying there are no legitimate use-cases out there, but I see plenty of reasons for not wanting to fight with the borrow checker if all I am doing is serving up a boring website with some forms and dynamic elements.

    source

    • nous@programming.dev ⁨1⁩ ⁨year⁩ ago

      There are legitimate use cases out there. And it is not just about speed. Rust is the most loved language for good reason and people wanting to use it in the browser rather than JS because they like is more is as good a use case as any. And this is despite the borrow checker issues - which are really only a problem when you are first learning rust.

      These days the rust web frameworks available are very close to the JS frameworks in terms of ergonomics as well as speed. There are even isomorphic web frameworks now that let you write rust code on the backend and frontend using a single rendering code for both. It can be very nice to have both the frontend and backend logic in the same language and even share the same code. And for anyone that does not enjoy JS as a language now has another option to do this with. That IMO is enough of a use case to warrant it.

      Though the frameworks are still maturing and have a few rough edges. Plus it is often not worth the effort to port old projects. But new greenfield projects are another matter. But the bigger question for this side is then hiring talent - and ATM JS is easier to hire for, for frontend developers.

      Over time this might change, but only very slowly.

      source

      • -> View More Comments
• pelya@lemmy.world ⁨1⁩ ⁨year⁩ ago

  I’ve ported games to web using WASM. You still need to interact with HTML DOM using JS, no way around it.

  You use WASM when you either need raw CPU speed, or you have some C++ code that you don’t want to rewrite in JS.

  If you just want to make a website, pure JS is better, unless you’re that kind of dev who prefers to render their own text strings pixel by pixel.

  source
• Kissaki@feddit.de ⁨1⁩ ⁨year⁩ ago

  Replacing costs expertise, time, and money. Nobody wants to invest that for (to them) insignificant or even pointless reasons.

  If you’re using tooling, a framework, a library - each of those makes a switch more risky, costly, or impossible.

  JavaScript works with the DOM. Why would you want to implement a separate WASM component that you have to interface with? JavaScript is good enough. Interfacing only brings problems with it.

  When you use JS you are doing it right - because there is no other way to interface with the DOM. Anything else is built on top. How would you interface with WASM? Manually? Library? Framework? What programming do you use to compile to WASM with? How do you analyze and debug WASM when it executes in a compiled WASM-binary format?

  The use case for WASM is performance, efficiency on CPU-bound operations. If CPU-bound performance is not a concern for you, or JS is good enough, there’s little reason to use WASM. Other reasons are even more niche.

  source

  • AnarchoYeasty@beehaw.org ⁨1⁩ ⁨year⁩ ago

    The language best suited for wasm is easily rust. And you can still interface with the Dom using frameworks like yew sycamore or leptos.

    Debugging is still a little tricky but you can debug wasm in chrome and DWARF allows you to have source maps that map to your rust code. This is s problem the community is working to improve. Until then you have the full power of console log which is how a large portion of developers already debug their applications.

    source
• vasametropolis@lemmy.world ⁨1⁩ ⁨year⁩ ago

  The truth is that JS is currently “good enough” and all the best (adopted) web frameworks are either server or JS based.

  I believe the chunking of script files is currently a bit more natural as well.

  WebAssembly is the best choice for certain kinds of apps but most web apps are good enough with JS. If communities pour a lot of polish into WASM frameworks you may start to see wider adoption. Diversity is good, but it does need to be asked why WASM + DOM is objectively better than JS + DOM. It complicates the ecosystem a bit because you might fracture it for no good reason. Should there be Rust, Python, and JS DOM rendering frameworks? Is there a benefit?

  If you have a more traditionally native app you want to port, that’s different. That’s a great fit for WASM. Personally I see it becoming more popular when it’s a good replacement for desktop technology and the DOM isn’t used at all (go straight to GPU).

  source

  • lnsfw3@lemmynsfw.com ⁨1⁩ ⁨year⁩ ago

    This is it.

    WebAssembly AFAICT is all about making existing code runnable in a JavaScript environment. JavaScript isn’t great itself, but Chrome provides pretty amazing tooling, so it’s good enough.

    Add to that: if you want to write WASM in a strongly typed language, you need support libraries that define all of the browser primitives. If you’re an accomplished web developer, it’s more effective to stay in js.

    source

    • nous@programming.dev ⁨1⁩ ⁨year⁩ ago

      WebAssembly AFAICT is all about making existing code runnable in a JavaScript environment.

      I would not say that. It is one aspect of web asm, but not the only or even main reason. There are far more frameworks and tooling out there designed for writing new stuff in it rather than getting existing stuff to run.

      if you want to write WASM in a strongly typed language, you need support libraries that define all of the browser primitives.

      These already exist for some languages - notably rust (but not exclusively). You can now write a web app fully in rust and have it preform on par with popular JS frameworks. There is JS involved in this - but it can all be generated so developers never need to actually touch it.

      If you’re an accomplished web developer, it’s more effective to stay in js.

      This is true, and the bigger reason why wasm is not as popular. If you already know a JS web framework there is little point in learning a whole new language as JS is good enough for most applications. And a whole new language and tooling is a large investment. But it does mean that people in other eco systems or that don’t really like JS are now able to write webapps in other languages (which by the very nature are going to be a fraction of web devs as these people will likely have avoided it where they can). Other eco systems are also a lot less mature than JSs eco system for web development.

      source
• pileghoff@programming.dev ⁨1⁩ ⁨year⁩ ago

  I think the truth is that not only can’t WASM manipulate the DOM, but javascript was build to manipulate the DOM and has been moulded around this purpose. Secondly, if you want to use WASM from another programming language, that is just another language you need to learn on top of javascript, because we are not at a stage where we can replace javascript (because of the DOM). Fo most it’s more cost effective to just optimize their javascript code instead of adding another layer to the tech stack.

  source

  • nous@programming.dev ⁨1⁩ ⁨year⁩ ago

    I think the truth is that not only can’t WASM manipulate the DOM

    Not directly no. But it can via JS (without the developer needing to ever touch JS code themselves via auto generated bindings). And this is simply a limitation of the current WASM implementations/standards. I believe there is work on going to get WASM more direct access to the DOM. But really this will just be an efficiency improvement over what is currently possible (which is already possibly to be as fast as pure JS frameworks).

    Secondly, if you want to use WASM from another programming language, that is just another language you need to learn on top of javascript, because we are not at a stage where we can replace javascript (because of the DOM).

    This is not quite true. Yes we cannot replace JS currently. But you don’t need to learn JS to develop using WASM - there is already enough tooling that can auto generate any JS code needed for you so developers never actually need to learn or touch JS if they don’t want to.

    But existing developers that already know JS don’t have a huge reason to learn another language that only have a vastly less mature ecosystem. So the door is currently open for those that don’t enjoy or want to touch JS, but those people will at this point in time be working on other things rather then web apps. So there is not going to be a huge push for moving to a different language with WASM support any time soon. Not to mention that there is only minor benefits to existing applications that make a full rewrite to another language not worth the effort. So people wont be flocking over toward it, but not for the reasons you mentioned.

    source

    • pileghoff@programming.dev ⁨1⁩ ⁨year⁩ ago

      Sure, you can autogenerated js bindings, but as soon as you need to start debugging or optimizing you need to understand the js that was generated for you.

      source

      • -> View More Comments
• livingcoder@programming.dev ⁨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.

  source

  • nous@programming.dev ⁨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. www.leptos.dev dioxuslabs.com yew.rs 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.

    source
  • Blamemeta@lemm.ee ⁨1⁩ ⁨year⁩ ago

    There’s Typescript, it’s as close as you can get.

    source
  • icesentry@lemmy.ca ⁨1⁩ ⁨year⁩ ago

    You can absolutely modify the dom, you just need to go through a thin js glue layer between the dom and wasm

    source
  • dneaves@lemmy.world ⁨1⁩ ⁨year⁩ ago

    For transpiled-to-JS languages: Elm, Purescript, Typescript

    I personally use Elm. Really helps remove all the JS funny business, without really having to type it (mostly)

    source
• Nighed@sffa.community ⁨1⁩ ⁨year⁩ ago

  Unless it has improved since last time I used it then it’s awful to debug in the browser. I hate JavaScript, but would probably still use it for a new web project now.

  source

  • AnarchoYeasty@beehaw.org ⁨1⁩ ⁨year⁩ ago

    If you use rust and structure your program correctly you can avoid debugging directly by building unit tests in language the verify behavior. Debugging tools are great and I look forward to better dx stories there (you can use chrome + DWARF to debug your native code) but strictly speaking it isn’t necessary most of the time.

    source

    • livingcoder@programming.dev ⁨1⁩ ⁨year⁩ ago

      Can you please elaborate on how, when using Rust, we can avoid needing to debug our JS code? I am very interested and hope that I didn’t misunderstand you.

      source
• fiat_lux@kbin.social ⁨1⁩ ⁨year⁩ ago

  How will we be making WASM 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.

  source

  • AnarchoYeasty@beehaw.org ⁨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.

    source
• Mubelotix@jlai.lu ⁨1⁩ ⁨year⁩ ago

  It’s only smaller for large apps

  source
• tonytins@pawb.social ⁨1⁩ ⁨year⁩ ago

  WebAssembly was never intended to replace JavaScript. It was intended to coexist with it. You still need something to initialize and load the binary.

  source
• Mandy@beehaw.org ⁨1⁩ ⁨year⁩ ago

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

  source

  • lambda@programming.dev ⁨1⁩ ⁨year⁩ ago

    Do it do it do it! 🤣

    source
• Reva@startrek.website ⁨1⁩ ⁨year⁩ ago

  As a hobbyist web dev:

  • I want to support niche browsers that might not support WASM such as Dillo or NetSurf.
  • Most of the resources out there are Javascript-only.
  • I don’t even use scripting most of the time in order to be accessible to text-only, old and minimalist browsers.

  I can also imagine that people who are more professional than me in their development require existing JS frameworks, libraries, tutorials and whatever, and were taught in Javascript; there is no reason for them to change. There is also probably no real money in developing WASM applications commercially.

  source
• jim_stark@programming.dev ⁨1⁩ ⁨year⁩ ago

  IIRC a startup tried to exactly that and they abandoned it. It’s wasn’t any faster and is actually harder to develop.

  • www.youtube.com/watch?v=461735zrjzY

  • github.com/leptos-rs/leptos

  Maybe things have changed now, I didn’t follow any updates.

  source

  • icesentry@lemmy.ca ⁨1⁩ ⁨year⁩ ago

    The video is essentially saying the exact opposite of what you are saying. It’s showing leptos to be much faster than react and I know primeagen doesn’t think rust is harder develop.

    source

    • jim_stark@programming.dev ⁨1⁩ ⁨year⁩ ago

      My bad. I can’t find the actually video but there exits a startup that shutdown because Rust/WASM performance wasn’t any better on top of that it’s was harder to develop with Rust. But as my edit to my previous comment shows things got better for Rust. It’s no longer the case.

      source
  • PipedLinkBot@feddit.rocks [bot] ⁨1⁩ ⁨year⁩ ago

    Here is an alternative Piped link(s): piped.video/watch?v=461735zrjzY

    Piped is a privacy-respecting open-source alternative frontend to YouTube.

    I’m open-source, check me out at GitHub.

    source
• ndotb@programming.dev ⁨1⁩ ⁨year⁩ ago

  From a historical standpoint, there is also the bad blood of ActiveX, Flash, Silverlight and early Java applets that still leaves a bad taste in people’s mouths. It has a slightly steeper uphill battle to fight.

  source
• Flyberius@hexbear.net ⁨1⁩ ⁨year⁩ ago

  Javascript is just really great. WASM is also great and really opens up some cool possibilities, but there is something inexplicably simple and approachable about Javascript. I think it will be very hard to topple it from its throne, even if WASM overcame it’s DOM issues.

  source
• icesentry@lemmy.ca ⁨1⁩ ⁨year⁩ ago

  On the subject of dom manipulation from wasm I highly recommend this video youtu.be/4KtotxNAwME. It’s from leptos author, one of the more popular wasm framework. The TLDR is that modifying the dom isn’t the bottleneck for wasm.

  source

  • PipedLinkBot@feddit.rocks [bot] ⁨1⁩ ⁨year⁩ ago

    Here is an alternative Piped link(s): piped.video/4KtotxNAwME

    Piped is a privacy-respecting open-source alternative frontend to YouTube.

    I’m open-source, check me out at GitHub.

    source
• magic_lobster_party@kbin.social ⁨1⁩ ⁨year⁩ ago

  JavaScript is much more mature. It has a lot of established tools and frameworks aiding the developer. JavaScript frontend developers are also easier to recruit. You will just make everything harder for yourself by adopting WASM.

  source
• companero@hexbear.net ⁨1⁩ ⁨year⁩ ago

  Faster than JavaScript

  JS is usually fast enough.

  Has a smaller file size

  It really depends. If you aren’t careful, your Wasm blob can end up ballooning in size. If you start pulling in libraries and doing things like parsing JSON, your binary can get big, quick.

  Wasm adds an extra layer of complexity that needs to be justified. In most cases, it’s just not worth it.

  source
• arthur@lemmy.zip ⁨1⁩ ⁨year⁩ ago

  JS have momentum, a lot of it.

  source