7 ms·

Show HN: A no-build fullstack SSR TypeScript web framework

75 points by thesephi 2y ago

Hi HN! I'd love to seek your insights on a fullstack web framework that employs a different approach: no build. It's not a new concept. The folks as Preact mentioned it: https://preactjs.com/guide/v10/no-build-workflows/ https://preactjs.com/guide/v10/no-build-workflows/ However, in the Web Framework market, I've yet to find many that support both "no build" and "SSR". There's always some sorts of "client mount" and "server mount" and either has (or both have) to go through a build (bundling) process. With the build process, there comes additional maintenance efforts and cognitive load. I've enjoyed wrestling with tsconfig, webpack config, all sorts of presets and plugins countless times... When things work, they just work, but when we need sth a bit custom or unconventional, then we're almost always in for a tough ride. (or it's just me ) Not to say I'm against any existing build workflow. In fact I benefited a lot in the past from webpack, and i'm very positive about modern bundlers like Parcel 2, Turbopack, rspack, etc. I just feel it'd be fair to save some slots for the "no build" route :) To this end, I spent the last month working on a prototype of a TypeScript fullstack SSR web framework. It's compatible with Deno and Bun runtimes. I'd love to make it compatible with Node.js as well (at some point). The framework registry page (https://jsr.io/@fullsoak/fullsoak https://jsr.io/@fullsoak/fullsoak) summarizes the motives expressed so far. An example deployment is available at: https://fullsoak.onrender.com/app https://fullsoak.onrender.com/app The code behind the deployment above: https://github.com/fullsoak/bun-examples https://github.com/fullsoak/bun-examples PS: you may see Preact being used & mentioned everywhere but I'm positive that React is 100% supported as well (just drop-in & use). I just happened to choose Preact to experience it more for myself. I look forward to your thoughts :) and learning if this might (or might not) be a feasible idea at scale. And perhaps, which future directions you would see this (or something like it) goes. Thank you much for any insight!

the_arun 2y ago
Sorry, slightly confused. From JSX docs: > The difference is that the precompile transform analyses your JSX statically and stores precompiled HTML strings if possible. That way a lot of time creating JSX objects can be avoided. So if there are compilation errors, who is stopping me from running without the build?
- thesephi 2y ago
  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-Deployment#example-lazy-loaded-tsx-component https://github.com/fullsoak/fullsoak/wiki/Concepts-&-Example...
alecnotthompson 2y ago
[flagged]
bsimpson 2y ago
I don't understand. You're authoring in TSX and serving JS to browsers, so there's clearly a build step. How is your model different from e.g. vite serve? How does it get deployed? Are the files translated to vanilla JS on request, or are they translated ahead of time and cached (in other words, a build step)?
- root_axis 2y ago
  It works with bun or deno which are alternative node runtimes that support jsx and typescript without a build step.
  - satvikpendem 2y ago
    So the build happens implicitly via the runtimes, then.
    - zero_shift 2y ago
      Bun handling the TSX at runtime is just its capabilities as an interpeter. Else we'd be saying all interpreted languages have a build step
      - nosefurhairdo 2y ago
        Browsers cannot parse jsx/tsx natively. Deno is transforming the code you write before it is executed in the browser. That transformation is typically referred to as a build step.
        zero_shift 2y ago
        I'm well aware that browsers don't run TS. But in this instance we are talking about the server side runtime. Building is creating the runnable artefact, but in the context of the server this artefact is already runnable, so I'd just call that "interpreting" the program
slowtec 2y ago
I like the no-build approach, but I'm afraid the problem is bigger. For years, a new framework has appeared every week (it feels like every day) that promises to solve all problems with the latest buzzwords. The mere fact that this happens shows that today's web development suffers from a plethora of unsolved fundamental problems. Instead of fighting a problem with workarounds (and thus new problems), it would be nice if the community would sit down and ask itself how we can create a future that makes frameworks obsolete. Sometimes I get the impression that we have more of a social problem than a technical one. If browser vendors, developers, managers, corporations, startups, freelancers and everyone else involved sat down at a table and talked constructively with each other, things would certainly be possible that would save everyone a lot of work, or am I wrong?
- root_axis 2y ago
  > it would be nice if the community would sit down and ask itself how we can create a future that makes frameworks obsolete. The community is not an entity, it can't sit down and ask itself things, new ideas appear and the good ones get adopted. You can't prevent the existence of alternative approaches and ideas.
