Perché JavaScript anziché una macchina virtuale standard per browser?

Non avrebbe senso supportare un insieme di linguaggi (Java, Python, Ruby, ecc.) Tramite una macchina virtuale standardizzata ospitata nel browser piuttosto che richiedere l'uso di un linguaggio specializzato - in realtà, un paradigma specializzato - solo per scripting client?

Per chiarire il suggerimento, una pagina Web conterrebbe il codice byte anziché qualsiasi linguaggio di livello superiore come JavaScript.

Capisco la realtà pragmatica che JavaScript è semplicemente ciò con cui dobbiamo lavorare ora a causa di ragioni evolutive, ma sto pensando di più al lungo termine. Per quanto riguarda la compatibilità con le versioni precedenti, non vi è alcun motivo per cui JavaScript inline non possa essere simultaneamente supportato per un certo periodo di tempo e, naturalmente, JavaScript potrebbe essere una delle lingue supportate dalla macchina virtuale del browser.

Beh si. Certamente se avessimo una macchina del tempo, tornare indietro e garantire che molte funzionalità di Javascript fossero progettate in modo diverso sarebbe un passatempo importante (quello, e garantire che le persone che hanno progettato il motore CSS di IE non siano mai entrati nell'IT). Ma non succederà, e ora ci siamo bloccati.

Sospetto che, col tempo, diventerà il "linguaggio macchina" per il web, con altri linguaggi e API meglio progettati che verranno compilati fino a quel momento (e che si rivolgeranno a diversi problemi del motore di runtime).

Non credo, tuttavia, nessuno di questi "linguaggi meglio progettati" sarà Java, Python o Ruby. Javascript è, nonostante la possibilità di essere utilizzato altrove, un linguaggio di scripting di applicazioni Web. Dato questo caso d'uso, possiamo fare meglio di qualsiasi di quelle lingue.

Penso che JavaScript sia un buon linguaggio, ma mi piacerebbe avere una scelta durante lo sviluppo di applicazioni web sul lato client. Per motivi legacy siamo bloccati con JavaScript, ma ci sono progetti e idee che cercano di cambiare quello scenario:

1. Google Native Client : tecnologia per l'esecuzione di codice nativo nel browser.
2. Emscripten : compilatore bytecode LLVM in javascript. Consente l'esecuzione delle lingue LLVM nel browser.
3. Idea: CLI .NET nel browser, dal creatore di Mono: http://tirania.org/blog/archive/2010/May-03.html

Penso che avremo JavaScript per molto tempo, ma prima o poi cambierà. Ci sono così tanti sviluppatori disposti a usare altre lingue nel browser.

Rispondere alla domanda - No, non avrebbe senso.

Attualmente le cose più vicine a una VM multilingue sono JVM e CLR. Queste non sono esattamente bestie leggere e non avrebbe senso cercare di incorporare qualcosa di queste dimensioni e complessità in un browser.

Esaminiamo l'idea che potresti scrivere una nuova macchina virtuale multilingue che sarebbe migliore della soluzione esistente.

• Sei dietro alla stabilità.
• Sei in ritardo sulla complessità (via, via, dietro perché stai cercando di generalizzare su più lingue)
• Sei dietro all'adozione

Quindi no, non ha senso.

Ricorda, per supportare queste lingue dovrai ridurre le loro API in modo feroce, eliminando tutte le parti che non hanno senso nel contesto di uno script del browser. Ci sono un numero enorme di decisioni di progettazione da prendere qui e un'enorme opportunità di errore.

In termini di funzionalità, probabilmente stiamo lavorando davvero solo con il DOM, quindi questo è davvero un problema di sintassi e linguaggio idom, a quel punto ha senso chiedersi: "Ne vale davvero la pena?"

Tenendo presente, l' unica cosa di cui stiamo parlando è lo scripting lato client, poiché lo scripting lato server è già disponibile in qualsiasi lingua tu voglia. È un'arena di programmazione relativamente piccola e quindi il vantaggio di introdurre più lingue è discutibile.

Quali lingue avrebbe senso introdurre? (Attenzione, segue materiale soggettivo)

Portare in un linguaggio come C non ha senso perché è fatto per lavorare con il metal, e in un browser non c'è molto metal davvero disponibile.

Introdurre un linguaggio come Java non ha senso perché la cosa migliore è comunque l'API.

Introdurre una lingua come Ruby o Lisp non ha senso perché JavaScript è un linguaggio dinamico potente molto vicino a Scheme.

Infine, quale browser maker vuole davvero supportare l'integrazione DOM per più lingue? Ogni implementazione avrà i suoi bug specifici. Abbiamo già attraversato il fuoco affrontando le differenze tra MS Javascript e Mozilla Javascript e ora vogliamo moltiplicare quel dolore di cinque o sei volte?

Non ha senso.

Su Windows, puoi registrare altre lingue con lo Scripting Host e renderle disponibili a IE. Ad esempio VBScript è supportato immediatamente (anche se non ha mai guadagnato molta popolarità in quanto è per la maggior parte anche peggiore di JavaScript).

Le estensioni win32 di Python hanno permesso di aggiungere Python a IE in questo modo abbastanza facilmente, ma non era davvero una buona idea in quanto Python è abbastanza difficile da sandbox: molte funzionalità del linguaggio espongono abbastanza hook di implementazione per consentire a un'applicazione presumibilmente limitata di uscire .

È un problema in generale che maggiore è la complessità aggiunta a un'applicazione di rete come il browser, maggiore è la probabilità di problemi di sicurezza. Un sacco di nuove lingue si adatterebbe sicuramente a quella descrizione, e queste sono nuove lingue che si stanno ancora sviluppando rapidamente.

JavaScript è un linguaggio brutto, ma attraverso un uso attento di un sottoinsieme selettivo di funzionalità e il supporto da idonee librerie di oggetti, può essere generalmente reso abbastanza tollerabile. Sembra che le aggiunte pratiche e incrementali a JavaScript siano l'unico modo per andare avanti con gli script web.

Gradirei sicuramente una VM indipendente dalla lingua standard nei browser (preferirei programmare in una lingua tipizzata staticamente).

(Tecnicamente) È abbastanza fattibile gradualmente: prima uno dei principali browser lo supporta e il server ha la possibilità di inviare bytecode se la richiesta corrente proviene da un browser compatibile o tradurre il codice in JavaScript e inviare JavaScript in chiaro.

Esistono già alcuni linguaggi sperimentali che vengono compilati in JavaScript, ma avere una VM definita consentirebbe (forse) prestazioni migliori.

Ammetto che la parte "standard" sarebbe piuttosto complicata, però. Inoltre ci sarebbero conflitti tra le caratteristiche del linguaggio (es. Tipizzazione statica e dinamica) riguardanti la biblioteca (supponendo che la nuova cosa avrebbe usato la stessa biblioteca). Quindi non penso che accadrà (presto).

Se ti senti come se ti sporcassi le mani, allora ti sei fatto il lavaggio del cervello o stai ancora sentendo gli effetti collaterali degli "anni DHTML". JavaScript è molto potente ed è adatto per il suo scopo, ovvero quello di eseguire l'interazione con gli script sul lato client. Questo è il motivo per cui JavaScript 2.0 ha ottenuto un rap così brutto. Voglio dire, perché pacchetti, interfacce, classi e simili, quando questi sono chiaramente aspetti dei linguaggi lato server. JavaScript va bene come un linguaggio basato su prototipo, senza essere completamente orientato agli oggetti.

Se le tue applicazioni sono carenti, perché lato server e lato client non comunicano bene, potresti voler riconsiderare il modo in cui architetti le tue applicazioni. Ho lavorato con siti Web e applicazioni Web estremamente robusti e non ho mai detto una volta "Hmm, vorrei davvero che JavaScript potesse fare (xyz)". Se potesse farlo, allora non sarebbe JavaScript - sarebbe ActionScript o AIR o Silverlight. Non ne ho bisogno, e nemmeno la maggior parte degli sviluppatori. Quelle sono belle tecnologie, ma cercano di risolvere un problema con una tecnologia, non una ... beh, una soluzione.

Non credo che una VM virtuale standard sia così inconcepibile. Esistono diversi modi in cui è possibile introdurre un nuovo standard di VM Web con garbo e con pieno supporto legacy, purché si garantisca che qualsiasi formato di bytecode VM che si utilizza possa essere rapidamente decompilato in javascript e che l'output risultante sarà ragionevolmente efficiente ( Andrei persino al punto di indovinare che un decompilatore intelligente genererebbe probabilmente un javascript migliore di qualsiasi javascript che un essere umano possa produrre da solo).

Con questa proprietà, qualsiasi formato di web VM potrebbe essere facilmente decompilato sul server (veloce), sul client (lento, ma possibile nei casi in cui si ha un controllo limitato del server) o potrebbe essere pre-generato e caricato dinamicamente da il client o il server (più veloce) per i browser che non supportano nativamente il nuovo standard.

Quei browser che supportano nativamente il nuovo standard trarrebbero beneficio da una maggiore velocità di runtime per le app basate su Web VM. Inoltre, se i browser basano i loro motori javascript legacy sullo standard web vm (ovvero analizzando javascript nello standard web vm e quindi eseguendolo), non devono gestire due runtime, ma dipende dal fornitore del browser .

Mentre Javascript è l'unico linguaggio di scripting ben supportato da cui puoi controllare direttamente la pagina, Flash ha alcune funzioni molto interessanti per i programmi più grandi. Ultimamente ha un JIT e può anche generare bytecode al volo (controlla la valutazione dell'espressione di runtime per un esempio in cui usano flash per compilare espressioni matematiche di input dell'utente fino al binario nativo). Il linguaggio Haxe ti dà la tipizzazione statica con deduzione e con le abilità di generazione del bytecode puoi implementare quasi tutti i sistemi di runtime che preferisci.

Aggiornamento rapido su questa vecchia domanda.

Chiunque affermasse che una "pagina web conterrebbe codice byte anziché qualsiasi linguaggio di livello superiore come JavaScript" "non accadrà".

Giugno 2015 il W3C ha annunciato WebAssembly che è

un nuovo formato portatile, efficiente in termini di dimensioni e tempo di caricamento, adatto per la compilazione sul Web.

Questo è ancora sperimentale, ma c'è già qualche implementazione prototipale in Firefox ogni notte e Chrome Canary e c'è già qualche dimostrazione funzionante .

Attualmente, tuttavia, WebAssembly è principalmente progettato per essere prodotto da C / C ++

man mano che WebAssembly si evolve supporterà più lingue rispetto a C / C ++ e speriamo che anche altri compilatori lo supportino .

Ti ho permesso di dare un'occhiata più da vicino alla pagina ufficiale del progetto, è davvero emozionante!

questa domanda riappare regolarmente. la mia posizione su questo è:

A) non accadrà e B) è già qui.

