<story><title>Is WebAssembly magic performance pixie dust? (2021)</title><url>https://surma.dev/things/js-to-asc/</url></story><parent_chain></parent_chain><comment><author>wylie</author><text>A group of smart WebAssembly experts tried to start a company around the idea of incrementally porting to WebAssembly, and wrote an excellent post-mortem of why that didn&amp;#x27;t work: &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;zaplib.com&amp;#x2F;docs&amp;#x2F;blog_post_mortem.html&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;zaplib.com&amp;#x2F;docs&amp;#x2F;blog_post_mortem.html&lt;/a&gt;</text></comment>
<story><title>Is WebAssembly magic performance pixie dust? (2021)</title><url>https://surma.dev/things/js-to-asc/</url></story><parent_chain></parent_chain><comment><author>dktoao</author><text>Looking to get the perspective of some HN&amp;#x27;ers here. I am primarily an embedded engineer working with C. Our (small) software team also has a few web people that work on the web UI of our embedded Linux product. Obviously, there is a ton of potential for shared code between the two products utilizing WASM. I recently ported one of our C libraries to WASM as an experiment with emscripten and was blown away by how easy it was. I can&amp;#x27;t run the unit tests in the browser yet but it seems to have worked perfectly. However, the JS &amp;quot;glue&amp;quot; code that is produced by the emscripten compiler is really scary looking, and as I understand is basically an abridged C runtime that needs to run in the browser. My questions are therefore:&lt;p&gt;1) Is it too early to adopt WASM for production use in a small company with limited resources?&lt;p&gt;2) If we did decide to go all in on WASM, what sort of gotchas might we be dealing with?&lt;p&gt;Thanks everyone!</text></comment>