scittle 2024-04-30

scittle should now be easy to use in non-browser contexts or webworkers since the hardcoded dependency on js/document is now made optional

😍 1
1

import scittle from 'scittle/dist/scittle.js';
console.log(scittle.scittle.core.eval_string('(+ 1 2 3)'));

So that's a bit over 800 KB on disk? Do you know how long the worker startup takes? I'm curious of another strategy of compiling to js first and then sending that to the worker, after booting it with basically no deps. I'm curious if that'd be faster than loading scittle in the worker.

I think worker boot up is getting faster for scenarios without a lot of deps

Still kinda slow for larger deps

This is awesome though

But a 5K worker and a 500K worker can serve completely different usecases, in terms of how much longer 500K starts to boot, last time I checked

yeah compiling to JS works with #squint

I didn't finish my port of cljs-thread to squint

You can essentially send beans "over the wire" transparently though

here is just a silly example I made, triggered by someone who suggested you could also use scittle in a webworker if you remove the dependency on js/document. I have no practical use for it at the moment, but it works https://clojurians.slack.com/archives/C034FQN490E/p1714502074884559

👀 1

I guess js folks can pass objects back and forth pretty easily

yeah that seems to work

not sure what the limitations are

A lot of stuff gets serialized

to what, a string?

a "transferable" but yeah pretty much I think

better than a string for somethings

if you build a transferable interface for it or something

but in my experience it's mostly the same performance as just using strings

Probably not for basic objects though

I guess if you use the same scittle version on the page and worker, CLJS maps etc should maybe just work, I'll give it a try

there's no goog-closure compiler right? Should work better than cljs

oh skittle is compiled with it

Yeah, that's what works in cljs-thread

we're sending compiled versions of the forms "over the wire"

And it all has to be from the same artifact to work correctly

Or you can use two different builds and only call exported fns between them

But scittle forms don't depend on the closure compiler the scittle compiler is compiled with, right?

sci gets us around the abi problem, right?

abi problem?

SCI in scittle is compiled using advanced compilation. you must use the exact same version to exchange CLJS maps or they will be incompatible

But can't we send them as strings?

how are they different maps?

you could convert them first to JS and then back, but otherwise they don't work the same because of closure renaming all the things

yes, you could send them as strings, of course, no problem there

oh, you mean sending compiled forms over the wire

Yeah minified cljs over the wire is actually pretty performant as a intermediate representation for sending code between workers

Everything goes a lot faster in cljs-thread in the advanced compiled version