create release for javascript

[biojppm]

Since emscripten is now supported, I'd like to create the javascript artifacts as part of the release workflow.

Also, a quick JS usage example in the main README is needed.

@cschreib could you kick this off? I don't know much about JS or JS packaging, so maybe it would be better if you kick this off. I'd be happy to join in after the first changes. If you're currently taken and that is too much, could you at least provide some pointers on how to package?

[cschreib]

I am not terribly experienced with this myself, but I can share whatever wisdom I've acquired along the way.

When you compile a library with Emscripten, all you get is a linux-standard .a file. I have never attempted to produce a shared library, and I don't know that such a concept even exists there. The .a file contains (to the best of my knowledge) the C++ code compiled into WASM binary. There is no JavaScript at this point. So, for a library, I would expect to deploy just the headers and the .a file(s), as this is what a user would consume to build their own C++/WASM applications.

As for applications themselves, you always need JavaScript to launch and manage the WASM code (how to handle memory; etc). At the lowest level, Emscripten can emit a .js file that will allow running the WASM entry point (main(), and the other functions explicitly exported to JavaScript, presumably, although I've never done this). It can also emit a combination of .js (loader), .wasm (code), .data (runtime input data; will be used to create an emulated file system to load stuff from) and .html (calls JS and setup canvas for rendering output). I don't think the rapidyaml fits in this, thought?

[mnahkies]

I'm unlikely to get time to figure this out anytime soon, but just wanted to express interest in having more documentation around the WASM support, and in a perfect world bindings for NodeJS to make it easy to use from Javascript code.

I currently use https://www.npmjs.com/package/js-yaml which works fine, but for my particular project parsing large YAML files makes up a large chunk of my integration test suite runtime (50%-60%) of total runtime, and I'd love to benchmark rapidyaml as an alternative