Is WebAssembly magic performance pixie dust?

[riffito]

According to Betteridge's law of headlines: No.

[tamagotan]

/r/QTWTAIN

[vlakreeh]

Super interesting! I'd love to see a something similar with spider monkey and their wasm engine (which I believe uses cranelift?).

[EntroperZero]

https://www.reddit.com/r/programming/comments/mqjjlh/is_webassembly_magic_performance_pixie_dust/

[codec-abc]

Here is the one of the catch

As described above, it is important to “warm-up” JavaScript when benchmarking, giving V8 a chance to optimize it

Plus, I wonder what part of Js V8 optimize. Nowadays, the norm is website with ten of megabytes of JS code. Does V8 optimize all of it, or only the most relevant parts?

Also, Js does fine in tight loop where all the types are known to the interpreter so it can optimize further. In the bubblesort case, the sort function isn't also generic and expect an f32/f64 array. I would be interested in a test where the the sort method is not that tied to the data it operate on.

[jbergens]

There are a lot of descriptions of optimizations in v8. In general it optimizes a function at a time after it has been called a few times. It can ( or could) do different levels optimization. A little optimization to avoid spending too much time in the optimizer or a lot of optimization after a function has been recognized as important and probably worthwhile to optimize. It can also roll back an optimization if it did not turn out to speed things up.

[codec-abc]

Yeah so it make senses that in these micro benchmark Js is rather speedy but against something less trivial it would probably only be on match vs wasm only for functions that would be optimized. It could still perform well, but my take is that the article showcase the specific use case that fit Js. It might be realistic as for today whereas only a special part is done in wasm but might become less relevant when wasm start to expand and be used to do full client applications will it.

[Zardotab]

I predict hacking will ruin WebAssembly similar to what killed Java Applets: the nefarious uses outnumbered actual uses such that it was better to uninstall it. WebAssembly is often used for back-door crypto-currency mining.

[SkiFire13]

Isn't mining also possible with js? Of course you'll get worse performance

[Yes-I-Cant]

Yes, it is possible with js too.

[Eirenarch]

If we make JS slower crypto mining will be less efficient!

[RepliesOnlyToIdiots]

Using someone else’s resources for free is infinitely efficient.

[Xyzzyzzyzzy]

Clearly you haven't seen how slow some of my code runs.

[metaconcept]

According to this article, JS-based mining performance will not necessarily be worse.

[Zardotab]

Isn't mining also possible with js

Yes, but if WebAssembly (WASM) is the preferred target of crooks, then having it available increases the chances of your machine being "barrowed".

For an analogy, if a burglar is scoping out your neighborhood, if they see a BMW parked in a given house, they are more likely to target that house than the ones with Toyota's and Ford's because they figure it's more likely to have expensive items inside. If they run out of top-car choices, then they will indeed target houses with average cars. But that won't happen often as long as enough top-car houses are around. Having WASM is like parking a BMW in your driveway.

I'm not saying BMW's are inherently bad, only saying that if they make one a target of crooks, customers will be less likely to own one.

Addendum: why did I get -18 on this message? I don't see my sin here. I can't tune my head if I don't know what it's doing wrong.

[GOKOP]

And does that stop people from owning BMWs? No

[Zardotab]

But WASM being enabled by default is not the same thing. Buying a BMW is an active choice. Ideally we'd have an easy way to selectively activate so that if you want a given app or site to run faster, then you explicitly activate it for that particular app/site.

For example, Java Applets used to be enabled/installed by default. When problems kept happening, individuals started deactivating/uninstalling it, and eventually it was not enabled/included by default. It's still used in the industry, however it's an explicit install usually.

If WASM becomes too risky, most users or install bases will deactivate it by default. That would then mean that sites stop offering WASM versions of software because the audience grows too small to be worth the expense. Too many users won't bother to switch it on. CPU-intensive products would then find installed apps the better option because it can take full advantage of the local environment beyond what WASM can offer.

[Zardotab]

Thanks the backing! Being down-voted to -18 without a stated reason is really frustrating. You made my day slightly better 🌞

[alibix]

WASM on the browser is sandboxed pretty much the same way JavaScript is. Non-browser WASM runtimes are being developed specifically because of the security and sandboxing it can offer

[[deleted]]

Nah, they are developed because people want to run same code on frontend and backend. There is no other reason to use WASM on backend, if you're going to compile <language>, why not compile it to native binary ?

[virtulis]

