I’m sorry, did I say earlier that the distribution build of JSDB 2.0 was 32KB. That’s non-minified. Minified, it’s 20KB.

That’s a pretty nifty native JavaScript database for 20KB. Enjoy! :)

Show thread

So the ESM version of JSDB is almost ready for release:)

Feel free to have a play with it here: github.com/small-tech/jsdb/tre

I’m going to bring the test coverage back up to 100% and, barring any last minute issues, I’ll publish it as version 2.0 and hold a live stream demonstrating it tomorrow.

(Actually, scratch that, since the issue was not in a dependency, I could easily work around it. Added possible solution + workaround to the issue. And now it’s running!) Yay! :)

Show thread

Aaaand… the esbuild bundle is 32KB (w00t!). Although it doesn’t work yet since I seem to have hit an edge case with the bundler (github.com/evanw/esbuild/issue)

Show thread

Yay, the upcoming 2.0 version of JSDB (which uses and outputs ECMAScript Modules) now has zero dependencies :)


This message brought to you by too much time spent reading StackOverflow comments.

Show thread

For every problem in JavaScript there is someone who will solve it by converting it to JSON first.

w00t, all tests passing with the ECMAScript Modules (ESM) version of JavaScript Database (JSDB) :)

Should have a release ready tomorrow :)


(PS. Before anyone feels the need, I’ve been doing this for a few decades now so please don’t chime in with “buh, eval.” I know exactly what I’m doing and why I’m doing it and, yes, it’s the right tool for the job. For more details, see previous posts on my blog. ar.al) ;)

Show thread

So after running all sorts of tests I’ve decided I’m going to keep the interface synchronous in the ESM version of JSDB (to match the current CommonJS version) and use fs.readFileSync() + eval instead of dynamic imports for the data files. Not only does it make the interface simpler but it also takes exactly the same amount of time and ends up using far less memory. The data files will be written out as ESM and can be loaded in using the regular methods outside of JSDB.


Folks who have security because they work at surveillance capitalists, to me, a person living precariously on the last of their personal funds while working to create alternatives to it: “not everyone has the privilege to not work at a surveillance capitalist, y’know!”

Great, just got a call from the landlord saying he’s selling the place so if we can’t somehow magically find half a million euros (yeah, right) in the next few months we’re gonna have to find somewhere new to live. Just do not need this right now :(

(TypeScript developers might want to look away now…) 

So fuck me, you know what it was? I got the fucking order of response and reject wrong in the arguments of the Promise() constructor *AGAIN*

:awesome: 👍


Show thread

(TypeScript developers might want to look away now…) 

(Also, I just checked and it’s not something specific to when the datatype your promise from the constructor resolves to is a proxy. That also works in isolation.)


Show thread

(TypeScript developers might want to look away now…) 

Hmm, no, it’s not that. Just created a basic spike to test just that and ESM is perfectly happy if you return a promise from a constructor that eventually resolves to a different datatype. So it must be something else that’s triggering it. With the stack traces were more helpful.

Show thread

(TypeScript developers might want to look away now…) 

(So in case you’re wondering the resolved datatype is a proxy to the datatype. Previously, I was returning this from the synchronous constructor but since dynamic imports are asynchronous, my constructor needs to be also now. And when the promise tries to resolve, that’s when Node throws its exception. Fun times!) :)

Show thread

(TypeScript developers might want to look away now…) 

So apparently ESM doesn’t like it when you change the type of an object by resolving to a different type from a promise returned from the constructor…

(Hey, don’t judge me, I have my reasons. And yes, they’re niche.) :P

Such useful errors, Node.js… (thank goodness for NODE_DEBUG=*)


Alicia Kennedy: On the future and why justice is more important than innovation.


Read and absorb every delicious word of this.

Show older
Aral’s Mastodon

The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!