aaaaaaabbbbbb

Ah yes, one step outside of New York City, and I'm immediately in the boondocks.

Assuming one has access to a credit card and is financially literate, I agree that using BNPL is a hard sell (never having used it myself). But there is a large population--the unbanked--that lacks access to credit cards. For that population, the choice is not between credit card and BNPL, but BNPL and cash.

I found the article's description of how BNPL structurally differs from credit cards interesting, as it is a reasonable explanation for how BNPL can serve the unbanked and still have functioning credit risk models:

> Even with adverse selection for BNPL, the underwriting is for each transaction, not for all monthly spending like that in credit cards; so if a consumer misses a payment, the BNPL provider can stop lending immediately, as opposed to the credit card company which has to underwrite the person’s full ability and willingness to repay their debts. This tech-enabled granularity allows for legibility and hence greater precision and predictability.

If you have a lot of files, the initial (dev server) page load times increases linearly with the number of files you have.

With a slow bundler, that tradeoff made sense, but with a fast bundler, it is suboptimal.

Also, typically the application is split into multiple smaller bundles, so only a slice of the application is rebundled on change.

Next.js et al. provides a set of opinionated packages designed to enable a specific paradigm. For Next.js, that's server-side rendering. For Remix, that's progressive enhancement.

If you are happy with client-side rendering and do not desire React on the server, there is not a strong reason to use Next.js; it introduces complexity and churn.

Note that while Vite transpiles with esbuild, it bundles with Rollup, which is single-threaded JS.

Vite also uses esbuild to prebundle dependencies for the dev server, but this is separate from production builds.

Since tree-shaking is a common term across frontend build tooling documentation, I adopted it as well.

Dead code elimination in its traditional form also runs during code minification, which is a separate build step from bundler tree shaking. Having separate terms avoids ambiguity.

Thanks for the feedback!

I struggled with the ordering since each section is somewhat mutually dependent; this is arranged more like a thematic history than a chronological one.

Tree-shaking naturally fits under bundling, and I'm afraid that explaining it earlier will make tree-shaking's explanation itself contextless since without bundling there is nothing to tree shake.

I can hyperlink those references to the tree-shaking section tomorrow so that there is an action for the confused.

Esbuild lacks the featureful plugin API that Webpack and Rollup have. It's pretty easy to avoid dependencies that require transpiler/bundler plugins and still have a great set of dependencies, but it's a deal breaker for many.