Full-time web dev; JS lover since 2002; CSS fanatic. #CSSIsAwesome
I try to stay up with new web platform features. Web feature you don't understand? Tell me! I'll write an article!
He/him
I'm a little nervous about the WASM hype. There's a sub-trend in there that showed up when WASM was first being discussed and has reemerged a few times since then that goes: "WASM means we don't need JS anymore! WASM means we can write the web in C# or Go!" And while the current counter argument is that that's just factually false, since WASM functions need to be imported into JS and run from there, that needn't always be true; if enough of the community clamors for end-to-end WASM apps, it'll probably happen eventually.
And I see a lot of potential danger in that idea: web app code becomes a lot less transparent, the attack surface of web apps dramatically increases, the potential for various walled gardens increases, the push to constantly improve JavaScript decreases, the complexity of web apps could blow way up...
But maybe I'm wrong; maybe those concerns are already present with WASM as it currently is, once it gets more mainstream use. And I do absolutely see its value. But still, I'm nervous. Not necessarily pessimistic, just... nervous.
This is right, WASM is far, far from being production ready, as it's a really unsafe option that will be a step back from the current web. Wasm is just a compiled bytecode that executes in the browser, it's usually C, C++ or Rust code in the background but once compiled to wasm it looks like this:
Good luck debugging this, and more importantly, good luck trying to figure what is this code meant to do on the client side. This code is much much harder to analyze than JavaScript because Wasm is a binary format whereas JavaScript is clear text. While malicious actors often heavily obfuscate JavaScript, deobfuscation is still relatively easy. By bringing Wasm into the game, bad guys get new ways to hide and obfuscate the intentions of their code.
And as there is still no viable WASM analyzers, an WASM app is just a blackbox to the user. The only thing that you can do is to analyze network requests and see if there is something suspicious there. In other words, say hi to the coin miners on every site, as with Wasm based approach, the return of investment will be higher for the malicious actors, since heavy math calculations can be done faster with Wasm than with JavaScript. To date, the majority of Wasm samples analyzed have been associated with cryptocurrency miners. Another opportunity for an attacker may be exploitation of hardware bugs.
On the side note it should be pointed out that Wasm is not intended to be seen as a replacement for JavaScript, but rather as a complement. For example, Wasm modules may be used for performing computation intensive tasks and JavaScript (and HTML) for providing the UI and gluing things together.
I guess that whole situation will improve with time, but, sadly, we're not there yet. Until then you can take a look here to learn how to disable WASM in the browsers.
Full-time web dev; JS lover since 2002; CSS fanatic. #CSSIsAwesome
I try to stay up with new web platform features. Web feature you don't understand? Tell me! I'll write an article!
He/him
On the side note it should be pointed out that Wasm is not intended to be seen as a replacement for JavaScript, but rather as a complement. For example, Wasm modules may be used for performing computation intensive tasks and JavaScript (and HTML) for providing the UI and gluing things together.
Yeah, this is what I meant when I said the following:
while the current counter argument is that that's just factually false, since WASM functions need to be imported into JS and run from there, that needn't always be true; if enough of the community clamors for end-to-end WASM apps, it'll probably happen eventually.
My concern is that while it's currently the case that WASM is no JS replacement, I don't necessarily trust that it will remain true, especially given how loud the cry was from the "JS sucks" community that WASM will finally let us write for the web in "real languages" etc etc. I'm not catastrophically worried or anything, I think the developers of WASM have a stake in keeping it scoped pretty narrowly for the time being at least, but I don't think we can predict what the web will look like in 5-10yrs; I could see WASM turning into a core part of the web platform that can be used independently of JS, and I agree with your concerns if that does happen. Not ready to disable WASM just yet, though; squoosh.app is just too good 😁
That's right, once again 😄Web is evolving rapidly, and while my comment might seem grim and in disfavor of WASM, I really hope that it can evolve into something like Js today but without its bad parts. Sharing, collaboration, and open source are the keys for the better future, and I wouldn't want to see web locked down and obfuscated.
This is right, WASM is far, far from being production ready, as it's a really unsafe option that will be a step back from the current web
I agree is far from being ready. I don't think it's inherently unsafe, it's boxed in the same box JS is. Regarding the step back or forward it really, really depends on what developers do and what becomes popular in the next few years. If all devs do with WebAssembly is "I can't wait to recompile my desktop app, ship it in the browser, call it quits and who cares about the web" yeah, we'll have a problem. But if it's used as a performance enhancer and used in conjunction with JS, why not?
Good luck debugging this, and more importantly, good luck trying to figure what is this code meant to do on the client side. This code is much much harder to analyze than JavaScript because Wasm is a binary format whereas JavaScript is clear text.
WebAssembly has a text format though, not as readable as a normal programming language but I'm quite sure "view source" tools that make our lives easier will appear. I think it's too early to decide if WebAssembly will doom us all or not.
I guess that whole situation will improve with time, but, sadly, we're not there yet.
That's why we're saying it will take some time to become mainstream :)
I don't necessarily trust that it will remain true, especially given how loud the cry was from the "JS sucks" community that WASM will finally let us write for the web in "real languages" etc etc.
This is a real thing, but I also don't think that developers will start throwing all the web principles out of the windows just because they can finally code a textarea using Go. That's bonkers in my opinion. Also: WebAssembly still needs to talk to JS and has only a few types, I reckon that writing an entire app might even be counter productive :D
Not ready to disable WASM just yet, though; squoosh.app is just too good 😁
Squoosh is a perfect example of why one would use WebAssembly for the transformation functions to alter images and JS for the rest of the app
Full-time web dev; JS lover since 2002; CSS fanatic. #CSSIsAwesome
I try to stay up with new web platform features. Web feature you don't understand? Tell me! I'll write an article!
He/him
For more background on squoosh and the tech that went into it, in case you're interested: youtu.be/ipNW6lJHVEs
It was built by a Google team including some of the more public faces, like Mariko Kosaka and Jake Archibald, who present the talk at that link. It's a pretty neat discussion of PWAs, WASM, and applying them practically on the web now
Full-time web dev; JS lover since 2002; CSS fanatic. #CSSIsAwesome
I try to stay up with new web platform features. Web feature you don't understand? Tell me! I'll write an article!
He/him
I was going to comment this myself, though I wasn't sure how usable the WASM text version is; I haven't read much about it. x86 has a text version as well, but it's horrible, haha. From the samples I have read it does seem like WASM's text version is much, much more readable and usable than traditional textified ASM.
I don't think developers will start throwing all the web principles out of the windows just because they can finally code a textarea using Go.
I doubt that too, I think what I'm more nervous about is an influx of Go (or other language) developers who start saying, as you said, "I can't wait to recompile my desktop app, ship it in the browser, call it quits and who cares about the web".
Just to say it again, I'm not super pessimistic about any of this, I think our community is far more resistant to negative change than that. We're a very self-critical community that is willing to reconsider best practices over time, despite what some may say. And because of that, I think it's worth talking about the things that we need to avoid, so as to "immunize" ourselves against possible future bad practices.
I really appreciate the input from everyone in this thread; I've learned a lot, and I have a lot to think about 🙂
Yeah, I understand, I don't think the majority wants WASM to be a better version of Java Applets :D
Currently there's a lot of JS going around, an some of it it's ill performing, WebAssembly could be a way to improve on that, not necessarily write an entire app in it on the server and just use the browser as a deploy target, but build a standard web app and use WASM if and when needed.
Paradoxically the long term view I've seen mentioned a few times by people interested in it is the one where WebAssembly becomes a universal binary target for regular apps.
I'm going to hype (sorry Ben :D) here but the dream here is to have a portable standard API. Imagine a situation where, because everything can be compiled down to webassembly, I can access the same battle tested functions (how many times as devs do we need to reimplement time.now().utc ?) for any language? Maybe even in an opensource standardized library.
I'm sure there's going to be people who abuse it (it happens to all technologies when they go mainstream, people use them for everything and anything) but we'll see.
This is a great overview of where we are and where we're going with WebAssembly, it also talks about the standard library/common interface thing: WebAssembly’s post-MVP future: A cartoon skill tree (you can skip down to "Outside the Browser" if you want to focus only on that part)
I'm pretty hype about WASM, though mostly just waiting for it to happen.
Everything outside the browser is so proprietary (Apple, Windows, Android, etc.) and WASM has the potential to open things up in that regard I think—And also allow for more powerful, reusable code.
(Google is doing its best to gradually make the browser their own proprietary platform, but that's another story).
Concerns here are real, but I think there's a lot to be pretty excited about with WASM.
Google is probably hoping to kick off a pretty big hype cycle around Fuschia I'd imagine.
Full-time web dev; JS lover since 2002; CSS fanatic. #CSSIsAwesome
I try to stay up with new web platform features. Web feature you don't understand? Tell me! I'll write an article!
He/him
I definitely agree with the overall excitement, and I think we've already seen some early successes. But regarding the proprietary code problem, haven't we tried this before with the JVM? It did pretty well for a while, but hasn't really solved the cross-platform problem. Do you (and anyone else who wants to chime in) see any major distinguishing factors between the two that might make WASM more successful than the JVM as a super-platform?
@rhymes
, you said, "I don't think the majority wants WASM to be a better version of Java Applets". Was that a reference to security issues, or performance, or just the "compile everything to JVM bytecode instead of writing JS" trend of the 2000s, or something else?
Full-time web dev; JS lover since 2002; CSS fanatic. #CSSIsAwesome
I try to stay up with new web platform features. Web feature you don't understand? Tell me! I'll write an article!
He/him
So then, is it really just JVM 2019? Nothing systematically different between the two, it's just more efficient at JIT? It's all just down to performance, not a matter of WASM doing something fundamentally different to the JVM or us using it differently or anything?
IIRC, the JVM didn't JIT at all back when applets first appeared. By the time it did it was too late and people equated Java with poor performance.
I suppose WASM is more tied in to the browser than the JVM tended to be. So that's a bit different (if you don't include any browser that was written in Java).
The programming model is different. Applets had a fairly well defined shape. WASM is more anything goes. Not sure if that really qualifies as fundamentally different though - it's certainly solving the same sorts of problems that Applets, ActiveX, Flash and Silverlight were meant to solve.
But regarding the proprietary code problem, haven't we tried this before with the JVM? It did pretty well for a while, but hasn't really solved the cross-platform problem.
WebAssembly's binary format is an open standard and can be reverse engineered. There's a text version of the binary and I'm sure "view source" tools will pop up when mainstream. You can already go from text to binary with command line tools. Is it super readable? No. But it's not proprietary. This is the first difference.
Another difference is that it's designed from the start to be cross platform, and already is: it's cross browser and cross platform.
Yet another difference is that all the major companies are backing it: Mozilla, Microsoft, Google, Apple are all in it and the major browsers support the 1.0 specification (backed by the W3C). An example implementation that's already in production is the one by Figma which used to speed up their design tool:
As you can see, our load time improved by more than 3x after we switched to WebAssembly regardless of document size. This is a huge improvement for our users, who often create very large design documents and frequently switch between them.
An additional load time benefit of WebAssembly that isn’t captured in this graph is that load time no longer depends on application size. As long as users have loaded the app before, the browser should already have the translation from WebAssembly to native code cached from last time.
WebAssembly doesn't need to be recompiled everytime so that's a plus :)
Was that a reference to security issues, or performance, or just the "compile everything to JVM bytecode instead of writing JS" trend of the 2000s, or something else?
No I just think they are two different things even if at the surface they can seem similar. WebAssembly can potentially be used as an applet. Drop a binary in a page and play a 3D game completely disconnected from the web around it. But it goes beyond that.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I'm a little nervous about the WASM hype. There's a sub-trend in there that showed up when WASM was first being discussed and has reemerged a few times since then that goes: "WASM means we don't need JS anymore! WASM means we can write the web in C# or Go!" And while the current counter argument is that that's just factually false, since WASM functions need to be imported into JS and run from there, that needn't always be true; if enough of the community clamors for end-to-end WASM apps, it'll probably happen eventually.
And I see a lot of potential danger in that idea: web app code becomes a lot less transparent, the attack surface of web apps dramatically increases, the potential for various walled gardens increases, the push to constantly improve JavaScript decreases, the complexity of web apps could blow way up...
But maybe I'm wrong; maybe those concerns are already present with WASM as it currently is, once it gets more mainstream use. And I do absolutely see its value. But still, I'm nervous. Not necessarily pessimistic, just... nervous.
This is right, WASM is far, far from being production ready, as it's a really unsafe option that will be a step back from the current web. Wasm is just a compiled bytecode that executes in the browser, it's usually C, C++ or Rust code in the background but once compiled to wasm it looks like this:
Good luck debugging this, and more importantly, good luck trying to figure what is this code meant to do on the client side. This code is much much harder to analyze than JavaScript because Wasm is a binary format whereas JavaScript is clear text. While malicious actors often heavily obfuscate JavaScript, deobfuscation is still relatively easy. By bringing Wasm into the game, bad guys get new ways to hide and obfuscate the intentions of their code.
And as there is still no viable WASM analyzers, an WASM app is just a blackbox to the user. The only thing that you can do is to analyze network requests and see if there is something suspicious there. In other words, say hi to the coin miners on every site, as with Wasm based approach, the return of investment will be higher for the malicious actors, since heavy math calculations can be done faster with Wasm than with JavaScript. To date, the majority of Wasm samples analyzed have been associated with cryptocurrency miners. Another opportunity for an attacker may be exploitation of hardware bugs.
On the side note it should be pointed out that Wasm is not intended to be seen as a replacement for JavaScript, but rather as a complement. For example, Wasm modules may be used for performing computation intensive tasks and JavaScript (and HTML) for providing the UI and gluing things together.
I guess that whole situation will improve with time, but, sadly, we're not there yet. Until then you can take a look here to learn how to disable WASM in the browsers.
Yeah, this is what I meant when I said the following:
My concern is that while it's currently the case that WASM is no JS replacement, I don't necessarily trust that it will remain true, especially given how loud the cry was from the "JS sucks" community that WASM will finally let us write for the web in "real languages" etc etc. I'm not catastrophically worried or anything, I think the developers of WASM have a stake in keeping it scoped pretty narrowly for the time being at least, but I don't think we can predict what the web will look like in 5-10yrs; I could see WASM turning into a core part of the web platform that can be used independently of JS, and I agree with your concerns if that does happen. Not ready to disable WASM just yet, though; squoosh.app is just too good 😁
That's right, once again 😄Web is evolving rapidly, and while my comment might seem grim and in disfavor of WASM, I really hope that it can evolve into something like Js today but without its bad parts. Sharing, collaboration, and open source are the keys for the better future, and I wouldn't want to see web locked down and obfuscated.
Also, that's really cool app :D Tnx for share!
@puritanic
I agree is far from being ready. I don't think it's inherently unsafe, it's boxed in the same box JS is. Regarding the step back or forward it really, really depends on what developers do and what becomes popular in the next few years. If all devs do with WebAssembly is "I can't wait to recompile my desktop app, ship it in the browser, call it quits and who cares about the web" yeah, we'll have a problem. But if it's used as a performance enhancer and used in conjunction with JS, why not?
WebAssembly has a text format though, not as readable as a normal programming language but I'm quite sure "view source" tools that make our lives easier will appear. I think it's too early to decide if WebAssembly will doom us all or not.
That's why we're saying it will take some time to become mainstream :)
@kenbellows
This is a real thing, but I also don't think that developers will start throwing all the web principles out of the windows just because they can finally code a textarea using Go. That's bonkers in my opinion. Also: WebAssembly still needs to talk to JS and has only a few types, I reckon that writing an entire app might even be counter productive :D
Squoosh is a perfect example of why one would use WebAssembly for the transformation functions to alter images and JS for the rest of the app
We'll see! :)
For more background on squoosh and the tech that went into it, in case you're interested: youtu.be/ipNW6lJHVEs
It was built by a Google team including some of the more public faces, like Mariko Kosaka and Jake Archibald, who present the talk at that link. It's a pretty neat discussion of PWAs, WASM, and applying them practically on the web now
thanks!
I was going to comment this myself, though I wasn't sure how usable the WASM text version is; I haven't read much about it. x86 has a text version as well, but it's horrible, haha. From the samples I have read it does seem like WASM's text version is much, much more readable and usable than traditional textified ASM.
I doubt that too, I think what I'm more nervous about is an influx of Go (or other language) developers who start saying, as you said, "I can't wait to recompile my desktop app, ship it in the browser, call it quits and who cares about the web".
Just to say it again, I'm not super pessimistic about any of this, I think our community is far more resistant to negative change than that. We're a very self-critical community that is willing to reconsider best practices over time, despite what some may say. And because of that, I think it's worth talking about the things that we need to avoid, so as to "immunize" ourselves against possible future bad practices.
I really appreciate the input from everyone in this thread; I've learned a lot, and I have a lot to think about 🙂
Yeah, I understand, I don't think the majority wants WASM to be a better version of Java Applets :D
Currently there's a lot of JS going around, an some of it it's ill performing, WebAssembly could be a way to improve on that, not necessarily write an entire app in it on the server and just use the browser as a deploy target, but build a standard web app and use WASM if and when needed.
Paradoxically the long term view I've seen mentioned a few times by people interested in it is the one where WebAssembly becomes a universal binary target for regular apps.
I'm going to hype (sorry Ben :D) here but the dream here is to have a portable standard API. Imagine a situation where, because everything can be compiled down to webassembly, I can access the same battle tested functions (how many times as devs do we need to reimplement
time.now().utc?) for any language? Maybe even in an opensource standardized library.I'm sure there's going to be people who abuse it (it happens to all technologies when they go mainstream, people use them for everything and anything) but we'll see.
This is a great overview of where we are and where we're going with WebAssembly, it also talks about the standard library/common interface thing: WebAssembly’s post-MVP future: A cartoon skill tree (you can skip down to "Outside the Browser" if you want to focus only on that part)
I'm pretty hype about WASM, though mostly just waiting for it to happen.
Everything outside the browser is so proprietary (Apple, Windows, Android, etc.) and WASM has the potential to open things up in that regard I think—And also allow for more powerful, reusable code.
(Google is doing its best to gradually make the browser their own proprietary platform, but that's another story).
Concerns here are real, but I think there's a lot to be pretty excited about with WASM.
Google is probably hoping to kick off a pretty big hype cycle around Fuschia I'd imagine.
I definitely agree with the overall excitement, and I think we've already seen some early successes. But regarding the proprietary code problem, haven't we tried this before with the JVM? It did pretty well for a while, but hasn't really solved the cross-platform problem. Do you (and anyone else who wants to chime in) see any major distinguishing factors between the two that might make WASM more successful than the JVM as a super-platform?
@rhymes , you said, "I don't think the majority wants WASM to be a better version of Java Applets". Was that a reference to security issues, or performance, or just the "compile everything to JVM bytecode instead of writing JS" trend of the 2000s, or something else?
any major distinguishing factors between the two that might make WASM more successful than the JVM as a super-platform?
20 years of development in JIT compilers.
So then, is it really just JVM 2019? Nothing systematically different between the two, it's just more efficient at JIT? It's all just down to performance, not a matter of WASM doing something fundamentally different to the JVM or us using it differently or anything?
IIRC, the JVM didn't JIT at all back when applets first appeared. By the time it did it was too late and people equated Java with poor performance.
I suppose WASM is more tied in to the browser than the JVM tended to be. So that's a bit different (if you don't include any browser that was written in Java).
The programming model is different. Applets had a fairly well defined shape. WASM is more anything goes. Not sure if that really qualifies as fundamentally different though - it's certainly solving the same sorts of problems that Applets, ActiveX, Flash and Silverlight were meant to solve.
@kenbellows , I'll try to answer :)
WebAssembly's binary format is an open standard and can be reverse engineered. There's a text version of the binary and I'm sure "view source" tools will pop up when mainstream. You can already go from text to binary with command line tools. Is it super readable? No. But it's not proprietary. This is the first difference.
Another difference is that it's designed from the start to be cross platform, and already is: it's cross browser and cross platform.
Yet another difference is that all the major companies are backing it: Mozilla, Microsoft, Google, Apple are all in it and the major browsers support the 1.0 specification (backed by the W3C). An example implementation that's already in production is the one by Figma which used to speed up their design tool:
WebAssembly doesn't need to be recompiled everytime so that's a plus :)
This is really a great intro if you want to understand it better: WebAssembly. Neither Web Nor Assembly, All Revolutionary
No I just think they are two different things even if at the surface they can seem similar. WebAssembly can potentially be used as an applet. Drop a binary in a page and play a 3D game completely disconnected from the web around it. But it goes beyond that.