- thesephi 2y ago
  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/script/type/importmap https://developer.mozilla.org/en-US/docs/Web/HTML/Element/sc... - TypeScript runtime: https://www.reddit.com/r/typescript/comments/y8tsav/comment/it2grpo/ https://www.reddit.com/r/typescript/comments/y8tsav/comment/... - SSR & Hydration: https://zustand.docs.pmnd.rs/guides/ssr-and-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)
- 2y ago
digitaltrees 2y ago
You are aware the term full soak is slang for sex right? Intentional name?
- thesephi 2y ago
  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..
  - yieldcrv 2y ago
    morman teenagers do 'soaking' because they were told active participation in pre-marital sex like thrusting is taboo while soaking inside… resisting the urge to thrust… satisfies the condition the lore continues that third persons jump on a bed they're all on is a surrogate for thrusting not generational, just mormon things
  - primitivesuave 2y ago
    The slang term "soaking" is primarily used in the Mormon community for a particular method of theologically-acceptable premarital intercourse.
- lerp-io 2y ago
  maybe do something like fullsock instead? idk just a thought
  - thesephi 2y ago
    i like that sound of that. Possibility for a nice logo image too!
viraptor 2y ago
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.
- deleted 2y ago
  [deleted]
- nosefurhairdo 2y ago
  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 2y ago
    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 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!
    - 2y ago
quectophoton 2y ago
I've been wanting to make a no-build webapp using Mithril.js[1][2], with plain-JS type annotations that don't require build steps (TypeScript's JSDoc syntax [3], but I'm looking forward to the proposed type annotations[4]). With something like this, type-checking would still require running a command when using Node.js, but it's just an optional developer dependency since the code would still be just standard JavaScript. But in the end I've not done that because I figured it's more effort than it's worth, compared to just doing server-side rendering with other backend languages and just using JS where needed (not necessarily "raw" JS, I just mean it as in "not having a full-page component"). I'm just letting you know that there are definitely some people like me that would like if more JS tooling didn't require a build step or specific runtimes (like Deno or Bun) as a hard dependency. [1]: https://github.com/MithrilJS/mithril-node-render https://github.com/MithrilJS/mithril-node-render [2]: https://github.com/StephanHoyer/mithril-isomorphic-example/ https://github.com/StephanHoyer/mithril-isomorphic-example/ [3]: https://www.typescriptlang.org/docs/handbook/jsdoc-supported-types.html https://www.typescriptlang.org/docs/handbook/jsdoc-supported... [4]: https://github.com/tc39/proposal-type-annotations https://github.com/tc39/proposal-type-annotations
- thesephi 2y ago
  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.
IshKebab 2y ago
> Then the app can be started up for local development: > > deno -A --watch src/main.ts Sure looks like a build step to me? Anyway I'm fine with one easy Deno build step, but Deno already has a fantastic web framework that supports SSR, so how is this different to Fresh?
- thesephi 2y ago
  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#-build-1 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!
  - IshKebab 2y ago
    Thanks for the reply! I don't quite understand why you want to avoid a build step. Normally when people talk about that what they really mean is they don't want to have to run a build command, but you still have that. To put it another way, what is the downside of Fresh's build step that you avoid?
    - thesephi 2y ago
      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#-build 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 https://deno.com/blog/node-config-hell). Here in FullSoak, I only wish to push this boundary further ie. "no build config at all".
cma 2y ago
SSR - server side rendering
lerchmo 2y ago
[flagged]
- deleted 2y ago
  [deleted]
zero_shift 2y ago
Can I ask (partly for my benefit, partly for yours) for a short summary of what the problem is I might have, that this tool solves?
- thesephi 2y ago
  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-maps https://preactjs.com/guide/v10/no-build-workflows/#import-ma... - TypeScript runtime: https://www.reddit.com/r/typescript/comments/y8tsav/comment/it2grpo/ https://www.reddit.com/r/typescript/comments/y8tsav/comment/... - SSR & Hydration: https://zustand.docs.pmnd.rs/guides/ssr-and-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 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 :)
cmrdporcupine 2y ago
Isn't this what VanJS is?
- thesephi 2y ago
  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/render.sh 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/package.json#L7 https://github.com/vanjs-org/vanjs-org.github.io/blob/master... )
  - cmrdporcupine 2y ago
    VanJS can be used just fine without a build step, and I do so. The first instructions in https://vanjs.org/start https://vanjs.org/start are for this.
    - thesephi 2y ago
      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