scusa, cosa? lasciatemi spiegare:

annuncio A

una VM non è solo una sorta di dispositivo magico universale. la maggior parte delle macchine virtuali sono ottimizzate per una determinata lingua e determinate funzionalità linguistiche. prendi JRE / Java (o LLVM): ottimizzato per la tipizzazione statica, e ci sono sicuramente problemi e svantaggi durante l'implementazione della tipizzazione dinamica o altre cose che java non supportava in primo luogo.

quindi, la "VM multiuso generale" che supporta molte funzionalità linguistiche (ottimizzazione delle chiamate di coda, digitazione statica e dinamica, foo bar boo, ...) sarebbe colossale, difficile da implementare e probabilmente più difficile da ottimizzare per ottenere buone prestazioni da esso. ma io non sono un progettista di lingue o vm guru, forse sbaglio: in realtà è abbastanza facile, solo nessuno ha ancora avuto l'idea? hrm, hrm.

annuncio B

già qui: potrebbe non esserci un compilatore bytecode / vm, ma in realtà non ne hai bisogno. afaik javascript è in fase di completamento, quindi dovrebbe essere possibile:

1. creare un traduttore dalla lingua X a javascript (ad es. coffeescript)
2. creare un interprete in javascript che interpreta il linguaggio X (ad es. brainfuck ). sì, la performance sarebbe terrificante, ma ehi, non può avere tutto.

