The real challenge is to do it in a way that's intellectually stimulating. Mind you The Economist just had an article about the monkey called Punch so all things are possible...
It misled me too - though I'm interested in the article anyway. I've emailed the mod team so hopefully the submission here will get a less context-dependent title soon.
Does anyone know if there's any reasonable timescale likely for this to happen? Last time I looked into the topic it seemed to be completely stalled, but I might well have been looking in the wrong places.
To a very casual observer (me) it seems like it ought to be simple, but I expect there are good reasons why it isn't.
The JS shim is still there, but it's hidden away from the programmer.
For a more direct approach which entirely avoids going through a JS shim:
Mozilla is starting to experiment with integrating the WASM Component Model into the browser. Personally I'm not a fan of this because apart from string conversion the JS shim is not the performance bottleneck that people think it is, but at the least it will finally shut up all the 'direct DOM access whining' that shows up in each and every HN thread about WASM from people who never actually used WASM ;)
> You make it sound like the shim layer is actively desirable - why is that?
More flexibility. For instance even though the 'official' WebGPU shim has the upside that it is compatible with the webgpu.h C API header, it buys that compatibility with some pretty serious performance compromises which can be avoided when using a non-standard JS shim (for instance reading/writing data from/to mapped WebGPU buffers which live in their own ArrayBuffer object, I don't think the WASM Component Model has a solution for such scenarios). The WASM Component Model solution basically has to deal with the exact same problems, but the WebGPU C API will essentially be baked into the browser. I expect though that it will still be possible to write your own specialized JS shim, so it's not a too big of an issue. I would prefer if the WASM peeps first focus on solving other problems which provide more bang for the buck though.
Only for traditional webpages, and for those JS/TS is perfectly fine but the web platform is much more than the DOM.
Once you build a web app via the DOM any sort of performance doesn't matter anyway because the DOM is slow by design, manipulating the DOM from WASM won't magically make an inherently slow system fast.
> Only for traditional webpages, and for those JS/TS is perfectly fine
I hate JavaScript and don’t want to use it at all. I want WebAssembly to allow me to write “traditional” webpages using a different scripting language.
...it's just another tool in the programmers toolbox? Right tool for the job etc... Also for anything non-trivial just use Typescript which is actually a decent language.
It’s not the right tool for the job if, for example, you need a tuple-indexed hashmap, which I needed for a web app recently. TypeScript does not help, it’s just a layer on top. Also I hate the inconsistent syntax and the footguns inherited from C, such as fallthrough in switch statements.
That's unusual. Maybe that's a US thing? In Europe anywhere I've had to interview people I've received at least a couple of hours of training and then usually sat in as the shadow on at least one interview.
Quality varies, but I think it's only the super small outfits where I've been expected to just wing it.
Currently in a brief macos phase before I can be issued my Linux laptop at work. It's so clunky. A major annoyance for me right now is the lack of MST multi-screen over USB which means my nice daisy-chained home setup is fine on my near-decade-old Dell but doesn't work at all on the fancy Macbook. They have the hardware to support it, they just don't.
Generally the hardware with Apple is amazing but I'll take the hit on that and things like battery life just to get an OS that feels like it's on my side.
I'd maybe consider Asahi for home use but I'd be wary of it for work. Perhaps in a few years.
While these are all reasonable points, there is a distinction between criticising people for using ${lang} (bad) and criticising the language (neutral).
Some people get their egoes attached to their choices (for or against Rust).
Also there's a time and a place for all criticism. If the conversation is not fundamentally about language choice then it's very irritating to have it brought up.
reply