skipants 2y ago
This looks great. I would love to see something like this evolve to become the industry standard. My only worry between then and now is will it run into a wall if it is unable to solve problems that build steps did? Does it handle extensions that webpack did browser shims? I assume those will just be imported modules. And of course it is a new-thing-to-learn(tm) which is always a tough sell to getting it used in a corporate setting. For good reason. Here's some things I like about the idea, mostly duplicating what you said already: 1. By holding your project to a no-build constraint, that means we won't go down the rabbit hole of toolchains like we did with bower, webpack, etc. to fix any problem. Ever. Yay! 2. You really did simplify the "build" step. My personal experience has been that that has always been a source of frustration, especially since most developers just want to get-shit-done and the more deep-diving devs would have to martyr themselves to get it working again. Now hopefully they just need to understand one set of config to tweak to get the application working as is. 3. It feels to me like your project will own any breaking issues that come out of it. It's always been a pain when there was complexities at the edges of parts of the toolchain. If NPM v16 breaks with webpack v5 or whatever its version scheme is, one or the other needed to upgrade to fix it and the ownership of the issue wasn't always clear. Sometimes it would take awhile because of a niche interaction between the two. And of course upgrading past it had other painful breaking changes your legacy app needed to address. Anyways, looks good! Keep it up & good luck! I'm curious to see where this goes.
- thesephi 2y ago
  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 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).
SignalM 2y ago
Very cool will try it out. Like the bun support
- thesephi 2y ago
  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-Deployment 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 https://glitch.com/~fullsoak
blinkymach12 2y ago
I like it! I spun up a little remixable Glitch project based on your demo so that I could play with it in a web editor. Thanks for sharing. https://glitch.com/~fullsoak https://glitch.com/~fullsoak
- thesephi 2y ago
  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 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/ https://fullsoak.onrender.com/ I wasn't aware Glitch can also support Deno. So, sincere appreciations for your Glitch example <3 <3
pomdtr 2y ago
Neat! I'm working on a self-hostable platform to host my deno apps (https://smallweb.run https://smallweb.run), I wonder if I would be able to your framework on there.
- thesephi 2y ago
  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!
nbbaier 2y ago
Does this support serverless environments like cloudflare workers and val town[0]? [0] https://www.val.town/ https://www.val.town/
- thesephi 2y ago
  I managed (with some struggles) to get it deployed with Cloudflare Workers here: https://fullsoak-cloudflare-example.dklab.workers.dev/ 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/ https://www.smallweb.run/ as well. It would be cool if it's supported everywhere :)
- thesephi 2y ago
  Hi, I just wish to update that: since fullsoak@v0.9.0, 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 https://github.com/fullsoak/cloudflare-workers-examples Live Demo here: https://fullsoak-cloudflare-workers-examples.dklab.workers.dev/ https://fullsoak-cloudflare-workers-examples.dklab.workers.d...
  - nbbaier 2y ago
    Nice! I'll check out this demo in the morning
darepublic 2y ago
Taking twobof my favorite parts of the ecosystem (ts and jsx) and leaving behind the rest (webpack). Good luck!
thesephi 2y ago
I keep a #buildinpublic blog for FullSoak on my bsky page: https://bsky.app/profile/mrkha.ng 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.

75 points by thesephi 2y ago

the_arun 2y ago

Sorry, slightly confused. From JSX docs: > The difference is that the precompile transform analyses your JSX statically and stores precompiled HTML strings if possible. That way a lot of time creating JSX objects can be avoided. So if there are compilation errors, who is stopping me from running without the build?

thesephi 2y ago
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-Deployment#example-lazy-loaded-tsx-component https://github.com/fullsoak/fullsoak/wiki/Concepts-&-Example...

alecnotthompson 2y ago

[flagged]

bsimpson 2y ago

I don't understand. You're authoring in TSX and serving JS to browsers, so there's clearly a build step. How is your model different from e.g. vite serve? How does it get deployed? Are the files translated to vanilla JS on request, or are they translated ahead of time and cached (in other words, a build step)?

root_axis 2y ago
It works with bun or deno which are alternative node runtimes that support jsx and typescript without a build step.
- satvikpendem 2y ago
  So the build happens implicitly via the runtimes, then.
  - zero_shift 2y ago
    Bun handling the TSX at runtime is just its capabilities as an interpeter. Else we'd be saying all interpreted languages have a build step
    - nosefurhairdo 2y ago
      Browsers cannot parse jsx/tsx natively. Deno is transforming the code you write before it is executed in the browser. That transformation is typically referred to as a build step.
      - zero_shift 2y ago
        I'm well aware that browsers don't run TS. But in this instance we are talking about the server side runtime. Building is creating the runnable artefact, but in the context of the server this artefact is already runnable, so I'd just call that "interpreting" the program