annuncio C

che cosa? non c'era un punto C in primo luogo !? perché non c'è ... ancora. google NACL. se qualcuno può farlo, è google. non appena Google lo fa funzionare, i tuoi problemi vengono risolti. solo che potrebbe non funzionare mai, non lo so. l'ultima volta che l'ho letto ci sono stati alcuni problemi di sicurezza irrisolti del tipo davvero complicato.

a parte quello:

• javascript è stato lì da ~ 1995 = 15 anni. tuttavia, le implementazioni del browser differiscono oggi (anche se almeno non è più insopportabile). quindi, se inizi ancora qualcosa di nuovo, potresti avere una versione che funziona su più browser intorno al 2035. almeno un sottoinsieme funzionante. questo differisce solo sottilmente. e necessita di librerie e livelli di compatibilità. inutile però non cercare di migliorare le cose.

• inoltre, che dire del codice sorgente leggibile? so che molte aziende preferirebbero non servire il loro codice come "tipo di" open source. personalmente, sono abbastanza felice di poter leggere la fonte se sospetto qualcosa di sospetto o se voglio imparare da essa. evviva il codice sorgente!

Infatti. Silverlight è effettivamente proprio questo: una VM basata sul client .Net based.

Ci sono alcuni errori nel tuo ragionamento.

