https://github.com/jhawthorn/execjs-fastnode
:zap: A faster Node.JS integration for Ruby/Rails ExecJS
https://github.com/jhawthorn/execjs-fastnode
execjs javascript rails ruby sprockets
Last synced: 6 months ago
JSON representation
:zap: A faster Node.JS integration for Ruby/Rails ExecJS
- Host: GitHub
- URL: https://github.com/jhawthorn/execjs-fastnode
- Owner: jhawthorn
- License: mit
- Created: 2016-10-13T06:23:46.000Z (almost 9 years ago)
- Default Branch: master
- Last Pushed: 2019-08-16T19:48:13.000Z (about 6 years ago)
- Last Synced: 2025-04-11T16:11:06.491Z (6 months ago)
- Topics: execjs, javascript, rails, ruby, sprockets
- Language: Ruby
- Homepage:
- Size: 92.8 KB
- Stars: 51
- Watchers: 2
- Forks: 2
- Open Issues: 3
-
Metadata Files:
- Readme: README.md
- License: LICENSE
Awesome Lists containing this project
README
# ExecJS FastNode
## What's this?
An alternative implementation of ExecJS's Node.js integration. This aims to speed up sprockets compilation without needing to embed a javascript interpreter inside of ruby like [therubyracer](cowboyd/therubyracer).
## How much faster is it?
Much.
```
$ rake bench
...
user system total real
Node.js (V8) fast 0.000000 0.000000 0.000000 (0.069723)
therubyracer (V8) 0.020000 0.000000 0.020000 (0.018010)
Node.js (V8) 0.000000 0.010000 1.470000 (1.487579)
```
Okay, so it's not as fast as `therubyracer`, but it's 20x faster than the standard ExecJS Node.js implementation.
The benchmark measures the time to compile the javascript CoffeeScript compiler and then eval a small snippet 10 times.
## How?
The existing ExecJS runtime has to run a new Node.js process each time any JS is to be run. This means that if you are loading up the CoffeeScript compiler in order to compile some sprockets assets, it needs to reload the node executable and the entire coffeescript compiler for each file it is compiling.
This implementation avoids this by starting a persistently running Node.js process connected through a UNIX socket. Isolation between different ExecJS contexts is achieved through Node's [vm.Script](https://nodejs.org/api/vm.html).
| ExecJS FastNode | Standard ExecJS Node |
| --- | --- |
|  |  |
## Is this production ready?
Maybe? It needs more testing to be labeled as such. If you encounter any troubles please [file an issue](https://github.com/jhawthorn/execjs-fastnode/issues/new).
Currently minimal effort is made to handle catastrophic errors: Node.js crashing, running out of memory, being killed.
It's probably fine for development.
## Installation
Add this line to your application's Gemfile:
```ruby
gem 'execjs-fastnode'
```
And then `bundle install`. You know the drill.
You can verify that this runtime is being autodetected and used by checking `ExecJS.runtime` in a console.
You can force a certain runtime to be used using `EXECJS_RUNTIME=FastNode`
```
$ EXECJS_RUNTIME=FastNode bin/console
> ExecJS.runtime
=> # ExecJS.runtime
=> #