plainvanilla: a tutorial site that refuses every tool

The site is the argument

Plain Vanilla is a website demonstrating how to do web development using only vanilla techniques, with no tools and no frameworks, just the browser and vanilla web code. The sentence that makes it more than a blog post is the next one: the site itself is also built in this way.

That is a design decision with consequences for how you evaluate it. A tutorial site about not using frameworks is easy to write, because the author is free to use whatever they like to build the site and then describe the manual approach in prose. Here the constraint is real, and you can check it by opening the page source. If the site claims something about the DOM or about events, you can verify it in the browser you are reading it in.

It also means the site is a working artifact rather than a pile of examples. Whatever technique it teaches, you can apply on the same page, in the same devtools, against the same markup.

The project description calls it a tutorial website for plain vanilla web development, and the primary language is recorded as JavaScript. The homepage is plainvanillaweb.com, the licence is MIT, and the last push was on 2026-04-26 with no GitHub releases, so the site is deployed from the repository rather than versioned as a package.

The distinction that the site is making is between the browser as a platform and the ecosystem that has grown up around it. The browser gives you a DOM, events, the fetch API, storage and CSS. A framework is one way of using them. The rest of the ecosystem, and the resources listed at the end of the README, is a set of answers to questions the browser already answers.

Three static servers and no build step

The whole running story is that you serve the public folder as a static website, and the README gives three ways to do it, one per language you are likely to have installed:

- node: `npx http-server public -c-1`
- php: `php -S localhost:8000 -t public`
- python: `python3 -m http.server 8000 --directory public`

The three commands differ in small ways that matter. The Node one runs http-server against the public directory with caching disabled, the -c-1 flag, which matters because a tutorial that serves stale JavaScript teaches something different from what the code says. The PHP one uses the built-in server with a document root of public. The Python one is the standard library module with the directory given explicitly.

The fact that all three work is the point. There is no configuration file to point at a different root, no server-side rendering, and nothing to compile. You are serving files.

There is a fourth option for people who would rather not start a server at all: the VS Code Live Preview extension, used to show the public/index.html file directly. That is a reasonable option for a single file, and it comes with the limitation that a multi-page site with relative links behaves differently when opened through a file path than when served over HTTP, so the server route is the one that matches how the site will really be used.

What is notable is what is absent. There is no package.json, no node_modules, no lockfile and no transpilation step in the top level entries. The repository is a .github/ directory, a .gitignore, a .hintrc, an SVG file, the LICENSE.md, the README, an eslint.config.cjs and the public/ directory.

So the tooling that does exist is linting rather than building. The eslint configuration is there to keep the JavaScript consistent, and the .hintrc file is the configuration for the webhint linter that checks markup and accessibility. Neither produces an artefact. Both exist to keep the source honest, which is a different relationship to tooling than a build step.

The resource list, and what the author is pointing at

The README closes with a list of other projects demonstrating the same approach, and the selection says more about the author's position than a generic reading list would.

The first two are learning resources: MDN Learn Web Development, described as a vanilla web development learning path, and The Odin Project Foundations, described as a vanilla web development course. Both are structured courses rather than reference pages, which fits a project whose purpose is to teach rather than to document.

Then come projects that push the idea further. create-react-app-zero is by the same author and is described as another project of theirs, a no-tools version of create-react-app, to be able to use React without frills. HEX is a React-like approach based on vanilla web development techniques. plainJS is a collection of vanilla JavaScript functions and plugins to replace the use of jQuery, and the Web Dev Toolkit is a collection of vanilla helper functions, boilerplates and libraries. The Modern JavaScript Tutorial is listed as a step-by-step tutorial to learn vanilla JavaScript.

What the list has in common is a refusal to treat a framework as a prerequisite. The create-react-app-zero entry makes that explicit, because it takes the most common starting point for web development and removes the tooling while keeping the library, which is a harder thing to do than avoiding React entirely.

