Hacker News Reader

Comment by themihai | Hacker News Reader

That's what I find great too, though for some reasons they put too much emphasis on JS-wasm compatibility and less on language support(i.e DOM or GC are considered "unicorn" features). I'm pretty sure 90% of the web developers won't mix js with wasm once they can compile their preferred language to wasm. You will find either js apps or wasm apps. There may be also a very small percent of js apps with wasm modules(i.e for video decoding)

View on HN

They are trying to convert current web devs. JS is the language of the browser and essentially the web, so most developers working in webdev primarily work w/ js.

Actually many of us use es6 with a compiler to turn into some dialect of js that runs in browsers. We will hardly notice if our code starts getting compiled to wasm instead..

JS will not compile to WASM.

Eh, there isn't any reason that it couldn't at some point in the future. That won't be happening any time soon, but I'd love to see that day, personally.

Lack of GC in WASM would make that difficult right now.

But yes, that's the future I'd like to see. Browsers only have a WASM engine, and provide a JS->WASM compiler client-side for backwards compatibility.

GC is just something you implement on the language runtime.

Then you're shipping the entire (or at least large pieces of) language runtime to the client since presumably, you'd need to compile that to WASM as well.

You can probably fit the runtime in a 10th of the size of JQuery.

You'll need most of a runtime anyway, since it provides much more than GC.

Something that never really worked was cached versions of jquery (and similar) from cdn. One reason is that browsers didn't give them any particular precedence. The other was that jquery was moving quite fast compared to devs using it so as an end user i nearly never benefited from the caching. I wonder if this might work better for language run times. Maybe browsers could be provided with some manifest saying 'this site needs python 3+' or 'this site needs python 3-3.5' so that end users end up with less runtimes cached.

Given that runtimes like Lua are comparable in size to a single image, and/or could be cached in web browsers, I don't think that will much of a problem. And the more that WebAssembly adds, the smaller that will get.

Obviously if we're trying to run a full JVM or CLR in WebAssembly, that will cause problems, but C# and F# both have compile-to-js targets that would likely just get faster.

The JS devs don't really need wasm. JS works just fine in browser. I find the use cases mentioned (js app + high performance wasm modules) limited to a very small niche. WASM is supposed to be a target language. Are they trying to convert current web devs to C++/rust devs? It doesn't make any sense to me. If wasm was designed just to help JS to do more then it is doomed to fail.

>JS works just fine in browser.

Sure it does. And the myriad of languages that pop up to support WASM will work infinitely better. ES6 was a huge step forward, but it's still a long way from a real language like C#.

I suspect Javascript development will always be a thing, but that front end development will fracture into multiple different languages and runtimes as full WASM support comes online.

> a real language like C#

While I can agree that C# has tons of language features that make it more powerful than JavaScript, I take issue with the idea that those features are the defining characteristic of a "real" language. I think there are many reasons to choose C# over JS, but there are also a non-trivial of reasons to make the opposite choice.

https://blog.codinghorror.com/the-principle-of-least-power/

Reply on news.ycombinator.com