Unification

[Charles Lowell]

The way less.rb is set up to dynamically select an implementation at runtime is cool, but it kinda sucks too, because you have to independently peg a version of therubyracer or therubyrhino in your Gemfile, which means that less can't specify which version of the interface it depends on. If there is a bug in a version of one of those gems or a feature that it requires, then it cannot add that constraint at bundle time.

Why not roll therubyrhino and therubyracer into a single gem called 'js' which we can dynamically load the code as needed, but all inside the context of the single gem. That way libraries that need javascript environments can depend directly on them at the gem level, and all the transitive dependencies can work themselves out like normal.

Also, if we somebody wants to add support for MacRuby, they could conceivably do so (by implementing redjs for JavaScriptCore) inside the single 'js' gem. Since all external ruby code would just use JS::Context and JS::Object, etc... it would be immediately portable.

thoughts?

cheers,

Charles

Charles Lowell 

thefrontside.net | twitter: @cowboyd | github: cowboyd

(p) +1.512.207.0229 (f) +1.512.374.0777

[Karol Bucek]

 Hey, right I was thinking about a 'javascript' gem but somehow ended up doubtful.

Isn't ExecJS kind of doing this "already", although I do understand it's primary goal is different it only "executes" strings of JS code, but still it's not far from it ...
I'm all for it if the gem turns out useful beyond less.rb or as you mention MacRuby finds itself usable with Less (but I doubt it ever will since v8 is doing the job and works on your production unix machine as well :)).

As I see it, moving the V8/Rhino switch knowledge into another gem, enables us to have a gemspec level 'js' gem declaration but that gem still can't have explicit deps, thus we only moved the runtime selection into somewhere else (unless we built separate versions of the gem for MRI and JRuby as fas as I understand), of course this might still turn out useful if there's multiple dependents on the gem itself.

The real reason I'm skeptical about introducing this solely due less.rb is there would be still some "if defined?(V8) / (Rhino)" code left even with the 'js' gem e.g. due the exceptions internally behaving differently in both runtimes, minimal JavaScript 1.8 compatibility hack required for Rhino to prepare the env for less.js etc.

On the other hand if the 'js' gem does have a usage beyond less.rb in a library where it can fully eliminate the JS runtime dependent code, than it might be worth upgrading less.rb code to adapt to it as well ...

K.

[Charles Lowell]

On May 15, 2012, at 11:50 AM, Karol Bucek wrote:

 Hey, right I was thinking about a 'javascript' gem but somehow ended up doubtful.

Isn't ExecJS kind of doing this "already", although I do understand it's primary goal is different it only "executes" strings of JS code, but still it's not far from it ...
I'm all for it if the gem turns out useful beyond less.rb or as you mention MacRuby finds itself usable with Less (but I doubt it ever will since v8 is doing the job and works on your production unix machine as well :)).

As I see it, moving the V8/Rhino switch knowledge into another gem, enables us to have a gemspec level 'js' gem declaration but that gem still can't have explicit deps, thus we only moved the runtime selection into somewhere else (unless we built separate versions of the gem for MRI and JRuby as fas as I understand), of course this might still turn out useful if there's multiple dependents on the gem itself.

What I'm suggesting is the type of transparent runtime detection and loading used by gems like Nokogiri.You just require 'nokogiri' and you're off to the races without being concerned whether your underlying implementation is xerces or libxml2. There would not be two separate gems for JRuby and CRuby, only single gem with both sets of files. Everything needed to instantiate a JS runtime in any environment would be packaged in that gem.

The real reason I'm skeptical about introducing this solely due less.rb is there would be still some "if defined?(V8) / (Rhino)" code left even with the 'js' gem e.g. due the exceptions internally behaving differently in both runtimes, minimal JavaScript 1.8 compatibility hack required for Rhino to prepare the env for less.js etc.

There will always be some of that, but we can minimize it by making the V8 and Rhino APIs as uniform as possible. This is an inevitability any time you have two completely different implementations sitting behind an abstraction.

On the other hand if the 'js' gem does have a usage beyond less.rb in a library where it can fully eliminate the JS runtime dependent code, than it might be worth upgrading less.rb code to adapt to it as well ...

I am using it for handlebars.js, mustache.js and I'd like to be able to use it for d3.js. My needs and, I think, the needs of the community for a solid, portable JS solution will only increase over time. It's more because I don't want those efforts to share the same weaknesses of the less.rb

cheers,

Charles