> [wasm] is executed in a stack-based virtual machine rather than as a native library code.
Wasm's binary format is indeed a stack-based virtual machine, but that is not how it is executed. Optimizing VMs convert it to SSA form, basic blocks, and finally machine code, much the same as clang or gcc compile native library code.
It is true that wasm has some overhead, but that is due to portability and sandboxing, not the stack-based binary format.
> On top of the above, memory available to WASM is limited by the browser (in case of Chrome, the limit is currently set at 4GB per tab).
wasm64 solves this, by allowing 64-bit pointers and a lot more than 4GB of memory.
The feature is already supported in Chrome and Firefox, but not everywhere else yet.
The JVM is designed around Java. That's really the main difference, and it brings some downsides for the goals of wasm, which include running native code - think C++ or Rust. The JVM is great at Java, which relies on runtime inlining etc., but not at C++, which assumes ahead-of-time inlining and other optimizations.
There is an in-between, which is the world we live in right now.
JavaScript and TypeScript are great languages with excellent Web integration, whereas wasm is focused on pure computation (forcing it to bundle its standard library, for example). But wasm has predictable performance that is close to native builds, and sometimes you need that.
Very few web pages use only wasm. Most uses of wasm on the wasm are as part of a JavaScript site, for the parts where wasm makes sense.
I'd bet the current state is not sustainable and we will see a consolidation one way or another.
The danger for WASM is that JavaScript doesn't stand still either and we might as well see improvements that make the gap to WASM's selling points smaller.
JavaScript is being developed with the assumption that wasm will continue to exist. For example, JS is unlikely to get SIMD support because wasm can do SIMD in a cleaner way than JS can. (I am one of the people developing JavaScript.)
Rather, what we're likely to see is work which makes integration between wasm and JS easier - see, for example, the wasm string builtins proposal [1], the proposal for native support for importing wasm from JS [2], or the proposal for fixed-layout JS objects which would allow directly reflecting wasm-GC objects in JS [3].
> Where is WASM in the browser really used apart from crypto miners?
Art and design: Photoshop, Figma
Games: Unity, many other engines or components inside engines (e.g. Bullet)
Videoconferencing: Zoom, Google Meet, etc.
Productivity: Google Sheets
Other: Google Maps and many, many more. For example, here is a talk about how Google uses wasm in a large range of its products: https://www.youtube.com/watch?v=2En8cj6xlv4
Look, wasm is a supplementary technology, used where JavaScript isn't good enough, like all the examples I just gave. Those use cases work extremely well right now, and most users on the web benefit from wasm, even if they are unaware wasm is running on the page - which is how it should be.
That is exactly the success that wasm aimed for from the start.
People have made that same argument about Java applets 25 years ago and we all know how that panned out.
I see your point and I see and love the advantages of WASM but I doubt they will be enough to outweigh the burden to support two ecosystems in the long run. Support in the browser, as well as on the development side.
"That is exactly the success that wasm aimed for from the start."
If this is true WASM has been doomed from the start. If WASM doesn't set out to eat JavaScript's cake it will be left with the crumbs and slowly but surely starve to death.
The difference with Java applets from back then is that wasm was designed by web browsers in order to work well in them.
Java applets were plugins, which led to security issues, and worse, security issues not under the control of the browser. Wasm is a proper part of the browser.
Java applets had limited interop with JavaScript and HTML. Wasm is also somewhat limited there, but it was designed to at least have fast calls to JavaScript itself.
Java also has language-specific issues. Most native code that people want to run on the web is not written in Java or another JVM language. Wasm was designed to support compilation from C++, Rust, etc. (and it has recently added Java support too).
WASM is also great for enabling web apps to locally perform tasks that would be compute/bandwidth intensive if foisted upon the server.
E.x. the Cobalt video downloader has an experimental on-device video remuxing feature that uses FFmpeg (libav) compiled to WASM. It's a win-win for both the provider (who saves on hosting and bandwidth fees) and the user (who enjoys snappier functionality and enhanced privacy guarantees.)
Exactly, the point is that C++ added templates as a huge new language feature, while in Zig it is just one of the things that is immediately possible thanks to comptime.
Needlessly replacing a working item is over consumption. An EV has much more embodied carbon compared to an ICE vehicle and needs 20,000 miles to "break even." I'm likely 2 years away from that given our driving habits.
You could argue that the next driver will pick up the slack for me, but I can't guarantee that to be the case.
While both those points would normally be valid, this is a pretty unique one-time event.
The best way to look at it is that cars are getting redistributed: left-leaning people that bought Teslas are trading them to right-leaning people (that's who are buying such cars today).
Those right-leaning people are getting fairly good deals from their perspective, and they'll use those cars, same as any traded car.
In fact, this is probably going to be a net win for the environment, because for many of those right-leaning people this will be their first electric vehicle, and some of them will continue that habit going forward. This is bringing EVs to a population that was resistant to them until now.
Reddit might not be representative of the larger shift. I am sure there is plenty of hatred, and even violence that makes the news, and that stuff is bad, but I mostly see people politely nudging those they know that own Teslas to sell them.
Which makes sense. The company sold to left-leaning, environmentally conscious buyers, and the CEO has now rebranded Tesla to basically the worst thing for that demographic. Sales are down, resale values are dropping, and insurance rates are rising. And there is no real opportunity on the horizon to save the company and/or the brand (robotaxis without LiDAR..?)
Maybe it looks like scorched earth on reddit, but in reality it's just a lot of people realizing the brand has self-destructed.
> He’s pro Israel and want less government regulation. I’m no expert, but to me that seems anti-Nazi?
Elon obviously does not tick off every box for "Nazi", but he gets so many that a lot of people are understandably horrified.
The salute was, physically, a Nazi salute - as any video comparison clearly shows. And he did it twice. Maybe he didn't "mean" it - maybe it was ironic, maybe it was for kicks, but it obviously was one.
Add to that his support for far-right parties around the world. That includes Germany, and, yes, Israel - while historic Nazis were antisemites, but some far-right people today find common ground with the far-right in Israel, which is exactly who is in power there now.
And Elon is allied with Trump, who got elected after a campaign in which he demonized immigrants as "poisoning the blood" of the nation, said that (legal!) immigrants were "eating the cats and the dogs", etc. etc. Those are classic lines from far-right, fascist governments. Demonizing gay and trans people as well, and Elon has done plenty of that himself.
So, is Elon just "far-right" and not "Nazi"? I'm not sure it's worth debating the difference. Obviously literal card-carrying Nazis are in the past, but the overlap between the modern far-right and historical fascism is enormous.
> Is there a JITing C compiler, or something like that?
Yes, for example, compiling C to JavaScript (or asm.js, etc. [0]) leads to the C code being JITed.
And yes, there are definitely benchmarks where this is actually faster. Any time that a typical C compiler can't see that inlining makes sense is such an opportunity, as the JIT compiler sees the runtime behavior. The speedup can be very large. However, in practice, most codebases get inlined well using clang/gcc/etc., leaving few such opportunities.
[0] This may also happen when compiling C to WebAssembly, but it depends on whether the wasm runtime does JIT optimizations - many do not and instead focus on static optimizations, for simplicity.
Wasm's binary format is indeed a stack-based virtual machine, but that is not how it is executed. Optimizing VMs convert it to SSA form, basic blocks, and finally machine code, much the same as clang or gcc compile native library code.
It is true that wasm has some overhead, but that is due to portability and sandboxing, not the stack-based binary format.
> On top of the above, memory available to WASM is limited by the browser (in case of Chrome, the limit is currently set at 4GB per tab).
wasm64 solves this, by allowing 64-bit pointers and a lot more than 4GB of memory.
The feature is already supported in Chrome and Firefox, but not everywhere else yet.