¿Tengo la certeza de que si alguien escribiera un plugin de Ruby para un navegador web y un usuario lo instalara entonces sería posible reemplazar javascript con ruby en la interfaz?Ruby plugin for web browser?
¿No hay complementos para esto? ¿O incluso para usar otros idiomas aparte de javascript en el lado del navegador?
Puede usar http://ironruby.net/ en un complemento de Silverlight, pero no tengo ni idea de cuán fácil es la interacción DOM de esta manera.
Pero yo BEG YOU ¡no lo hagas! Por favor, use Open Web Stack para resolver sus problemas.
Si no abandona su mundo de confort Ruby, no solo dañará la experiencia de sus usuarios "WTF? ¿Por qué necesito Silverlight para esta página?" pero también te quedarás atrapado en tu pequeño mundo de Ruby sin aprender nada nuevo y emocionante.
Sería mejor para los dos, si simplemente seguir adelante y aprender JavaScript.
Porque recuerde: "¡El aprendizaje es algo bueno!"
Técnicamente eso sería correcto, suponiendo que el navegador/complemento también proporcionara una extensa API para manejar el DOM y tal. No conozco ningún complemento que lo haga posible, pero es una idea interesante.
Puede haber una manera de hacerlo indirectamente. Here is the original presentation en RubyConf 2008. El tema:
Esta charla es sobre los muchos caminos hacia la ejecución de ruby en su navegador web. Primero hablaré acerca de por qué esto es incluso una buena idea. Luego hablaré brevemente sobre cada enfoque que he investigado y las diferentes cantidades de errores que encontré con cada uno. A continuación me centraré en el contendiente más prometedor, rubyjs, un compilador de ruby que arroja javascript.
El proyecto rubyjs still exists, pero parece estar muerto. La idea probablemente era un poco loca.
Una cosa es HECHO: a partir de 2010, JavaScript no tiene una función de "detención" de hilo (que no sea la que acaba de grabar los ciclos de CPU).
He estado trabajando con JavaScript durante al menos un año antes de publicar este comentario y he llegado a la conclusión de que la falta de una función de suspensión de hilos es un verdadero obstáculo para enhebrar el código relacionado.
Una consecuencia de la falta de la función de reposo es que no es posible simular un Ruby/C#/C++/etc. como el modelo de subprocesamiento en JavaScript, lo que a su vez significa que no es posible traducir ninguno de los lenguajes habilitados para enhebrar a JavaScript, sin importar lo que haga, a menos que el JavaScript se complemente con un modo de dormir (preferiblemente sin CPU) función.
Si uno navega, entonces uno puede encontrar muchos comentarios que afirman que la función de suspensión ni siquiera es necesaria, que el setTimeout es suficiente, etc., pero supongo que las personas que dicen eso, no han intentado implementar un marco de enhebrado en JavaScript. (Piense en mutexes, secciones críticas. Me niego a entrar en una discusión que las secciones críticas/sincronización son/no son necesarias para casos, donde el contenido del widget consiste en múltiples componentes de datos que forman un "todo atómico".)
El segundo stop-show para todo el modelo DOM es la implementación que representa elementos DOM EN EL HILO DE FONDO.
de aquí, lo que sucede:
en javascript: create_my_awsome_widget_in_DOM(); edit_my_awsome_widget_by_editing_DOM_inside_it() if_we_are_lucky_we_reach_here_without_crashing_the_app()
Como el DOM se procesa en segundo plano (es decir: en un hilo separado), no será una condición de carrera entre el hilo que inició la edición de DOM, haciendo una llamada a la create_my_awsome_widget_in_DOM(), y la representación DOM. Si el hilo de renderización es "lo suficientemente rápido" para representar el DOM antes de que el hilo de JavasSript llame a edit_my_awsome_widget_by_editing_DOM_inside_it(), todo funciona bien, pero si es al revés, entonces el JavaScript comienza a modificar la región del DOM que no (aún) existe.
Esencialmente significa que debido a la DOM renderización de fondo del create_my_awsome_widget_in_DOM() y edit_my_awsome_widget_by_editing_DOM_inside_it() se ejecutan en un orden aleatorio y, obviamente, la aplicación se bloquea, si el edit_my_awsome_widget_by_editing_DOM_inside_it() es llamado antes de la create_my_awsome_widget_in_DOM().
En realidad, puede haber una forma de simular un sueño adecuado() en JavaScript. A partir del 01.2011 no sé, si funciona, pero puede ser, si uno "anula la clase de función", digamos, envolviendo todas las llamadas de funciones a nivel de aplicación a instancias que uno mismo ha diseñado y usa " hilos virtuales hechos a sí mismos ", uno podría obtener una simulación sleep() adecuada sin grabar ciclos de CPU. Sin embargo, podría ser un placer, porque, como dije, a partir de enero de 2011 no lo he probado todavía. –
mruby parece ser una opción interesante para el funcionamiento de rubí en un navegador web: http://qiezi.me/projects/mruby-web-irb/mruby.html
No es un plugin típica, ya que no requiere instalación, es javascript (compilado de C) que se ejecuta código de rubí.
Los complementos pueden presentar inmensas pérdidas de seguridad y problemas de rendimiento. Tomemos, por ejemplo, el complemento flash, que consume demasiado el procesador para funcionar correctamente en los teléfonos móviles y tiene un parche a intervalos regulares para cerrar una peligrosa fuga de seguridad. JavaScript ES el idioma del navegador, en todo caso, busque un compilador de Ruby a JavaScript. – BGerrissen