[viraptor]

Can I just add to the other "words have meaning" comments?

> FullSoak is (mostly) WYSIWYG. Compared to sophisticated frameworks such as Next.js or Remix, FullSoak is actually very "stupid looking": 1) you start with a "Controller" file (as in good old "MVC") which 2) renders your TSX component as text/html content (i.e. a plain string), and then 3) the content hydrates itself on the client side.

Unless it integrates a gui page editor, it's not wysiwyg.

And hydration on the client side is very much not SSR.

Also "stupid looking" doesn't really mean "simple".

There may be something interesting here, but the naming / description is really all over the place and misleading.

[nosefurhairdo]

Additionally, "no build" when writing typescript and jsx/tsx is not possible. The web does not have native support for these files, so by definition there must be a build step.

I think the tech here looks good, but the terminology needs a big overhaul.

[thesephi]

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!

[nosefurhairdo]

Should point out that "no bundling" has serious trade-offs. From https://vite.dev/guide/why.html#why-bundle-for-production

> Why Bundle for Production

> Even though native ESM is now widely supported, shipping unbundled ESM in production is still inefficient (even with HTTP/2) due to the additional network round trips caused by nested imports. To get the optimal loading performance in production, it is still better to bundle your code with tree-shaking, lazy-loading and common chunk splitting (for better caching).

[thesephi]

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

[demarq]

Also wondering what is meant by fullstack.

I was expecting Laravel/Ruby on rails

[thesephi]

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.