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 🤷
honestly, I never ever, ever thought fullsoak.dev would work with Shadcn one day.
Disclaimer: at the current state, it's obviously alpha work & heavily discouraged on PROD or anything serious, actually. I just find it hard to believe myself that it does somehow work. Will link to source code later.
fullsoak demo, the react component example code
fullsoak demo, the SCSS example code
fullsoak demo, the final visual output (server-side rendered HTML)
fullsoak demo, the final output source code (server-side rendered HTML)
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.
I hacked my way pretty deep into forcing a non-conventional use of the sass-embedded library. At this point, deploying to a standard VPS seems like the only viable choice, as Deno Deploy doesn't allow subprocess, which is needed by sass-embedded.
Tho, is there any other route for FullSoak.dev 🧐 ?
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 🤔
I recently enabled IPv6 only for my AWS EC2 instance.
Stressed on IPv6 _only_ ie. the server has zero IPv4 interface.
I notice: while most tasks still happen normally, some outbound requests (esp. ssl) fail consistently.
#CSS only carousels arrive in Chrome 135
⤷ nerdy.dev/css-carousel...
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.
ppl go crazy 'bout TSC going Go. Yes it's amazing, but doesn't mean JS-based compilers have no use anymore.
for use cases where native bindings are `import`ed during runtime, unless it's direct VPS / inside Docker, it's a no-go for most hosting svc with a "sandboxed runtime" eg Cloudflare Workers
"vibe-enjoying" an example SSR web page on such a #nobuild fullstack TypeScript framework. Feels like an escape to a breezy country life of simplistic values of basic web development, away from the sexy but stressful metropolitan life of layers of build configurations stacked on top one another...
simplifying code example to the bare minimum
I take "barrier of entry" very seriously. A getting-start / demo codebase for a basic UI having more than a few lines of code, can already be a "conversion rate killer".
but I myself am susceptible to this. Ytd I happened to push a commit that brought more lines than needed.
reverted now.
#kiss
left: officially documented directory setup
right: rebellious teenager
FullSoak framework doesn't care. It just serves both.
source code for the left: github.com/fullsoak/den...
source code for the right: github.com/Thesephi/ful...
*disclaimer: unofficial setup is only supported at best effort
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...
I want to provide out-of-the-box support for react-helmet (or preact-helmet actually). I'm short on time, yet it looks bad if there's zero support for basic title & meta tags, so a bespoke API: makeHat
why Hat? cuz it's like a Helmet, but way, way lighter
(silly lol)
usage: jsr.io/@fullsoak/fu...
I got a micro EC2 instance back in 2007 or so.
Today I wanted to switch it to nano.
Did some googling. Followed the steps:
- stop the instance
- change instance type
- start it again
Boom, cannot start cuz ENA not compatible
I switch instance type back
It still.. doesn't start
I'm now a 'happy' user
Just randomly learned that the awesome people at @jsr.io got us this amazing dependency graph for our modules. We still have nice things in 2025, everybody!! 😆
(screenshot from jsr.io/@fullsoak/fu...)
just released a bit more verbose example, with simple authentication, showing how a typical Web App can be built with the FullSoak framework
Live Demo: fullsoak-guestbook.deno.dev
Will be adding more features & colors down the road. Now I need some sleep 😅
deploying a #FullSoak app cannot be simpler with #Deno #Deploy:
- just leave all install / build options empty
- declare the single entrypoint of our app (eg `src/main.ts`)
and boom, the app is ready.
see it for yourselves: fullsoak-examples.deno.dev/app
source code: github.com/fullsoak/den...
Now that the framework has taken some shape, I'll migrate the #buildinpublic log from this bsky account to a Discord server where 1) there are more rooms and 2) less spammy for you all here 😀 Here goes: discord.gg/hzGsVVKy2N
I'll continue using this bsky account for "normal" posts. See you around!
Just added (experimental) support for Cloudflare Workers to FullSoak web framework
Still rooms for perfection, but very happy to share a milestone. Lessons learned are noted in the demo code: github.com/fullsoak/clo...
Live Deployment: fullsoak-cloudflare-workers-examples.dklab.workers.dev
Finally decided on a fallback for SWC on Deno Deploy: `tsc` itself (surprised surprised 😅). Trade-offs are acceptable.
For the 1st time since the initial PoC, this framework supports deploying straight into #DenoDeploy
Live Demo: fullsoak-examples.deno.dev/app
Details: github.com/fullsoak/ful...
I should have known better. Both SWC and esbuild make use of native binding, which is apparently not yet supported by Deno Deploy. I left the discovery notes here: github.com/denoland/dep...
Next explorative direction: maybe try something without native binding.
On 2nd thought, I think I'll go with esbuild's jsx transform: esbuild.github.io/api/#jsx as it's still actively maintained.
Whether SWC or esbuild, I'd love to conform to the 'no config' wish (ie: using 'best defaults'). If/when the community needs arise, we'll think about customization options.
I already like Bublé by reading the first few intro lines: its focal points match those of FullSoak:
- zero config
- code is only altered where necessary
Still, it's not without its limitations, eg. it doesn't support 'for...of' loops (1 thing I personally like).
Maybe there're alternatives still?
@swc/core has been used behind the scene by FullSoak to transpile JSX. It works seamlessly for Deno and Bun, but when using with Deno Deploy or Cloudflare Workers, the native binding doesn't work: github.com/denoland/dep...
Thus im exploring buble.surge.sh/guide/ as a potential fallback.
