The Discontinuation of node-fibers
Posted 26 March 2021 by Natalie Weizenbaum
We have recently received the unfortunate but not entirely surprising news that the
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 being.
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
renderSync() which synchronously returned the compiled CSS, and
render() which instead takes a callback to which it passes the compiled CSS asynchronously. Only
render() 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
render() in Dart Sass tends to be 2-3x slower than
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
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:
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 stylesheets.
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 tires.
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
node-fibers, and 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
node-fibers codebase 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!