Story about ExecJS or how to execute javascript in Ruby
Suppose you are writing a cool webdvant project on rails. You have a friend Petya - a strong programmer in javascript. As Petya writes a lot and defiantly, he decided to make his life easier and came up with a new language with a beautiful and simple syntax that will be broadcast in javascript.
Even Petya is a big fan of green tea, so he called his new language GreenTeaScript.
Besides Petit, you have one more programmer-on-javascript friend Vasya. Vasya once thought of writing a program that would parse JS on AST, optimize it, and then compile it back into beautiful, structured code, cutting off any unnecessary and formatting according to Crawford. He called his brainchild BeautifyJS. By the way, BeautifyJS was also able to assemble AST into minimized compressed code and did it faster and better than other alternatives existing in nature.
Since both Petya and Vasya did not know how to program anything other than javascript, they wrote their products on it.
')
And here again, let us assume, the first in the world had the idea to fasten these wonderful pieces to their cool web-dance project on the tracks. You really liked writing frontend in GreenTeaScript, and compressing scripts with BeautifyJS would certainly speed up the site.
Now the fun begins.
Both programs are written in javascript, but we need to somehow perform them from the rail. Fast googling tells you that in Macosi, which you, say, use, there is JavaScriptCore built into the system, which can be launched from the console with the command
You show the project prototype to the investor from your laptop, the investor likes it, but he says that it is necessary to start in a week. Damn, in a week you will not have time to finish the entire function, so you decide to hire programmer Dima as your assistant.
And Dima, a programmer, uses the Windows operating system, so his MacOS JavaScriptCore doesn't work. Dima quickly googles and finds a solution - JScript , after which he writes alongside a second class for working under Windows. And all again nishtyak and works. This time under Makos and under Windows.
For a week you somehow manage to finish everything you need, the investor is very pleased and gives the command to start. Happily bought a Linux server, is deployed, and then everything breaks down. Well, right, you forgot to foresee the possibility of executing javascript under Linux.
It does not matter, the solution comes quickly enough. You just need to put on the NodeJS server and add existing classes to work with it. No sooner said than done. Now all this bodyaga works in Linux too.
The project is rapidly gaining popularity, a queue of investors is accumulating under the door, wanting to urgently dump you a heap of money, and the server stops cope. You hire a sysadmin, whose tasks will include the installation and configuration of new servers. The sysadmin boldly gets down to business, rolls in 5 new servers, deploit them and everything breaks again. It turns out that on the new servers the version of NodeJS is slightly different from the one on the first server. It also lies not in
You are armed with a “C ++ from scratch in 3 hours” textbook and feel free to sit down to write a new gem that would allow you to use the NodeJS V8 engine directly from Ruby. As a result, you get therubyracer . When installed, the gem collects its own V8 of the required version in its sandbox and uses it directly. Lepote!
Now you can clear out that mountain of crutches, which was responsible for the execution of javascript and replace all this with a beautiful class that therubyracer simply uses. One version is registered everywhere in Gemfile.lock, everything works quickly and equally in all operating systems, everyone is happy.
Once you read article on Habré about JRuby. In the article, among other things, it is written that they say, JRuby is very fast and generally cool. As an experiment, you decide to run your project on JRuby and drive benchmarks. Naturally, everything shuts up on therubyracer, which does not work under JRuby.
So you collect a new gem on your knee, therubyrhino , which in general does the same thing as therubyracer, but uses Mozilla's Java-based engine and works in JRuby. Chased benchmarks and calmed down, in general.
The project grows up and out, the number of servers increases, you hire 5 new programmers per week. Each new programmer you buy a computer, and then half a day you tell how to install a compiler with all the reasons for therubyracer to assemble. And then it’s still going to be 10 minutes. You sadly remember the days when everything worked on the built-in JavaScriptCore without any compilers right away.
Why all this long story? And to the fact that the new Rails 3.1 adds support for CoffeeScript and UglifyJS by default. This is almost the same as our imaginary GreenTeaScript and BeautifyJS, only real-life. And the Rails Core Team ran into the same problems as we, only for real.
How did they get rid of them? They wrote ExecJS - an ingenious gem that allows you to use all possible ways to execute javascript from Ruby without adding any dependencies. He checks each of the methods for accessibility, and then suggests using the best one found.
Thus, the developer on macos will all run via JavaScriptCore, in his neighbor on Windows via JScript, and under Linux it will try to cling to NodeJS or politely suggest to put therubyracer.
Everything works like this:
As you can see, everything is quite transparent and simple. It is not necessary to go into details, it just works in the most optimal way available.
Thus, it turns out that chasing javascript to Ruby is now simpler than steamed turnip. In my opinion, this is very cool!
Even Petya is a big fan of green tea, so he called his new language GreenTeaScript.
Besides Petit, you have one more programmer-on-javascript friend Vasya. Vasya once thought of writing a program that would parse JS on AST, optimize it, and then compile it back into beautiful, structured code, cutting off any unnecessary and formatting according to Crawford. He called his brainchild BeautifyJS. By the way, BeautifyJS was also able to assemble AST into minimized compressed code and did it faster and better than other alternatives existing in nature.
Since both Petya and Vasya did not know how to program anything other than javascript, they wrote their products on it.
')
And here again, let us assume, the first in the world had the idea to fasten these wonderful pieces to their cool web-dance project on the tracks. You really liked writing frontend in GreenTeaScript, and compressing scripts with BeautifyJS would certainly speed up the site.
Now the fun begins.
Javascriptore
Both programs are written in javascript, but we need to somehow perform them from the rail. Fast googling tells you that in Macosi, which you, say, use, there is JavaScriptCore built into the system, which can be launched from the console with the command
/System/Library/Frameworks/JavaScriptCore.framework/Versions/A/Resources/jsc . You quickly write a class that takes a piece of javascript, feeds this thing, parses the result and voila - everything works! Nishtyak.JScript
You show the project prototype to the investor from your laptop, the investor likes it, but he says that it is necessary to start in a week. Damn, in a week you will not have time to finish the entire function, so you decide to hire programmer Dima as your assistant.
And Dima, a programmer, uses the Windows operating system, so his MacOS JavaScriptCore doesn't work. Dima quickly googles and finds a solution - JScript , after which he writes alongside a second class for working under Windows. And all again nishtyak and works. This time under Makos and under Windows.
Nodejs
For a week you somehow manage to finish everything you need, the investor is very pleased and gives the command to start. Happily bought a Linux server, is deployed, and then everything breaks down. Well, right, you forgot to foresee the possibility of executing javascript under Linux.
It does not matter, the solution comes quickly enough. You just need to put on the NodeJS server and add existing classes to work with it. No sooner said than done. Now all this bodyaga works in Linux too.
therubyracer
The project is rapidly gaining popularity, a queue of investors is accumulating under the door, wanting to urgently dump you a heap of money, and the server stops cope. You hire a sysadmin, whose tasks will include the installation and configuration of new servers. The sysadmin boldly gets down to business, rolls in 5 new servers, deploit them and everything breaks again. It turns out that on the new servers the version of NodeJS is slightly different from the one on the first server. It also lies not in
/bin/node , but in /usr/local/bin/node . And in general, according to the administrator, external dependencies are not cool and we must, they say, get rid of them.You are armed with a “C ++ from scratch in 3 hours” textbook and feel free to sit down to write a new gem that would allow you to use the NodeJS V8 engine directly from Ruby. As a result, you get therubyracer . When installed, the gem collects its own V8 of the required version in its sandbox and uses it directly. Lepote!
Now you can clear out that mountain of crutches, which was responsible for the execution of javascript and replace all this with a beautiful class that therubyracer simply uses. One version is registered everywhere in Gemfile.lock, everything works quickly and equally in all operating systems, everyone is happy.
therubyrhino
Once you read article on Habré about JRuby. In the article, among other things, it is written that they say, JRuby is very fast and generally cool. As an experiment, you decide to run your project on JRuby and drive benchmarks. Naturally, everything shuts up on therubyracer, which does not work under JRuby.
So you collect a new gem on your knee, therubyrhino , which in general does the same thing as therubyracer, but uses Mozilla's Java-based engine and works in JRuby. Chased benchmarks and calmed down, in general.
Together
The project grows up and out, the number of servers increases, you hire 5 new programmers per week. Each new programmer you buy a computer, and then half a day you tell how to install a compiler with all the reasons for therubyracer to assemble. And then it’s still going to be 10 minutes. You sadly remember the days when everything worked on the built-in JavaScriptCore without any compilers right away.
Why all this long story? And to the fact that the new Rails 3.1 adds support for CoffeeScript and UglifyJS by default. This is almost the same as our imaginary GreenTeaScript and BeautifyJS, only real-life. And the Rails Core Team ran into the same problems as we, only for real.
How did they get rid of them? They wrote ExecJS - an ingenious gem that allows you to use all possible ways to execute javascript from Ruby without adding any dependencies. He checks each of the methods for accessibility, and then suggests using the best one found.
Thus, the developer on macos will all run via JavaScriptCore, in his neighbor on Windows via JScript, and under Linux it will try to cling to NodeJS or politely suggest to put therubyracer.
Everything works like this:
require 'rubygems' # 1.8 require 'execjs' # jsfunc = <<JS function square(n){ return n*n; } JS # context = ExecJS.compile(jsfunc) # context.call('square', 10) # => 100 # ExecJS.eval 'Math.pow(10, 2)' # => 100 As you can see, everything is quite transparent and simple. It is not necessary to go into details, it just works in the most optimal way available.
Thus, it turns out that chasing javascript to Ruby is now simpler than steamed turnip. In my opinion, this is very cool!
Source: https://habr.com/ru/post/121167/
All Articles