Hacker News Reader

Comment by CharlesW | Hacker News Reader

Wasm isn't a replacement for JavaScript. I think it's clever to leverage JavaScript as an interface to an ever-changing and extremely broad suite of native browser APIs, and keep Wasm small, fast, and secure.

View on HN

> Wasm isn't a replacement for JavaScript

I think a lot of people want it to be a replacement for JavaScript. And I think that makes sense, if for no other reason than learning JavaScript is a hassle. Lots of folks think of themselves as a C# developer, or a Python developer or whatever. A lot of developers would rather make websites in their language of choice than learn JavaScript. (And who can blame them?). Webassembly (with GC bindings) should be able to make that possible.

Indeed. node.js was popular in part because you can use the same language on the client and the server. All-WebAssembly no-JavaScript sites would allow the same thing with other languages.

Learning new languages may be component of it, but I think more generally, different languages are suitable for different problems and different developers. Being free to use the most suitable or preferred tool for a task is undoubtedly desirable, rather than having JavaScript as the only option.

And, while more of a personal opinion, JavaScript is not a well designed language - permanently shackling the web to it prevents progress forward.

As much as many people want alternatives to JavaScript, there are also people who consider themselves JavaScript experts (or the various related languages like TypeScript). They’ve invested a ton of time and effort into getting to where they are.

There’s a balance between disruptive change and keeping these folks on board. Get it wrong and you’ll end up with it strangled in its cradle.

My own take is that low-code platforms will continue aggressively moving into this space, especially in the enterprise space. They come with their own problems and are often aggressively overhyped, but they will put pressure on “traditional” developers to move faster and look for better solutions.

"As much as many people want alternatives to JavaScript, there are also people who consider themselves JavaScript experts (or the various related languages like TypeScript). They’ve invested a ton of time and effort into getting to where they are."

I do not see a problem here. The idea is not to replace js (not realistic anyway), but to have a full working alternative to not have to use js anymore, so in the end you can really choose how to build for the web.

I also invested heavily into js ... but I am really looking forward to the day, I can use something sane again.

> A lot of developers would rather make websites in their language of choice than learn JavaScript. (And who can blame them?).

Personally I’m quite happy to blame them. If I want to do ML I use Python, if I do statistics I use R, for messing with Windows I use C#, for using databases I use SQL and for the web I use JavaScript. I think that refusing to learn other languages is a foolish consistency.

If those all compiled to WASM, then you can mix and match freely.

Already possible in .NET for years, it is called Common Language Runtime for a reason.

Also TIMI on IBM i, language environments on z/OS, among other examples.

True, but imagine being able to interop with all the languages ;)

I don't need to imagine,

> More than 20 programming tools vendors offer some 26 programming languages — including C++, Perl, Python, Java, COBOL, RPG and Haskell — on .NET.

Taken from https://news.microsoft.com/2001/10/22/massive-industry-and-d...

In 2001.

https://en.wikipedia.org/wiki/List_of_CLI_languages

At first it seems like an impressive list of languages! But upon closer inspection, over half of them are either abandoned or are commercial products that have been coasting mostly unmaintained for a decade... By now even the JVM ecosystem is a lot healthier.

With WebAssembly, all languages[1] supported by LLVM can be compiled with no custom compiler nonsense. AND we get all the languages[2] that depend on those languages for free as well! The entire burden is on LLVM (and soon GCC) with everything benefiting downstream, surely you can see how it's different from CLI/JVM?

This time the compile-once-run-everywhere promise might actually be true.

1. C, C++, Zig, Rust, etc 2. Python, Perl, PHP, Lua, we can even do some inception with webassembly runtimes.

Just like it happened during the last 25 years, the amount of languages where people will be willing to keep the effort, daily, will fade way.

Or the money from all those VC firms betting the farm on Webassembly startups will dry out.

Until someone comes up with yet another bytecode format, claiming yet again to be UNCOL from 1958.

https://en.wikipedia.org/wiki/UNCOL

LLVM is now the modern version of UNCOL, it seems.

> With WebAssembly, all languages[1] supported by LLVM can be compiled with no custom compiler nonsense.

You can do that without WASM. This really reinforces the authors point.

What you're describing already exists today, that's exactly what Blazor is:

https://dotnet.microsoft.com/en-us/apps/aspnet/web-apps/blaz...

Blazor lets you build web apps using C#. It achieves that by running C# inside WebAssembly.

Yeah I know; but blazor is huge because it needs to ship its own garbage collector and object runtime. Google says 1.3mb for a hello world blazor app.

With wasm-GC, blazor should get way faster and smaller. And the blazor-(JS & DOM) bridge can be massively simplified too. I don't see any good reason for blazor apps to be any larger than the equivalent react app. And that will make it a much more viable platform.

There's also something that you might have actually already heard of called Unity3D. And it's actually widely used and supported and taught by more than a few people and companies and educational institutions.

Blazor is silly. It’s more complicated to use than simply using React/Angular/Whatever you want and it’s less efficient, take up huge amounts of space and is much harder to debug. Coupled with how hard it is to actually build reusable components in any sane way…

It may get there eventually, but as with most C# things these days, it’s mostly meant to sell other Microsoft products to the horde of developers who view themselves as single language developers. The real risk isn’t so much in the technology, however, it’s in whether or not Microsoft abandons it before it’s good like they have with their previous GUI frameworks going all the way back to ASP classic. I know that angular made a big leap from JS to TS, but aside from that, your major JS frameworks have been fairly stable in the same time frame that Microsoft has gone through web forms, mvc, razor, whatever the hell the web-api bundled with X period was and now Blazor, and what is the most telling of all is how virtually every Microsoft Office365 product is written in JS. Would you really bet on a semi-shitty technology that doesn’t even see adoption within the company that makes it? Well, I guess you do considering you’re using C#.

Just use Flutter, that's what they're already doing, similar to Blazor. In fact, Chrome shipped WASM-GC and Flutter has an experimental build that uses it.

Looks like most people have misunderstanding: they think that WebAssembly is the only way to run their favourite language in the browser. However, there's another way that exists for decades: simply use compiler of their favourite language that produces JavaScript! As for Java, GWT exists almost 20 years. Another example I know of is Brython which runs Python on top of JavaScript. However, looks like Java developers don't like to write websites, even while GWT is there.

And according to my experience, WebAssembly is not a game changer: it does not provide extra performance here, neither does it allow to get smaller binaries. I'm a developer of another Java-to-JavaScript compiler, TeaVM. I recently compared performance of JavaScript and WebAssembly targets, and in one particular case WebAssembly is slower: https://teavm.hashnode.dev/comparing-teavm-with-kotlinjs-pef.... There's another example where WebAssembly is only slighly better: https://teavm.org/gallery/jbox2d/index.html. In both cases WebAssembly binary is huge compared to JavaScript. On one hand this can be because of I don't target Wasm GC, so binaries get bloated because of need to maintain shadow stack. On another hand, there's Google Closure Compiler, which produces Wasm GC binaries, and from what I heard of it, WebAssembly binaries still don't win in their size.

Reply on news.ycombinator.com