> Then WASM comes along and (although it's not fully baked yet) it seems that > Nim's JS backend efforts are now somewhat less valuable...
Let's look at how big that "somewhat" actually is according to some specific aspects of WASM vs JS in the browser: * JS call performance: Calling JS from WASM is slow. That's a problem, especially because, as of now, calling JS is the only way for WASM to access the page DOM and other runtime objects. * Memory management: Nims garbage collector only works if the Nim runtime controls the root of the call stack, if I understand the experts correctly. That's normally not the case in the browser, but the fact that Nims GC is thread-local might save us here: recently, mainstream browsers have started to implement "Webassembly threads" which are basically OS threads. So if a WASM module written in Nim would be run in its own thread, the GC could be made to work. * Politics: WASM markets itself explicitly as a complement to JS, _not_ a replacement. I see no real technical reason for this. Maybe somebody is afraid that, when people see what can be done with sane programming languages (sry for the anti-JS-bias), they would start to rebel against this sad the-browser-is-the-paltform-and-JS-is-its-prophet religion.
