What's stopping WebAssembly from effectively replacing JavaScript? - eviltoast

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?

  • kicksystem@lemmy.world
    21·
    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.

    • nous@programming.devEnglish
      1·
      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.

      • kicksystem@lemmy.world
        21·
        1 year ago

        Language preference, ergonomics and isomorphic code have not been good enough use-cases to get people off of Js. There was a big hype around compiling to Js a decade ago, but that hype past us and nowadays this is usually only done for some small piece of pure logic that really needs to be isomorphic, which is kind of what we have wasm for nowadays. People who hate Js should really get off their high horse. Writing frontend code in Rust really isn’t going to make a material improvement over writing the same thing in TypeScript, unless you need raw performance which is less than a percent of all webapps.

        This is a good thing, because the frontend community is really not going to benefit from having the same thing written in a dozen languages. We’ve already got a bazillion datepickers, we don’t need a gazillion. People are dumb enough to want to rewrite a bunch of stuff in Rust just because they like the language. And Rust absolutely isn’t the best language to write a datepicker in. Having a single language, however crappy, did create some much needed stability in the frontend space. It is also quite handy that frontend engineers can focus on their job, not on learning language X with toolchain Y and libraries Z.

        Don’t get me wrong. I am not a Js fan. I’ve been coding since the 90s and am familiar with most languages and pretty much every paradigm. I can be quite picky when it comes to languages, but I’d rather have a single okay language that gets the job done with a good ecosystem then a dozen competing ecosystems some of which may be better in some respects. The current status quo with the advent of TypeScript isn’t terrible either. What is shitty though, is React and the complete lack of use of web standards, but that’s another tangental discussion.

        • nous@programming.devEnglish
          1·
          1 year ago

          Language preference, ergonomics and isomorphic code have not been good enough use-cases to get people off of Js

          But they are good enough reasons for people to want to use it over JS when coming experience with rust backends.

          There was a big hype around compiling to Js a decade ago, but that hype past us and nowadays

          What do you mean? This hype never passed - this is exactly what typescript is, a compile to JS language. And TS has taken off as a language and adopted by a large amount of people working in the web frontend world and with JS in general.

          Writing frontend code in Rust really isn’t going to make a material improvement over writing the same thing in TypeScript, unless you need raw performance which is less than a percent of all webapps.

          Developer satisfaction is a good enough reason to pick a language for something (assuming it outweighs other tradeoffs). And if you have picked something like rust for your backend then there is a good reason to also use it for your frontend - assuming your devs are more experience in rust than JS and you have no existing JS code you need to interact with. Performance is not the only, or even main reason you would want to pick rust over JS. There are a lot of other reasons it can be beneficial.

          Having a single language, however crappy, did create some much needed stability in the frontend space

          Stability in the frontend space? What are you talking about? There is a new framework or library or even compile to js language every week. The web platform is just a fast moving target now you are constantly needing to learn new things to keep up with it. And adding more optional things like other languages does not make this any worst or better - but does mean those that are not already familiar with JS, but are with other languages can use the language they are familiar with instead of the whole fast moving JS ecosystem.

          It is also quite handy that frontend engineers can focus on their job, not on learning language X with toolchain Y and libraries Z.

          And if you have people familiar with JS already then there is not as much point in getting them to learn the rust eco system. Just like it is nice that if you already know the rust eco system you don’t need to learn a JS just to do frontend development. And JS developers are already constantly learning new frameworks and libraries as the churn in the JS eco system is quite high.

          but I’d rather have a single okay language that gets the job done with a good ecosystem then a dozen competing ecosystems some of which may be better in some respects

          I disagree. Having more languages available on the web is better IMO. It gives more people more options to get into it and you are not stuck on some language that was created in 10 days 28 years ago and only recent years had any improvements done to it at all. Yea, most people will still use it and there is little to no point in converting existing projects to it. But that does not mean we should not be exploring different languages in the web space at all. Or being forced to only use compile to JS languages. It is all optional, you are not forced to use it. But it lets those that want to use it do so.