fibjs: a V8 JavaScript runtime that hides the event loop behind fibers

What fibjs solves, and who it is actually for

The README describes fibjs as "a JavaScript runtime built on Chrome's V8 JavaScript engine" that "uses fibers-switch, sync style & non-blocking IO model to build scalable system." That sentence is the whole pitch, and it is a direct answer to a specific annoyance: in Node, every I/O call forces you to leave the current function. You write a callback, or you await a promise, and the code that logically belongs together gets split across continuation boundaries. fibjs keeps the code linear. A read looks like a read, a connect looks like a connect, and the fiber scheduler does the yielding underneath.

The audience is narrower than "JavaScript developers." It is people writing servers, proxies, crawlers, CLI tools and system utilities where I/O dominates and where the synchronous shape of the code matters more than compatibility with the npm ecosystem's async idioms. The repository ships samples named disk_analyzer, gui and webpty, which is a fair sketch of that audience: filesystem work, terminal work, and something with a user interface. If your project is a browser bundle or a React app, none of this applies to you.

How fiber switching replaces the callback boundary

V8 executes JavaScript. fibjs wraps it with a fiber abstraction, which the README links to the Wikipedia article on fibers in computer science. A fiber is a cooperatively scheduled unit of execution with its own stack, lighter than a thread. When JavaScript running inside a fiber issues an I/O request, fibjs suspends that fiber and lets the scheduler run another one. The call site does not return to the caller; it simply pauses until data is available, then resumes with the result in place.

That is why the I/O is non-blocking even though the source code is not written asynchronously. The blocking is an illusion maintained by the scheduler. The practical consequence is that you can express request handling as straight-line code, including loops, try/catch and conditionals around I/O, without restructuring it into promise chains. The cost is that the runtime, not the JavaScript engine, owns the concurrency model. Anything that assumes a single event loop with microtask ordering, or that reaches into Node-specific globals, has no defined behavior here. The README does not document a compatibility layer for Node APIs, so treat that as an open question rather than a promise.

The repository also carries an idl/ directory and a vender/ directory alongside fibjs/ and npm/. The idl/ naming indicates interface definition files used to generate the JavaScript-facing bindings for the C++ core, which is consistent with a runtime whose built-in modules are native rather than pure JavaScript.

Installing fibjs and running a first script

The README's Download section points at http://fibjs.org/download/, and the Get Started section links to a Beginning guide under fibjs.org/docs/guide. Those two links are where the project tells you to go; the README itself does not list package-manager commands or per-platform install instructions. If you prefer to build, the README defers to BUILDING.md in the repository root, and the tree contains build.cmd for Windows plus a docker/ directory and a build/ directory.

On Windows the repository ships a build script at the root, which is the only build entry point the README points at through BUILDING.md:

build.cmd

Running that script from the repository root is the Windows build path the tree provides. On other platforms BUILDING.md is the reference, and the docker/ directory gives you a containerized build if you would rather not match the toolchain on your own machine.

The README does not show a script example, so there is no command or snippet to copy from it. The honest first step is the one the project names: open the Beginning guide linked from the Get Started section, and use the download page for a binary. The samples/ directory is the next thing to read, because the repository includes samples/disk_analyzer/, samples/gui/ and samples/webpty/. Reading disk_analyzer is the cheapest way to see the sync-style I/O model in practice: filesystem traversal written as ordinary recursion, with the fiber scheduler handling the suspension. The README does not document how to invoke the samples, so check the guide for the run command before assuming a convention.

Where fibjs stops being the right choice

The strongest limitation is ecosystem gravity. Node's package ecosystem is built on a specific concurrency contract: callbacks, then promises, then async/await over a single event loop. A library that was written for that contract may still parse under fibjs, but its scheduling assumptions do not carry over automatically. The README does not claim Node compatibility, and nothing in the repository listing suggests a shim layer. If your service is mostly glue around third-party npm packages, fibjs asks you to replace that glue.

