The "free" in this case is a verb. The objects are freed from the background.

Until your comment I didn't realise I'd also read it wrong (despite getting the gist of it). Attempted rephrase of the original sentence:

Imagine history documentaries where they take an old photo, free objects from the background, and then move them round to give the illusion of parallax.

I'd suggest a different verb like "detach" or "unlink".

isolate from the background?

Even better, agreed!

Free objects in the background.

No, free objects in the foreground, from the background.

Their motivation is explained in the first post of the series[1]

[1] https://www.grisp.org/blog/posts/2025-06-23-jit-arm32.1#why-...

For their real motivation[0], click on hardware at the top of the page.

Their existing hardware is aarch32. It really is that simple.

0. https://www.grisp.org/hardware

loved them complaining about having "only" 16 registers

Looks fantastic! Now it simply needs a non-Scratch runtime and a Scratch-like frontend, and we'll finally be able to teach bootstrapping to the 5-10 year old demographic.

adazem009 has been developing an alternative runtime for Scratch written in C++ [1]. It even uses compilation to speed-up the performance of Scratch projects, perfect runtime for goboscript projects.

[1]: https://github.com/scratchcpp/libscratchcpp

Video introduction: https://www.youtube.com/watch?v=llRUKwqMah4

via: https://ersei.net/en/blog/niri

Maybe we can spend this downtime researching self-hosting options

I use AltTab [0] for this. I find using a mac without it horrendous.

[0]: https://alt-tab-macos.netlify.app/

oh wow, you can have multiple "alt-tabs" and set what they show

thanks for the link!

I've enjoyed trying to use Deno for a small new service at $WORK. Sadly had to give up and retreat back to Node due to missing support for private NPM repositories and lack of Datadog tracing support.

Their compatibility is getting better and better, so I'm confident Deno will eventually be a clear "better Node".

One use case where pure Deno works for me is shell scripts. Writing them in Deno is quite pleasant and they usually don't need many dependencies. Plus you can always host then and just "deno run <url>" from any machine that has it. It used to be a problem that you had to know permissions ahead of time but now they interactively ask you for it which makes the scary "-A" flag much less needed.

You can also compile them to standalone executables easily with `deno compile`.

I wonder how that works, do they ship the entire Deno runtime with the executable à la Electron?

Yes, a `console.log()` compiles to a 78.46MiB .exe

Wow, sounds like I'll stick with Rust.

What was the issue you encountered with private registries on Deno? Based on Deno's docs, it looks like they're supported[0]

[0] https://docs.deno.com/runtime/manual/basics/modules/private

What I'm looking for is the equivalent of this .npmrc contents to access an NPM module on Github Packages:

  //npm.pkg.github.com/:_authToken=${AUTH_TOKEN}
  @myEmployer:registry=https://npm.pkg.github.com/

My impression is that the document you've linked isn't related to their NPM compatibility, but perhaps I need to look more into it.

Here is the relevant Github issue with a better explanation:

https://github.com/denoland/deno/issues/16105

Now that there is also bun, both javascript tooling/runtime ecosystem will improve faster, now there are 3 competing mainstream runtimes (but as now the only one that is production ready imho is node)