thesephi

Enabling this on Cloudflare Workers has been a rather challenging journey, due to the fact that the file-system APIs (that FullSoak uses) are not available on Cloudflare Workers. In fact there are still some bugs to squash, but I'm excited to share an early PoC: https://github.com/fullsoak/cloudflare-workers-examples

Live Demo here: https://fullsoak-cloudflare-workers-examples.dklab.workers.d...

Not sure if it's better than a Discord or sth like Tulips chat, but imho it doesn't matter, as long as there's a safe "draft space" to jot down the thinking-out-loud process, all while getting potentially feedback & help from everyone.

My next immediate exploration goals: make this framework compatible with deployment solutions such as Cloudflare Workers and Smallweb.run - atm I can't guarantee 100% success rate, but excited to see how it turns out.

But it's a long way until it's groomed & released as a standard feature. I'll share more details in the near future!

I'll also check val.town later. On a related note: someone was suggesting https://www.smallweb.run/ as well.

It would be cool if it's supported everywhere :)

I wouldn't call Fresh build step a downside either. With build step, there comes a build config (https://fresh.deno.dev/docs/concepts/server-configuration#-b...).

Imo, Fresh' build config is already way simpler than the "traditional" webpack approach (https://deno.com/blog/node-config-hell). Here in FullSoak, I only wish to push this boundary further ie. "no build config at all".

Laravel and RoR are veteran giants in the Web Framework industry. I'm sure they cover "isomorphy" in their own ways, just that at the time they were born, the terms "isomorphic" and "fullstack" weren't even coiled.

This "FullSoak" framework is by no means aimed to be as full-fledged as the likes of Laravel / RoR / or even other JavaScript frameworks such as Next.js, Remix, SvelteKit, etc. - but it stays true to the "isomorphy" concept, where the same code is runnable on the browser & the server alike.

I do wish to elaborate: since we use JSX/TSX, in theory we can in-line as much as we'd like. Here I include CSS in the component itself: https://github.com/fullsoak/bun-examples/blob/main/src/compo...

So it can be just 1 HTML resource + 1 js file for every unique path. And with preact-iso (or react router) we can make subsequent pages load on-the-fly without a hard browser refresh / hard resource reload. Like so: https://github.com/fullsoak/bun-examples/blob/main/src/compo...

But ultimately: I do see rooms for improvements re. resource optimizations. My personal wish is to use standard web specs such as "preload", "prefetch", "server push", etc. to optimize as much as possible, without taking the "bundling route" - so: just exploring a different taste, not that I have anything against the existing "build routes" :)

As for JSX itself: if we choose to use it, for sure we still need to transform it back to vanilla JS. I elaborate more in this wiki: https://github.com/fullsoak/fullsoak/wiki/Concepts-&-Example...

You're absolutely correct at the "problems that build steps do". One example is the whole loader stuff (e.g. SCSS, Less, and the plethora of other things we can "just import (tm)" into our TSX components). For now it was a conscious decision that I keep things "stupid simple" as I shared in a Bsky post: https://bsky.app/profile/mrkha.ng/post/3lg3qw377ss27

Re. the "selling" part, it's also my wish to see how people resonate with this. Maybe not the framework itself, but only the concept of using standard specs (ie importmap + TypeScript runtime) - & since it's just bare standards, let's see if it attracts frictions (or not).

And Jude was kind enough to roll out a Deno example on Glitch: https://glitch.com/~fullsoak