The Discontinuation Of Node-fibers
We have recently received the unfortunate but not entirely surprising news that
node-fibers package has reached its end-of-life and will not be updated
users to pass in
node-fibers to improve the performance of the asynchronous
render() method, but going forward this will unfortunately no longer be an
option in Node 16 and on.
There are a number of alternative options for reclaiming this lost
performance, some of them which are available today, some which are in
development, and some which are theoretical but could be made real with pull
requests from users like you. Sadly, none of the options that are ready today
are drop-in solutions with the same level of ease-of-use as
node-fibers, so if
that performance is crucial to you we recommend staying on Node 14 for the time
What Happened? permalinkWhat Happened?
In order to understand how we got here, it’s important to know two pieces of
history. First, why does Dart Sass use
node-fibers in the first place? And
second, why is
This section is fairly technical, so feel free to skip ahead if you don’t care
about the gory details.
Fibers in Sass permalinkFibers in Sass
This API has two main functions for compiling Sass files:
synchronously returned the compiled CSS, and
render() which instead takes a
callback to which it passes the compiled CSS asynchronously. Only
allowed asynchronous plugins, including widely-used importers such as webpack’s
render() became very widely used in practice.
For Node Sass, the performance difference between
was negligible, because it was built on C++ code which had few restrictions on
contagious, which means that if any function (such as an importer plugin) is
asynchronous, then everything that calls it must be asynchronous, and so on
until the entire program is asynchronous.
allocate callbacks, store them somewhere, and take a trip back to the event loop
before invoking those callbacks, and that all takes time. In fact, it takes
enough time that the asynchronous
render() in Dart Sass tends to be 2-3x
Enter fibers. Fibers are a very cool concept, available in languages like Ruby
and C++, that give the programmer more control over asynchronous functions. They
can even allow a chunk of synchronous code (such as the Sass compiler) to call
asynchronous callbacks (such as the webpack plugin). The
did some arcane magick with the V8 virtual machine to implement Fibers in
implement the asynchronous
render() API. And for a time, it was great.
The Death of Fibers permalinkThe Death of Fibers
Unfortunately, the arcane magick that
node-fibers used involved accessing some
parts of V8 that were not officially part of its public API. There was no
guarantee that the interfaces they were using would stay the same from release
to release, and indeed they tended to change fairly regularly. For a long time,
those changes were small enough that it was possible to release a new version of
node-fibers that supported them, but with Node.js 16 the luck ran out.
The latest version of V8 involves some major overhauls to its internals. These
will eventually allow it to implement some cool improvements, so its hard to
begrudge, but a side effect is that the APIs
node-fibers was using are
completely gone without an obvious replacement. This is no one’s fault: since
those interfaces weren’t part of V8’s public API, they were under no obligation
to keep them stable. Sometimes in software that’s just the way things go.
Reclaiming Performance permalinkReclaiming Performance
There are a few options for getting back the performance that’s lost by no
longer being able to pass
sass.render(). In order from
nearest to longest term:
Avoid Asynchronous Plugins permalinkAvoid Asynchronous Plugins
This is something you can do today. If it’s at all possible to make the plugins
you pass in to Sass synchronous, you can use the
renderSync() method which
doesn’t need fibers to go fast. This may require rewriting some existing
plugins, but it will pay dividends immediately.
Embedded Dart Sass permalinkEmbedded Dart Sass
While it’s not ready for prime-time yet, the Sass team is working on a project
called “embedded Dart Sass”. This involves running Dart Sass as a subprocess,
rather than a library, and communicating with it using a special protocol. This
provides several important improvements over the existing alternatives:
sassfrom the command line, this will still work with plugins
API as closely as possible. This will probably run asynchronous plugins even
faster than synchronous ones.
Unlike the existing JS-compiled version, this will use the Dart VM. Due to the
more static nature of the Dart language, the Dart VM runs Sass substantially
faster than Node.js, which will provide about a 2x speed improvement for large
The Node.js host for Embedded Sass is still in active development, but there’s
a beta release available (with minimal features) if you want to kick the
Worker Threads permalinkWorker Threads
We’ve explored the possibility of running the pure-JS Dart Sass in a Node.js
worker thread. Worker threads work a bit like fibers in that they make it
possible for synchronous code to wait for asynchronous callbacks to run.
Unfortunately, they’re also extremely restrictive about what sorts of
information can be passed across the thread boundary, which makes it much harder
to use them to wrap a complex API like Sass’s.
At the moment, the Sass team is focused on Embedded Sass, so we don’t have the
spare bandwidth to dive into worker threads as an alternative. That said, we’d
be happy to help a motivated user implement this. If you’re interested, follow
up on the GitHub issue!
Reanimating node-fibers permalinkReanimating
There’s one other potential solution, although it would take true dedication to
turn into reality. It would in principle be possible to add a new API to V8 that
would officially support the hooks
node-fibers needs to do its good work.
This would allow the package to return gloriously to life and Sass to make
render() fast on into the future.
The Sass team has contacted both the V8 team and the owner of
both of them are amenable to this idea in principle. While neither one has the
time to see it through to completion themselves, they’ve expressed willingness
to help an engineer who’s willing to give it a shot.
This isn’t a contribution for the faint of heart, though: it requires knowledge
of C++, a willingness to learn at least the basics of the
and V8’s isolate APIs, and skills in both API design and human interaction to
negotiate a stable API that will meet the needs of
node-fibers and that the
V8 team feels comfortable committing to maintain. But if you’re interested,
please don’t hesitate to reach out!