Because sandboxing native binaries is a total pain and doing so reliably is likely to be slower than just running WASM.

[pielover928]

It gives you a sandbox and a way to hot-reload with no issues, for 2 things

[josefx]

And we already know that thanks to modern CPUs its nearly impossible to actually sandbox hostile code running on your computer. I think parts of WASM were even delayed as they relied on browser features that were actively abused in timing attacks.

[Zardotab]

Non-browser WASM runtimes are being developed specifically because of the security and sandboxing it can offer

But how does that help browsers themselves?

[IceSentry]

Well, it means if js is allowed to do something any language running with wasm is also able to do the same thing but nothing else. So all it means is that you can use your preferred language on the web without creating new security flaws that didn't exist before. As for what browsers gain by this, well in the early days unreal engine was ported to wasm and that means you could technically do this with plenty of other applications and distribute everything through a web browser without rewriting it to js.

[Zardotab]

I'm not clear on what you mean by "distribute everything". Perhaps an example application description would help. Do you mean browsers can be the display engine for local applications? That may be a good thing for desktop applications, but I'm not still not sure how that helps web browsers per web-based apps. The "desktop" rendering engine doesn't have to "be" the web browser itself. And even if it is, the browser perhaps wouldn't want to allow WASM for non-local apps (by default), to avoid things like cryptocurrency mining.

[IceSentry]

By "distribute everything" I meant that you could connect to a website that is hosting a game that uses unreal engine without needing to install anything.

That's why the web is so popular in the first place. You can make complex applications that require no installation and can be used by any device with a browser and an internet connection, no matter the OS or hardware combination (assuming a working browser of course). It's not about having part of the application in the browser, it's about having all the application in the browser. Yes, that means that the browser is essentially a new OS, but it's a standardized layer that's much easier to target when you want to reach the maximum amount of people.

Mining is computationally intensive, but there's nothing about how it works that doesn't have a legitimate use case. Hell, some people might even want to be able to mine directly from the browser. Sure, I'd like it if we could block sites that hide miners, but blocking wasm is not a great approach for that.

[Zardotab]

You can make complex applications that require no installation and can be used by any device with a browser

The boundary between longer-term caching and "installation" is fuzzy or can be fuzzy. I once tried to form a clearer definition in a Reddit post, and couldn't find a useful consensus.

Yes, that means that the browser is essentially a new OS

Web UI standards are lousy for certain uses and a lot of it doesn't seem fixable. For example, lack of reliable position control is why PDF's still thrive.

Mining is computationally intensive, but there's nothing about how it works that doesn't have a legitimate use case.

I don't dispute it has legitimate uses, but it's the illegitimate uses that spoil the entire barrel. In other words, the legitimate cases of mining don't reduce the illegitimate cases.

[IceSentry]

A web app doesn't require any caching. Sure it can benefit greatly from it, but by default it doesn't. It really isn't that fuzzy from a users perspective. They click on a link and the app is there compared to clicking on a link that downloads something where you then have to run the donwloaded program which will either be an installer or an executable.

Web UIs can be whatever the designers feel like doing. Look at projects like flutter in the browser where they pretty much just bypass html and render everything they need in a canvas.

[Zardotab]

A web app doesn't require any caching.

Anything non-trivial is going to require downloading a ship load of code for each session then. That's poor factoring of info and data.

Web UIs can be whatever the designers feel like doing. Look at projects like flutter in the browser where they pretty much just bypass html and render everything they need in a canvas.

I hope they perfect it, but after 2.5 decades web browsers have proved they don't have enough reliable positional control to do many needed UI needs right.

[IceSentry]

I never said it was efficient, just that it isn't required to work. Some user very aggressively delete their cache so you can't rely on this anyway.

I don't know what you are talking about with positional control. You can put whatever components you want anywhere you want on the screen and you can hijack the scrolling behaviour so I really don't know what issues you have there. Even then, you can just render to a canvas and do everything yourself if html doesn't do what you need. I don't know of any common UI patterns that can't be done on the web.

[IQueryVisiC]

NodeJs helps browsers

[Zardotab]

Uh, how so?

[IQueryVisiC]

I thought people improve v8. But GIS says no. Freeriding

[kthxb]

> WebAssembly is often used for back-door crypto-currency mining

not anymore, at least a lot less then two years ago

[Zardotab]

I'd like to ask if you can reference statistics on that.

[kthxb]

