Potrò mai codificare il codice del browser sul lato client in una lingua di mia scelta? [chiuso]

15

Chiuso . Questa domanda è basata sull'opinione . Al momento non accetta risposte.

Vuoi migliorare questa domanda? Aggiorna la domanda in modo che possa essere risolta con fatti e citazioni modificando questo post .

Chiuso 6 anni fa .

Sarò brutalmente onesto: odio scrivere codice lato client in JavaScript. Non sono un fan di questa lingua, per non dire altro.

Mi sembra sciocco che i browser supportino un linguaggio di programmazione , piuttosto che una macchina virtuale intermedia (come CIL o JVM). Quest'ultimo consentirebbe ai programmatori di scrivere in una lingua a loro scelta (in una certa misura), piuttosto che in una lingua preimpostata fissa. Questa lingua potrebbe evolversi più rapidamente, perché solo le modifiche a CIL / JVM / qualunque cosa richiederebbero l'aggiornamento di tutti i principali browser. Le funzionalità della lingua possono essere aggiunte senza influire sulla vecchia esperienza del browser.

I notevoli risparmi di sforzo che portano i linguaggi intermedi sono ben noti . Ci sono iniziative là fuori per promuovere lo "scripting" del browser in qualcosa di diverso da JavaScript, e specialmente in una macchina virtuale già progettata, sviluppata e ottimizzata? Hanno qualche slancio?

programming-languages browser

— Roman Starkov
fonte

vedi anche: Perché non ci sono altri linguaggi di scripting lato client per i siti Web?

— moscerino

11

Per rispondere alla tua domanda, sì, ci sono sforzi per deprecare Javascript a favore di un linguaggio più coeso per gli script web. Google ha messo molta spinta dietro il loro linguaggio Dart . Dart ha la propria VM che è già integrata in Chrome, ma non sono sicuro che gli altri browser lo abbiano ancora adottato. Esiste anche un linguaggio abbastanza promettente chiamato CoffeeScript .

C'è anche un progetto dall'aspetto molto ambizioso chiamato HaXe che mira a unificare tutta una serie di piattaforme di sviluppo con una sola lingua.

Credimi, non sei il solo a non apprezzare Javascript, ma temo che non andrà presto da nessuna parte - in effetti sembra guadagnare molto slancio rispetto alle app HTML5 / JS di Windows 8, ecc. Ma alternative come quelle che menzionato stanno iniziando a spuntare :)

— MattDavey
fonte

9

Unificare tutto in una sola lingua è esattamente l'opposto di ciò che si desidera. Ti lascia solo con la stessa situazione di adesso, solo con una lingua diversa invece di JavaScript. Il punto è che gli sforzi esistenti dovrebbero essere basati su: IL / CLR è ben consolidato, ha già JITters ad alte prestazioni per la maggior parte delle piattaforme e diversi compilatori compilano già diverse lingue in esso. Per portare la rete nel 21 ° secolo, i browser devono farne uso, invece di cercare costantemente di creare nuove cose e partire da zero.

— Timwi,

3

@ Timwi, il CIL è troppo pesante e contiene troppa burocrazia. Non avrebbe senso allegare un file bytecode completo e gonfio con una classe dedicata e tutti i metadati ingombranti a ciascun onSomethinggestore di eventi: l'analisi e l'interpretazione di 10-20 caratteri di un semplice linguaggio di scripting è molto più efficiente.

— SK-logic,

1

@ SK-logic: sembra che tu abbia un'immagine completamente sbagliata di CIL e del bytecode in generale. Non ho idea di cosa ti farebbe pensare che i metadati binari siano "ingombranti" rispetto a una sintassi di alto livello come JavaScript. Soprattutto, non ho idea del perché il "ogni singolo gestore di eventi onSomething". I programmi C # chiaramente non vengono compilati in più assembly per ogni gestore di eventi.

— Timwi,

1

