←back to thread

11 points jerrysievert | 1 comments | | HN request time: 0.2s | source

PLJS is a new, modern JavaScript trusted language extension, bundling QuickJS, a small and fast JavaScript runtime with Postgres, providing fast type conversion between Postgres and JavaScript, fast execution, and a very light footprint.

Here are bencharks that show how it compares to PLV8: https://github.com/plv8/pljs/blob/main/docs/BENCHMARKS.md

This is the first step toward a truly light-weight, fast, and extensible JavaScript runtime embedded inside of Postgres. The initial roadmap has been published at https://github.com/plv8/pljs/blob/main/docs/ROADMAP.md

You can join the discussion by joining the PLV8 Discord: https://discord.gg/XYGSCfVNBC

You can find PLJS at https://github.com/plv8/pljs

Show context
mhio ◴[] No.44383736[source]
What are the advantages to pljs over plv8? I thought the context creation would have been the big one, but it doesn't appear so in the current benchmarks.

How did the project weigh the intermittent updates of bellard quickjs and the community fork quickjs-ng?

replies(1): >>44384075 #
1. jerrysievert ◴[] No.44384075[source]
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.