This one is basically my daily driver for similar tasks: https://app.heynote.com/ (full app at https://heynote.com/). And it seems to work almost out-of-box for your first two examples, once you switch the buffer from "Plain-text" into "Math" mode.
It also supports switching between different buffers and some kind of local storage.
Umm, yes? Not sure about the rest of Europe, but here in Czechia most of merchants have a direct payment method based on QR code.
Basically: 1) you select your bank at the checkout; 2) you're redirected to the bank's payment page with a QR code; 3) you scan the code from your banking app and confirm it; 4) the bank redirects back the merchants page with the payment status confirmed/declined. No payment processor involved and the money goes straight from your account to merchant's account.
I would say that the problem really is there. Dealing with native dependencies and addons was almost always a pain as the article describes (and not just from developer perspective), so anything that helps there is really appreciated.
Not sure what you mean by the right tools in this context.
Code testing is a big one for me. I'm currently using in-memory sqlite for tests and I'm often running into differences between sqlite and postgres (default values, JSON handling, etc). This could allow me to use the real thing without running a full Docker instance.
What I meant to say is that this definitely isn't a safe assumption and performance of this loop will be less predictable. That said, I wouldn't be surprised that such complex JITs as V8 or JSC can detect this scenario.
That's a really good point and I think that in this sense the comparison is really made between Rust and JS rather than between WASM and JS (as others have complained).
The innermost rendering loop in the JS seems to create and destruct an array instance for every single pixel iteration (see https://github.com/dmaynard/chaos-screen-saver/blob/master/s...). I guess that this could be potentially optimized away by the JIT, but it will make things slower or at least less predictable.
Yeah, I'd say that it's actually pretty good result. Too bad that the benchmark doesn't include any non-browser WASM runtimes, like Wasmtime or Wasmer.
So why not just write the original formula into the comment above the code? Maybe it's not the purest approach, but it sure would help parsing the code in this case.
In my experience, it's better to create a "request context" at the beginning of handling a request and pass it down explicitly to subsequent async calls that handle the request. I think that this approach is similar to Golang's "context" package, for example.
As other commenters note, using CLS (via async hooks or domains) is often too much magic and can possibly cause leaks or at least it results in program logic that's hard to reason about and hard to test.
I think that the AssemblyScript project is halfway there. It compiles a stricter subset of Typescript to webassembly format, which can be then translated to CPU-specific machine code.
If I remember it correctly MPEG-2 patents are supposed to expire this year. So maybe it's time for JSMPEG2? (Ok just kidding, the whole MPEG-2 spec looks huge).
It also supports switching between different buffers and some kind of local storage.