@Timwi, sto mangiando ECMA-335 a colazione, quindi so fin troppo bene quanto sia ingombrante il CIL. I nodi DOM sono spesso generati dinamicamente. Non c'è modo di aggiungere qualcosa a un modulo esistente in CIL: devi definire un nuovo modulo. E non puoi aggiungere a una classe: devi definire una nuova classe (con i metadati ingombranti allegati). E basta confrontare il costo di lettura, JIT ed esecuzione di CIL con l'analisi, l'esecuzione e l'eliminazione immediata di una minuscola stringa di testo. Ci sono molti casi in cui un'interpretazione ad hoc è molto più efficiente di qualsiasi tipo di compilazione.

— SK-logic,

2

@ Timwi, stai proponendo di utilizzare il bytecode come denominatore comune e formato di comunicazione, giusto? Il mio punto è che l'attuale specifica del CIL è praticamente inutile. ExpandoObject è irrilevante. E la tua visione sull'analisi della complessità è oscurata. Il modulo CIL contiene la propria tabella di riferimento dell'assembly, la tabella dei token dei metadati e solo allora classi e metodi. Confronta lo sforzo richiesto per leggere e JIT tutte queste cose voluminose con l'interpretazione di una stringa di un linguaggio banale di alto livello. Il costo di analisi è quasi zero qui. Prova entrambi gli approcci e confronta te stesso.

— Logica SK

5

Javascript stesso può essere visto come una lingua intermedia, definendo una macchina virtuale in cui è possibile compilare altre lingue. In progetti come GWT questa nozione sta già decollando. Potrebbe non essere quello che avresti progettato da zero, ma sta già diventando realtà che potresti compilare "la tua lingua preferita" in Javascript.

— John Snelson
fonte

5

In sostanza, no. Sei praticamente bloccato con Javascript.

Detto questo, ci sono stati degli sforzi in passato per integrare altre lingue (applet java, vbscript, ecc.) Ognuna di queste non ha mai realmente guadagnato la trazione che javascript ha perché javascript è integrato .

L'unico modo per creare ciò a cui ti riferisci sarebbe creare un linguaggio di script che venga eseguito su una macchina virtuale, compilato sul lato client e quindi eseguito. Quindi ogni browser dovrebbe implementare la macchina virtuale nel proprio codebase in modo che tutto il codice fosse eseguito su tutti i browser. Quindi dovresti assicurarti di avere una sorta di standard in modo che tutti i browser eseguano i comandi allo stesso modo. Naturalmente, essendo i browser creati in modo indipendente, probabilmente ci sarebbero delle stranezze che gli sviluppatori dovrebbero tenere a mente.

Ma ora abbiamo appena descritto Javascript.

Quindi, alla fine, le tue scelte sono:

