From the engine to the plugin

When we type node hello.js, the shell asks the operating system to start the program file node, passing the words node and hello.js as its arguments (argv). That file is ordinary compiled C++, like any program built with gcc. Its main function is three lines, and it calls node::Start.

Start does three jobs. It initializes V8, Google's JavaScript engine, the same one inside Chrome. It creates an environment with Node's own objects: process, require and the file and network modules. Then it runs our script and spins the event loop (libuv's loop), which keeps the process alive while timers, files or sockets are pending. So "Node" is a C++ program that embeds V8 and adds system abilities. It is not a compiler and not a language.

An engine executes one language: it parses the text, compiles it to bytecode, interprets it and compiles hot code to machine code (just-in-time, or JIT). The V8 page follows one expression through those steps. A runtime is an engine plus everything the place it runs in adds, such as the global objects, the APIs and an event loop. The language is the same in both, but the objects available to it differ.

We asked both runtimes the same question, typeof window, typeof document, typeof process, typeof require, and recorded what each one answered.

A module is one file that shares things with other files through export and import. Navbar.tsx ends with export default Navbar, and App.tsx gets it back with import Navbar from './components/Navbar'. A package is a folder of modules with a package.json label, published so anyone can install it. Our own project is a package too.

The registry is the server that stores every published package, and npm's is registry.npmjs.org. It works like an app store for code: authors publish to it, and npm install downloads from it. A package name is unique across the whole registry and belongs to whoever published it first, which causes two problems. Good short names run out, and anyone can take a name that sounds official. A scope solves both. It is a prefix such as @tailwindcss/ owned by one account or organisation, and only that owner can publish under it. Scopes work like folders: @tailwindcss/vite and @sentry/vite are two different packages, both called vite.

Here is the real conversation with the registry during our npm install. Each line is one HTTP request asking the registry about a package, and the answer lists every version with its download address. The scoped name @types/node goes out as @types%2fnode: the slash is URL-encoded, so the server sees one name and not a folder path. That is the line this.escapedName = name.replace('/', '%2f') in npm-package-arg.

The two @ signs mean different things. An @ at the start begins a scope, and an @ after the name begins what we want: an exact version (4.3.3), a range (^4.3.0 means 4.3.0 or newer but below 5), or a tag (latest, a name the registry points at a version, shown above). With nothing after the name, npm uses the range *, any version, and picks the newest.

Library or framework: who is in charge

The difference is who calls whom. We call a library: our code decides when to use it, and it does one job and hands control back. toast("Added!") from react-toastify is a library call. A framework calls us. It runs the program and calls our code when it needs to, much like a form whose questions and order are already decided, where we only fill in the blanks. In Next.js we write app/about/page.tsx, export a function and never call it ourselves. Next.js creates the /about address and calls our function when someone visits. This is called inversion of control, also known as the Hollywood principle: "don't call us, we'll call you".

Every command has the same grammar: program (which tool), command (what to do), arguments (what to do it to), and options (settings that start with a dash: one dash and a letter like -D, or two dashes and a word like --save-dev). Spaces separate the parts. The shell (bash, PowerShell) splits the line into words and starts the program; the program never sees the spaces. After that, npm runs four small steps of its own code. We follow each one.

1. npx is npm exec. The npx program is a tiny script: it inserts exec as the first word and puts -- in front of the first word that is not an option. So npx tsc --noEmit becomes npm exec -- tsc --noEmit, and --noEmit goes to tsc, not to npm.
2. Options are sorted out by nopt. nopt walks the words and looks each option up in npm's definitions. -D is a shorthand for --save-dev, and -gD means -g -D because every letter is a one-letter shorthand. An option npm does not know, such as --template, becomes a true/false npm setting, and the word after it is left as an ordinary argument. A lone -- stops option parsing, and everything after it is kept as it is.
3. The first plain word becomes a command. cmd-list.js holds the 67 commands and the aliases: i is install, run is run-script, and create is init. It also accepts any unambiguous abbreviation (insta) and a few common typos (isntall).
4. Each package argument is read by npm-package-arg into a name, a scope and a version, range or tag, as in Frame 2.

Why npm create vite@latest dev-stack -- --template react-ts needs the --. create is init, and npm init vite@latest turns the name into create-vite@latest and runs it with npm exec. The real output in Frame 6 shows this: npm prints > create-vite dev-stack --template react-ts. Without the --, nopt reads --template as an unknown npm setting (template = true), so react-ts becomes a stray argument and create-vite never sees --template. The command lab shows both versions.

Why npm run dev finds vite when typing vite in the terminal says "command not found". Every package that provides a command declares a bin, and npm links it into node_modules/.bin. Before running a script, npm's run-script library puts that folder at the front of PATH, the list of folders the operating system searches for programs. It adds node_modules/.bin for the project folder and for every folder above it. We added a script that prints the first entries of PATH and ran it.

Type an npm, npx, node or git command, or pick a preset. Each word is coloured by its role, and every package spec is broken into scope, name and version. Try removing a space, or the --, and watch what changes.

Browsers run JavaScript, not TypeScript or JSX, and they import modules by URL, not by package name. Something has to translate. Vite does that in two ways. As a dev server (npm run dev), it serves our project on localhost and transforms each file when the browser asks for it, so starting is instant and a saved file updates in place (hot module replacement). As a build tool (npm run build), it transforms everything once, bundles the many modules into a few files and minifies them into dist/ for a host to serve.

Every request goes through loadAndTransform: load the file, then transform it, which means calling the transform function of every plugin in order. Each plugin receives the code and the file's id, and can return new code.

This is what the browser actually received when it asked our dev server for /src/App.tsx. The type annotation : Props is gone, because Vite removes types without checking them. That is the job of our editor and of tsc in npm run build. Each <nav> became a call, _jsxDEV("nav", { className: … }), that returns a plain object. And import { useState } from "react" became a real URL, /node_modules/.vite/deps/react.js, because a browser cannot look up a package name.

Read these in order, because each one builds on the one before.

1. API: the named functions and objects a program lets other code use, like the buttons on a remote. Examples: the DOM's document.querySelector, React's useState, Node's fs.readFile. We call it.
2. Callback: a function we hand to other code so that it can call it at the right moment, as in addEventListener('click', fn), onClick={…} or the function given to .map(…). It calls us. A common mistake is addEventListener('click', sayHi()): the parentheses call sayHi immediately and hand over its result instead of the function.
3. Hook (in tools): a named moment in a host's work where it calls the callbacks plugins gave it. Vite's include config (reading settings), transform (each file) and buildEnd. The loop in Frame 4 is the transform hook being called.
4. Plugin: a package of callbacks for a host's hooks, which adds a feature without changing the host's code. A Vite plugin is an object with a name and hook functions. react() and tailwindcss() in vite.config.ts return such objects. A plugin can be a host too: Tailwind is a plugin of Vite, and daisyUI is a plugin of Tailwind.

Tailwind CSS is a list of ready-made utility classes, each one a small CSS rule. Its Vite plugin reads our files, collects every word that looks like a class name, and writes CSS for exactly those words. utilities.ts registers every family. Here is the padding family, which maps px to padding-inline. The spacing helper turns the number into --spacing(4), and that becomes calc(var(--spacing) * 4). The theme sets --spacing: 0.25rem, so px-4 is 1rem, which is 16px. The multiplier must be a multiple of 0.25, so p-2.5 works and p-0.3 produces nothing.

A variant is a prefix ending in a colon that wraps the rule in a condition. lg: wraps it in @media (width >= 64rem), so it applies from 1024px wide and up, and a class with no prefix applies at every width. This is what "mobile-first" means: we write the phone layout plainly, then change it for bigger screens. hover: holds a detail many tables leave out. It adds :hover and also wraps the rule in @media (hover: hover), so a phone, which cannot hover, does not keep the colour after a tap. Variants stack from left to right: lg:hover:x puts the lg media query on the outside.

Here is the real stylesheet the dev server sent for our navbar. Every class we used has exactly one rule, and nothing else is there, except a few extra words that happen to be class names somewhere in the project's files (transform, filter). Tailwind's scanner reads every file that git does not ignore, so a word in a README can produce CSS too. That is harmless, and it shows that the scanner matches words, not meaning. Our own bg-brand appears because of the @utility rule in index.css, which is how it works with hover: and lg: like a built-in class.

Type one or more classes separated by spaces, exactly as in className="…". Each class shows the rule Tailwind writes, what its values work out to, and whether its condition is true in this window right now. Check in this browser applies the declarations to a test box 400px wide and reads back what your browser computes.

Now every word together, in the order things happen when we work on the assignment. Steps 1 to 4 and 7 to 9 run in Node on our machine; steps 5 and 6 run in the browser.

This page holds about a hundred words, twenty commands and the five Tailwind rules. Reading it again tomorrow will feel productive, and it is one of the least effective things we can do. This is one of the best-replicated findings in learning research. A 2013 review of ten study techniques by Dunlosky and colleagues rated practice testing (recalling from memory) and distributed practice (spacing reviews out) as the two most useful. It rated rereading and highlighting low, because they make material feel familiar without making it retrievable. Below is what each technique is, why it works, and exactly how to apply it to this page.

Ebbinghaus measured his own memory for nonsense syllables in 1885, and Murre and Dros repeated the experiment in 2015. Most of what we learn is lost within the first day, and what survives fades more slowly after that. The useful part is that each successful recall makes the next drop slower. The chart below illustrates the shape. It is not a measurement of us: retention decays as e−t/S, and each review multiplies the stability S by 2.5. Add reviews and watch the curve flatten.

Roediger and Karpicke had students either reread a passage or try to write down what they remembered. After five minutes the rereaders did better. After two days and after a week, the students who had practised recalling remembered clearly more, even though rereading felt more effective to them. The effort of pulling something out of memory is what strengthens it. The honest check is the question "can I produce it with the page closed?", not "does this look familiar?".

Applied here: cover the right-hand column of any table on this page and say the answer out loud first. Use the quizzes in Try it before reading their explanations. The trainer never shows an answer until we have tried.

The same total time spread over several days beats one long session, and the best gap grows with how long we want to remember. Cepeda and colleagues' meta-analysis of hundreds of experiments found this again and again. The simplest schedule is the Leitner system. Cards live in five boxes. A card we recall moves up one box, and a card we miss goes back to box 1. Box 1 is reviewed every day, box 2 every 2 days, box 3 every 4, box 4 every 8 and box 5 every 16. Easy cards drift away; hard ones keep coming back.

Applied here: ten minutes a day with the trainer, rather than an hour on Sunday. It remembers which box each card is in, in this browser only.

We can hold only a handful of items in mind at once, but one item can be a whole chunk: a pattern that stands for many facts. Experts do not remember more facts; they have better chunks. This page is built around four chunks, and each one replaces a long list:

Slamecka and Graf found that words people produce themselves, even from a small cue, are remembered better than words they read. Copying a command from a tutorial teaches the fingers nothing. Typing it from the goal ("add TypeScript as a dev dependency") makes us build it from the grammar.

Applied here: the trainer's command cards give a goal and check whatever we type with the command model, so npm i -D typescript and npm install --save-dev typescript both count, because npm reads them identically. Its class cards give a description and check our class against the Tailwind model.

Practising one kind of thing at a time (all the spacing classes, then all the colour classes) feels smooth. Mixing them teaches us to tell them apart, which is the skill we need when facing a blank className. Kornell and Bjork found that interleaved examples taught categories better, even though learners believed the blocked order worked better.

Applied here: the trainer shuffles terms, commands and classes into one queue.

Memory is for what we need instantly and for the chunks that let us understand. Look the rest up, deliberately and quickly. Knowing where to look is a skill worth practising too.

Explaining forces retrieval and shows the gaps immediately: the sentence we cannot finish is the thing we did not understand. After each study session, explain one frame of this page out loud in plain words, without looking, as if to a friend who has never coded. Where we get stuck, reread only that paragraph, then try again.

One card at a time, with the answer hidden until we have tried. For a word card, answer out loud, reveal it, and say honestly whether we got it. Command and class cards are checked by the page's two models, so any form npm or Tailwind would treat the same is accepted. Correct moves a card up a box; a miss sends it back to box 1.

Six questions in the style of a web engineering or software tools exam. Write the answer first, then open the model answer and mark it honestly. Answers about commands were produced by the command model and agree with npm 10.9.4; answers about CSS were produced by the class model and agree with Tailwind CSS 4.3.3.