Hacker News new | ask | show | jobs
by nosefurhairdo 497 days ago
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.
1 comments
thesephi 497 days 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 - 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!

link
nosefurhairdo 496 days ago
Should point out that "no bundling" has serious trade-offs. From 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).

link
thesephi 495 days 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 :)

link