Who else believes WASM makes sense as a first class Nim target?
I am still looking for the prefect language and not yet fully engaged with Nim yet, coz it strikes me chiefly as "leverage over C" and I never got into C in a big way. And agree with this sentiment completely: (C is not a programming language any more) https://www.theregister.com/2022/03/23/c_not_a_language/
I believe the optimal target for the best language designer in the world is 'compiled character with dynamic productivity' which is also an obvious goal of Nim. However at the moment the top title is firmly taken by Typescript, since the V8 accomplishments are so significant, and the convenience factor (browser as platform + dynamic scripting nature, preserved + type safety if wanted) is considerably higher reward for programming time invested.
If I had to make games I would feel differently, of course. But for the time being I am am into digital publishing, and plenty of graphically rich, interactive content is already possible - within severe limits.
If Nim was the optimal way to publish to the web - using WASM performance - I think I wouldn't be able to resist though...
I think that WASM is too low-level for most purposes unless you're building an engine on top of it. For publishing to the web I think Flutter is awesome. Unfortunately there is some startup cost, but it's low. I found a way to overcome this by lazy loading the libraries on the landing page of a site.
I'm building a minimal SDK that looks similar in structure to HTML for Nim (among other back-end languages). This powers a Flutter app/engine which does all the render work. https://nexusdev.tools/
I am still looking for the perfect language and not fully engaged with Nim yet, coz it strikes me chiefly as "leverage over C" and I never got into C in a big way. [...]
Ah, the old "it compiles to X so it cannot really be any better than X" 'argument'. It's wrong.
And Wasm as a target, well, shrug, when I looked at it, it lacked multi-threading and support for IO, interacting with the DOM was hard and it lacked goto. .NET's design was much better but that's from evil MicroSoft so let's better not talk about it and pretend there is nothing less of a "revolution" going on.
You think Typescript is different than Nim because Nim doesn't compile to WASM? There is a JS target.
If you really want to compile to WASM there are ways (google for more). But just the ability to compile to WASM doesn't really accomplish much, especially based on what you're describing; WASM isn't a stand-in for JS.
Publishing to both web and native is such a common need that many people already do it their own way with Nim without waiting for the ecosystem to make libraries for it. I don't see people complain much about how Nim could be more accomodating for multiple platforms besides straight up bugs with platform backends.
One problem you might have is that Nim does not really have full dynamic productivity. It provides some very powerful abstractions over code but some additional abstractions you would need to exactly match dynamic languages would complexify the language and compiler a lot. But this doesn't really matter as long as Nim is still the most productive statically typed and compiled language out there.
The reason not everyone will ultimately use Nim for everything IMO is this. It's designed to be statically typed and compiled more than languages like Haxe, Kotlin, Scala which are all designed to be statically typed and compiled as well. Nim just being better to work with than JS and Python doesn't mean people wouldn't prefer a language with aspects of JS and Python they like that Nim isn't designed for.
There is something fundamentally different in Wasm compared to .NET: it's designed to work in a web sandbox. Features like IO is severy limited by that, and multi-threading might be difficult to get at.
However, emscripten can easily be switched as a backend for the Nim compiler. What this lacks it better integration with the language. Rust for example is leading in this area and has integrated type conversion with wasm-bindgen.
Asyncdispatch relies on selectors.nim which rely on select or poll, IIRC.
select/poll are generally part of the OS'es socket api and would require support from both WASI and the Nim side to port. I'm not familiar with what WASI provides in terms of select/poll or events, timers or callbacks, but it probably could be done.
Considering that the amount of languages who can sensibly deploy to WASM, I can imagine that from a purely 'popularity' perspective, it can make sense, to support WASM.
Not that I am a huge fan of it - there are obvious downsides to it - assuming there is a crowd outside, that waits for a proper language to support it, I think Nim is in an unique position due to ORC.
Usually, GC'd languages have to ship a runtime with them. I am also in the F# community and dotnet does not do good to the download times. Several mb even with stripped runtimes are not feasible in most scenarios.
Nim on the other side, would be able to deploy relatively slim.
I think big companies intentionally break / limit / delay features for web, to avoid competition with their app markets.
In theory WASM could be great... but it seems that so far it's only in theory...