Version 9.0.1 is a website skeleton, not an application stack
HTML5 Boilerplate v9.0.1 gives a new site the files people often forget until launch: an HTML document, base CSS, a 404 page, icons, robots.txt, a web manifest, and sample JavaScript. The index includes viewport, description, theme color, favicon, Apple touch icon, and Open Graph placeholders. Nothing chooses a component model, router, server, database, or content system. That restraint is the product, and it is also the reason some projects should start elsewhere.
The shipped index is only 868 bytes and still says Hello world. Its language attribute, title, description, canonical social values, and Open Graph image fields are blank. You must replace the icons, review the manifest, write the page, and check every metadata value before deployment. HTML5 Boilerplate lowers the chance of forgetting a file; it does not make an unfinished page ready to publish. Treat every placeholder as a task, not as a useful default.
Three start paths avoid cloning the authoring repository
The README gives 3 practical routes for users: create a project with the companion initializer, use the GitHub template, or obtain the published package or release archive. The repository itself contains Gulp tasks, tests, and release machinery used to create /dist. Cloning all of that for a simple site adds work with no benefit unless you intend to change how the Boilerplate is produced. Most users should begin from its output and keep their history clean.
The npm package still deserves careful handling. Its useful files live under node_modules/html5-boilerplate/dist, and the README says users may need to copy them into their project. That is different from a library imported by application code. The companion template repository is clearer if you want a normal Git starting point. Developers who need a live module graph, asset imports, and hot replacement should choose Vite rather than turn this folder into a custom build system.
What happened when we ran it
Our sandbox installed commit 8b3b188 in 21 seconds, adding 328 npm packages and occupying 70 MB. The build completed in 8 seconds. The checkout itself had 60 files, around 400 source lines, and measured 0.3 MB. This gap between a tiny output and a larger dependency tree is mostly a contributor concern because release-archive users do not need the authoring toolchain.
Mocha completed in 9 seconds with 25 passed and 0 failed out of 25. Npm audit reported 0 known vulnerabilities across the installed packages, including 0 critical, high, moderate, and low findings. We also counted 8 CI workflow files and a tests directory; no Dockerfile was present. Containers would add little to a static folder, while the workflow coverage and passing archive tests give maintainers credible evidence that the distributed files match the source build.
Node 22 is required for contributors, not archive users
The repository package declares Node 22 or newer and pins its Volta setup to Node 22.23.1. Gulp 5 builds the distribution, and Mocha checks the generated archive. An end user downloading the v9.0.1 zip can work directly in HTML, CSS, and JavaScript without Node. This distinction makes setup easier than the 328-package lab result first suggests, provided you choose the release output rather than the authoring checkout.
The included CSS has common helpers, media-query placeholders, and print rules. The HTML links to a plain js/app.js, while sample Webpack configuration is available for users who want it. There is no TypeScript setup in the published baseline. Pull request 3466 proposes TypeScript documentation, which confirms that typed application development is an addition rather than an existing first-class path. Vite is the cleaner choice if TypeScript and package imports are already decided.
Browserslist defaults replace a fixed legacy support promise
Browser support follows the current Browserslist defaults query instead of naming fixed browser versions. That keeps the promise understandable as browsers change, but it does not help a contract that requires an old embedded WebView or a specific enterprise release. Test those targets yourself and pin the browsers list used by your own build. Progressive enhancement makes the starter forgiving; it cannot prove that custom scripts, CSS, or media work on equipment outside its stated support set.
Accessibility is similar. Version 9.0.1 added an og:image:alt placeholder, and the base document uses familiar semantic elements, yet the project cannot supply accessible content or interactions before you build them. Open issue 3038 asks for expanded accessibility documentation. The current docs explain the shipped HTML and CSS, but teams need their own keyboard, contrast, heading, form, and assistive-technology checks once real interface code replaces the empty page.
Fifty-seven thousand stars accompany current maintenance
GitHub showed 57,617 stars and 28 open issues and pull requests on September 11, 2026, split into 7 issues and 21 pull requests. The last push was September 11, and same-day dependency pull requests were being reviewed or merged. The latest release remains v9.0.1 from April 2024, but recent repository work means the older tag alone is not evidence of abandonment. Users should decide between the stable archive and current template branch consciously.
HTML5 Boilerplate remains a good answer to a narrow question: what files should surround a hand-built web page? Our 25-of-25 test result supports using the measured commit as a starting point, and the 0.3 MB checkout is easy to inspect. It is a poor substitute for an application framework, a static-site generator, or a design system. Start here when plain files are the plan. Start with Vite or Eleventy when you already need more than a page skeleton.