thesephi

Hi, I just wish to update that: since [email protected], support for Cloudflare Workers has been added in experimental mode :)

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

Completely agreed! And "trade-offs" is the perfect keyword here. In exchange for zero cognitive load (ie. complexities in managing build config & consistency between dev & prod setups), we get a bunch of ESM, rendering the performance of our app dependent on browser loading optimizations (among other things).

I'll try to benchmark this "no build" setup on mdeium-large codebases, also comparing between different use cases (e.g. blog-like website vs rich-interactive web app such as "online photo editing") and let's discover the pros and cons of everything :)

I keep a #buildinpublic blog for FullSoak on my bsky page: https://bsky.app/profile/mrkha.ng

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.

Hi! Kudos for the work on SmallWeb. I actually attempted to run this on your platform as well. I was able to run it partially on Cloudflare workers, so I trust it's compatible with environments like SmallWeb as well. Let's see!

that's a nice perspective :) I totally had no intention for 'taking credits' as I assumed it's a 'given' that we run TS directly with Deno, Bun, or Node.js with the experimental flag.

I'll take this to my desk & update the wordings towards your suggestions above - thank you!

I managed (with some struggles) to get it deployed with Cloudflare Workers here: https://fullsoak-cloudflare-example.dklab.workers.dev/

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 :)

Ah please don't get me wrong, there's no build command in my example. The command to start the app directly is: `deno src/main.ts`

and `main.ts` is an original source file, it's not a "bundle" of many files together, like in other setups with build config (tsconfig, webpack config, babel config, etc.)

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

i like that sound of that. Possibility for a nice logo image too!

it's a valid question. In the JavaScript / TypeScript community, we usually understand "fullstack" as "isomorphic": https://www.lullabot.com/articles/what-is-an-isomorphic-appl...

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.

and that's a totally valid concern :) So far I only wish to check the concept in general (ie: "does it work"). As for "does it work fast / at scale", definitely a future topic.

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" :)

Hi! My apologies if the wording was confusing :( By "no build" I mostly meant "no bundling" (so: we're not combining all files into a single js bundle entry).

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

my appreciations!

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

kudos to the MithrilJS project & also for having earned visibility on OpenCollective <3 I can see the (much respected) history track of this project.

Having "survived" the "Internet Explorer ages" of the www, I can share that my heart always has a slot for "vanilla JS" (& anything towards its direction). When coding solo and/or for light-weight (enough) projects, I also tended to do pure JS.

ahh good to know :) Thanks - I'll try it out for sure.

Also irrelevant but VanJS does have a way more invested logo & better name than "FullSoak" which I cooked up at 4am xD

thank you! You may find a Live Demo example (deployed as a Bun app) mentioned in this wiki: https://github.com/fullsoak/fullsoak/wiki/Concepts-&-Example...

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

Wonderful!!! I wanted to provide a Live Demo, I tried with Deno Deploy, but I got a brick wall there because of some unintended blocker (ironically haha): https://github.com/denoland/deploy_feedback/issues/802

My next best choice was to extend the support to Bun, and then deploy it with Render.com: https://fullsoak.onrender.com/

I wasn't aware Glitch can also support Deno. So, sincere appreciations for your Glitch example <3 <3

My apologies if the wording made it confusing :D By "no build" I only meant "no bundling".

You can check the generated source code of the example deployment to see how it's deployed: https://fullsoak.onrender.com/

But spoiler: it's like in the 90s: each page request results in a text/html response, and the HTML doc then links in any .js or .css file it needs.

I elaborate more in this wiki: https://github.com/fullsoak/fullsoak/wiki/Concepts-&-Example...

my apologies for using controversial wording. I'd love to confirm that we still must have some sort of transpilation / transformation because no Web Browser can consume JSX code directly (after all, JSX is just syntactic sugar, not a base language).

What I meant by "no build" is "no bundling". I elaborated more in this wiki: https://github.com/fullsoak/fullsoak/wiki/Concepts-&-Example...

Thank you for your help above in making things clearer <3

Thanks for your thoughts! I do adore Fresh. In fact, I have run production projects on Next.js and Remix, and played around with Deno Fresh, and I enjoy them in different ways.

When I wrote "no build", I simply meant that we do not bundle the whole app into a single file.

Fresh is indeed very close to what I'm trying to explore here, yet if I understand correctly about Fresh, we still need a real build step: https://fresh.deno.dev/docs/concepts/server-configuration#-b...

Disclaimer: I have nothing against build steps, I just wish to explore an alternative approach where we completely do without them!

thank you! You are both right that the wording could use some revamp. Perks of hacking on sth til 3am and writing a dirty README that leaves a stigma for years haha.

Also by "no build" I mostly meant "no bundling". If you look at the source code of the example deployment: https://fullsoak.onrender.com/app - you'd see that every HTML file loads a single .js file. Sometimes we can "lazy load" the entire component .tsx file (if we choose to do so).

So there's no bundling of the whole app into 1 single "entry point". From JSX/TSX to vanilla JS, we do need a "transpilation" step, and right now it's done ad-hoc (on every request). Some caching technique could be employed to make this scale & perform, but it's a topic for another day I guess.

Definitely need to find a coherent wording to describe this whole concept without causing mix up or misunderstanding. Thanks again for pointing these out!

i wouldn't really introduce this as "a problem solver" :) It's more like an exploration of an alternative approach that combines base concepts such as:

- import map: https://preactjs.com/guide/v10/no-build-workflows/#import-ma... - TypeScript runtime: https://www.reddit.com/r/typescript/comments/y8tsav/comment/... - SSR & Hydration: https://zustand.docs.pmnd.rs/guides/ssr-and-hydration

But if I have to pick my brain and find a benefit that this approach brings, i guess it would be that we now avoid the entire "config hell" and cognitive load of managing build setups. This article shares some of this view: https://deno.com/blog/node-config-hell

Disclaimer: i have nothing against standard build processes that we've used for years. I've juggled a lot with browserify, webpack, and their successors & siblings. I just feel it's worthy to give a spotlight for an approach where we completely go without them :)

wow I wasn't aware of VanJS before. It looks nice!

in my limited exploring of VanJS so far, I like that it also takes the direction to simplify things. That said, afaik VanJS simplifies the "JSX" part (so: we don't have to transpile from JSX to vanilla JS because... we don't even use JSX :D).

For the target output (which we need to start the actual app), afais, VanJS still involves this build step: https://github.com/vanjs-org/vanjs-org.github.io/blob/master...

( we can see it being used from `package.json` at the "build" step: https://github.com/vanjs-org/vanjs-org.github.io/blob/master... )

thank you for your approval of the 'no build' approach. We don't have to necessarily discuss the "framework perspective" of this topic - this all is more like a concept, a "lego mashup" of several standards:

- import map: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/sc... - TypeScript runtime: https://www.reddit.com/r/typescript/comments/y8tsav/comment/... - SSR & Hydration: https://zustand.docs.pmnd.rs/guides/ssr-and-hydration

So even without naming a new framework, one can simply pick up the "base concepts" above and mix them together, and have something similar :)

(of course as @root_axis mentioned: sooner or later any concept materializes as a "framework" or at least a "library" - so while we unfortunately can't change the nature of society, we can actively choose what we use & what we don't use. Psss: tbh i'm not really a framework person myself haha)

no I had completely no idea. Is this a generation gap thing, or maybe I just lived under a rock for too long - thank you for the heads up haha. If this causes too much friction, for sure it should be renamed..