slowtec 2y ago

I like the no-build approach, but I'm afraid the problem is bigger. For years, a new framework has appeared every week (it feels like every day) that promises to solve all problems with the latest buzzwords. The mere fact that this happens shows that today's web development suffers from a plethora of unsolved fundamental problems. Instead of fighting a problem with workarounds (and thus new problems), it would be nice if the community would sit down and ask itself how we can create a future that makes frameworks obsolete. Sometimes I get the impression that we have more of a social problem than a technical one. If browser vendors, developers, managers, corporations, startups, freelancers and everyone else involved sat down at a table and talked constructively with each other, things would certainly be possible that would save everyone a lot of work, or am I wrong?

root_axis 2y ago
> it would be nice if the community would sit down and ask itself how we can create a future that makes frameworks obsolete. The community is not an entity, it can't sit down and ask itself things, new ideas appear and the good ones get adopted. You can't prevent the existence of alternative approaches and ideas.
thesephi 2y ago
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/script/type/importmap https://developer.mozilla.org/en-US/docs/Web/HTML/Element/sc... - TypeScript runtime: https://www.reddit.com/r/typescript/comments/y8tsav/comment/it2grpo/ https://www.reddit.com/r/typescript/comments/y8tsav/comment/... - SSR & Hydration: https://zustand.docs.pmnd.rs/guides/ssr-and-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)
2y ago

digitaltrees 2y ago

You are aware the term full soak is slang for sex right? Intentional name?

thesephi 2y ago
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..
- yieldcrv 2y ago
  morman teenagers do 'soaking' because they were told active participation in pre-marital sex like thrusting is taboo while soaking inside… resisting the urge to thrust… satisfies the condition the lore continues that third persons jump on a bed they're all on is a surrogate for thrusting not generational, just mormon things
- primitivesuave 2y ago
  The slang term "soaking" is primarily used in the Mormon community for a particular method of theologically-acceptable premarital intercourse.
lerp-io 2y ago
maybe do something like fullsock instead? idk just a thought
- thesephi 2y ago
  i like that sound of that. Possibility for a nice logo image too!

viraptor 2y ago

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.

deleted 2y ago
[deleted]
nosefurhairdo 2y ago
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 2y ago
  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 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!
  - 2y ago

quectophoton 2y ago

I've been wanting to make a no-build webapp using Mithril.js[1][2], with plain-JS type annotations that don't require build steps (TypeScript's JSDoc syntax [3], but I'm looking forward to the proposed type annotations[4]). With something like this, type-checking would still require running a command when using Node.js, but it's just an optional developer dependency since the code would still be just standard JavaScript. But in the end I've not done that because I figured it's more effort than it's worth, compared to just doing server-side rendering with other backend languages and just using JS where needed (not necessarily "raw" JS, I just mean it as in "not having a full-page component"). I'm just letting you know that there are definitely some people like me that would like if more JS tooling didn't require a build step or specific runtimes (like Deno or Bun) as a hard dependency. [1]: https://github.com/MithrilJS/mithril-node-render https://github.com/MithrilJS/mithril-node-render [2]: https://github.com/StephanHoyer/mithril-isomorphic-example/ https://github.com/StephanHoyer/mithril-isomorphic-example/ [3]: https://www.typescriptlang.org/docs/handbook/jsdoc-supported-types.html https://www.typescriptlang.org/docs/handbook/jsdoc-supported... [4]: https://github.com/tc39/proposal-type-annotations https://github.com/tc39/proposal-type-annotations

thesephi 2y ago
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.

IshKebab 2y ago

> Then the app can be started up for local development: > > deno -A --watch src/main.ts Sure looks like a build step to me? Anyway I'm fine with one easy Deno build step, but Deno already has a fantastic web framework that supports SSR, so how is this different to Fresh?

thesephi 2y ago
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#-build-1 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!
- IshKebab 2y ago
  Thanks for the reply! I don't quite understand why you want to avoid a build step. Normally when people talk about that what they really mean is they don't want to have to run a build command, but you still have that. To put it another way, what is the downside of Fresh's build step that you avoid?
  - thesephi 2y ago
    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#-build 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 https://deno.com/blog/node-config-hell). Here in FullSoak, I only wish to push this boundary further ie. "no build config at all".

