tensorflow/tfjs-examples: a working reference for TensorFlow.js, not a library

What the tfjs-examples repository is actually for

The README states the intent plainly: the repository contains a set of examples implemented in TensorFlow.js, and each example directory is standalone so it can be copied to another project. That single sentence defines the whole contract. This is not a framework you add to a dependency list. It is a set of small, self-contained programs you read, run, and then lift into your own codebase.

The audience follows from that. Someone who has decided to use TensorFlow.js and now needs to see how a convolutional network is wired in the browser, how a tf.data.Dataset is built from a remote CSV, or how a model trained under tfjs-node is exported and then loaded in a browser. The table in the README is the index, and its columns are the real navigation aid: input data type, task type, model type, training environment, inference environment, API type, and save-load operations.

That last column is where the repository earns its keep. Several examples carry an explicit save-load story: abalone-node saves to the filesystem and loads in Node.js, cart-pole and lstm-text-generation use IndexedDB, and date-conversion-attention saves to the filesystem and loads in the browser. Those are the awkward parts of a real deployment, and having a runnable reference for each is more valuable than another tutorial on dense layers.

How the examples are organised and how data flows through them

The layout is flat and predictable. Top-level entries are directories named after the example: mnist, mnist-node, mnist-core, mnist-acgan, mnist-transfer-cnn, lstm-text-generation, jena-weather, sentiment, translation, quantization, and so on. Shared code lives in shared/, and there is a test_util.js at the root plus a presubmit.ts script driven by the root package.json.

The data flow differs per example, and the README table is explicit about it. In the browser examples such as mnist and iris, training and inference both happen in the page, using the Layers API. In the Node.js examples such as abalone-node and baseball-node, the same Layers API is used but the runtime is Node and the artefact goes to the filesystem. A third pattern crosses the boundary: fashion-mnist-vae trains under tfjs-node and then loads the trained model in the browser, and date-conversion-attention trains in Node.js with inference in both browser and Node.js.

Some examples are not about models at all. custom-layer is about defining a Layer subtype. data-csv is about constructing a tf.data.Dataset from a remote CSV. data-generator builds a Dataset from a generator. chrome-extension and electron are about deploying TensorFlow.js inside a Chrome extension and an Electron desktop app. Treating those as model examples misses the point; they document packaging and environment constraints.

There are also two entries that stand apart from the Layers API: tfdf-adult-gbt and tfdf-penguins, which sit alongside the rest as their own directories. The README excerpt does not describe their contents, so anyone evaluating them should open the directory rather than assume parity with the neural network examples.

Installing and running your first tfjs-examples directory

There is no repository-level install that gives you a usable library. The root package.json has no dependencies field, only devDependencies, and its single script is presubmit, which runs ts-node presubmit.ts. The name is tfjs-examples and the version is 0.0.1. That combination tells you the root is tooling for the examples, not a published package.

The practical route is to work inside one example directory. Each one carries its own package.json and its own build setup, which is what makes the copy-out promise true. A typical local run looks like this:

cd mnist
npm install
npm run watch

The watch script is the common pattern across the browser examples: it compiles and serves the example so you can open it in a browser. The README does not spell out the port or the exact dev-server command for every directory, so read the package.json in the directory you chose before running anything.

For the Node.js examples the shape is different, because training writes to disk rather than to a page. abalone-node is the clearest case in the table: numeric input, multilayer perceptron, training and inference both in Node.js, and saving to the filesystem with loading back in Node.js. After installing that directory's dependencies, you run its training entry point and it produces a model artefact on disk that a second script loads.

cd abalone-node
npm install
npm run train

If you only want to see TensorFlow.js work before committing to a setup, the browser examples are the lower-friction start, since the README links hosted demos for many of them (addition-rnn, boston-housing, cart-pole, iris, jena-weather, mnist, and others) under storage.googleapis.com/tfjs-examples. Those links let you confirm the example does what you expect before you install anything.

Where this repository stops being the right tool

The standalone-directory promise is also the limitation. Because each directory is meant to be copied out, there is no shared runtime, no common version pin across examples, and no upgrade path that moves all of them together. If you copy three examples into one project, reconciling their TensorFlow.js versions and build configs is your work, not the repository's.

The root package.json reinforces this. With no dependencies and a 0.0.1 version, there is nothing to depend on. Adding tfjs-examples to a project's dependency list gets you nothing useful.

Second, the examples are teaching artefacts. They are sized for a browser tab or a short Node.js run, not for production data volumes. The README table lists task types and model types but says nothing about dataset size, throughput, or memory behaviour, and the repository does not document rollback or deployment procedures for the models it trains.

Third, the environment matrix is a trap for the careless. Training and inference environments are not interchangeable across examples: some train in the browser, some in a Web Worker, some in Node.js, one infers in a Service Worker, and date-conversion-attention splits training in Node.js from inference in both. Picking an example because its model type looks right, without checking the training and inference columns, is the most common way to waste a day here.

How it compares with Keras examples and the tfjs package itself

The obvious comparison is the Keras examples catalogue. Both are curated sets of small models, and both are meant to be read rather than installed. The difference is the runtime and the deployment surface. Keras examples target Python and a server or notebook, where you control the interpreter and the hardware. tfjs-examples target JavaScript, which means the same model may have to run in a browser tab, a Web Worker, a Service Worker, Electron, or React Native, and the repository has a directory for each of those environments. If your deployment target is a page or a desktop shell, the Keras catalogue does not answer the questions that chrome-extension and electron answer here.

The second comparison is with TensorFlow.js itself. The library is the thing you install; this repository is the thing you read to learn how the library is used. They are not alternatives. The confusion only arises because the repository shares the project's name and lives under the same GitHub organisation, which makes it look like a companion package.

A third point of contrast is the data-pipeline examples. data-csv and data-generator are not model examples at all; they show how to construct a tf.data.Dataset from a remote CSV and from a generator respectively. That ground is not covered by a model catalogue, and it is often the part that blocks a first real project.

Maintenance, licensing and the cost of tracking TensorFlow.js

The repository is not archived and the last push was on 2026-06-22. That is recent enough that the examples are unlikely to have drifted far from the current TensorFlow.js release, but the repository does not publish releases, so there is no changelog to read when something breaks. Your signal for drift is the update-tfjs-version and update_yarn_lock.sh scripts at the root, which exist precisely because keeping many example directories on a consistent TensorFlow.js version is manual work.

That is the upgrade cost in one sentence: the burden is distributed across dozens of independent package.json files rather than centralised. A TensorFlow.js API change that affects the Layers API will touch many directories, and the presubmit script is the mechanism the maintainers use to catch it.

On licensing, the root package.json declares Apache-2.0 and there is a LICENSE file at the top level. Apache-2.0 permits commercial use and modification and includes a patent grant, which matters if you copy an example into a product. The README does not state whether every example directory inherits the root licence or carries its own, so check the directory you copy. This is a description of the licence text, not legal advice.

Editorial conclusion

Use it if you are learning TensorFlow.js or need a working skeleton for a browser or Node.js model, and copy one directory rather than depending on the repository. Do not use it as a production library or expect a published npm package: package.json is private and versioned 0.0.1, with only a presubmit script. Verify first that the example you pick matches your runtime (Browser, Web Worker, Service Worker, Node.js, Electron, React Native) and your save/load target, because those columns differ widely across the table.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. Project website
4. README
5. tensorflow/tfjs-examples on GitHub