1. Una macchina virtuale standard in un browser standard non sarà mai standard. Abbiamo 4 browser e IE ha interessi contrastanti rispetto allo "standard". Le altre tre si stanno evolvendo rapidamente ma il tasso di adozione delle nuove tecnologie è lento. Che dire dei browser su telefoni, piccoli dispositivi, ...

2. L'integrazione di JS nei diversi browser e la sua storia passata ti porta a sottovalutare la potenza di JS. Impegni uno standard, ma disapprovi JS perché lo standard non ha funzionato nei primi anni.

3. Come raccontato da altri, JS non è lo stesso di AIR / .NET / ... e simili. JS nella sua attuale incarnazione si adatta perfettamente ai suoi obiettivi.

A lungo termine, Perl e Ruby potrebbero benissimo sostituire javascript. Tuttavia l'adozione di queste lingue è lenta ed è risaputo che non prenderanno mai il controllo di JS.

Come definisci meglio? Il meglio per il browser o il meglio per lo sviluppatore? (Inoltre ECMAScript è diverso da Javascript, ma questo è un tecnicismo.)

Trovo che JavaScript possa essere potente ed elegante allo stesso tempo. Sfortunatamente la maggior parte degli sviluppatori che ho incontrato lo tratta come un male necessario anziché come un vero linguaggio di programmazione.

Alcune delle funzionalità che mi piacciono sono:

• trattare le funzioni come cittadini di prima classe
• essere in grado di aggiungere e rimuovere funzioni su qualsiasi oggetto in qualsiasi momento (non molto utile ma strabiliante quando lo è)
• è un linguaggio dinamico.

È divertente da affrontare ed è stabilito. Divertiti mentre è in giro perché, anche se potrebbe non essere il "migliore" per lo scripting dei client, è sicuramente piacevole.

Sono d'accordo che è frustrante quando si creano pagine dinamiche a causa delle incompatibilità del browser, ma ciò può essere mitigato dalle librerie dell'interfaccia utente. Questo non dovrebbe essere tenuto contro JavaScript stesso più di Swing dovrebbe essere tenuto contro Java.

JavaScript è la macchina virtuale standard del browser. Ad esempio, OCaml e Haskell ora hanno entrambi compilatori che possono generare JavaScript. La limitazione non è JavaScript la lingua, la limitazione sono gli oggetti del browser accessibili tramite JavaScript e il modello di controllo degli accessi utilizzato per garantire la sicurezza di eseguire JavaScript senza compromettere la macchina. Gli attuali controlli di accesso sono così scarsi, che a JavaScript è consentito un accesso molto limitato agli oggetti del browser per motivi di sicurezza. Il progetto Harmony sta cercando di risolverlo.

È una bella idea. Perché non fare un ulteriore passo avanti?

• Scrivi il parser HTML e il motore di layout (tutti i bit complicati nel browser, in realtà) nello stesso linguaggio VM
• Pubblica il motore sul Web
• Servire la pagina con una dichiarazione di quale motore di layout usare e il suo URL

Quindi possiamo aggiungere funzionalità ai browser senza dover inviare nuovi browser a tutti i client: i nuovi bit pertinenti verrebbero caricati dinamicamente dal web. Potremmo anche pubblicare nuove versioni di HTML senza tutta la ridicola complessità di mantenere la retrocompatibilità con tutto ciò che ha mai funzionato in un browser: la compatibilità è responsabilità dell'autore della pagina. Possiamo anche sperimentare linguaggi di markup diversi dall'HTML. E, naturalmente, possiamo scrivere fantasiosi compilatori JIT nei motori, in modo da poter scrivere le tue pagine web in qualsiasi lingua tu voglia.

Accolgo con favore qualsiasi lingua oltre a JavaScript come possibile linguaggio di scripting.

Ciò che sarebbe bello è usare altre lingue quindi Javascript. Java probabilmente non si adatterebbe molto bene tra i tag ma linguaggi come Haskell, Clojure, Scala, Ruby, Groovy sarebbero utili.

