5 ms·

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? Ho

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
        wubrr 2y ago
        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.
        deleted 2y ago
        [deleted]
        deleted 2y ago
        [deleted]
        zero_shift 2y ago
        Yes, I'm aware the code doesn't run natively on the frontend. But we aren't talking about that.
        wubrr 2y ago
        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).
        deleted 2y ago
        [deleted]
        wubrr 2y ago
        > 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/ 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 2y ago
        JIT?
      - thesephi 2y ago
        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-Deployment#no-build https://github.com/fullsoak/fullsoak/wiki/Concepts-&-Example... Thank you for your help above in making things clearer <3
        nosefurhairdo 2y ago
        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!
        thesephi 2y ago
        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!
    - lolinder 2y ago
      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.
- wubrr 2y ago
  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/ 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.
  - nsonha 2y ago
    > 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.
    - wubrr 2y ago
      > 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.
      - nsonha 2y ago
        you're right, found this benchmark https://maxday.github.io/lambda-perf https://maxday.github.io/lambda-perf
  - nextaccountic 2y ago
    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
thesephi 2y ago
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/ 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-Deployment https://github.com/fullsoak/fullsoak/wiki/Concepts-&-Example...
- leptons 2y ago
  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!
  - thesephi 2y ago
    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/components/MyOtherComponent/index.tsx#L13 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/components/MyRouteAwareComponent/index.tsx#L23-L39 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" :)
  - xps 2y ago
    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.

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
      - wubrr 2y ago
        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.
        deleted 2y ago
        [deleted]
        deleted 2y ago
        [deleted]
        zero_shift 2y ago
        Yes, I'm aware the code doesn't run natively on the frontend. But we aren't talking about that.
        wubrr 2y ago
        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).
        deleted 2y ago
        [deleted]
      - wubrr 2y ago
        > 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/ 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 2y ago
      JIT?
    - thesephi 2y ago
      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-Deployment#no-build https://github.com/fullsoak/fullsoak/wiki/Concepts-&-Example... Thank you for your help above in making things clearer <3
      - nosefurhairdo 2y ago
        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!
        thesephi 2y ago
        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!
  - lolinder 2y ago
    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.
wubrr 2y ago
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/ 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.
- nsonha 2y ago
  > 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.
  - wubrr 2y ago
    > 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.
    - nsonha 2y ago
      you're right, found this benchmark https://maxday.github.io/lambda-perf https://maxday.github.io/lambda-perf
- nextaccountic 2y ago
  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

thesephi 2y ago

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/ 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-Deployment https://github.com/fullsoak/fullsoak/wiki/Concepts-&-Example...

leptons 2y ago
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!
- thesephi 2y ago
  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/components/MyOtherComponent/index.tsx#L13 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/components/MyRouteAwareComponent/index.tsx#L23-L39 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" :)
- xps 2y ago
  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.