Question

J'aimerais que mon application rack puisse s'interfacer avec un moteur javascript côté serveur.

Pour l'instant, la seule façon dont je sais que cela pourrait être possible est d'exécuter JRuby et Rhino sur la JVM, mais j'espère une solution plus simple.

Quelqu’un a-t-il entendu parler d’une autre option, peut-être plus rubis ?

Modifier :En lisant les commentaires, je commence à penser que je me suis trompé en supposant que l'exécution de JRuby et Rhino sur la JVM impliquerait une certaine interopérabilité entre Ruby et Javascript... ?
Ce n'est de toute façon pas une solution souhaitable pour moi, mais j'aimerais quand même clarifier cela.

Était-ce utile?

La solution

Le coureur rubis est maintenant sorti de la pré-alpha et se situe quelque part entre l'alpha et la bêta.Il prend désormais en charge :

  • appeler du code Ruby à partir de Javascript
  • appeler des fonctions javascript depuis Ruby
  • intégration d'objets Ruby dans la portée javascript.
  • laisser des objets rubis être votre portée javascript

Autres conseils

  • Johnson est un rubygem qui fait tourner le moteur JavaScript SpiderMonkey Mozilla dans une extension IRM C et permet intégration très profonde entre Ruby et JavaScript,
  • il y a un de Johnson qui remplace le moteur SpiderMonkey avec le moteur Mozilla TraceMonkey et
  • Lyndon Johnson est comme, mais avec JavaScriptCore au lieu de SpiderMonkey et MacRuby au lieu de l'IRM.

Je pense que je me souviens aussi quelqu'un qui travaille sur l'intégration V8 avec l'IRM, mais je ne peux pas trouver la référence en ce moment.

Le principal problème avec Johnson est que l'IRM est une implémentation du langage incroyablement merdique que des fuites de mémoire à gauche et à droite, et la seule mise en œuvre de la langue dans le monde qui pourrait être encore plus merdique est SpiderMonkey. Ainsi, la liste TODO dans le dépôt Git Johnson n'inspire pas exactement la confiance; il ne contient qu'un seul élément, et je cite littéralement:

  

Arrêtez paniquer segfaulting.

Lyndon est construit sur une base beaucoup mieux, mais il faut évidemment en cours d'exécution sur le serveur OSX. De plus, MacRuby n'a pas encore été publié.

Je pense que JRuby + Rhino est probablement l'option la plus stable, bien que vous devrez construire l'intégration vous-même: ils ne sont que deux implémentations linguistiques indépendantes qui se trouvent à vivre sur la même machine virtuelle, mais il n'y a pas d'intégration entre les <. / p>

Un autre point de vue sur le problème est rkelly qui est un moteur d'analyse syntaxique et l'exécution de JavaScript écrit en Ruby.

Comme alternative, vous pouvez essayer d'aborder le problème d'une autre direction: au lieu de garder votre logique d'application en JavaScript et en cours d'exécution que les deux sur le client et le serveur, vous pouvez garder votre logique d'application en Ruby et exécuter que sur la serveur et le client: il y a quelques compilateurs là-bas qui peuvent compiler (un sous-ensemble) Ruby JavaScript. Sur d'entre eux est RubyJS . (Il y a aussi HotRuby , qui est un interpréteur de bytecode YARV écrit en JavaScript, mais ce serait très probablement énorme surpuissant pour ce que vous faites.)

Et last but not least, vous pouvez faire ce que Rails à l'origine fait avec leurs aides JavaScript: vous ne définissez votre logique Ruby ni JavaScript, au lieu que vous définissez une fois dans un DSL interne Ruby et générer à la fois Ruby et logique JavaScript de cela.

Jetez un oeil à Le Ruby Rhino . Il utilise JRuby et Rhino pour intégrer le javascript dans votre environnement rubis. Entre autres, il prend en charge l'évaluation en toute sécurité, d'appeler des fonctions Ruby de javascript et vice-versa (fonctions javascript de ruby)

Il y a aussi « Le Ruby Racer » qui intègre v8 en IRM. Ceci est encore très phase de pré-alpha, mais j'espère avoir une version utilisable quelque temps en mars de l'année prochaine

Un autre moteur que je connaisse est Hurlement qui utilise également JRuby et rhinocéros à un effet similaire.

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top