cma 2y ago

SSR - server side rendering

lerchmo 2y ago

[flagged]

deleted 2y ago
[deleted]

zero_shift 2y ago

Can I ask (partly for my benefit, partly for yours) for a short summary of what the problem is I might have, that this tool solves?

thesephi 2y ago
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-maps https://preactjs.com/guide/v10/no-build-workflows/#import-ma... - TypeScript runtime: https://www.reddit.com/r/typescript/comments/y8tsav/comment/it2grpo/ https://www.reddit.com/r/typescript/comments/y8tsav/comment/... - SSR & Hydration: https://zustand.docs.pmnd.rs/guides/ssr-and-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 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 :)

cmrdporcupine 2y ago

Isn't this what VanJS is?

thesephi 2y ago
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/render.sh 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/package.json#L7 https://github.com/vanjs-org/vanjs-org.github.io/blob/master... )
- cmrdporcupine 2y ago
  VanJS can be used just fine without a build step, and I do so. The first instructions in https://vanjs.org/start https://vanjs.org/start are for this.
  - thesephi 2y ago
    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

skipants 2y ago

This looks great. I would love to see something like this evolve to become the industry standard. My only worry between then and now is will it run into a wall if it is unable to solve problems that build steps did? Does it handle extensions that webpack did browser shims? I assume those will just be imported modules. And of course it is a new-thing-to-learn(tm) which is always a tough sell to getting it used in a corporate setting. For good reason. Here's some things I like about the idea, mostly duplicating what you said already: 1. By holding your project to a no-build constraint, that means we won't go down the rabbit hole of toolchains like we did with bower, webpack, etc. to fix any problem. Ever. Yay! 2. You really did simplify the "build" step. My personal experience has been that that has always been a source of frustration, especially since most developers just want to get-shit-done and the more deep-diving devs would have to martyr themselves to get it working again. Now hopefully they just need to understand one set of config to tweak to get the application working as is. 3. It feels to me like your project will own any breaking issues that come out of it. It's always been a pain when there was complexities at the edges of parts of the toolchain. If NPM v16 breaks with webpack v5 or whatever its version scheme is, one or the other needed to upgrade to fix it and the ownership of the issue wasn't always clear. Sometimes it would take awhile because of a niche interaction between the two. And of course upgrading past it had other painful breaking changes your legacy app needed to address. Anyways, looks good! Keep it up & good luck! I'm curious to see where this goes.

thesephi 2y ago
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 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).

SignalM 2y ago

Very cool will try it out. Like the bun support

thesephi 2y ago
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-Deployment 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 https://glitch.com/~fullsoak

blinkymach12 2y ago

I like it! I spun up a little remixable Glitch project based on your demo so that I could play with it in a web editor. Thanks for sharing. https://glitch.com/~fullsoak https://glitch.com/~fullsoak

thesephi 2y ago
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 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/ https://fullsoak.onrender.com/ I wasn't aware Glitch can also support Deno. So, sincere appreciations for your Glitch example <3 <3

pomdtr 2y ago

Neat! I'm working on a self-hostable platform to host my deno apps (https://smallweb.run https://smallweb.run), I wonder if I would be able to your framework on there.

thesephi 2y ago
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!

nbbaier 2y ago

Does this support serverless environments like cloudflare workers and val town[0]? [0] https://www.val.town/ https://www.val.town/

thesephi 2y ago
I managed (with some struggles) to get it deployed with Cloudflare Workers here: https://fullsoak-cloudflare-example.dklab.workers.dev/ 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/ https://www.smallweb.run/ as well. It would be cool if it's supported everywhere :)
thesephi 2y ago
Hi, I just wish to update that: since fullsoak@v0.9.0, 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 https://github.com/fullsoak/cloudflare-workers-examples Live Demo here: https://fullsoak-cloudflare-workers-examples.dklab.workers.dev/ https://fullsoak-cloudflare-workers-examples.dklab.workers.d...
- nbbaier 2y ago
  Nice! I'll check out this demo in the morning

darepublic 2y ago

Taking twobof my favorite parts of the ecosystem (ts and jsx) and leaving behind the rest (webpack). Good luck!

thesephi 2y ago

I keep a #buildinpublic blog for FullSoak on my bsky page: https://bsky.app/profile/mrkha.ng 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.