[HN Gopher] Show HN: A no-build fullstack SSR TypeScript web fra...
___________________________________________________________________
Show HN: A no-build fullstack SSR TypeScript web framework
Hi HN family! 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/ 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)
summarizes the motives expressed so far. An example deployment is
available at: https://fullsoak.onrender.com/app The code behind
the deployment above: 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!
Author : thesephi
Score : 46 points
Date : 2025-02-12 19:54 UTC (3 hours ago)
(HTM) web link (jsr.io)
(TXT) w3m dump (jsr.io)
| the_arun wrote:
| 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?
| bsimpson wrote:
| 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 wrote:
| It works with bun or deno which are alternative node runtimes
| that support jsx and typescript without a build step.
| satvikpendem wrote:
| So the build happens implicitly via the runtimes, then.
| jbreckmckye wrote:
| 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 wrote:
| 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.
| jbreckmckye wrote:
| 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
| wubrr wrote:
| The code is not runnable on the frontend. It needs to be
| transformed/built before that can happen.
|
| Saying this doesn't have a build step is like saying a
| python script that compiles and runs a C program from
| source has no build step.
| jbreckmckye wrote:
| Yes, I'm aware the code doesn't run natively on the
| frontend. But we aren't talking about that.
| wubrr wrote:
| That's exactly what everyone in this comment chain is
| talking about (even though you just updated your previous
| comment to make it sound different).
| wubrr wrote:
| > But in this instance we are talking about the server
| side runtime.
|
| Not at all. We are talking about SSR, and the need for a
| build step (on the backend). That should be pretty
| obvious considering the explicit mentions of running the
| code in the browser, jsx, ts, etc. (Not to mention the
| backend runtime cannot run typescript/jsx without build
| either)
|
| > Building is creating the runnable artefact
|
| That's not all that 'building' is...
|
| > but in the context of the server this artefact is
| already runnable
|
| No it's not. The JIT/interpreter within Deno cannot run
| this code without doing a build first. This is made very
| obvious and explicit in the Deno docs.
|
| https://docs.deno.com/runtime/fundamentals/typescript/
|
| > With its built-in TypeScript compiler, Deno will
| compile your TypeScript code to JavaScript with no extra
| config needed.
| kupopuffs wrote:
| JIT?
| thesephi wrote:
| 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/w
| iki/Concepts-&-Example...
|
| Thank you for your help above in making things clearer <3
| wubrr wrote:
| Deno does not support jsx and typescript 'without a build
| step'. It just runs a build/transform step for you under the
| hood - using the same tsc compiler, config, etc.
|
| https://docs.deno.com/runtime/reference/jsx/
|
| Saying this is not a 'build step' is like saying a shell
| script that builds and runs a C program from source has no
| build step.
| thesephi wrote:
| 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...
| slowtec wrote:
| 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 wrote:
| > _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 wrote:
| 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)
| bsimpson wrote:
| It's also a thorny political problem.
|
| Remember that Dart started as an attempt to evolve web
| programming past some of the perceived deficiencies of
| JavaScript. It came out of Google, who also maintains a
| significant share of the web platform via Chrome. There were a
| bunch of snarky comments about Google trying to colonize the
| web and force its new language upon everyone. Fast forward a
| decade+: now most professional web dev is done in TypeScript, a
| Microsoft language that's backwards compatible with JavaScript.
| JavaScript itself has evolved to address some of the complaints
| of the past. Dart is now the VM embedded in Flutter runtime,
| and has sworn off ever being baked into a browser.
|
| There are two methods that have been successful at changing the
| web:
|
| - Spend countless manhours and calendar years building
| consensus among dozens of people through the standardization
| process, and hope at the end of the day that your pet proposal
| is one of the few that survive. There are many awesome
| proposals that have never made it out of committee.
|
| or
|
| - Build a thing that's compatible with the existing platform
| (e.g. React, CoffeeScript, etc.), and get a critical mass to
| adopt it organically, until is has the influence that the web
| platform will change to meet the demand.
| digitaltrees wrote:
| You are aware the term full soak is slang for sex right?
| Intentional name?
| thesephi wrote:
| 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 wrote:
| 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 wrote:
| The slang term "soaking" is primarily used in the Mormon
| community for a particular method of theologically-acceptable
| premarital intercourse.
| viraptor wrote:
| 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 wrote:
| 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 wrote:
| 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!
| quectophoton wrote:
| 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
|
| [2]: https://github.com/StephanHoyer/mithril-isomorphic-example/
|
| [3]: https://www.typescriptlang.org/docs/handbook/jsdoc-
| supported...
|
| [4]: https://github.com/tc39/proposal-type-annotations
| IshKebab wrote:
| > 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 wrote:
| 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!
| cma wrote:
| SSR - server side rendering
| lerchmo wrote:
| This means something different to people who lived in Utah for
| any length of time...
| jbreckmckye wrote:
| 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 wrote:
| 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 :)
| cmrdporcupine wrote:
| Isn't this what VanJS is?
| thesephi wrote:
| 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... )
| cmrdporcupine wrote:
| VanJS can be used just fine without a build step, and I do
| so.
|
| The first instructions in https://vanjs.org/start are for
| this.
| skipants wrote:
| 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.
| SignalM wrote:
| Very cool will try it out. Like the bun support
| thesephi wrote:
| 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
| blinkymach12 wrote:
| 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
| thesephi wrote:
| 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
___________________________________________________________________
(page generated 2025-02-12 23:01 UTC)