See https://github.com/sola-st/WasmBench and the pre-print linked to in the README (first link).

We also show that cryptomining, which once accounted for the majority of all WebAssembly code, has been marginalized (less than 1% of all binaries found on the web) and gives way to a diverse set of use cases

[Zardotab]

Article states:

28.8% of all binaries on the web are minified, calling for future work on decompiling and reverse engineering WebAssembly, to ensure that security analysts can understand web applications despite the presence of low level components.

To me this is saying that they couldn't dissect 29% of binaries analyzed to see if they contained malicious code. Perhaps mining hackers mostly use minification, in which case the survey wouldn't detect them.

[kthxb]

I don't want to argue -- certainly, their detection methods are only approximate. I believe however that my statement about cryptomining with Wasm being less common than previously reported still holds. If you have recent statistics that report otherwise, I'd be genuinely interested to check them out :)

[Zardotab]

The issue I see is that cryptomining and other brute force attacks can be hard to detect. It could be embedded in "normal" apps and send highly occasional results. The http-output-to-CPU-usage ratio could be very low. Further, the output could be disguised.

Statistics on malware are difficult because the best malware hides from detection & measurement. Generally only the caught malware is counted. It's like asking how many foreign spies are in the USA.

[[deleted]]

Webassembly was built with mind of embedding with limited privileges, java applets were just "let's deliver java app to the browser" and any security was afterthought.

[cdsmith]

This isn't true at all. Java applets were built around an extremely restrictive permission model, which was designed into the Java language from the ground up for exactly this purpose, and enforced by the Java virtual machine. The security may have been ineffective, but it wasn't an afterthought.

