[leerob]

IMO, this post doesn't discuss the tradeoff of removing the build step. What a “build” is has been obfuscated. When you deploy an app, you now need to convert TypeScript into JS, and then the JS needs to be turned into an optimal representation for V8 to process.

For example, Fresh has a “build process” whose cost is paid for by the user [1]. You want to do these things before the user hits your page, and that’s the nice thing about CI/CD. You can ensure correctness and you can optimize code.

In the interest of losing the build step, a tradeoff is made for worse UX for developer experience (DX). Rather, I would recommend shifting the compute that makes sense to the build step, and then give developers the optionality to do other work lazily at runtime[2].

[1]: https://github.com/denoland/fresh/blob/08d28438e10ef36ea5965...

[2]: https://vercel.com/docs/concepts/incremental-static-regenera...

[KyleJune]

In addition to this, the bundle files generated at runtime are stored in memory in a Map. If you have a server and want to have multiple processes for handling requests, each of those processes will have a copy of the build artifacts in memory. Any requests that get routed to newly started processes will have their response delayed by however long it takes to generate the bundle. So users would experience seemingly random delayed load times due to runtime bundling.

I think it would be better to do bundling in your CI/CD. esbuild supports incremental builds, so using that + code splitting would be one way of speeding up builds.

With their current bundling design, if they believe bundling is fast enough for users to not be negatively impacted, wouldn't it also be fast enough to not slow down development/deployment by having it in a build step?