A second limitation is release cadence. The most recent tagged release listed is v0.37.0 from 2024-02-07, with v0.36.0 in 2023 and v0.35.0 in 2022. The default branch is dev and the last push was on 2026-09-23, which means active commit work is happening on a branch that is not the same thing as a shipped release. Anyone who needs a stable, versioned artifact on a predictable schedule should weigh that gap.

A third issue is documentation depth. The README is short by design and routes everything to fibjs.org and to the separate fibjs_docs repository. The README does not document rollback, upgrade procedures or breaking changes between the v0.35 to v0.37 line; CHANGELOG.md and RELEASE.md exist in the tree, so that is where you would look, but the README itself is silent. Plan to read the changelog before moving a production service across a minor version.

How fibjs differs from Node.js in approach

Node.js and fibjs both embed V8 and both aim at non-blocking I/O. The difference is where the asynchrony is expressed. Node puts it in the language surface: the API returns before the work is done, and you handle completion through a callback or a promise. fibjs puts it in the scheduler: the API does not return until the work is done, and the fiber yields in the meantime.

That single choice cascades. Error handling in fibjs can use try/catch around I/O directly, because the failure surfaces at the call site. In Node, the same failure arrives in a rejection handler or an errback, and stack traces cross the async boundary. Control flow in fibjs can use ordinary loops over I/O results; in Node the equivalent needs for-await or a reducer. On the other side, Node's model composes with the enormous body of existing packages and with browser-adjacent tooling, and fibjs's model does not.

There is also a resource distinction worth naming. Fibers carry stacks, so a program that spawns very large numbers of concurrent operations pays memory per fiber in a way that a pure event-loop design does not. The README does not quantify this, and the repository does not publish fiber-count guidance, so treat concurrency limits as something you measure on your own workload rather than something the project documents for you.

Maintenance, licensing and what to verify before adopting

The repository is not archived, and the last push was on 2026-09-23, so development activity is recent. That is a statement about commits, not about releases: the newest tagged release in the list is v0.37.0 from 2024-02-07. If your organization pins dependencies to tagged versions, you are adopting a 2024 artifact with a 2026 branch behind it, and you should read CHANGELOG.md and RELEASE.md to see how the two relate.

The licence field reports NOASSERTION, which means the automated classifier could not map the terms to a standard identifier. The repository does contain LICENSE.md, so the terms are stated there, but they are not summarized by a short SPDX tag. If your legal review depends on identifying a known licence by name, that review has to start from the file itself. This is not legal advice; it is a note that the metadata alone will not settle the question.

Upgrade cost is the other item to price in. The project ships prebuilt binaries through its download page, so a runtime upgrade may be as simple as swapping a binary, but the C++ core, the idl/ bindings and the vendored dependencies mean that building from source ties you to whatever toolchain BUILDING.md specifies. The docker/ directory gives you a containerized path if you would rather not match that toolchain on your own machine. Verify the binary for your target platform exists on the download page before you plan around it, and check BUILDING.md before you promise a source build to anyone.

Editorial conclusion

Adopt fibjs if you are building an I/O-heavy service or tool and you want synchronous-looking code with non-blocking behavior underneath, and you are willing to work outside the npm async mainstream. Do not adopt it if your project depends on callback- or promise-based libraries that assume Node's event loop semantics, or if you need a runtime with a large third-party module surface. Before committing, verify three things: that the prebuilt binary for your platform is listed on the download page, that the modules you need exist in fibjs's own module documentation, and that BUILDING.md covers your toolchain if you plan to compile from source. The repository's last push was on 2026-09-23, so the codebase is moving; the most recent tagged release, v0.37.0, dates to 2024-02-07, which tells you the release cadence is slower than the commit cadence.

Frequently asked questions

Official sources

1. fibjs/fibjs on GitHub
2. Issues
3. Project website
4. README
5. Releases