abituarsi a Javascript
prova ad usare un linguaggio che si compila fino a Javascript. (Tieni presente che vorrai comunque verificare il Javascript, che riporta all'opzione 1.)
utilizzare un linguaggio esistente come plug-in per il browser, come actionscript (Flash), ActiveX, applet java, .Net (SilverLight). Ciò evita il problema con più fornitori / implementazioni della lingua, ma non integra la lingua.

In sostanza, se vuoi un linguaggio integrato, sei bloccato con Javascript.

— Richard
fonte

2

Un'altra scelta sarebbe quella di usare un linguaggio che si compili in javascript e usarlo.

— Jetti,

@Jetti Stai pensando a CoffeeScript ? È il motto - è "Regola d'oro" come la chiamano - è "È solo Javascript" . Ma se stai scrivendo qualcosa che è essenzialmente Javascript, non stai davvero scrivendo Javascript? È come sostenere che jQuery non è javascript perché è più pulito e più facile da usare.

— Richard,

2

dai un'occhiata a questo elenco di lingue che vengono compilate in javascript

— Jetti il

@Jetti Forse avrebbero funzionato bene. Ma con la stranezza del supporto cross-browser, sarei nervoso nel raccomandare qualcuno di questi e non verificare l'effettivo javascript generato.

— Richard,

1

Solo che javascript è un linguaggio intermedio assolutamente orribile e molto difficile da eseguire in modo coerente.

— Milind R

4

In realtà non stai odiando javascript, come descritto negli standard Ecma, ma stai odiando l'implementazione terribile su vari browser , con loro stranezze, bug e wtfs. Javascript lato server è piuttosto divertente in realtà. Anche il modello DOM è la causa dell'80% del dolore del javascript sul lato client.

Se vuoi ancora usare un'altra lingua, puoi usare GWT , che sostanzialmente ti consente di scrivere Java, quindi compilarlo in (brutto) javascript o CoffeeScript , che è uno zucchero sintattico su JS, che si compila in JS.

— Clemente Herreman
fonte

9

Non posso parlare per romkyns, ma io odio JavaScript per sé ( in aggiunta ai problemi che hai menzionato). Non è orientato agli oggetti, non ha una digitazione statica, nessuna gestione degli errori utile e nessun quadro utile delle funzionalità moderne. È anche incoerente e ingombrante. E a proposito, la caratteristica più odiata di JS, l'inserimento di punti e virgola, è nello standard ECMA.

— Timwi,

1

@Timwi, è basato sulle funzioni e puoi scrivere il codice OO se vuoi. La digitazione statica è buona, ma se il tuo codice è scritto bene (piccole funzioni, corretto ambito), raramente è un problema. Per quanto riguarda l'inserimento di punti e virgola, trovo che sia un lieve fastidio. Mi ha morso solo una volta, perché avevo il ritorno e l'apertura {di un oggetto su linee diverse. Quale "quadro di funzionalità moderne" trovi mancante?

— CaffGeek,

2

JavaScript stesso non è il miglior linguaggio in circolazione (per dirla educatamente). Non mi importa delle cose orientate agli oggetti (tanto meno - meglio è), del suo sistema di tipo dinamico (è davvero necessario per un linguaggio di scripting di questo tipo, sfortunatamente), ma la presenza di dichiarazioni e la mancanza di un'adeguata elenchi e tuple è fastidioso. Sia per la scrittura in JavaScript sia per l'implementazione di compilatori destinati a JavaScript.

— SK-logic,

2

@Timwi: stai vedendo non orientato agli oggetti come una cosa negativa, mentre non è sempre così. Per favore, non vedere OOP come il proiettile d'argento dei paradigmi di sviluppo. Anche l'approccio funzionale, come JS o Scala, è fantastico. Puoi avere OOP in JS, ma la differenza principale è che è la programmazione basata su prototipo, anziché la programmazione basata su classi. OOP è un nome generico e non si limita a Java / C #. Basato su prototipo è diverso da quello basato su classe e ben utilizzato, è potente quanto basato su classe.

— Clemente Herreman,

2

@ClementHerreman: JavaScript non si limita al lato client, ma questa discussione riguarda il lato client. JavaScript è limitato al prototipo, il che è un aspetto negativo rispetto a IL che ti permetterebbe di usare praticamente qualsiasi lingua.

— Timwi,

2

Questa domanda si presenta di volta in volta.

Perché non abbiamo altre lingue nei tag script anziché solo Javascript

Nel passato IE ha introdotto VB come alternativa a Javascript. Penso che puoi già vedere come questo porterebbe all'inferno degli standard se prendesse piede ...

Allora perché non una lingua intermedia standard comune allora?

C'è un vecchio podcast di Brendan Eich che spiega perché non vede un linguaggio bytecode intermedio nel prossimo futuro:

http://www.aminutewithbrendan.com/pages/20101122

http://news.ycombinator.com/item?id=1893686

Il problema di base è che mentre il linguaggio intermedio (come i bytecode CIL e JVM) cerca di essere generico, la maggior parte delle volte si rivela essere di livello troppo basso e troppo legato ai linguaggi di alto livello originali che li hanno compilati. Ad esempio, non è possibile implementare realmente funzioni ricorsive di coda nella JVM: quali altre funzionalità linguistiche o scelte di implementazione non saremo in grado di implementare se ci associamo a un'astrazione di bytecode di basso livello troppo presto?

Nel frattempo, Javascript è un linguaggio flessibile di alto livello con semantica esaurita e implementazioni multiple, diverse ed efficienti. Quello che potremmo vedere in futuro è lo stesso Javascript come linguaggio intermedio - Sfortunatamente questo è un po 'immaturo e poche lingue compilate per JS ad oggi.

— hugomg
fonte

Ma questo argomento si applica a JavaScript tanto quanto si applica a JVM e CIL, non è vero? :) L'unica cosa che va per JavaScript è che è già supportato da tutti i browser.

— Roman Starkov,

Il punto è più sottile: Javascript è descritto a un livello superiore rispetto alla maggior parte dei linguaggi intermedi, quindi le implementazioni ottengono più spazio per le gambe nella scelta di cosa fare. (Certo, questo non è tutto un mare di rose - volevo solo sottolineare che non siamo i primi a pensare a un IL per il web e che non è così semplice)

— hugomg

1

Sì. Puoi già compilare Dart, Coffeescript e Java in Javascript. Hai Emscripten, che è un backend del compilatore per LLVM per la generazione di bytecode Javascript (e LLVM gestisce parecchie lingue, credo).

Ma oltre alla compilazione in JS, non in un breve lasso di tempo. IE6 ha 10 anni e continua a calciare. Spero che gli attuali browser (che non supportano altre lingue) non sopravvivranno così a lungo, ma rimarranno in circolazione per alcuni anni, provocando il ciclo mordace di "dobbiamo ancora supportare i browser che supportano solo Javascript, quindi dobbiamo usare Javascript ", in un modo molto più difficile di quanto si pensi a CSS3 - il tuo sito potrebbe funzionare senza CSS3, ma prova a farlo funzionare senza script sul lato client.

— alex
fonte

0

Potresti essere fortunato. Questo è il paragrafo iniziale di una presentazione sul forum webkit-dev:

Molte lingue vengono compilate in JavaScript oggi per essere eseguite sul Web. In alternativa, abbiamo provato a consentire l'esecuzione di runtime di lingue diverse in WebKit in pagine Web insieme a JavaScript ...

Puoi visualizzare il resto del messaggio qui .

— pgfearo
fonte

0

JavaScript è l'anima dei browser, ecco perché la maggior parte dei nuovi tentativi genera JavaScript (CoffeeScript ne è un chiaro esempio).
In GWT, si codifica la logica lato client nel linguaggio di programmazione Java e il toolkit genera JavaScript.

ClojureScript è un progetto interessante se sei in codice Lisp.

Quindi non importa quale sia, JavaScript è qui per rimanere. (COBOL del web forse?).

— Chiron
fonte

0

"Ogni cliente può far dipingere un'auto di qualsiasi colore desideri, purché sia nero." -- Henry Ford

Esistono già numerosi compilatori che hanno come target javascript e puoi scegliere qualsiasi lingua che compili in javascript.

Il tuo link che discute del valore delle lingue intermedie le discute nel contesto dell'implementazione di una suite di compilatori, non nel fornire il codice che verrà spedito attraverso una rete ed eseguito su un computer client. Javascript potrebbe non essere il formato migliore per questo, ma qualunque cosa sia, non assomiglierà molto ai codici byte CIL o java.

Se odi javascript, ti suggerisco di spostarti nello spazio di sviluppo incorporato, scientifico o di gioco, dove C, Fortran e C ++ governano il posatoio. Le app line of business si stanno spostando molto sul Web e questo significa più Javascript, non meno.

— Sean McMillan
fonte