The plainJS and Web Dev Toolkit entries are the pragmatic middle of the list. They are the answer to the question a working developer asks, which is not whether to avoid libraries but which parts of the jQuery or utility library era are worth keeping. The site does not pretend that writing everything yourself is the only valid position, and pointing at collections of drop-in helpers is a more useful thing to do than insisting otherwise.

The Modern JavaScript Tutorial is the one to note as a language resource, since it is described as step-by-step, and a step-by-step JavaScript tutorial is the foundation the rest of the list assumes.

What the repository does not tell you

There is a reason to be careful about how much you infer from this project, and it is worth saying plainly rather than filling the gaps with plausible-sounding description.

The README does not list the topics the site covers. It does not describe a curriculum, a chapter order or a set of exercises. It does not say whether the pages are in order, whether there is a navigation, or how many there are. The public/ directory is the site itself, and the top level entries confirm that it is a directory of files rather than a source tree that gets built into one, but the structure inside it is not described in the documentation available here.

That is unusual for a tutorial project, and it cuts both ways. There is no syllabus to follow, so you cannot tell whether the site covers the DOM, events, fetch, storage, forms, accessibility or something else entirely without opening it. And the site being the demonstration means the content and the code are the same artefact, which makes it impossible to review the topics without running it.

So the sensible way to evaluate it is to serve the public folder and click through, which is the same thing the project asks you to do. The three server commands are given for exactly that purpose, and the absence of a build step means there is nothing to set up before you can read it.

The one thing the documentation does tell you about the content is where it is not: the site is about the browser, not about a specific framework, and the resources list tells you which adjacent projects the author considers comparable in spirit. The name of the repository, plainvanilla, and the site domain, plainvanillaweb.com, are the same statement twice.

If you are evaluating it as a learning resource, the questions to ask are the ones the README cannot answer. How much of the browser API does it cover. Whether the examples are runnable as written or abbreviated for the page. And whether the sequencing leads a beginner through the DOM and events before the asynchronous parts, which is the difference between a reference and a course.

Licensing, attribution and the shape of the contribution model

The project is MIT licensed, with the licence in a LICENSE.md file at the repository root, and the README notes that issues or pull requests are welcome.

There is one attribution outside the MIT terms. The soft ice icon is by Twemoji and is licensed under CC BY 4.0, which is a separate and more restrictive obligation than the MIT licence covers. That is the correct way to handle an asset with a different licence, and the fact that the repository carries an SVG file at the top level is consistent with the icon being the one piece of artwork in the project.

The contributor model is deliberately loose. The README does not describe a branch policy, a commit format, a review process or a changelog. It says issues or pull requests are welcome, and it links to a .github/ directory, which in practice holds the issue and pull request templates and the workflows.

The static analysis configuration tells you the same thing about the author's priorities. The eslint.config.cjs file is at the root, so the JavaScript in public/ is linted, and the .hintrc file configures webhint, which is the linter that checks HTML and CSS for correctness and accessibility problems. Neither is a build step. Both exist to catch mistakes in code that is served as written.

The .gitignore is present, and with no package manager involved it is not about ignoring node_modules. It is most likely ignoring editor and operating system noise, which is the ordinary use when the repository contains no build artefacts.

The overall shape is a small, well-licensed, deliberately minimal project: a public directory, a linter configuration, a licence, an icon and a readme that tells you how to serve it and where to look next. For a tutorial site, that is about the right amount of repository.

Editorial conclusion

plainvanilla suits someone who wants to understand what the browser gives you before reaching for a framework, since every technique on the site is one you can open and read in a text editor. It does not suit you as a project template, because there is no build pipeline to add one to, and the repository is a single public directory with a configuration file for a linter and a hint file rather than a package manifest. Before you start, pick a static server from the three documented options and open the site that way, and note that the project is MIT licensed with the Twemoji ice icon credited separately under CC BY 4.0.

Frequently asked questions

Official sources

1. Issues
2. jsebrech/plainvanilla on GitHub
3. License: MIT
4. Project website
5. README