Bin ich richtig, wenn jemand ein Ruby-Plugin für einen Webbrowser geschrieben hat und ein Benutzer dieses Plugin installiert hat, dann wäre es möglich, JavaScript durch Ruby im Frontend zu ersetzen?Ruby Plugin für den Webbrowser?
Gibt es dafür keine Plugins? Oder sogar für die Verwendung anderer Sprachen als Javascript auf der Seite des Browsers?
Sie könnten http://ironruby.net/ in einem Silverlight-Plugin verwenden, aber ich habe keine Ahnung, wie einfach DOM-Interaktion auf diese Weise ist.
Aber ich BEG SIE tun Sie es nicht! Bitte verwenden Sie den Open Web Stack, um Ihre Probleme zu lösen.
Wenn Sie Ihre Ruby Welt nicht von Komfort verlassen, werden Sie nicht nur Ihre Benutzer Erfahrung verletzen "WTF? Warum brauche ich Silverlight für diese Seite?" aber Sie werden auch in Ihrer kleinen kleinen Ruby-Welt stecken bleiben, ohne etwas Neues und Aufregendes zu lernen.
Es wäre besser für Sie beide, wenn Sie einfach weitermachen und JavaScript lernen würden.
Da erinnern: "Lernen ist eine gute Sache!"
Technisch wäre das korrekt, vorausgesetzt, der Browser/das Plugin bot auch eine umfangreiche API zum Umgang mit dem DOM und so. Ich kenne keine Plugins, die das möglich machen, aber es ist eine interessante Idee.
Es könnte einen Weg geben, es indirekt zu tun. Here is the original presentation bei RubyConf 2008. Das Thema:
Dieser Vortrag ist über die vielen Wege Ruby in Ihrem Webbrowser laufen. Ich werde zuerst darüber sprechen, warum das überhaupt eine gute Idee ist. Ich werde dann kurz über jede Herangehensweise, die ich untersucht habe, und über die unterschiedlichen Mengen von FAIL, mit denen ich je konfrontiert war, sprechen. Als nächstes konzentriere ich mich auf den vielversprechendsten Bewerber, Rubyjs, einen Ruby-Compiler, der Javascript ausgibt.
Das Projekt rubyjs still exists, aber es scheint tot zu sein. Die Idee war wahrscheinlich ein wenig zu verrückt.
Eine Sache ist eine Tatsache: ab 2010 JavaScript hat keine Thread-Stopp "Schlaf" -Funktion (anders als die, die nur CPU-Zyklen brennt).
Ich habe mindestens ein Jahr lang mit JavaScript gearbeitet, bevor ich diesen Kommentar gepostet habe. Ich bin zu dem Schluss gekommen, dass das Fehlen einer Thread-Stop-Funktion ein echter Hingucker für Threading-Code ist.
Eine Konsequenz des Fehlens der Schlaffunktion ist, dass es nicht möglich ist, ein Ruby/C#/C++/etc zu simulieren. wie das Threading-Modell in JavaScript, was wiederum bedeutet, dass es nicht möglich ist, eine der Threading-fähigen Sprachen in JavaScript zu übersetzen, egal, was man tut, es sei denn, das JavaScript wird durch einen (vorzugsweise nicht CPU-Zyklus-brennenden) Schlaf ergänzt Funktion.
Wenn man surft, dann kann man viele Kommentare finden, die besagen, dass die Schlaffunktion nicht einmal notwendig ist, dass setTimeout ausreichend ist, usw., aber ich denke, dass Leute, die das behaupten, nicht versucht haben, dies zu implementieren ein Threading-Framework in JavaScript. (Denken Sie an Mutexe, kritische Abschnitte. Ich lehne ab, in eine Diskussion zu gehen, dass die kritischen Abschnitte/Synchronisierung für Fälle, in denen der Widget-Inhalt aus mehreren Datenkomponenten besteht, die ein "atomares Ganzes" bilden, nicht notwendig sind.)
Der zweite Hingucker für das gesamte DOM-Modell ist die Implementierung, die DOM-Elemente in den Hintergrund Thread darstellt.
Hier ist, was passiert:
In 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()
Da das DOM im Hintergrund wiedergegeben wird (sprich: in einem separaten Thread), wird es eine Wettlaufsituation zwischen dem Faden sein, der die DOM Bearbeitung eingeleitet, durch einen Aufruf der create_my_awsome_widget_in_DOM machen() und das DOM-Rendering. Wenn der Rendering-Thread "schnell genug" ist, um das DOM zu rendern, bevor der JavasSript-Thread edit_my_awsome_widget_by_editing_DOM_inside_it() aufruft, funktioniert alles einwandfrei, aber wenn es andersherum ist, beginnt das JavaScript, die Region des DOM zu ändern, die (noch nicht)) existieren.
Im Wesentlichen bedeutet dies, dass aufgrund des Hintergrunds DOM die create_my_awsome_widget_in_DOM Rendering() und edit_my_awsome_widget_by_editing_DOM_inside_it() in zufälliger Reihenfolge ausgeführt werden und natürlich die Anwendung abstürzt, wenn die edit_my_awsome_widget_by_editing_DOM_inside_it() vor dem create_my_awsome_widget_in_DOM() aufgerufen wird.
Eigentlich kann es eine Möglichkeit geben, einen richtigen sleep() in JavaScript zu simulieren. Ab 01.2011 Ich weiß nicht, ob es funktioniert, aber möglicherweise, wenn man "die Funktionsklasse" überschreibt, sagen wir, indem alle Funktionsaufrufe auf Anwendungsebene auf Instanzen, die man selbst entworfen hat, gewickelt werden, und verwendet " selbst erstellte virtuelle Threads ", könnte man eine richtige sleep() -Simulation bekommen, ohne CPU-Zyklen zu brennen. Allerdings könnte es ein Hokuspokus sein, denn wie gesagt, ab Januar 2011 habe ich es noch nicht ausprobiert. –
mruby scheint wie eine interessante Option für Ruby in einem Webbrowser ausgeführt wird: http://qiezi.me/projects/mruby-web-irb/mruby.html
Es ist kein typisches Plugin, da es erfordert keine Installation, es ist Javascript (von C kompiliert) Ruby-Code ausgeführt wird.
Plugins können zu immensen Sicherheitslecks und Leistungsproblemen führen. Nehmen Sie zum Beispiel das Flash-Plugin, das zu prozessorintensiv ist, um auf Mobiltelefonen richtig zu funktionieren, und in regelmäßigen Abständen einen Patch hat, um ein gefährliches Sicherheitsleck zu schließen. JavaScript IST die Sprache des Browsers, wenn überhaupt, suchen Sie nach einem Compiler für Ruby to JavaScript. – BGerrissen