2 ms·

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

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!
- dkkergoog 2y ago
  [dead]
- nosefurhairdo 2y ago
  Should point out that "no bundling" has serious trade-offs. From https://vite.dev/guide/why.html#why-bundle-for-production https://vite.dev/guide/why.html#why-bundle-for-production > Why Bundle for Production > Even though native ESM is now widely supported, shipping unbundled ESM in production is still inefficient (even with HTTP/2) due to the additional network round trips caused by nested imports. To get the optimal loading performance in production, it is still better to bundle your code with tree-shaking, lazy-loading and common chunk splitting (for better caching).
  - thesephi 2y ago
    Completely agreed! And "trade-offs" is the perfect keyword here. In exchange for zero cognitive load (ie. complexities in managing build config & consistency between dev & prod setups), we get a bunch of ESM, rendering the performance of our app dependent on browser loading optimizations (among other things). I'll try to benchmark this "no build" setup on mdeium-large codebases, also comparing between different use cases (e.g. blog-like website vs rich-interactive web app such as "online photo editing") and let's discover the pros and cons of everything :)

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!

dkkergoog 2y ago
[dead]
nosefurhairdo 2y ago
Should point out that "no bundling" has serious trade-offs. From https://vite.dev/guide/why.html#why-bundle-for-production https://vite.dev/guide/why.html#why-bundle-for-production > Why Bundle for Production > Even though native ESM is now widely supported, shipping unbundled ESM in production is still inefficient (even with HTTP/2) due to the additional network round trips caused by nested imports. To get the optimal loading performance in production, it is still better to bundle your code with tree-shaking, lazy-loading and common chunk splitting (for better caching).
- thesephi 2y ago
  Completely agreed! And "trade-offs" is the perfect keyword here. In exchange for zero cognitive load (ie. complexities in managing build config & consistency between dev & prod setups), we get a bunch of ESM, rendering the performance of our app dependent on browser loading optimizations (among other things). I'll try to benchmark this "no build" setup on mdeium-large codebases, also comparing between different use cases (e.g. blog-like website vs rich-interactive web app such as "online photo editing") and let's discover the pros and cons of everything :)