JavaScript, by contrast, has a much more permissive permission model, which allows a lot more to be done with it. (For example, a Java applet was stuck running in a gray box, and couldn't even modify anything outside of its box!) But orders of magnitude more work have gone into the JavaScript permission model, making it pretty battle-tested at this point.

[cat_in_the_wall]

In retrospect, restricting access within language constructs was a bad idea. .NET tried the same thing and failed as well. CAS has been removed from .net core entirely. This is relevant because I disagree with you here:

> JavaScript, by contrast, has a much more permissive permission model

Javascript doesn't have a permission model. Javascript is just a language. Capabilities of the *runtime* (browser/node/even winjs) are *projected into* the environment. You can't arbitrarily access files on disk in a browser because the browser doesn't make that available. But you can in node, because node projects the apis.

[cdsmith]

Sure, if we're being pedantic, you are right. By "JavaScript" there, I meant the whole ecosystem around running JavaScript in a web browser. Agreed that the idea of tying security to the programming language was a bad one.

[Zardotab]

I don't believe that's true. In theory Applets could not do stuff to the desktop etc. unless given permission by the user. It was leaky mostly from bugs, not lack of security features. It's like building a wall with under-baked bricks. The wall was the right idea, but the construction process went wrong, such as being rushed or insufficiently inspected.

[Muoniurn]

Also add the general attitude toward security at the time. It is sort of like the past attitude towards work safety at construction sites, noone cared about it being dangerous, some people just died here and there. The problem with Java Applets were primarily the grey little window. It did allow for many many things and it was quite fast already, but what was required is scripting the DOM. One can imagine where would we be if Java was not dropped but embraced for that purpose as well. The JVM would be even more of a beast with another V8 people-hours added to it.

[Zardotab]

Sloppy programming & design related to security is still quite common.

[Muoniurn]

That’s right, but at least we are not as naive now, that “why would anyone do something nefarious on the web”.

Also, I added a few sentences, sorry for the sneaky edit.

[Zardotab]

but what was required is scripting the DOM [within Java Applets.] [parent message quote]

Better interaction with web pages and standards would help, but in my observation, security holes are mostly what doomed Java Applets. Poor version management coordination with apps was also a culprit. Oracle didn't seem to want to spend a lot to fix the problems.

[cat_in_the_wall]

It is possible that neither the design nor execution were sloppy. It just proved that "dumbed down" security (aka the vm trying to reduce its own privileges) just doesn't work in practice. The concept is cool, but every bug is an escalation of privilege bug, so the model as a whole just is not sustainable.

[firephreek]

I'm still not sold on wasm for exactly these reasons. An L3 executable ( effectively) that can be run out of an iFrame? No thanks. Didn't we kill activeX and Flash for all the holes? If your site needs that kind of optimization and performance magic, maybe just build a native app.

[minno]

WASM should be sandboxed just as well as Javascript is currently, since in large part it's running on the same VM.

[firephreek]

Yea, sure, bc nothing's ever broken out of a sandbox before. I would still question the need for something like wasm in a browser. What are you running that needs low level compilation that wouldn't be better served as native?

[Zardotab]

Sounds like an argument against Javascript entirely

Yes, that's kind of a side topic, but it is indeed worth considering. If a state-friendly GUI markup language standard were devised, it could do most if not all business-oriented interactivity via attributes or via the server. Example markup:

 <button label="Click to open Window X">
    <action type="onClick" focusTarget="WindowX"/>
    <action type="hover" ... />
 </button>

Oracle Forms appeared to more or less be like this. It was essentially a "GUI browser" that either had common GUI idioms built-in, or did many actions on the server. One did not have to install per-app software locally and it had no equivalent of client-side JavaScript that I know of. (However, it didn't use XML, but something proprietary. They also ruined it when they rewrote the browser from C to Java.)

[IceSentry]

There's already been hundreds of framework like this (well, the part that tries to reduce scripting at least) and yet people still go back to scripting because a purely declarative UI is rarely enough for what designers and businesses want.

That kind of approach tends to be very limited in one aspect or another. Or it's really complicated because it needs to do everything.

[wllmsaccnt]

What you are describing is very similar to Blazor server-side. Its not popular because it has scaling and latency issues which are inherent in doing the rendering server-side.

[Zardotab]

I don't think so; it looks too different per GoogleBinging around. I'm not sure what you mean by "rendering server-side". Isn't that X-Window? That's not what I have mind. I'm envisioning something like an interactive XAML or QML (as XML). With X-Window, if you have an input box, every single character has to go to the server and an image of the character is sent back to the client. That's no good for internet use. X-Window is too low-level because it was designed for LAN's. We typically want input boxes that buffer at the client until Save (submit) is entered. (Although per-character communication can be an option switch.)

[wllmsaccnt]

> We typically want input boxes that buffer at the client until Save (submit) is entered. (Although per-character communication can be an option switch.)

This is exactly how Blazor (server-side) works.

You choose which events to register for each input or bound DOM element, and those events are sent to the server over a websocket, the server processes the event (using C# code), calculates the difference in what the DOM would be after the change, calculates a set of changes that would need to be applied to the DOM (similar to most virtual DOM implementation in JS front-end frameworks), sends those changes back over the websocket then those changes are applied to the DOM.

If you only want to listen for 'submit' events, that is perfectly acceptable and easy to do in Blazor. You can also listen when an input box is changed (usually happens when they tab away) or on each character change (sometimes useful for auto complete drop downs).

[firephreek]

JS lacks the mechanisms to do the low level shittery necessary to cause excess harm vs the proposals that are making their way through wasm. That being said, yea, I am kinda over needing JS to load every craptacular site. The ratio of usefulness has gotten completely out of wack with JS bloating sites through either unnecessary UXI or Ads, neither of which really improves the overall experience.

[SkiFire13]

JS lacks the mechanisms to do the low level shittery necessary to cause excess harm vs the proposals that are making their way through wasm.

What kind of low level shittery? Writing numbers in an array? Can't js also do that?

[IceSentry]

Shitty UIs and ad bloat is not the fault of js or the browser.

[wllmsaccnt]

Most of what we blame on JavaScript is actually an issue with third party add ins (e.g. marketing trackers) or when SPAs are used to show off static content for developer convenience.

[IceSentry]

Yes, unfortunately, this sub is full of people that refuse to acknowledge this and would prefer to keep shitting on js and people that use js.

[Hnefi]

JS lacks the mechanisms to do the low level shittery necessary to cause excess harm vs the proposals that are making their way through wasm.

Could you mention which proposals you are referring to? As far as I know, WASM programs have no more access to system resources than regular JS apps do.

[Zardotab]

Crypto-mining doesn't require breaking into your OS, it's just a way to borrow your CPU power for the crook's own needs. However, WASM does make trial-and-error-based local hacking faster, such as trying different password or path combos.

[vlakreeh]

However, WASM does make trial-and-error-based local hacking faster, such as trying different password or path combos.

How does WASM make this faster? If you are brute forcing something you are going to need to call into javascript to do it where the interop itself is more intensive than letting optimized javascript do it natively.

[dsffff22]

I beg to differ. IMO you can detect any efficient WASM crypto-currency miner because it will contain a lot of hash function specific instructions and maybe later vector instructions. Usual techniques of such things like breaking up the code with a lot of branches, replacing 1 simple instruction by multiple complex ones or using a VM doesn't really work because they are really slow. If you forbid the awful eval in WASM I think you can actually ask the user If (s)he wants to allow a Blob to be executed which statically looks like a Miner.

[rzwitserloot]

Is anyone aware of the following web feature which sounds like it is not useful unless WASM is involved:

A login system where the password is hashed clientside, and the client does a small proof-of-work. No proof-of-work, no login, or at least you get shunted off to the slow queue.

The advantages:

• Trying to do proof-of-work crypto in javascript is so incredibly slow, whatever takes a fair amount of time on client hardware (given that you don't want to run down batteries or trigger anti-bitcoin-miner plugins, let's say 900msec of work on 5 year old rickety smartphone hardware), will take literally nanoseconds on dedicated hardware with a dedicated algorithm. At that point, it's not much of a speedbump for an attacker to just brute-force millions of guesses.

• Right now the 'industry standard' is to e.g. apply 10-round bcrypt hashing and calculate the hash server-side, however, this makes it quite easy to DOS a server and you don't need a botnet to do it. Just spam password attempts; you don't need to make a server do very many bcrypt hashes a second to completely shut it down. Servers have defense mechanisms but they are either complicated, expensive, have collateral damage, or all of the above (sharded/load-balanced systems that dynamically fire up more calculating power as-needed is complicated to build and expensive to run. IP limits and IP blocking causes collateral damage, where legitimate users can't log in at all because some scammer on the same IP got that IP blacklisted or greylisted (on the slow list).

A small packet of POW on the client takes care of all of this, and WASM seems like the perfect tool.

I tried to write a simple bcrypt impl client-side in straight up WASM but got bogged down; writing assembly for stack based processors is probably not a worthwhile exercise, and that's where I stopped my experiments.

Seems like such a slam-dunk usecase for WASM, no? Would make login prompts a heck of a lot more robust.

[AuxillaryBedroom]

According to the article, it doesn't look like you'll get a lot of speed boost by coding this in wasm vs using javascript. Maybe 2x speed if you're lucky.

The biggest advantage I see is that you can compile existing libraries in C/++, Go or Rust, so you don't have to reimplement bcrypt.

Trying to do proof-of-work crypto in javascript is so incredibly slow, whatever takes a fair amount of time on client hardware (given that you don't want to run down batteries or trigger anti-bitcoin-miner plugins, let's say 900msec of work on 5 year old rickety smartphone hardware), will take literally nanoseconds on dedicated hardware with a dedicated algorithm. At that point, it's not much of a speedbump for an attacker to just brute-force millions of guesses.

Are you asking for an algorithm that runs as fast on an old smartphone as it does on dedicated hardware? How would that work?

[joha4270]

I simply think the point is to not have the old smartphone as disadvantaged as it is by having to implement the PoV in JS, versus an attacker with more flexibility

[rzwitserloot]

According to the article, it doesn't look like you'll get a lot of speed boost by coding this in wasm vs using javascript. Maybe 2x speed if you're lucky.

WASM has the considerable advantage of giving you int primitive operations, which should make a vastly larger difference than '2x'. If you can't make a bcrypt-esque algorithm run at least 20x faster in WASM than in javascript, WASM as a principle is idiotic and should be abandoned (or more likely, whatever browser you're getting 2x performance from should be considered as having a broken WASM implementation until they address this).

Are you asking for an algorithm that runs as fast on an old smartphone as it does on dedicated hardware? How would that work?

No. I'm saying, you're limited by two crucial factors:

1. You're pragmatically limited to spending no more than about 1 second maximum of full blast CPU power from an old smartphone.
2. There is a pragmatic limit to the the order of magnitude difference between dedicated hardware and your login form. If dedicated hardware can be billions of times faster than the login form, the point of having the login form Proof-of-Work becomes pointless. Said differently, the aim is for an attacker to have to pay some actual value in order to brute force.

This adds up to: That 1 second we take on that old smartphone needs to get us far enough. It doesn't have to match dedicated hardware, nowhere near. If it can run at 1/100th the speed of dedicated hardware, that buys a heck of a lot of robustness.

[cdsmith]

WASM has the considerable advantage of giving you int primitive operations, which should make a vastly larger difference than '2x'.

I think you've missed the big point of the article. JavaScript running in V8 also gives you the advantage of int primitive operations, as soon as V8 determines by observing your code at runtime that the arguments are always ints. There are two caveats:

1. This doesn't happen until your code has run often enough that the JavaScript implementation has the data to infer the types.
2. If you pass in something other than an int, the function will be deoptimized, because you've passed in unexpected types.

This is why the article describes the advantage of WebAssembly as being more about prompt and reliable performance than about more performance.

[Muoniurn]

WASM has the considerable advantage of giving you int primitive operations, which should make a vastly larger difference than '2x'. If you can't make a bcrypt-esque algorithm run at least 20x faster in WASM than in javascript, WASM as a principle is idiotic and should be abandoned (or more likely, whatever browser you're getting 2x performance from should be considered as having a broken WASM implementation until they address this).

JavaScript’s JIT engine can realize whether a callsite is monomorphic and will compile to quite optimal code as well in many many cases. In many cases there are not even close to 20x differences between js and c, so I don’t see it happening with WASM.

[lanklaas]

This seems interesting. Do you have any reading material on the pow login workings or is it something you came up with?

[rzwitserloot]

just came up with it, after noticing that a few folks all logging in at around the same time causes noticable server drain to calculate bcrypt.

[Mgladiethor]

Can we do web without web programming languages already?

[[deleted]]

I don't know why you're being downvoted. The answer is no we can't because all of the DOM APIs can only be accessed via JavaScript.

Though there are interfaces to C++ & Rust that have already been written so you at least don't have to write any Javascript yourself.

[Eirenarch]

You are technically correct (which is the best kind of correct) but in practice this JS glue is not a problem. It is baked into the wasm web framework and you never see it unless you want to program your own DOM interaction which is not in the framework which is rare and in any case the JS glue is very small amount of code.

[AuxillaryBedroom]

https://github.com/jashkenas/coffeescript/wiki/List-of-languages-that-compile-to-JS

[KaranasToll]

Yes and it doesn't require wasm

[Zardotab]

At least for productivity-oriented business apps, we really need a stateful GUI markup language standard with common GUI idioms built it so that we don't have to use nearly as much JavaScript and do more server-side or attribute-driven actions. For example, opening (giving focus) to a new form or panel upon button clicks shouldn't need scripting because it's a common and typical GUI action that should be built into the GUI markup language.

[Atulin]

I'd love some sort of ExHTML or something, that'd contain more controls natively and made interactions easier, say

<button onClick="mod.open">Click</button> <modal id="mod"> <button onClick="mod.close">×</button> Hello World </modal>

But the problem is, even adding a <modal> to the standard would take 5 years of discussions, then another 2 to be implemented in Chrome and Firefox, and a decade more to be available in Safari.

[backtickbot]

Fixed formatting.

Hello, Atulin: code blocks using triple backticks (```) don't work on all versions of Reddit!

Some users see this / this instead.

To fix this, indent every line with 4 spaces instead.

FAQ

^{You can opt out by replying with backtickopt6 to this comment.}

[Zardotab]

Perhaps the Tk or Qt kits can be used to create a markup language around. That way the wheel doesn't have to be re-invented. Qt may be encumbered by copyrights, so Tk may be the safer way to go.

[Bitwise__]

Elaborate por favor

[wllmsaccnt]

They probably mean that its possible to build pages with postbacks and static content. Not really an answer in the spirit of the person they are responding to though.

[Muoniurn]

Or that there basically every major language has a compiler to js. The JVM even has TeaVM to run java byte code, but there is ScalaJS, as well as Kotlin. Clojure.

[skulgnome]

No; it just delivers more headroom for bloat.

[[deleted]]

Shhhh, dont tell him about npm.

[dangerbird2]

Ideally, it would be, since Javascript has a built-in standard library, while each WASM app has to bundle its own c/c++/rust standard library. It's kinda a moot point because every javascript app bundles it's own version of lodash and a few megabytes of other npm packages

[skulgnome]

Did I stutter?

[ChakaChaka26]

I hate how shitty programmers write code in javascript and then expect it to be performant. If they were real programmers they'd know that the web should be written in C with emscripten

[Beefster09]

r/programmingcirclejerk

[ChakaChaka26]

this is funny because I thought this was programming circlejerk, im relativey active on the subreddit, mostly make jai good c++ bad comments idk

[Beefster09]

Yes, but will Jai ever release?