It works with bun or deno which are alternative node runtimes that support jsx and typescript without a build step.

So the build happens implicitly via the runtimes, then.

I mean, no? Unless you're saying all interpreted languages have a build step?

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.

Building is creating the runnable artefact, but this artefact is already runnable, so I'd just call that "interpreting" the program

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.

Yes, I'm aware the code doesn't run natively on the frontend. But we aren't talking about that.

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

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

JIT?

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

I would probably replace a lot of this language with something along the lines of "powered by Deno, enabling simplified, all-in-one tooling." You don't want it to look like you're taking credit for the features that Deno is responsible for. Would also help me understand what your project offers vs what Deno offers.

Hope that helps!

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!

Bun does not handle TSX at the runtime level because Bun uses JavaScriptCore as its runtime and JavaScriptCore does not support TS(X).

Bun transpiles all typescript code before executing it in the JavaScriptCore runtime. That's an implicit on-startup build step.

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.

> a shell script that builds and runs a C program from source has no build step

I would say so. Ultimately build step or not isn't a meaningful thing to care about. What matters is the cold start/runtime impact. In the case of deno/bun, the impact seem minuscule/not meaningful.

> Ultimately build step or not isn't a meaningful thing to care about. What matters is the cold start/runtime impact.

The two are closely related.

> In the case of deno/bun, the impact seem minuscule/not meaningful.

Seems like a pretty baseless assertion.

you're right, found this benchmark https://maxday.github.io/lambda-perf

It has no build step. It builds when you run

It's like language implementations that nominally aren't "compiled", like Python, but nonetheless compile to bytecode when you run the program

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

Not having all the code in-line that can be in-line is like the 90s. You had me until the 'no bundling' thing. Separate http requests for all resources is a non-starter for anyone worried about page speed. I do like the choice of Preact though!

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

I take the opposite approach - bundling is a non-starter for me. But it really depends on what you're building. Bundling can be great for web apps, but for content-driven websites where SEO optimization is key, I prefer the "90s-style" approach and Fullsoak's philosophy.

Also, separate HTTP requests allow for granular caching, and with HTTP/2 the overhead is minimal.

You're doing the opposite of SEO optimization if page speed score is of any value to your SEO (and it's important to Google's SEO ranking, so yeah). I work on a "content-driven website" - actually a few thousand of them - and our clients definitely want their SEO to be top-notch and page speed score factors into that. Any http requests for external resources will bring page speed down, and that can affect SEO. I don't have to worry about caching at all when the pages are scoring perfect 100% on Lighthouse.