TensorFlow.js builds six backends and platforms from one repository, and its newest release is from 2024

The newest release is October 2024 and the branch moved in June 2026

Put the two dates next to each other. The three most recent tags are `tfjs-v4.22.0` on 2024-10-21, `tfjs-v4.21.0` on 2024-09-04 and `tfjs-v4.20.0` on 2024-06-03. The last push to the default branch was on 2026-06-23.

So the published artefact and the source have been apart for close to two years. A project that pins to the latest tagged release is running code from October 2024, not the current code on the default branch.

The tag names carry a second piece of information as well. They are prefixed `tfjs-`, so a release tag is a repository-wide version rather than a per-package one.

The practical question for an adopter is which side of that gap you are on. If you need a behaviour that only exists on the branch, you are building from source, and this repository is a Bazel and Cloud Build project rather than a `npm install` target.

This repository combines packages, it is not the library

The README says it directly: this repository contains the logic and scripts that combine several packages. That single sentence explains the top level, which is a directory per package rather than a source tree for one library.

The API packages are `tfjs-core/`, described as a flexible low-level API for neural networks and numerical computation, `tfjs-layers/` for a high-level API with functionality similar to Keras, `tfjs-data/` analogous to `tf.data`, `tfjs-converter/` to import a TensorFlow SavedModel, `tfjs-vis/` for in-browser visualization, and `tfjs-automl/` to load and run models produced by AutoML Edge.

Then the packages the README's table does not mention, which are in the tree all the same: `tfjs-backend-nodegl/`, `tfjs-node-gpu/`, `tfjs-inference/`, `tfjs-tfdf/`, `tfjs-tflite/`, `link-package/`, and the umbrella `tfjs/` that the CDN script tag loads.

For someone reporting a bug or sending a change, that layout decides where the work goes. A problem in tensor arithmetic belongs in `tfjs-core`, a problem in the model API belongs in `tfjs-layers`, and the release that would have shipped either fix is produced by the scripts in this repository.

Op parity lives in a Google spreadsheet, and the backends are not equal

The README does not publish a support table. It links one: a TFJS Ops Matrix on Google Sheets, under a section headed various ops supported in different backends.

That is the honest arrangement, because the backends genuinely differ. The set is a CPU backend that is pure JavaScript for Node.js and the browser, a WebGL backend for the browser, a WASM backend for the browser, a WebGPU backend for the browser, a Node platform reached through a TensorFlow C++ adapter, and a React Native platform reached through an expo-gl adapter. Six backends and platforms, one API, and no assumption that a kernel exists on all of them.

The consequence for a user is that a model can work on the backend you tested and fail on the one you deploy, so check the ops matrix for the backend you ship.

There is one bundle-size lever in the README and it is worth using. If you care about bundle size, you can import those packages individually rather than taking the umbrella build.

The CDN script tag is the only path with no build step, and it costs a global

There are two routes into a project, and they are not equivalent. The script tag route is a single line in an HTML file:

<script src="https://cdn.jsdelivr.net/npm/@tensorflow/tfjs/dist/tf.min.js"> </script>

The comment in the example is the important part: there is no `import` statement, and `tf` is available on the page because of the script tag above. That is a global, not a module, and it is the reason the same page can call `tf.sequential()` without any import machinery.

The NPM route is different in kind, and the README flags the condition rather than hiding it. Because the library uses ES2017 syntax such as `import`, this workflow assumes you are using a modern browser or a bundler or transpiler to convert your code to something older browsers understand. Parcel, WebPack and Rollup are the tools named, and the project ships its own Parcel setup as the reference.

So the practical division is that experimentation and demos use the script tag with no tooling, and anything you ship uses a bundler. The `import * as tf from '@tensorflow/tfjs'` form is the one you will actually write.

Benchmarks are a webpage you run on your own device, not a table in the repo

The benchmarks section offers two tools and publishes no numbers. The first is a local benchmark tool served as a webpage, and the description is specific about its purpose: use it to collect the performance related metrics, speed and memory among them, of TensorFlow.js models and kernels on your local device with the CPU, WebGL or WASM backends. Custom models are covered by a guide under `e2e/benchmarks/local-benchmark`.

