You can still obfuscate JS heavily and make a VM that executes also obfuscated code calling arbitrary browser APIs. At least In WASM everything is sandboxed so the attack surface is smaller.
After the incident with Tailwind CSS, I decided not to make this open source. Sponsorship has been zero since COVID, so it’s genuinely hard for open-source developers to sustain their work
Sorry don't take this personally but isn't this made with LLMs? Isn't the "incident with Tailwind" the problem that devs no longer support the project because they use it through LLMs often without knowing?
I mean if i understand you are saying you won't release open source code because LLMs would feed/stole it. I get that position. But you are already feeding from the devs that were exploited. Seems a bit hypocritical to use LLMs if you have that stance.
> I read Effective Modern C++ years ago and was confused exactly like what you describe.
It's been a while since I read it, but if I recall correctly the book focused on special member functions and when the compiler actually stepped in for the developer, not the actual concept of move semantics. Those are different things.
Special member functions is a development experience issue, and covers aspects such as "can I get the compiler going to generate code for me". If you write code that tells the compiler it should not generate move constructors for you, often it ends up generating copy constructors. That's it.
> It only supports a subset of Javascript close to ES5 [...]
I have not read the code of the solver, but solving YouTube's JS challenge is so demanding that the team behind yt-dlp ditched their JS emulator written in Python.
To declare "open source", you have to provide a way for the public to get access to the source code. But there seems to be none at least for the time being.
I wrote my first SPSC circular buffer implementation in TS upon reading the previous post on futex [0] from the same author. It was more intricate than it had seemed, until I finally sat down and wrote my own code.
I recently started playing with these in game design as well to coordinate networking and game threads in a lock free manner. If it fits your use case it is truly a free lunch! They definitely have a lot of edge cases and are not easy to implement, but they aren't too crazy either.
By a quick glance, yes, this is what I want: a channel to communicate between processes via a piece of shared memory, protected by a pair of futexes.
In JS ecosystem, buffers that allow data loss is more common (aka ring buffers), but ringbuf.js [1] is the only complete implementation to my knowledge. In my use case on I/O between WASM modules where data must be transferred as-is, the process must block on buffer overrun/underrun in a synchronous manner. Therefore a circular buffer is required. I could not find such a niche library written in JS, so I decided to bite the bullet and reinvent the wheel [2].
After a quick glance, it seems that you don’t maintain the reading/writing status in the shared memory. That means you have to make a syacall in every read/write call. You could look into the kaze-core for an alternative implementation, which doesn’t require any syscall if possible.
Btw, kaze-core uses a `used` atomic variable, to avoid reading both readPos/writePos in routine - they are not atomic at all.
That is a fair assessment. Maintaining read/write pos and peek them at every operation is a big performance hit. The impact is amplified if each invocation needs a syscall. That is exactly what futexes address: Allowing spin locks to remain in user space and avoid entering the kernel as long as contention is low.
In JavaScript, atomic operations are relatively lightweight, so their overhead is likely acceptable. Given that, I am open to adjusting my code to your suggested approach and seeing how it performs in practice.
reply