scratch-www: Scratch Website Client Architecture and Development

What scratch-www covers in the Scratch site

scratch-www is the standalone web client for Scratch and contains code for much of the public website at scratch.mit.edu. Its main documented responsibility is the project page. That page presents a playable project together with its title, description, comments, remixes, and studios. The project page also operates in the background when a user selects "See inside" a project.

The repository also covers the site home page, the Ideas page, landing pages for Scratch extensions such as LEGO MINDSTORMS and micro:bit, the Scratch Desktop information page, and pages including Credits and FAQ. These are site-specific experiences rather than a small collection of reusable UI widgets. The project is primarily JavaScript, with React, Redux, Webpack, and Sass forming the documented frontend stack.

The intended users are therefore two different groups. Scratch contributors can use the repository to work on website behavior, while the broader Scratch site audience consumes the resulting pages. Someone looking for a general-purpose web application foundation should note the README's warning: the design depends on Scratch backend systems.

Frontend pages depend on Scratch backend services

The repository layout separates frontend source under `src/` from static assets under `static/`, with Webpack configuration at the webpack.config.js file and a development server under `dev-server/`. The `package.json` scripts show that the site is assembled through Webpack and that the build pipeline cleans `build/` and `intl/`, generates translation data, produces browserlist output, and then compiles browser bundles.

That build structure is only the visible side of the application. The README states that scratch-www makes backend calls throughout the codebase and that its design is tied to backend systems operated by the Scratch team. A project page needs more than a React component if it is to display comments, remixes, studios, project metadata, or the background editor view. Those data sources are part of the assumed operating environment.

The repository is consequently different from a frontend package that can be dropped into an unrelated application and connected to arbitrary APIs. Adopters would need to inspect every backend call and create services that perform the corresponding functions. The README points to this work explicitly when explaining how scratch-www fits in with other Scratch repositories.

React, Redux, Webpack, and Sass shape development work

The documented core technologies are Node, Webpack, React, Redux, and Sass. Jest is used for most newer tests, while the repository still contains Tap tests. Enzyme and Selenium are also listed as testing technologies. The `package.json` scripts distinguish linting, browser bundle generation, Jest tests, legacy Tap tests, integration tests, health tests, coverage, deployment, and translation generation.

This separation matters when judging maintenance work. A change can involve React views and Redux state, but it may also affect locale data, static files, Webpack behavior, browser targets, or tests written in two test systems. The `test` script runs linting, a full build, and unit tests, so the documented test path is broader than a single JavaScript test command.

The repository also contains operational scripts for deployment, including S3 and Fastly steps, plus `s3cmd` listed in `requirements.txt`. These files indicate deployment work beyond ordinary component development. The README does not provide a complete deployment tutorial, but the package scripts show that deployment is treated as a separate workflow rather than as a side effect of running the local server.

Installing scratch-www for a first local build

The README requires Node version 16 and npm. It says the codebase works with specific dependency versions, so the lockfile and the repository's package definitions should be retained rather than replaced with an unrelated dependency set. The documented installation command is:

npm install

After installation, a one-time build can be started with:

npm run build

For development, the README gives this sequence:

npm run translate
npm start

`npm run translate` creates the `intl` directory. The README says the site can build without translated strings being fully prepared, but translatable text will not display correctly until that step has run. `npm start` starts the development server and watches changes in `./static` and `./src`, rebuilding the project after edits.

Once the server is ready, open the documented local address:

localhost:8333

The README identifies `webpack: bundle is now VALID.` as the message indicating that the bundle has loaded into memory and is viewable. An `INVALID` message means compilation is still in progress or updates are not yet reflected in the browser.

Backend coupling limits scratch-www as a reusable client

The clearest limitation is stated directly in the README: using scratch-www for another project requires reviewing all backend calls and creating backend systems that perform those functions. This is a deployment and data-contract problem, not merely a missing configuration option. A developer cannot assume that the project page, comments, remixes, studios, or related metadata will work with a generic API.

The repository is also more difficult to contribute to than `scratch-gui`, according to the README. The reason is specific. `scratch-gui` can run on its own without requiring other services, while scratch-www communicates with several backend systems operated by the Scratch team. A local frontend build may compile, but that does not establish that every page has the services needed for its data.

The documented alternative is `scratch-gui`, which the README says is designed to be usable by anyone without creating backend systems. It can also support backend systems for project and asset saving. The difference is architectural: scratch-www represents a complete website client tied to site services, whereas `scratch-gui` targets the Scratch editor and can function as a more independent component. A contributor new to Scratch source code is directed by the README toward becoming familiar with `scratch-gui` first.

Maintenance, licensing, and upgrade obligations

The repository is not archived, and the last push was on 2026-10-16. The repository metadata does not by itself document a release cadence or compatibility policy. The only listed release is `v2.2.3-hotfix` from 2015-11-11, so the release list should not be treated as evidence that versioned releases describe current development.

The README requires Node 16 and warns that the code works with specific dependency versions. Upgrades therefore need attention to `package-lock.json`, the Node version, Webpack, browser targets, React, Redux, and the translation scripts. The package scripts also show that tests span Jest and Tap, so an upgrade that changes one test stack may not cover the legacy path.

The repository is licensed under AGPL-3.0. The presence of `LICENSE` provides the license text for review. This article does not interpret the legal obligations of that license. Organizations considering redistribution or network use should review the license and any project-specific requirements themselves. The separate `TRADEMARK` file is also notable because this is a Scratch website repository, not a generic package named `www`.

Editorial conclusion

Adopt scratch-www when maintaining or extending the Scratch website itself, with access to the required backend services. Do not choose it as a general reusable frontend foundation unless you are prepared to build equivalent backend systems. Verify first that your deployment can satisfy its backend calls, Node 16 requirement, dependency versions, and translation workflow. The project is not archived, and its last push was on 2026-10-16.

Frequently asked questions

Official sources

1. License: AGPL-3.0
2. Project website
3. README
4. Releases
5. scratchfoundation/scratch-www on GitHub