I’ve also run into several ppl with a very strong opinion against “javascript on the server”. I’m pretty sure there are countless horrors about bad JS on the server, but isn’t it like saying all ppl shouldn’t live on Earth cuz there are bad ppl 🤔

anyway each to their own, as i often tell myself 🤷

NB: when everything works, this is what we're supposed to have (the code & the output)

PS: I also tried the sass-embedded non-async API, which is `compile` (instead of `compileAsync`) and bumped into another brick wall. Here a dependency `sync-message-port` doesn't seem to be fully compatible with Deno.

Of course I could try targeting Node.js - a topic for another day.

Totally find to have a healthy mix of non-programming topics. Makes us, uhm, less LLM like 😆

E.g: git-ssh clone, or a certbot follow-up work which talks to supporters.eff.org:443 - they all fail.

Not sure if it's because I missed some additional setups, or just a coincident. But it'd be funny if it's 2025 and not all processes and machines do IPv6 OOTB 🤔

As someone who recently had to Box<dyn std::err::Error> all the things (also i try to cut down on external libs like anyhow), i find this post very educational. Thank you :)

for example: this code works perfectly with the current tsc: github.com/fullsoak/ful... on both Deno Deploy and Cloudflare Workers

I'm quite positive it'll throw like in the screenshots above the very moment the new TSC comes into play.

and that's how I have a huge crush on Zed's pride versioning standard 😂

feeling a similar thing to the bone, too, as I'm hacking on a web framework. From the beach of SSR to the valley of JSX transpilation, then top the hill of posix vs windows vs Cloudflare filesystems (or lack thereof).

just as one stops to take a sip, the shadow of (s)css mountain casts over...

source code: github.com/fullsoak/gue...