How do modern build tools handle TypeScript vs tsc?
separating transpilation from type checking for speed. Great answer: fast native tooling strips TS per-file on demand via native ESM; browser loads only visited modules; tsc/ts-loader check/bundle the whole graph upfront.
What's really being asked
Your understanding of the architectural trade-off between correctness and speed in development. Specifically, whether you know that TypeScript transformation can be separated from type checking, and that serving modules on-demand via native ESM eliminates the need to process the entire application graph before the first page load.
The full answer
Four points in order. First, modern tools like Vite transform TypeScript files individually as the browser requests them, using fast native tooling that strips types and lowers syntax without performing full type checking. Second, because the browser loads source code via native ES modules, only the modules needed for the current page are processed; the rest of the codebase is ignored until visited. Third, tsc and traditional ts-loader in Webpack must understand the entire module graph upfront, either type-checking everything or bundling all dependencies into a single artifact before serving, which makes startup time scale with application size. Fourth, the combination of no upfront bundling for source code and native-speed per-file transpilation means dev server startup is effectively constant time regardless of how many files exist in the project.
The mistakes people make
Claiming that Vite uses tsc under the hood during development. Saying that the speed difference is only because Vite is written in Rust. Asserting that Vite pre-bundles application source code the same way it pre-bundles dependencies. Another red flag is ignoring the native ESM on-demand model and attributing everything to caching.
What usually comes next
How do you surface type errors if the dev server does not check them? Why is bundling still used for production if ESM is fine for development? How does dependency pre-bundling work with large node_modules graphs? What trade-offs exist when you skip type-aware emit for features like const enum or decorator metadata?
A concrete example
Imagine a project with thousands of source files. On first load the browser only needs the entry point and a handful of route modules. With Vite, those few files are transformed on demand and the server starts instantly. With a traditional Webpack and ts-loader setup, the bundler must crawl and compile the entire dependency graph before serving the first byte, so a large codebase can take tens of seconds to start. Type checking with tsc adds even more time, but in Vite's model it can run asynchronously without blocking the dev server.
Interview question
What allows Vite to start its dev server in constant time even in a large TypeScript codebase?
- a.It strips types and transforms syntax only for files the browser actually requests via native ESMCorrect
- b.It relies on aggressive disk caching of previously compiled modules to avoid recompilation on restart
- c.It uses tsc under the hood during development but runs type checking asynchronously so it does not block startup
- d.It pre-bundles all application source modules into chunks at startup using native Rust code
Why? this is the answer
Vite transforms individual TypeScript files on demand as the browser requests them via native ESM, so startup time remains constant regardless of total project size. Distractor A is tempting because many developers assume Vite relies on tsc for transpilation, but Vite actually uses fast native tooling that separates type checking from transformation during development.
Just read this? Test yourself on what you have been reading.
Read the original → vite.dev
- #typescript
- #vite
- #build-tools
- #webpack
- #esbuild
You just looked this up. Could you explain it out loud?
That is the part interviews actually test. Tezvyn takes questions like this one and gives you what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on typescript — each one lists the topics its interview covers.
See open roles