Qualche tempo fa sono arrivato su un rubyscript incrociato ... http://almaer.com/blog/running-ruby-in-the-browser-via-script-typetextruby e http://code.google.com/p/ruby- in-browser /
Ancora sperimentale e in corso, ma sembra promettente.
Per .Net ho appena trovato: http://www.silverlight.net/learn/dynamic-languages/ Ho appena scoperto il sito, ma sembra anche interessante. Funziona anche dal mio Apple Mac .

Non so quanto sia efficace quanto sopra nel fornire un'alternativa a Javascript, ma a prima vista sembra piuttosto bello. Potenzialmente, ciò consentirebbe di utilizzare qualsiasi framework Java o .Net nativamente dal browser, all'interno della sandbox del browser.

Per quanto riguarda la sicurezza, se il linguaggio scorre all'interno della JVM (o motore .Net per quella materia), la VM si prenderà cura della sicurezza, quindi non dobbiamo preoccuparci di questo - almeno non più di quanto dovremmo per tutto ciò che funziona all'interno del browser.

Probabilmente, ma per farlo dovremmo avere i principali browser per supportarli. Il supporto IE sarebbe il più difficile da ottenere. JavaScript è utilizzato perché è l'unica cosa su cui puoi contare per essere disponibile.

La stragrande maggioranza degli sviluppatori con cui ho parlato di ECMAScript et. al. finiscono per ammettere che il problema non è il linguaggio di scripting, è il ridicolo DOM HTML che espone. Confondere il DOM e il linguaggio di scripting è una fonte comune di dolore e frustrazione per ECMAScript. Inoltre, non dimenticare che IIS può utilizzare JScript per gli script lato server e cose come Rhino ti consentono di creare app indipendenti in ECMAScript. Prova a lavorare in uno di questi ambienti con ECMAScript per un po 'e vedi se la tua opinione cambia.

Questo tipo di disperazione va in giro da un po 'di tempo. Ti suggerirei di modificarlo per includere o ripubblicare con problemi specifici. Potresti essere piacevolmente sorpreso da un po 'di sollievo.

Un vecchio sito, ma comunque un ottimo punto di partenza: il sito di Douglas Crockford .

Bene, abbiamo già VBScript, no? Aspetta, solo IE lo supporta!
Lo stesso per la tua bella idea di VM. Cosa succede se scrivo la mia pagina usando Lua e il tuo browser non ha il parser per convertirlo in bytecode? Ovviamente, potremmo immaginare un tag di script che accetti un file di bytecode, che sarebbe anche abbastanza efficiente.
Ma l'esperienza mostra che è difficile portare qualcosa di nuovo sul Web: ci vorrebbero anni per adottare un nuovo cambiamento radicale come questo. Quanti browser supportano SVG o CSS3?

Inoltre, non vedo cosa trovi "sporco" in JS. Può essere brutto se codificato da dilettanti, propagando cattive pratiche copiate altrove, ma i maestri hanno dimostrato che può anche essere un linguaggio elegante. Un po 'come il Perl: spesso sembra un linguaggio offuscato, ma può essere reso perfettamente leggibile.

Dai un'occhiata a http://www.visitmix.com/Labs/Gestalt/ : consente di utilizzare Python o Ruby, a condizione che l'utente abbia installato Silverlight.

Questa è un'ottima domanda

Non è un problema solo in JS, in quanto è la mancanza di buoni IDE gratuiti per lo sviluppo di programmi più grandi in JS. Ne conosco solo uno gratuito: Eclipse. L'altro buono è Visual Studio di Microsoft, ma non gratuito.

Perché sarebbe gratuito? Se i venditori di browser Web vogliono sostituire le app desktop con app online (e lo desiderano), devono offrire a noi programmatori dei buoni strumenti di sviluppo. Non puoi creare 50.000 righe di JavaScript utilizzando un semplice editor di testo, JSLint e il debugger Google Chrome integrato. A meno che tu non sia un macohist.

Quando Borland creò un IDE per Turbo Pascal 4.0 nel 1987, fu una rivoluzione nella programmazione. Sono passati 24 anni da allora. Peccato, nel 2011 molti programmatori non usano ancora il completamento del codice, il controllo della sintassi e debugger adeguati. Probabilmente perché ci sono così pochi buoni IDE.

È nell'interesse dei fornitori di browser Web creare strumenti adeguati (GRATUITI) per i programmatori se vogliono che costruiamo applicazioni con cui possono combattere Windows, Linux, MacOS, iOS, Symbian, ecc.

