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