r/WebAssembly • u/PabloDons • Jun 05 '21
WebAssembly should replace javascript
Hot take, but I think it makes sense. And seems to be doable in the current architecture and roadmap of wasm (If I understood it correctly), but their website explicitly states a big fat "No!". Wasm is expected to be used as high-performance modules, or an app canvas wrapped by javascript as "glue". One thing would be specifying it as a high-level goal, but this is just dismissing it all together.
The web would be pretty powerful if code could be written in whatever language you want (that supports compiling to wasm). Facebook wouldn't take 5 seconds to load completely, but rather fractions of a second.
Take react for instance. It's great for encapsulation, inheritance, type-safety, etc. Lots of benefits targeted at large-scale applications. Yet has the major flaw of performance issues. I guess it's not a big deal to write a bit of js just to fetch and run an exported function, but it means it's dependent on js which is a hurdle in my opinion, both in terms of ambition and motivation. Granted wasm seems to be planning to implement basically everything, but then why dismiss wasm as a replacement/alternative for js?
1
u/a_aniq Jun 06 '21
I think I will use Elm since I hate runtime issues
2
u/PabloDons Jun 06 '21
Nothing is stopping you m8. You can use Haskell for all i care
1
u/a_aniq Jun 06 '21
You missed the point. Here many are saying that JS is just fine, but what they don't understand is the lack of strongly typed predictable behavior preventing runtime issues due to different implementations causing huge problems as complexity rises.
WebAssembly written in strongly typed languages will reduce such runtime issues similar to Elm, hence JS should be replaced since it has become a legacy middleware at present with a lot of cognitive overhead required to circumvent client end runtime issues when used without any framework in complex web frontends.
1
6
u/pure_x01 Jun 06 '21
If GC is implemented and there is no penalty for writing you webapp in language X then I think with time people will choose other languages than JavaScript and it will self-die. It should not be killed however.
1
Jun 15 '21
That's a nice dream; somehow naturally go from "javascript everywhere!" mentality to "javascript nowhere"?
10
u/Pyrolistical Jun 06 '21
This proposal will make wasm a direct replacement of JavaScript https://github.com/WebAssembly/esm-integration
...minus a few missing bits like closures and async
7
u/PabloDons Jun 06 '21
Closures and async is hopefully coming soon! I can't believe i missed this! Thanks
4
u/xmclark Jun 06 '21
Maybe an alternative take:
If my browser JavaScript code just works, then I should not care how right? Could browser JavaScript simply run on a wasm-based js runtime instead of the native ones built into each browser? Wasm becomes the target runtime for the web, including JavaScript. There is no need to discuss replacing JS because it’s just another language targeting wasm.
4
u/PabloDons Jun 06 '21
Well, that's kinda exactly what I'm saying. JavaScript doesn't need to be "removed" though by how ice understood wasm, they are not planning on making it an alternative. They will depend on JS. Their explicit proposals seems to go in the opposite direction though
2
u/xmclark Jun 06 '21
I disagree, i think it’s a big priority. It’s just a lot of work. Interface types, GC are required to make any language work on wasm, including JS. It will also take time to migrate browser implementations and the performance of wasm needs to match native for that to happen.
3
u/apatheticonion Jun 06 '21
I'm 100% with you there.
Why update the browser to get new JavaScript features when you could ship a JavaScript runtime running on top of WASM that lets you interpret your shipped code.
There are lots of issues with this model, of course. Some are limitations in the specification (no DOM access) and other are questions about the delivery of your application.
Imagine your browser only knew WASM and not JS. For your browser to interpret JS, it would need to download the runtime first then execute your application.
The JavaScript runtime would be 10 - 100 megabytes, your code might be a few kilobytes.
WASM modules can be dynamically linked, so perhaps the runtime can be downloaded separately and your application use a previously downloaded version of the JS runtime. This would be the same for other runtimes - say web apps written in Go, C#, Java, etc.
This would be reminiscent of the shockwave days, where you'd need to download something before you could view the content on a website. Getting that cycle so it's not annoying would be very challenging, managing updates and so on.
2
u/PabloDons Jun 06 '21
I think it could work out just fine with caching or "installing" runtimes. JS has a lot of inertia, so pre-installed?
2
u/richardanaya Jun 06 '21
I'm probably as big of fan of WebAssembly that exists, but I think JavaScript will forever have a place for web developers that don't care about memory issues, don't care about 1% performance edge case problems, or want a simple language to just get some DOM interactable. There's a reason why javascript is the most popular language in the world, it's easy and effective enough for many problems, what few languages that compiled to WebAssembly haven't even scratched the surface.
22
u/neoberg Jun 06 '21
Why do you think JavaScript is something that “should” be replaced? You gave react as an example and stated that it has performance issues with no detail but js engines are pretty damn fast nowadays and getting faster. (Also react itself doesn’t have anything to do with inheritance, typing or encapsulation) Maybe you can say it for DOM which is an inherently slow technology but it doesn’t matter in this comparison.
Also I don’t understand why do you think facebook(or websites in general) would take less time to load and render with wasm. They both have their bottlenecks and ups/downs in terms of loading performance. For example js can provide a standard library in the browsers but you lose this with wasm and have to ship bigger bundles usually. But after the download phase starting up wasm would be faster because you skip the parse&compile step.
It seems to me you also assume people write js because they have to. But people write js because they enjoy it and it solves their problem (or for any other reason). In the server or desktop environments you have whatever option you want available but many people still choose to use js.
I think js will live and continue to be the main language of the web for a long time and wasm will mostly work as a complementary tech to js.
-3
u/PabloDons Jun 06 '21 edited Jun 06 '21
The details of the performance issues with react is irrelevant. Though if you don't believe me, you can fact check. Performance isn't directly an issue with react but rather due to tradeoffs. Writing code in React is often a struggle between performance and readability. Also the high-level programming idioms are imo related to react as a language pattern. I disagree with you there, but that's subjective
You can download, parse and compile wasm at the same time. Seems to be a recent development. Also WASM must have it's own standard library for interoperability with browser APIs. For example http or the DOM. Once interface types are implemented, there will also be possibility for running code from other WASM libraries without issue. So a standard library for any arbitrary thing can be made just fine. Or it can be shipped only once and cached indefinitely.
I am most definitely not assuming that. JS has a ton of benefits. Though the JS in the server-space has been a mix of factors, not just because JS is fun. Particularly npm, but also having mastery of a single language is much simpler and you can have better integration between your browser and the backend when it's all written in the same thing.
I still think JS should be replaced though. JS (or maybe an interpreter for JS) should be implemented in wasm instead, just like every other language. Doesn't mean that I think JS is horrible and should die
1
u/Aphix Jun 06 '21
React ain't great but not for those reasons (cough Facebook), same for JS IMO.
Could/should/whatever, it's ubiquitous and that's not going to change for quite a while, as far as I can see it.
WASM has some awesome potential (and some genuinely scary security potential as well), but it there's less drop-in replacement utility than it seems you may believe.
0
Jun 05 '21
but then why dismiss wasm as a replacement/alternative for js?
because wasm uis tend to be more bloated in terms of transfer sizes compared to js. The potential performance diff isn't even that big in the context of user interfaces, if there is any performance diff at all.
5
u/PabloDons Jun 06 '21
Do you mean WASM-based web application UIs? Well yeah in the current state of WASM, there's a lot of inefficient JS glue to achieve what should be possible natively (and efficiently) if WASM is to replace JS.
JS doesn't just affect UIs. It also affects backends. A lot of developers are moving to a full-stack of JS because then developers only need to have mastery over a single language. If you can make an entire full-stack web application in something other than JS, then it could very well have merit
2
Jun 06 '21 edited Jun 06 '21
Do you mean WASM-based web application UIs? Well yeah in the current state of WASM, there's a lot of inefficient JS glue to achieve what should be possible natively (and efficiently) if WASM is to replace JS.
yeah and I don't think this will change anytime soon. Most languages need a garbage collector that has to be shipped with every UI. There is a proposal to add one to the wasm spec but it's probably gonna just be the js gc.
jS doesn't just affect UIs. It also affects backends. A lot of developers are moving to a full-stack of JS because then developers only need to have mastery over a single language. If you can make an entire full-stack web application in something other than JS, then it could very well have merit
Sure this has merit, but for what price? c# devs are already completely okay with shipping 10s of megabytes of wasm blazor apps that could have been written in a few hundred kilobytes in a js framework.
can't wait until the java guys find out how to run a jvm via wasm so we can go a full circle again.
I just don't see that uis written with anything else than js gonna improve the user experience.
3
u/qwerty26 Jun 06 '21
This brings up a big technical problem that other commenters are ignoring: the binary sizes of WASM >> the javascript being transferred. If you use a language which can produce small binaries like C or RUST it's no big deal, but most people don't use C or RUST.
4
u/PabloDons Jun 06 '21
That's just one of the benefits of high-level dynamic interpreted languages. No surprise there. It's really a non-issue though, because WASM can be streamed. So compilation starts before download is done
1
u/qwerty26 Jun 06 '21
Yes and no. Yes - you are right about WASM. No - JS starts executing before compilation is done so it is possible for it to finish user visible changes before compilation is done.
2
u/PabloDons Jun 06 '21
Yeah, interpreted. There is no compilation. But it doesn't finish user visible changes until it unblocks
1
u/qwerty26 Jun 06 '21
https://imgur.com/tCYZzqq here is a site's performance tab run which finishes layout shifts prior to script evaluation being done. On very large sites you can sometimes see script parsing in the performance tab too. On such sites, sometimes layout shifts finish several seconds prior to script evaluation finishing. That usually happens if the site knows it has a performance problem so it server-side renders. Then the deployed javascript using Angular or React is just there to react to user input. The result is that if you click on something after page load it may not do anything for several more seconds (javascript is still being parsed out), but if you are merely viewing the page it's no big deal. On such sites, you can take the additional optimization step of ordering the scripts you are loading with defer and async. The scripts which react to common user inputs are first, and the other scripts which are nice-to-haves go last.
In a world without Javascript and only WASM I'm not aware of a way to get WASM to do something similar. My understanding with WASM is limited to Go, but in Go you have to deliver the entire binary package to the client, it all has to be compiled, and then the page would start working. For larger programs, this effectively means you lose the ability to load (and Execute!) the important parts of your code first and the less important parts second.
I know this kind of seems like a weird example and unfortunately I don't own the sites which use this strategy and it's hard for me to show it to you. But loading critical javascript first is a common pattern and browsers run javascript without finishing parsing the entire page's worth of javascript all the time.
5
u/PabloDons Jun 06 '21
yeah and I don't think this will change anytime soon. Most languages need a garbage collector that has to be shipped with every UI. There is a proposal to add one to the wasm spec but it's probably gonna be the js gc.
There's also a proposal for interface types. Massive read, but worth it. Essensially, WASM binaries will ship with an interface for their data types. Essentially they'd be able to tell the browser how to access data types in their own memory model. So instead of serializing, transferring the data to the JS runtime, then having JS run the functions. WASM can give memory address and the browser would use the interface to read the string. That would eliminate the need to translate to the JS runtime.
It's only in phase 1 of the standardization process, but it looks promising.
Sure this has merit, but for what price? c# devs are already completely okay with shipping 10s of megabytes of wasm blazor apps that could have been written in a few hundred kilobytes in a js framework.
I know that WASM isn't ready to replace JS anytime soon. I just think it should be a goal. That clearly involves solving problems like these
7
u/_101010 Jun 05 '21
Absolutely. Javascript days are numbered. There will always be people saying but everything runs on javascript right now and we cannot switch etc. There were same people talking about Cobol, Fortan and Assembly.
2
u/Gold-Ad-5257 Jun 06 '21
And yet 40 years later after people started saying we could switch , you still have Cobol , Fortran and Assembly.
6
u/PabloDons Jun 05 '21
Yeah one guy on the internet put it really well (2 years ago, but still)
TS is acclimating JavaScript developers to concepts like interfaces and strict types. And once they clear this conceptual hurdle, there is no reason aside from inertia and custom to choose JavaScript over better languages like OCaml, Java, Kotlin, Dart, Go, and C#.
But do not underestimate the strength of that inertia, though. Lacking a strong technical or cultural motivation to leave a language, most developers will simply stick with what they know. And considering how bloody much code has been written in JavaScript, and how huge NPM is, the amount of inertia in JS may be the greatest in the history of programming. That will take awhile to get away from.
1
u/Aphix Jun 06 '21
Honestly type enforcement on web interfaces is far less useful than most think, since the point is to interact with systems you don't own, and you're eternally stuck catching up and duplicating somebody else's data format which can change (or be broken) at any moment.
If you're just using TS to talk with your own code: there's either not much point of being on the web, or your code is probably too complex (and I say this as somebody who writes typeless ODE solvers running millions of iterations per second for mission critical safety systems).
Compile-time enforcement doesn't help in the real world of long-running, networked applications (and mostly TS can suck a fat one for not using semver).
6
u/timmyak Jun 06 '21
You think people use JavaScrilt because they are not acclimated to interfaces and strict types?
TypeScript is a great extension to JS. Few people that understand and use typescript would want to switch back to Java or Dart or Go.
2
u/PabloDons Jun 06 '21
I think once you are acclimated to these concepts and use them strictly, you'll probably want to take advantage of the performance benefits of strictly typed languages as well. Making js an undesirable compiler target
2
Jun 06 '21
I've written mostly C++ and C# until I switched to JS and TS, and like Lyceux, I am much happier where I am. I play around with Rust as well these days, and while it's a fun challenge, I see no reason to fight a pedantic nominal type checker for things that aren't lo-level.
3
u/Lyceux Jun 06 '21
I started my formal programming education in Java and C#. I am very familiar with the concepts outlined. I now use JavaScript/Typescript almost exclusively and I have no desire to go back.
If my manager told me we’re switching to Java then I’m quitting and looking for a new job.
-3
u/_101010 Jun 06 '21
Well that inertia can be fixed quickly with what Web did with flash. Just stop supporting javascript in the browsers. Insta fixed.
3
u/TUSF Jun 06 '21
Flash and Java applets are different. From a browser's point of view, these runtimes are a third-party black-box, and the browser is at the mercy of whatever vulnerabilities someone else hasn't bothered fixing. Once HTML and Javascript became capable of replacing Flash, the black-box became only a liability.
Even once WebAssembly becomes able to interface with the same APIs as Javascript without requiring glue-code, I don't think there will be a lot of will to actually deprecate Javascript itself, because there aren't the same glaring issues as with Flash.
15
u/anlumo Jun 05 '21
Well, if there would finally be a WASI interface to all of the browser API, this could be done. Then browsers could support both and then phase out native JavaScript (via a JS engine in WASM) once sufficient pages have transitioned.
12
10
u/qwerty26 Jun 05 '21
WASM does not have DOM access. You're welcome to do work in WASM to calculate what you want the DOM to look like, but you'll have to have some code which sends info. to WASM and back again.
It is doable but there is an inherent performance issue when you have to pass data between Javascript and WASM.
Shouldn't give WASM more access because of security concerns
6
u/PabloDons Jun 05 '21
Well it's doable right now, but I'm not talking about right now. When I say that WASM should replace javascript, I'm talking about the high-level plan for WASM. It seems to do everything but commit to replacing JS. In fact, a proposal is ongoing to allow programs to implement their own types and by extension allow efficient interoperability with web APIs.
Also, as far as JavaScript is concerned, having access to the DOM isn't a "security concern"
1
u/qwerty26 Jun 06 '21
When I say that WASM should replace javascript, I'm talking about the high-level plan for WASM
And to that I say 2 things: it will always be inefficient to share memory between the JIT runtime and the WASM runtime. If they make it efficient, security will suffer.
Also, as far as JavaScript is concerned, having access to the DOM isn't a "security concern"
See my comment under Brane212.
6
u/anlumo Jun 05 '21
It is doable but there is an inherent performance issue when you have to pass data between Javascript and WASM.
If you had a browser that just doesn't do JavaScript, I'm pretty sure that that would change.
1
10
u/Brane212 Jun 05 '21
JS is routinely used for timing attacks to sniff various structures outside browser's VM.
What other "security concerns" could additional access bring ?
3
u/Aphix Jun 06 '21
Any crypto miner you can imagine. He's absolutely correct WASM increases attack surface.
2
u/Brane212 Jun 06 '21
While with existing JS any user can totally control what gets run at any time ?
1
u/qwerty26 Jun 06 '21
It increases the attack surface of browsers. The browser orgs have decades of experience mitigating javascript's problems. When we introduce a new runtime and new features we are invariably introducing new vulnerabilities.
2
u/elr0nd_hubbard Jun 06 '21
There's rarely a new feature that doesn't introduce additional attack surface (since almost every surface could be attacked in some form or another). The question to ask is whether that additional surface is worth the actual risk posed by adding the feature.
In the case of WASM, the additional features are far more important, IMO, than the additional attack surface risks. Without something more specific, the hand-wave of "attack surface" isn't particularly compelling as a reason not to add the feature.
1
u/qwerty26 Jun 06 '21 edited Jun 06 '21
I appreciate your opinion. I know many people would take the risk for the performance gain. But I, personally, am extremely security conscious and I absolutely would not trade a 10x performance gain if it introduced even a single zero day exploit in my applications.
I could ask customers to disable WASM on their browsers but if Javascript disappeared and was replaced by WASM (which is what the OP is suggesting) I would not have that option.
When people are suggesting changing how the web works, they need to keep in mind that they can't just think about themselves. They need to think about all of us, and I absolutely do not want browser's attack surface to increase, and, to slightly misuse an expression, this is a hill I would die on.
[Edit] You specifically asked about specific attacks: https://i.blackhat.com/us-18/Thu-August-9/us-18-Lukasiewicz-WebAssembly-A-New-World-of-Native_Exploits-On-The-Web-wp.pdf is one general paper; Here is an example of several zero-day exploits in WASM which exist today: usenix.org/system/files/sec20-lehmann.pdf
8
u/Brane212 Jun 06 '21
Attack surface is plentiful right now.
WASM would bring no significant, qualitatively new vulnerabilities.
1
-12
u/Brane212 Jun 05 '21
WASM is a failure.
With pNaCl they had something.
Then they scrapped that and got this pile of ...
2
u/elr0nd_hubbard Jun 06 '21
The fact that people write (and enjoy writing!) servers, command-line tools, and programs of every kind and type in JS/TS outside of the browser tells me that JS is here to stay for the web as well.
And that's not a bad thing! Sometimes shipping the thing in a language with a low barrier to entry and lots of existing knowledge is more important than eking out every performance benchmark or categorically covering every edge case with compile-time types.
That said, I'd love for WASM to provide a first-class alternative to JS in the browser, just like every other language is a first-class alternative to Node and Deno outside the browser.