tfjs-examples: forty three standalone TensorFlow.js programs

Every example directory is meant to be copied out

The design rule is stated once, at the top: each example directory is standalone so the directory can be copied to another project. That single sentence explains the rest of the repository's shape. There is no umbrella package, no shared entry point and no build that produces one artifact. Forty three example directories sit at the top level next to infrastructure entries such as .github/, .vscode/ and shared/, and each one carries its own concern: abalone-node and baseball-node train in Node.js, while iris and mnist train in the browser. The price of that portability is that dependency versions travel with the copy instead of being settled once. A directory you pull into your project brings its own choices with it, and you inherit whichever TensorFlow.js version it was written against. The claim and the shared/ directory sit in mild tension, and nothing in the overview says which examples reach into it.

The root manifest is a lint harness, not an application

The manifest at the repository root is worth reading closely, because it is not what you would expect from a repository of demos. It has no dependencies at all, only devDependencies, and it defines exactly one script:

"scripts": {
  "presubmit": "ts-node presubmit.ts"
},

Everything around that one entry is tooling for checking the examples rather than running them:

"devDependencies": {
  "@types/node": "~18.15.11",
  "jasmine": "~3.10.0",
  "typescript": "4.8.3"
},
"resolutions": {
  "path-parse": "1.0.7"
},

The full list also carries tslint and tslint-no-circular-imports for linting, shelljs and @types/shelljs for script glue, yalc pinned to a 1.0.0 pre-release, and an fs entry pinned to ~0.0.1-security, a version string that reads as a placeholder rather than a real package. A single resolutions entry pins one transitive dependency to an exact version, and the manifest names itself tfjs-examples at version 0.0.1. So the root exists to check code. It is not the place to import anything from.

The example matrix has more empty cells than filled ones

The overview in the README is a nine column table: example name, demo link, input data type, task type, model type, training, inference, API type and save load operations. It is the most useful page in the repository and the least finished. Among the first twenty one rows, eight carry no demo link at all: abalone-node, addition-rnn-webworker, angular-predictive-prefetching, baseball-node, chrome-extension, electron, fashion-mnist-vae and interactive-visualizers. The Training column is empty for several rows that do have an inference target, including angular-predictive-prefetching, chrome-extension and electron, so for those the table tells you where the code runs but not where the weights come from. Model type is blank for custom-layer, data-csv and interactive-visualizers. data-csv is a data plumbing example where a network would be the wrong column, but the row then has little beyond its task description to tell you what it demonstrates. Read the table as an index of intent, not as a specification.

Hosted demos sit under a dist/ path that deploy.sh publishes

Where a demo exists, it follows one pattern. The link is a Google Cloud Storage URL whose tail is dist/index.html inside a bucket path named after the example:

https://storage.googleapis.com/tfjs-examples/boston-housing/dist/index.html

The dist component is a build output directory, and the repository root carries both deploy.sh and cloudbuild.yml. Getting the source is the ordinary git operation, and from there each directory behaves like its own small project:

git clone https://github.com/tensorflow/tfjs-examples.git
cd tfjs-examples

Keep the demo column narrow in what it proves. A link means this example was built and hosted at some point. A blank tells you nothing about whether the example works, only that nobody published it, so a missing demo is not a signal about quality.

Node trains, the browser infers, and the model crosses over

Several examples split training from inference on purpose, and that split is where the save load entries earn their place in the table. abalone-node trains in Node.js, runs inference in Node.js and saves to the filesystem. date-conversion-attention trains in Node.js, runs inference in both the browser and Node.js, and saves to the filesystem so the browser can load the result. fashion-mnist-vae inverts the emphasis: training runs in Node.js with tfjs-node, and its entry describes exporting the trained model from tfjs-node and loading it in the browser. jena-weather trains in both environments, does its inference in the browser, and works over sequence input with an MLP and RNNs. The pattern repeats: the expensive step runs where the data already sits, and what crosses over to the other side is a model file rather than a training script.

Persistence is the sparsest column in the table

Read down the save load operations column and the table goes quiet. Of the first twenty one rows in the README table, only five say anything at all: abalone-node, cart-pole, lstm-text-generation, date-conversion-attention and fashion-mnist-vae. Two of those store through IndexedDB and three move through the filesystem. Every other row among those is blank. That is a real limit for anyone trying to learn how to ship a model from JavaScript, because the storage layer is exactly where the awkward decisions sit, and the README names no file format or schema for any of the five entries that do exist.

The API column only ever says Layers

One column narrows this repository's scope more than any other. Wherever the API type cell is filled in among the rows shown, it says Layers, and it is blank for the rows that are demonstrating something outside that abstraction. Layers is the friendlier surface and it is the right default when the point of a directory is the model rather than the interface, and the rows shown are all built through that high level API. The repository also publishes no GitHub releases, so there is no release stream to track. The root manifest sits at version 0.0.1, and the TensorFlow.js dependency inside each example directory is the only real marker of what that directory targets.

Editorial conclusion

tfjs-examples is a good fit if you want a working TensorFlow.js program to read rather than a library to depend on: the directories are self contained, several ship a hosted demo, and the Node.js to browser handover in date-conversion-attention and fashion-mnist-vae is the clearest published example of it. It is the wrong place to look if you want a release stream to pin against, since the repository publishes none. Before copying a directory, read its own package.json for the TensorFlow.js version it targets, and check the table row first, because at least eight of the examples have no hosted demo to compare your own build against.

Frequently asked questions

Official sources

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