Realisticamente, Javascript è l'unica lingua che qualsiasi browser utilizzerà per molto tempo, quindi mentre sarebbe molto bello usare altre lingue, non riesco a vederlo accadere.

Questa "VM standardizzata" di cui parli sarebbe molto ampia e dovrebbe essere adottata da tutti i principali browser e la maggior parte dei siti continuerebbe comunque a utilizzare Javascript poiché è più adatta ai siti Web rispetto a molti altri browser.

Dovresti eseguire il sandbox di ciascun linguaggio di programmazione in questa VM e ridurre la quantità di accesso che ogni lingua ha al sistema, richiedendo molte modifiche nelle lingue e rimozione o reimplementazione di molte funzionalità. Considerando che Javascript ha già in mente questo, e lo fa da molto tempo.

Forse stai cercando Native Client di Google.

In un certo senso, avere un linguaggio più espressivo come Javascript nel browser invece di qualcosa di più generale come il bytecode Java ha significato un web più aperto.

Penso che non sia così facile problema . Possiamo dire che siamo bloccati con JS, ma è davvero così male con jQuery, Prototype, scriptaculous, MooTools e tutte le fantastiche librerie?

Ricorda, JS è leggero , ancora di più con V8, TraceMonkey, SquirrelFish - nuovi motori Javascript utilizzati nei browser moderni.

È anche dimostrato - sì, sappiamo che ha problemi, ma ne abbiamo risolti molti, come i primi problemi di sicurezza. Imaging che consente al browser di eseguire il codice Ruby o qualsiasi altra cosa. La sandbox di sicurezza dovrebbe essere eseguita per zero. E tu sai cosa? La gente di Python ha già fallito due volte.

Penso che Javascript verrà rivisto e migliorato nel tempo, proprio come HTML e CSS. Il processo potrebbe essere lungo, ma non tutto è possibile in questo mondo.

Non credo che "capisca il problema pragmatico che JavaScript è semplicemente quello con cui dobbiamo lavorare ora". In realtà è un linguaggio molto potente. Hai avuto la tua applet Java nel browser per anni, e dove si trova ora?

Ad ogni modo, non è necessario "sporcarsi" per lavorare sul client. Ad esempio, prova GWT.

... intendi...

Java e Java applet Flash e Adobe AIR ecc.

In generale, qualsiasi framework RIA può soddisfare le tue esigenze; ma per ognuno c'è un prezzo da pagare per usarlo (ej. runtime disponibile sul browser o / e propietario o / e meno opzioni rispetto al desktop puro) http://en.wikipedia.org/wiki/List_of_rich_internet_application_frameworks

Per lo sviluppo del Web con qualsiasi lingua non web, hai GWT: sviluppa Java, compila in Javascript

Perché tutti hanno già macchine virtuali con interpreti bytecode e anche il bytecode è diverso. {Chakra (IE), Firefox (SpiderMonkey), Safari (SquirrelFish), Opera (Carakan).

Spiacenti, penso che Chrome (V8) si compili fino al codice macchina IA32.

bene, considerando che tutti i browser utilizzano già una VM, non penso che sarà così difficile creare un linguaggio VM per il web.
Penso che sarebbe di grande aiuto per alcuni motivi:
1. dal momento che il server compila il codice, la quantità di dati inviati è inferiore e il client non impiega tempo a compilare il codice.
2. dal momento che il server può compilare il codice in preparazione e memorizzarlo, a differenza del client che tenta di smorzare il compilatore JS in pochissimo tempo, può effettuare ottimizzazioni del codice migliori.
3. la compilazione di una lingua in codice byte è molto più semplice della traspilazione in JS.

come nota finale (come qualcuno ha già detto in un altro commento), HTML e CSS si compilano in un linguaggio più semplice, non sono sicuro se contano come codice byte, ma si potrebbe anche inviare html e css compilati dal server al client che ridurre i tempi di analisi e recupero

IMO, JavaScript, la lingua, non è il problema. JavaScript è in realtà un linguaggio piuttosto espressivo e potente. Penso che ottenga una cattiva reputazione perché non ha le caratteristiche OO classiche, ma per me più vado con il groove prototipo, più mi piace.

A mio avviso, il problema sono le implementazioni traballanti e incoerenti nei molti browser che siamo costretti a supportare sul web. Le librerie JavaScript come jQuery fanno molto per mitigare quella sensazione sporca.