I too was surprised about the slower startup and am planning on spending a lot of time in the quickjs repo to try to improve it. Thankfully most use cases use a connection pooler, which removes startup costs from the equation, leaving conversion speed much more important. I was able to speed up conversion of jsonb by writing a custom conversion from jsonb to quickjs and back, but feel there is still a lot of room for improvements.
As for quickjs vs quickjs-ng: ng is a fantastic project and I’m really hoping it pulls an egcs and ends up canonical, but when this project was started, it did not exist, so quickjs was chosen as the starting point. As for why it has not been adopted yet by this project, it comes down to a few things that helped make the decision:
* quickjs is still having releases
* as learned from plv8, when there are constant changes it becomes much harder to maintain, so a steady target is easier to deal with (this is constantly being evaluated)
* the build system change from make to cmake adds friction to Postgres embedding, I already have to patch quickjs, and would need more complicated patches for quickjs-ng. I have a good working relationship with Ben Noordhuis, but it’s still a source of friction that isn’t needed now.
As things change, everything will be re-evaluated, but for now quickjs itself works great.
