Sono sicuro che se qualcuno ha scritto un plug-in Ruby per un browser Web e un utente ha installato quel plugin, sarebbe possibile sostituire javascript con ruby sul frontend?Plug-in Ruby per browser web?
Non ci sono plugin per questo? O anche per l'utilizzo di lingue diverse da javascript sul lato browser?
È possibile utilizzare http://ironruby.net/ in un plug-in Silverlight, ma non ho idea di quanto sia facile l'interazione DOM in questo modo.
Ma I BEG YOU non farlo! Per favore, usa l'Open Web Stack per risolvere i tuoi problemi.
Se non lasci il tuo mondo di comfort Ruby, non solo farai del male alla tua esperienza utente "WTF? Perché ho bisogno di Silverlight per questa pagina?" ma rimarrai bloccato nel tuo piccolo mondo Ruby senza imparare nulla di nuovo ed eccitante.
Sarebbe meglio per entrambi, se andassi avanti e imparassi JavaScript.
Perché ricordare: "L'apprendimento è una buona cosa!"
Tecnicamente ciò sarebbe corretto, presupponendo che il browser/plug-in fornisse anche un'estesa API per gestire il DOM e così via. Non sono a conoscenza di alcun plugin che lo renda possibile, ma è un'idea interessante.
Potrebbe esserci un modo per farlo indirettamente. Here is the original presentation a RubyConf 2008. Argomento:
Questo discorso riguarda i numerosi percorsi verso l'esecuzione di ruby nel browser web. In primo luogo parlerò del perché questa è anche una buona idea. Parlerò quindi brevemente di ogni approccio che ho esaminato e delle diverse quantità di FAIL che ho riscontrato con ciascuna di esse. Successivamente mi concentrerò sul concorrente più promettente, rubyjs, un compilatore ruby che emette javascript.
Il progetto rubyjs still exists, ma sembra essere morto. L'idea probabilmente era un po 'troppo pazza.
Una cosa è UN FATTO: dal 2010 JavaScript non ha un thread che ferma la funzione "sleep" (diversa da quella che brucia solo i cicli della CPU).
Ho lavorato con JavaScript per almeno un anno prima di postare questo commento e sono giunto alla conclusione che la mancanza di una funzione di interruzione del thread è un vero ostacolo allo show per il threading del codice correlato.
Una conseguenza della mancanza della funzione sleep è che non è possibile simulare un Ruby/C#/C++/etc. come il modello di threading in JavaScript, che a sua volta significa che non è possibile tradurre nessuno dei linguaggi abilitati per il threading in JavaScript, non importa, a meno che il codice JavaScript non sia integrato con un (preferibilmente senza ciclo di CPU). funzione.
Se si naviga, si possono trovare molti commenti che affermano che la funzione sleep non è nemmeno necessaria, che setTimeout è sufficiente, ecc., Ma suppongo che le persone, che lo dichiarano, non abbiano provato a implementare una struttura di threading in JavaScript. (Pensa ai mutex, sezioni critiche.) Mi rifiuto di entrare in una discussione che le sezioni/sincronizzazione critiche non sono/non sono necessarie per i casi, dove il contenuto del widget è costituito da più componenti di dati che formano un "intero atomico".)
Il secondo show-stopper per l'intero modello DOM è l'implementazione che rende gli elementi DOM nel FILO DI SFONDO.
Ecco, che cosa accade:
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()
Come il DOM è reso in background (leggi: in un thread separato), ci sarà una condizione di competizione tra il filo che ha avviato la modifica DOM, effettuando una chiamata al create_my_awsome_widget_in_DOM() e il rendering DOM. Se il thread di rendering è "abbastanza veloce" per rendere il DOM prima del thread JavasSript chiama edit_my_awsome_widget_by_editing_DOM_inside_it(), tutto funziona correttamente, ma se è il contrario, allora JavaScript inizia a modificare la regione del DOM che non lo fa (ancora) esiste.
Essenzialmente significa che a causa della bassa DOM rendendo la create_my_awsome_widget_in_DOM() e edit_my_awsome_widget_by_editing_DOM_inside_it() vengono eseguiti in un ordine casuale e ovviamente l'applicazione si blocca, se l'edit_my_awsome_widget_by_editing_DOM_inside_it() viene chiamato prima del create_my_awsome_widget_in_DOM().
In realtà, potrebbe esserci un modo per simulare un sonno adeguato() in JavaScript. A partire dal 01.2011 non so, se funziona, ma potrebbe essere, se uno "sostituisce la classe di funzione", diciamo, avvolgendo tutte le chiamate di funzione a livello di applicazione alle istanze che uno ha progettato autonomamente e utilizza " thread virtuali creati autonomamente ", si potrebbe ottenere una simulazione sleep() corretta senza masterizzare i cicli della CPU. Tuttavia, potrebbe essere un hoke, perché, come ho detto, a gennaio 2011 non l'ho ancora provato. –
mruby sembra come un'opzione interessante per l'esecuzione di rubino in un browser Web: http://qiezi.me/projects/mruby-web-irb/mruby.html
Non è un plugin tipico in quanto non richiede installazione, è javascript (compilato da C) l'esecuzione di codice Ruby.
I plug-in possono introdurre immense falle di sicurezza e problemi di prestazioni. Prendiamo ad esempio il plug-in Flash, che richiede troppo processore per funzionare correttamente sui telefoni cellulari e ha una patch a intervalli regolari per chiudere una pericolosa perdita di sicurezza. JavaScript È la lingua del browser, semmai, cerca un compilatore da Ruby a JavaScript. – BGerrissen