The second is a multi-device benchmark tool under `e2e/benchmarks/browserstack-benchmark`, which the README describes as collecting the same performance related metrics on a collection of remote devices. The root dev dependencies include `karma-browserstack-launcher`.

The consequence is that a backend comparison has to be run, not read. For a library whose performance is a function of the user's GPU, browser and device, that is a defensible position. If you are choosing between WebGL, WASM and WebGPU, you run the tool on the hardware you are deploying to.

The build is Bazel with a pinned version, and releases run on Cloud Build

The build tooling at the top level is Bazel, and the configuration is complete enough to pin it. There is `.bazelrc`, `.bazelignore`, `BUILD.bazel`, `WORKSPACE` and a `BAZEL_MIGRATION.md`, plus a `.bazelversion` file and `@bazel/bazelisk` in the dev dependencies, which is the wrapper that reads that file and fetches the matching Bazel. Several rules are pinned together at 5.8.1, covering concatjs, esbuild, jasmine, rollup, terser and typescript, with buildifier at 6.1.0.

The presence of `BAZEL_MIGRATION.md` at the root says the build was moved, and the file is what a contributor reads to find out what a given package has to do now.

Releases are automated on Google Cloud Build, and there are three separate configs: `cloudbuild.yml`, `cloudbuild-release.yml` and `cloudbuild-verdaccio.yml`, the last named for a Verdaccio registry. A `dockers/` directory and a `remote-execution/` directory sit next to them.

TSLint config and four tsconfig files sit side by side

The configuration tells a story about how the project was assembled. There is a `.tslint/` directory with `tslint.json` and a dedicated `tsconfig_tslint.json`, and alongside them four more TypeScript configurations: `tsconfig.json`, `tsconfig.test.json`, `tsconfig_base.json` and `tsconfig_ts_library.json`.

TSLint is the older of the two lint ecosystems, deprecated in favour of ESLint, and it is still wired in here. The root dev dependencies also show the surrounding test and build apparatus: Karma with launchers for Chrome, Firefox, BrowserStack, Jasmine and RequireJS, plus Jasmine itself, `express` for serving, `core-js`, `js-yaml`, `ajv` and `inquirer` for the release scripts, and `@octokit/rest` for the GitHub API calls those scripts make.

The type packages include `@types/dom-webcodecs` at 0.1.4, `@webgpu/types` at 0.1.48 and `@types/emscripten`, and `clang-format` is pinned at around 1.2.4.

For a new contributor, `yarn.lock` rather than a `package-lock.json` is the file that defines the install.

Model import covers SavedModel and Keras, and the weights live in another repository

Running a model that already exists is the converter's job, and the README names exactly two source formats: TensorFlow SavedModel and Keras. Anything else has to be exported to one of those first, which is the boundary of the import path.

The pieces that support it are the `tfjs-converter/` package and, in the tree, `tfjs-inference/`. A third path is `tfjs-automl/`, a set of APIs to load and run models produced by AutoML Edge, which is a different provenance again.

The pre-trained models themselves are not in this repository. They are hosted on NPM in `tensorflow/tfjs-models`, and the examples live in `tensorflow/tfjs-examples`, with the tutorials at js.tensorflow.org. `GALLERY.md` at the root is the index of projects built with the library.

So adopting a pretrained model can involve two repositories: fetch the model from `tensorflow/tfjs-models` and depend on `@tensorflow/tfjs` from this one.

Editorial conclusion

TensorFlow.js fits a team that wants the Keras-shaped API in a browser tab or a Node process, that can choose a backend to match the platform rather than shipping one, and that accepts a JavaScript linear algebra core. It does not fit a project that needs op parity across backends without checking first, since the coverage matrix lives in an external spreadsheet, or a team that needs a Node.js native TensorFlow binding and has to accept it is a separate package. Before adopting, check three things: which version you are actually installing, given that the tags stop at `tfjs-v4.22.0` from 2024-10-21 while the last push to the default branch was on 2026-06-23, that the ops matrix for your chosen backend contains every kernel your model needs, and whether you can accept a transpiler, since the library uses ES2017 syntax and only the CDN script tag path avoids a build step.

Frequently asked questions

Official sources

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