I wanted to create webdav servers hosted by glitch and cpanel. I ended up with exactly the same code on both, nice! Basically they both have node.js capabilities so I could use node.js webdav-server.

But then I got the bright idea of using deno deploy which I've used in the past and loved, even using kv rather than a file system. It works (thanks chat) but it basically required creating my own version of the node.js webdav-server. Kinda annoying.

The bottom line is that deno deploy is fighting a battle it can't win. Deno was the "better" node.js. And then it started integrating node capabilities, trying for a drop-in replacement of node. Nope. Sigh. I still love it for many simple projects but there's a reason node.js is, er, node.

https://comebackalive.org.ua/donate/ worked for me. I tried the original url last night and ran into problems. Note you need to use UAH currency. $250 was 7336.23 UAH .. sorta sticker shock!

Actually, it should be: JavaScript is weakening the JavaScript ecosystem.

In the olden days, html, css, js were it. But each were "subclassed" by better solutions compiling to html, css, js.

Then huge frameworks arrived to try to organize the mess we'd created. Making devs further than ever from html, css, js.

Remember the old saw: Sure I understand JS, I use jQuery every day! Er, but how about closures? direct DOM use via JS? And so on.

To be fair, jQuery and later CoffeeScript, improved JS considerably.

I don't get the feeling that TS is going to help JS, but hopefully I'm wrong. But unarguably it is SPLITTING the JS ecosystem into warring camps.

From 50,000 feet: - Top engineers are able to solve a problem, and are hired to do so. - Others are able to solve tasks, and are hired to do so.

This is easy: check out D3's architecture. It is "near functional" and tosses all the overly-complex (i.e. dangerous) parts.

And definitely read the still important "Javascript, the Good Parts".

Where is the repo? A project here in Santa Fe may be a useful addition and I'd like to get in touch with the authors.

So I should give up on JS programming, go back to C/C#/C++/Java/Swift and have them generate wasm? Kinda sad, I like JS. But I like performance too.

Is there a possibility for JS tooling? Babel etc? Or any compile-to-JS language like CoffeeScript, TypeScript etc being able to emit/convert to wasm?

Or maybe I'm missing the whole point of this? :)

Chances are JS will remain a first-class citizen. WASM is just for those who would prefer to not use JS. Basically, if you like JS hopefully nothing will change for you, if you don't like JS you will have better options than cross compiling to JS.

Boy do I hope you're right! Performance is likely an issue tho. Wasm is designed to be faster, both loading/parsing and execution.

I did notice that es6 import/export works for Wasm, so I can write performant segments in C. Whew!

> Wasm is designed to be faster, both loading/parsing and execution.

If you want that from your JS codebase, I'm sure it would happily compile to Wasm - you'd probably find that a JS-to-Wasm compiler would be one of the first proofs-of-concept for Wasm.

This misses the division of labor behind wasm (and asm.js, and PNaCl). JS is a dynamic language, in full it needs JITting, speculative optimization based on runtime profile feedback, statically unsound type inference rescued by dynamic checks that have low-enough cost.

In contrast, wasm is for C and C++ first, and in due course many languages. The C/C++-first design point is a way of limiting scope creep and catering to important native-code use-cases (games, AI, CV, etc.). It's the starting point, not the final state. But it involves the usual static types trade-off that reduces runtime overhead.

Therefore a full JS engine in wasm would not run very fast compared to today's in-browser JS VMs, which are evolving to be JS/wasm VMs. For dynamic languages to compile to efficient wasm, we'll need the future JIT-generated wasm support and other desiderata on the roadmap. These come after the "MVP" that is co-expressive with asm.js.

So the proof of concept for wasm must start with asm.js and grow to PNaCl in full (which has had APIs and optimizations that asm.js or JS and the Web APIs have not provided yet), and then on to dynamic language runtime support. HTH.

That makes a ton of sense, thanks for taking the time to clarify.

No problem. I could go on (but should cut myself short to save time for other things).

Another dynamic language support part of wasm's roadmap that's post-MVP: GC support, both for GC of allocations from wasm code, and for references from wasm memory into the JS (DOM whatever) object space. One GC to rule them all, and one VM too.

Turing Complete is soooo comfy!

Wow, JavaScript is approaching science fiction levels of sophistication! Love the idea of moving functionality from client to server or reverse. Knew about Docker but not Ansible, thanks for that. Now we need some Sweet Macros to help too.