public-roadmap VS iswasmfast

We use Caddy for serving our free dashboards and status pages on your own domain at https://checklyhq.com

It was not super easy to set up. I think the whole config is 20 lines or so, but the docs, naming and functionality of how Caddy actually interfaces with LE was tricky to find out. Basically had to scrape together answers from various GitHub issues etc.

I should write a blog post…

Have you given checklyhq.com a look? Sounds like it could be a great fit. (Disclaimer: I work there).

Have a look at https://checklyhq.com. We do exactly that, API monitoring. You can set up a check that parses your API response and validates a specific field. We also have a free plan. Disclaimer: I’m the CTO.

We're looking forward to how Checkly will make their monitoring solution even more accessible for developers with e.g. versioned code, an integrated Monaco editor with better auto-completion, support for custom NPM modules, or a better debugging experience. We would recommend giving it a try and have not to worry about where to run your status checks or end-to-end tests and benefit from their simplicity. For a more detailed outlook, they provide an official public roadmap on GitHub.

At a glance, the bindings for wasm copy the data,

https://github.com/zandaqo/iswasmfast/blob/54bbb7b539c127185...

If the running code is short enough then that copy might easily make the wasm version much slower. That is indeed a known downside of wasm (calls to JS are somewhat slow, and copying of data even more so - wasm shines when you can avoid those things).

If it's not that, then a 10x difference suggests you are running into some kind of a VM bug or limitation.

WASM has its moments, as you can see in this[1] benchmark it outperforms JS and native addons on certain tasks.

Since the bottleneck with native addons is usually data copying/marshalling, and we have direct access to WebAssembly memory from the JavaScript side, using WebAssembly on this "shared" memory might become the best approach for computationally heavy tasks. I wrote about it a bit here[2].

[1] https://github.com/zandaqo/iswasmfast

A few years ago I did similar comparison but in context of Node.js and sans manual optimizations: https://github.com/zandaqo/iswasmfast

In my work, I have come to conclusion that it seldom pays off to go "native" when working with Node.js. More often than not, rewriting some computationally heavy code in C and sticking it as a native module yielded marginally better results when compared with properly optimized js code. Though, that doesn't negate other advantages of using said technologies: predictable performance from the start and re-using existing code base.