dk

dk

@mrkha.ng

professional 👨🏼‍💻, amateur 🎹 player 🌳 https://fullsoak.dev ⚙️ https://zzzz.dev 🕸️ https://mrkha.ng

26 followers32 following62 posts

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.

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 🧐 ?

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 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.

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 🤔

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...

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

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 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 😅

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!

discord.ggJoin the FullSoak Discord Server!Community Support forum for FullSoak SSR Web Framework | 1 members
dk@mrkha.ng

I'll start using this bsky account as an informal #buildinpublic diary of my progress designing a Fullstack TypeScript SSR web framework. It'll be quite opinionated, but not as "magical" as Next.js or Remix. OSS ofc. Not guaranteed to be better than existing options, but will be different for sure.

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...

dk@mrkha.ng

@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.

View full thread

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.

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?

Adapted the framework so it's compatible with Bun runtime as well. Example for Bun: github.com/fullsoak/bun...

github.comGitHub - fullsoak/bun-examples: example using FullSoak web framework on Bunexample using FullSoak web framework on Bun. Contribute to fullsoak/bun-examples development by creating an account on GitHub.
dk@mrkha.ng

Finally the 1st PoC is out of the oven: FullSoak - a Fullstack TypeScript SSR-first web framework. The design decisions shared so far are summarized in the README: jsr.io/@fullsoak/fu... Once again: I did this mostly as a self-challenge, to see how far we can keep-it-stupid-simple.

Finally the 1st PoC is out of the oven: FullSoak - a Fullstack TypeScript SSR-first web framework. The design decisions shared so far are summarized in the README: jsr.io/@fullsoak/fu... Once again: I did this mostly as a self-challenge, to see how far we can keep-it-stupid-simple.

dk@mrkha.ng

Design decision: I adore the straightforwardness of website development in the early 2000s. One html file linking to css files. Since this framework is SSR-first, I’d love to keep this stupidly simple mantra. I’ll think about scss at some point (for now it can be a separate, bring-ur-own thing).

Design decision: I adore the straightforwardness of website development in the early 2000s. One html file linking to css files. Since this framework is SSR-first, I’d love to keep this stupidly simple mantra. I’ll think about scss at some point (for now it can be a separate, bring-ur-own thing).

dk@mrkha.ng

Day 0: based tech selection --- DOM rendering: I've been a React user since ~2014 I picked up #deno in 2024 Deno Fresh endorses #preact So will I --- URL routing: I used Express, Koa I made github.com/somnusjs/som... based on Restify I made github.com/Thesephi/oak... based on Oak which I'll use

The framework users can make decisions about which CSS rules to put in CSS files, and which to pass directly into the Preact components (ie. as one of the methods to avoid FOUC). Atm I'm not sure what the consequence of this decision will be. Any insight is much appreciated 🙏

Design decision: While Preact endorses HTM (Hyperscript Tagged Markup), I wish to support both HTM and "traditional" JSX. Note: I do like HTM, but I'd assume the community is already very familiar with JSX. So even if I use HTM for myself, I wouldn't strip JSX support away from this framework.

dk@mrkha.ng

Day 0: based tech selection --- DOM rendering: I've been a React user since ~2014 I picked up #deno in 2024 Deno Fresh endorses #preact So will I --- URL routing: I used Express, Koa I made github.com/somnusjs/som... based on Restify I made github.com/Thesephi/oak... based on Oak which I'll use

Day 0: based tech selection --- DOM rendering: I've been a React user since ~2014 I picked up #deno in 2024 Deno Fresh endorses #preact So will I --- URL routing: I used Express, Koa I made github.com/somnusjs/som... based on Restify I made github.com/Thesephi/oak... based on Oak which I'll use

dk@mrkha.ng

I'll start using this bsky account as an informal #buildinpublic diary of my progress designing a Fullstack TypeScript SSR web framework. It'll be quite opinionated, but not as "magical" as Next.js or Remix. OSS ofc. Not guaranteed to be better than existing options, but will be different for sure.

DX: Browserify, webpack, babel, all sorts of loaders & plugins: they helped me tremendously in the past. Still, I'm gonna ditch them all in this project. KISS attempt. Util functions (ie getServerSideProps, loader, handle etc.) are magical. I appreciate magic, but my memory is too weak for spells.

Design tradeoffs: My goal is SSR-first. I think it'll be crazy hard to design an SSR-first framework that also supports CSR & client-side routing seamlessly. Next.js and Remix may excel there. I won't have the resources to keep up. I'll treat those as "best efforts" and focus on SSR only for now.

I'll start using this bsky account as an informal #buildinpublic diary of my progress designing a Fullstack TypeScript SSR web framework. It'll be quite opinionated, but not as "magical" as Next.js or Remix. OSS ofc. Not guaranteed to be better than existing options, but will be different for sure.

Few notes on the intents behind: 1. I prefer to KISS; existing options are awesome, but a bit more bulky than my brain can handle (& I trust there are others like me) 2. I'd love to benchmark "how complex things need to be" to support standard business use cases. Let's see how long we can KISS.

PS on "KISS": when I say KISS I mean for the devs who work with the framework. I don't mean necessarily for the actual source code of the framework. I trust: the more simple a (working) piece of software seems from the outside, the more complex it is inside.

for the RPG-gamer -turned #deno devs out there, remember NieR: Automata, because we'll constantly do: ``` deno test -NIER ``` ジ

Ending 2024 with a library version bump, not sure if I should be happy or sad about it. But what’s done is done, here to hoping i’ll up my Rust skills a bit more in 2025 🦀🍾🎊 #rust #sdk #happynewyear

developing ts libs in deno world When developing an npm module, it's a well known standard to install the module locally (from another workspace) by npm link or simply npm install straight from a local directory. How does that look in Deno world? For example when developing a JSR module locally?…

khangdinh.wordpress.comdeveloping ts libs in deno worldWhen developing an npm module, it's a well known standard to install the module locally (from another workspace) by npm link or simply npm install straight from a local directory. How does that look in Deno world? For example when developing a JSR module locally? Not much of a difference, actually. Here is my current setup as I work on…

For many of us Devs, making an API call and doing sth with the response is “the start of the visible job”, but it’s worthy to take 5’ once in a while to appreciate and admire the hard work put into the submerged parts of the iceberg, one of which is TLS.

just learned today that I need both lines in my Workspace settings to have `deno fmt` as the default formatter for .ts files. It's cuz VS Code has its own "TypeScript Format" User setting, which somehow overwrites Workspace setting. I have non-Deno ts projects too, so this is the best of 2 worlds.

When our REST API Schema and implementation logic live in the same code space, parameter parsing and Open API doc generation happen together... Efficient. Centralized. Let alone Elegant. Demo code: replit.com/@sephdinh/au... #oak, #oak-routing-ctrl

I‘m dealing with these topics in combination: - Deno.ChildProcess instances running Docker commands - WebStream - SIGTERM / SIGKILL Lots of eye-opening experiences. Heaps of questions unanswered. Plethoras of things that can go wrong (and will go wrong). But at the same time so exciting.

Moving here feels like “127.0.0.1” for me, after posts from my favourite persons started disappearing from my twitter feeds. I tried Mastodon for a while but for some reason did not get the same homie feeling. I hope this place stays like this til i’m too old to use internet anymore ☺️

You are up to date.