Recent searches
Search options
FML, something that’s changed between Node 12.16.2 and 18.16.0 has made the OCSP stapling library I’m using¹ 1,000× slower (~4ms vs ~4s per request).
At least I know where the issue is… Tomorrow, I dig into the library to try and narrow it down further.
(The network graph in Firefox was useful as it showed that the problem was with the TLS Setup. And 0x² and its flame graphs helped me narrow it down further.)
¹ https://github.com/indutny/ocsp#ocsp-apis-for-nodejs-
² https://github.com/davidmarkclements/0x#readme
Right, well, whatever the regression is, it doesn’t exist in Node 20.3.1.
To whit, the time it takes to run my SNICallback:
Node 12.16.2: ~10ms
Node 18.16.1: ~4,000ms
Node 20.3.1: ~10ms
So there’s been a *massive* regression in performance in something in Node 18 (LTS) – buffers/strings? – that appears to be fixed in Node 20 (but not backported) that’s affecting the ocsp module.
CC @indutny – if you get a chance, could you possibly let the right folks at Node core know about this? Thanks :)
@indutny PS. Profiling the ocsp.request.generate() function in your (excellent/life saver) oscp module between Node versions 12 (I haven’t tested with >12 but <18) , 18, and 20 should reproduce the performance regresssion in Node 18.
@aral deno has pretty good node compatibility now, i’d be curious if kitten could be run with deno and not need any code changed?
@tychi Last I checked they were all about “serverless” so I’m not sure it would. Will likely take a look again at some point but I use very Node-specific features like ES Module Loaders, etc.
@aral serverless is their business model, but the approach is web browser compatible APIs. even if they deviate, the deno_core cargo crate is where they lightly wrap v8 so their conflict of interest is bound in code. i’ve been using deno for a couple years now and would rather fork and maintain deno_core than go back to node.
all that aside, ESM in deno can resolve npm packages but also URLs like in the browser, eliminating the need for the microsoft > github > npm middleware dependencies.
the deno team wrote about how to extend deno core:
https://deno.com/blog/roll-your-own-javascript-runtime
https://deno.com/blog/roll-your-own-javascript-runtime-pt2
https://deno.com/blog/roll-your-own-javascript-runtime-pt3
node compatibility docs:
https://deno.land/manual@v1.17.0/npm_nodejs/compatibility_mode
@tychi @aral They put a lot of effort in parity between the CLI open source offering and the cloud product (where it makes sense and is possible at least).
I was worried the kv-store would be cloud only but it's in the CLI. Different backend (sqlite versus Foundation), but it's there with an identical API.
@giltayar @tychi I was doing more with them in a previous iteration but since moving away from svelte to plain HTML/CSS/JS and introducing .<type>.js extensions in Kitten, all I’m using is the resolution function to map .<type>.js file to ES modules so folks don’t have to use the ridiculous .mjs extension or add a package.json file with “type”: “module” just to use ES modules while authoring.
https://codeberg.org/kitten/app/src/branch/main/src/processes/loader.js
@aral @giltayar the .mjs was such a weird decision. i’m using plain .js in deno for esm, same as you, but no configuration change since what you and i are both doing is within browser spec.
i’m curious if that was originally the result of node doubling down on commonjs instead of getting on board with esm.
@tychi @aral Deno can choose to use only `.js` because it supports only ESM. Node.js was not so privileged so they needed a way to mark which file is ESM and which is CJS.
The discussions around this were long and heavy, but the final approach of `.mjs` with the `type: module` workaround is I believe an acceptable compromise.
And maybe one day, in 20 years or so, we can finally deprecate CJS! Maybe 
