Modern front-end code is written as many small modules — components, utilities, styles — but shipping dozens of separate files to a browser is inefficient, and browsers historically could not handle modern syntax and module systems directly. Build tools bridge this gap, transforming and packaging your source into optimised files the browser can load fast. Vite is the modern, fast tool that has become the default for new front-end projects. Bundling is the core idea: combining many module files into a small number of optimised files, minifying them by stripping whitespace and shortening names, and dropping code that is never used. The result is far fewer, far smaller files for the browser to download — a direct improvement in load performance. Vite's distinctive contribution is splitting development and production into two different strategies. During development, it serves your modules directly over the browser's native ES Module support without bundling them upfront, which makes the dev server start almost instantly no matter how large the project, and makes edits appear immediately through hot module replacement. For production, Vite switches strategy entirely, using a bundler to combine, minify, and tree-shake everything into optimised output. The two modes serve different goals — instant feedback while developing, maximally optimised files when shipping — and Vite handles the switch transparently. This lesson covers what bundling is and why it matters, how Vite's dev and build modes differ, and the practical workflow — scaffolding a project, running the dev server, producing and verifying a production build. It also surfaces front-end-specific concerns like never bundling secrets into client code, completing the tooling picture for the front-end half of the MERN stack.
25 minbeginner
Bundling — Vite intro
Analogy🏏Cricket
🏏 Think of it like cricket: Imagine you are following an India vs Australia match but you cannot watch it live — you ask a friend at the Wankhede Stadium to text you the final scorecard. Asking is the asynchronous operation: you do not stand frozen by your phone until the match ends. You go about your day (other code keeps running) and deal with the score when the text arrives. The promise your friend makes — 'I will send you the scorecard when the innings ends' — is exactly a JavaScript Promise: a commitment to deliver a value later. Just as your friend's promise is initially pending (innings in progress), then settles into either fulfilled (they text you '187/4') or rejected (they text 'rain stopped play, no result'), a Promise transitions once from pending to fulfilled or rejected and never flips back. Just as you plan in advance what you will do when the score arrives ('if India scored 180+, I will celebrate; if the feed fails, I will check another source'), `.then()` and `.catch()` register what happens on success and failure. The insight this reveals is that asynchronous programming is not about doing things faster — it is about not standing idle while you wait, so the single JavaScript thread stays free to handle everything else going on.
Lesson 29 of 36
0% complete