JavaScript è morto. Lunga JavaScript diretta!

Da 16 anni, JavaScript è il linguaggio del browser web. Questo linguaggio ha permesso la costruzione di applicazioni web convincenti e contribuito al successo del web. Altri linguaggi di scripting potrebbero hanno riempito il ruolo JavaScript fa ma JavaScript era nel posto giusto al momento giusto. Microsoft ha aggiunto di base per Internet Explorer molto tempo fa, ma JavaScript era la lingua in tutti i browser e così ha vinto. Poiché JavaScript è cross-browser e almeno abbastanza buono, i produttori di browser non hanno avuto bisogno di aggiungere altri interpreti di lingua per i browser stessi.

Ma ancora non abbiamo scelto di usare JavaScript. È stato l'unica opzione. Ha caratteristiche potenti come le chiusure e abbiamo imparato ad amare queste caratteristiche mentre si gira un occhio alle parti verrucosa del linguaggio. C'è anche stato un sacco di chiedere scusa alla comunità dei programmatori sulla falsariga di "Sì sappiamo che è una lingua piuttosto funky, ma si prega di dargli una possibilità. Sono sicuro che imparerete ad amarlo. "Non dovrebbe essere difficile vendere la qualità del linguaggio. JavaScript è stato descritto come un esperimento sfuggito il laboratorio un po 'troppo presto e siamo stati bloccati con le verruche da allora.

Eppure, JavaScript è stato un grande linguaggio. Nel 2007, Steve Yegge dichiarato JavaScript come The Next Big lingua ed è stato. Tra allora e adesso basato su JavaScript web-applicazioni sono diventati più grandi e migliori. Con l'aiuto di JavaScript, il web ha continuato a svilupparsi anche con la minaccia di applicazioni mobili native presa in consegna lo stesso spazio.

In tempi molto recenti, JavaScript ha fatto il suo tentativo più riuscito ad essere un linguaggio server-side. La piattaforma Node.js, con la sua non-blocking I / O, possono essere risolvere un problema che i programmatori avere bisogno risolto per lungo tempo. JavaScript è il linguaggio per Node.js e così JavaScript può andare avanti per il giro di diventare un linguaggio server-side di successo dopo molti tentativi falliti in passato.

Nel complesso, JavaScript è stato un successo selvaggio. Il linguaggio di programmazione più popolare nel mondo. Ma se il browser è morto oggi, quanto il nuovo codice JavaScript sarebbe da scrivere domani? Molto probabilmente JavaScript sarebbe diventato un giorno all'altro lingua frangia. Ma il browser non sta morendo domani. Saremo programmazione per esso per gli anni a venire.

Come è stato utilizzato JavaScript per ulteriori e più grandi programmi, le verruche del linguaggio sono diventati più evidenti e ha causato crescenti quantità di dolore per molti sviluppatori. Può essere una sorpresa che, anche se ho scritto su JavaScript per anni, io non sono un fanboy JavaScript. La maggior parte dei miei articoli JavaScript sono stati per me lavorare attraverso le difficoltà di trovare una coesistenza pacifica con la lingua. Sì ho apprezzato la programmazione in JavaScript e ho imparato molto, ma c'è sicuramente sono stati momenti in cui mi sono sentito come se fossi sguazzare nel fango.

Una delle carenze più evidenti in JavaScript è con la sua interfaccia utente: la sua sintassi. L'incapacità di migliorare rapidamente la sua sintassi ha portato alla caduta del linguaggio.

Il caso per le estensioni di sintassi: Verbose Idioms

Qui guardiamo solo quattro dei tanti esempi in cui la sintassi di JavaScript potrebbe essere migliorata per rimuovere idiomi verbose dalle nostre esistenze quotidiane di programmazione.

Parametri e valori predefiniti Optional

Funzioni JavaScript può essere chiamato con un numero variabile di parametri attuali. Questo rende alcuni dei parametri formali nella dichiarazione della funzione opzionale. Spesso questi parametri opzionali devono essere impostati a un valore predefinito se nessun parametro reale è fornita. Sono pronto a scommettere che hai scritto e visto un sacco di codice come il seguente.

function (a, b, opzionale) {
    option = opzione || {};
    // ...
}
Ho e ancora scrivere il codice come questo. Questo codice è sbagliato. Se un valore falsy è passato alla funzione per l'opzione allora la cosa sbagliata accade. Dovremmo scrivendo quanto segue.

function (a, b, opzionale) {
    option = arguments.length> 2? Opzione: {};
    // ...
}
Anche se questo codice esprime il pensiero previsto di fissare un valore predefinito se un parametro attuale per l'opzione non viene fornito, è troppo prolisso e meno leggibile. Il lettore deve contare per determinare quale variabile si ha indice 2. Al di là del disagio, la versione corretta è più difficile da mantenere. È facile produrre il seguente codice buggy se il b parametro viene rimosso.

function (a, opzionale) {
    option = arguments.length> 2? Opzione: {};
    // ...
}
Se l'applicazione utilizza parametri facoltativi con valori di default, qualche nuova sintassi sarebbe vantaggioso per voi.

function (a, b, opzione = {}) {
    // ...
}
L'aggiunta di questa nuova sintassi sintonizza la lingua meglio alle esigenze della vostra applicazione.

Lasciare

Fa il seguente codice buggy sembra familiare?

for (var i = 0, ilen = elements.length; i <ilen; i ++) {
    elemento var = elementi [i];
    LIB_addEventListener (elemento, 'click', funzione (evento) {
        alert ('Sono stato originariamente numero' + i);
    });
}
Tutti gli elementi sono lo stesso numero ?! La soluzione è quella di utilizzare una espressione funzione immediatamente valutata in modo che ogni avviso segnala un numero diverso. Questo è l'idioma "let", dopo vari di Lisp Let forme.

for (var i = 0, ilen = elements.length; i <ilen; i ++) {
    elemento var = elementi [i];
    (Function (num) {
        LIB_addEventListener (elemento, 'click', funzione (evento) {
            alert ('Sono stato originariamente numero' + num);
        });
    } (I));
}
Certo a volte delegano ascoltatori potrebbe essere migliore di codice di cui sopra, ma a volte il codice di cui sopra è l'idea desiderata. Nel caso di cui sopra, stiamo cercando di legare l'ordine degli elementi quando il ciclo viene eseguito. Questo ordine può essere perduto con il modello delegato se gli elementi sono riorganizzate nel DOM.

Questa sintassi è particolarmente scomodo a causa della distanza tra il convenzionale num ed effettivi i parametri della funzione immediata.

La funzione immediata potrebbe essere scomposto fuori in un altro luogo e chiamato all'interno del ciclo.

Funzione attachListener (elemento, num) {
    LIB_addEventListener (elemento, 'click', funzione (evento) {
        alert ('Sono stato originariamente numero' + num);
    });
}
for (var i = 0, ilen = elements.length; i <ilen; i ++) {
    attachListener (elementi [i], i);
}
Anche con questa opzione, a volte i programmatori usano ancora la funzione immediata perché trasmette meglio il loro messaggio destinato ai lettori.

Se l'applicazione utilizza l'idioma let, non sarebbe bello avere nuova sintassi per esso?

for (var i = 0, ilen = elements.length; i <ilen; i ++) {
    elemento var = elementi [i];
    lasciare (num = i) {
        LIB_addEventListener (elemento, funzione (evento) {
            alert ('Sono stato originariamente numero' + num);
        });
    };
}
Con num e io insieme è molto più facile da leggere il codice e un nuovo ambito che contiene nuovo è stato introdotto così la chiusura funzioni correttamente. Ancora una volta, l'aggiunta di nuovo brano sintassi può il linguaggio meglio alle esigenze della vostra applicazione.

Moduli

Uno dei linguaggi più comuni programmi JavaScript che tutti noi conosciamo e amiamo è di solito chiamato "il modello di modulo." Questo linguaggio offre i vantaggi di variabili incapsulati che sono private al modulo e impartisce sanità mentale al nostro codice.

evento var = (function () {

    // variabili private
    ascoltatori var = [];
 
    funzione addEventListener (f) {
        listeners.push (f);
    }

    clearEventListeners function () {
        ascoltatori = [];
    }
   
    // ...
   
    // Esportare API del modulo
    ritorno {
        addEventListener: addEventListener,
        clearEventListeners: clearEventListeners
        // ...
    };
} ());
L'obiettivo di incapsulamento qui non è la sicurezza. E 'per garantire che altri sviluppatori mantenere i loro sporchi,-scimmia patching mani fuori dati del modulo.

L'esportazione può essere fatto un paio di modi, ma non importa in che modo vi è una certa piastra caldaia.

L'importazione è verbose anche

(Function () {

    // importazione desiderato proprietà del modulo di manifestazione
    var addEventListener = event.addEventListener;
    var clearEventListeners = event.clearEventListeners;
   
    // ...
} ());
Qualche nuova sintassi sarebbe bello per trasmettere l'intento del pattern modulo di meglio.

evento module {
   
    // variabili private
    ascoltatori var = [];
 
    funzione di esportazione addEventListener (f) {
        listeners.push (f);
    }

    clearEventListeners funzione di esportazione () {
        ascoltatori = [];
    }
   
    // ...
}
(Function () {

    evento import;
   
    // ...
} ());
Il modello modulo è quasi ovunque e qualche nuova sintassi per esprimere meglio questo idioma sarebbe meglio sintonizzare il linguaggio di tutte le nostre applicazioni.

Eredità

Questi esempi idioma sono cresciuti nel modo in cui ciascuna abbracciano un numero crescente di linee di codice. Il linguaggio JavaScript che si estende potenzialmente la maggior parte delle linee del vostro programma può essere il linguaggio eredità.

funzione Employee (primo, ultimo, posizione) {
    // Chiamare il costruttore della superclasse
    Person.call (questo, in primo luogo, l'ultima);
    this.position = posizione;
};
// Ereditare da persona
Employee.prototype = Object.create (Person.prototype);
Employee.prototype.constructor = Impiegato;

Metodo // definire un toString overridding ()
Employee.prototype.toString = function () {
    Metodo // toString ridefinito chiamare di superclasse ()
    ritorno Person.prototype.toString.call (questo) +
           'È un' + this.position;
};
Che casino. Si JavaScript rende l'ereditarietà singola come questo possibile prototipi collegano ma ci vuole un sacco di codice per fare manualmente le cose eccellenti che accadono così come si potrebbe eredità al lavoro.

Se ci potrebbe essere un incubo di manutenzione che è. Le stringhe "persona" e "dipendenti" sono distesi in tutto il codice per la "classe" Employee.

Se le classi con ereditarietà sono una grande parte della propria applicazione, una sintassi sarebbe davvero aiutare a ripulire il codice. Forse qualcosa di simile a quanto segue.

class Employee estende Person {
    constructor (primo, ultimo, posizione) {
        super (primo, ultimo);
        posizione pubblica = posizione;
    }

    update (fotocamera) {
        super.update ritorno () + 'è un' position +;
    }
}
Questo è un grande miglioramento.

Imparare dai Idiomi

Questi idiomi comuni rendono chiaro che JavaScript potrebbe usare qualche nuova sintassi per diverse ragioni. La capacità di fare ciò che vogliamo è solitamente in JavaScript da qualche parte. La verbosità degli idiomi è a volte troppo. Abbiamo tagliato angoli. A volte evitiamo certi algoritmi perché gli idiomi sono troppo prolisso. Gli idiomi non sono autoesplicativi. Sono segreti all'interno della comunità e l'intento non è facilmente riconoscibile da parte di estranei.

Il Comitato ECMAScript ha riconosciuto che gli idiomi di cui sopra, e altri idiomi, sono comuni in una vasta gamma di applicazioni. Ci sono proposte per tutti questi casi di sintassi in Harmony. Alcuni di loro possono farlo nella prossima versione di ECMAScript e nei browser per il vostro uso. Se nuova sintassi arriva alla fine, allora si può utilizzare usarlo.

Idiomi possono sono emerse nel vostro applicazione che non appaiono in una vasta gamma di applicazioni. Ad esempio, non-blocking I / O e la forte dipendenza di Node.js su callback indubbiamente comporterà idiomi che non appaiono negli script del browser. Sintassi specifica solo le applicazioni probabilmente mai farne ECMAScript.

Se si desidera utilizzare la sintassi specializzata per gli idiomi generali come quelle mostrate in precedenza o se volete la sintassi per i propri idiomi, cosa si può fare?

Se solo avessimo Macro

Lingue Lisp hanno avuto le macro in piena regola per decenni. Attraverso le macro, Lisp offre ai programmatori la possibilità di regolare la sintassi del linguaggio per soddisfare meglio le proprie applicazioni. A causa delle sue macro, Lisp è stato descritto come "il linguaggio di programmazione programmabile." Roba potente.

Di s-espressione sintassi Lisp, si sa, la sintassi con tutte quelle parentesi, dà il linguaggio una proprietà speciale chiamato homoiconicity. Significa circa la sintassi del linguaggio è anche la sintassi delle sue strutture di dati o che albero sintattico di un programma utilizza le strutture di formati di dati. Questo homoiconicity rende macro di Lisp possibile.

JavaScript non ha le macro. Una delle principali ragioni di ciò è che l'aggiunta di macro per linguaggi con C-come sintassi, le lingue che non sono homoiconic, è ancora un argomento di ricerca. Estratti da una breve conversazione su Twitter con littlecalculist, Dave Herman, Ph.D., ECMAScript membro del comitato, e Mozilla Ricercatore:

petermichaux
Credolittlecalculist sa di più sulla ricerca e le possibilità per le macro di ECMAScript. Mi piacerebbe sapere di più anche.
littlecalculist
Ho pensieri su di sicuro. Ma macro per le lingue non sexp è ancora molto un argomento di ricerca impegnativo
petermichaux
[...] Ci rivolgiamo blu in attesa per le macro.
littlecalculist
Potrei suggerire di mantenere la respirazione? ;-) Scherzi a parte, spero di provare, ma credetemi, la progettazione del sistema macro è difficile.
Il messaggio è abbastanza chiaro. Macro JavaScript non sono proprio dietro l'angolo.

Harmony Sintassi ETA

Forse le estensioni di sintassi in Harmony sono tutti sogni e altro ancora. Se Harmony diventa ECMAScript 6 e ECMAScript 6 diventa onnipresente allora sarete tutti insieme. Quindi tutto quello che dovete fare è aspettare ... pazienza.

In primo luogo, diamo un'occhiata a adozione del browser. Purtroppo io prendersela con Internet Explorer un po ', che è diventato quasi un cliché, ma non perché ho qualcosa contro il team di sviluppo di Internet Explorer di Microsoft o le versioni più recenti di Internet Explorer. E 'necessario guardare a questa del browser perché è forse il più importante studio caso per stimare quando funzioni saranno disponibili per tutti i visitatori del tuo sito web.

A partire da maggio 2011, w3schools , che ha visitatori relativamente tech-savvy, rapporti di Internet Explorer 6 ha ancora il 2,4% di quota di mercato. Net Market Share riporta Internet Explorer 6 ha ancora una quota di mercato pari al 10,36%. Il tuo sito probabilmente ha una quota di mercato da qualche parte tra questi due numeri, ma questo browser è ancora appeso anche se è stato sostituito da Internet Explorer 7 in novembre 2006. Quante persone stanno ancora utilizzando Internet Explorer 6 o 7? Il sito mostra W3Schools 7,7% e Net Market Share mostra 18,2%. Questi browser semplicemente non stanno andando via abbastanza velocemente. Un sito accessibile al pubblico (ad esempio Amazon) non può permettersi di ignorare i numeri di quote di mercato questo di grandi dimensioni.

Non vi è alcun senso spendere qualsiasi lamenti energia che gli utenti dovrebbero aggiornare i loro browser, o che "IE devono morire!" Non succederà. Non so se è vero, ma qualcuno una volta mi disse: "Gli utenti di Internet Explorer aggiornare il browser quando aggiornano il loro hardware." Negli ultimi anni, l'hardware è sicuramente diventato sufficiente che le persone non hanno bisogno di aggiornare nulla a utilizzare la posta elettronica, Facebook, Twitter, etc.

Supponiamo che il vostro web app è così avanzata che avete deciso che vi interessa soltanto gli utenti dotati di browser "moderni". Google Apps ha recentemente annunciato che il 1 Agosto 2011 si fermeranno a sostegno di Internet Explorer 7. Questo è quasi 5 anni dopo Internet Explorer 7 è stato rilasciato.

Ora pensate a questo: Internet Explorer 10 non è ancora uscito, ma, naturalmente, anche se non avrà le estensioni di sintassi di Harmony. Facciamo stimano che Harmony è approvato come ECMAScript 6 a metà del 2012 e Internet Explorer 11 è rilasciato nei primi mesi del 2013, con il supporto per tutte le sintassi di Harmony. Cinque anni dopo, nel 2018, il team di Google Apps può cadere il supporto per Internet Explorer 11 e, infine, utilizzare la sintassi Harmony liberamente. (Il 1 ° agosto 2011, sono anche abbandonare il supporto per quattro anni, Safari 3 e due anni, Firefox 3.5 in modo che le attese sono ancora a lungo ish per altri browser anche.)

Gli sviluppatori di Amazon potrebbe essere necessario attendere altri 5 anni prima di poter usare la sintassi Harmony. Questo è 2023!

Sarete soddisfatti attesa 7-12 anni prima di poter iniziare a utilizzare la sintassi che sarebbe utile sviluppare le vostre applicazioni web oggi? Essere più ottimisti, anche se l'attesa è a soli 5 anni, vuoi aspettare?

JavaScript è morto.

Causa della morte: cancro virgola.

Forse a causa della sintassi di JavaScript sola, JavaScript non ha le macro ora e non li hanno presto se mai. Milioni di programmatori usano JavaScript ora e molti di loro sono stanchi o faticoso degli idiomi verbose confrontano quotidianamente. Vogliono nuova sintassi ora e non aspettare. Per questo gruppo crescente di sviluppatori, il linguaggio Javascript codice sorgente è morto.

Hai avuto un buon regno, JavaScript. Abbiamo avuto alcuni buoni tempi e scritto alcune applicazioni cool insieme. Che tu possa riposare in pace.

Lunga JavaScript diretta!

I programmatori piace di controllare il proprio destino e che stanno prendendo provvedimenti. Si possono avere tutte la nuova sintassi che si desidera per gli script del browser, in questo momento, se si scrive in un'altra lingua di origine e compila il ECMAScript 3 dialetto JavaScript per i miliardi di browser in natura. Compilando per ECMAScript 3 si sono completamente liberati dalla evoluzione sintattica di JavaScript. Come bonus aggiuntivo, si può anche risolvere alcuni dei trucchi semantici di JavaScript con un compilatore sufficientemente sofisticato. Nuova vita di JavaScript è un obiettivo compilation.

Lingue compilare in JavaScript

Ci sono stati i compilatori di JavaScript per anni. Nel 2007, ho cominciato a raccogliere un elenco di lingue con i compilatori a JavaScript. C'erano lingue estensione JavaScript: la ormai defunta ECMAScript 4, Narrative JavaScript, e Objective-J. C'erano preesistenti lingue: regime, Common Lisp, Smalltalk, Ruby, Python, Java, C #, Haskell, ecc Ci sono stati anche nuovi linguaggi di zecca haXe, Milescript, Links, Flapjax che sono stati progettati per soddisfare le esigenze di programmazione web.

Di questi progetti compilatore, il compilatore GWT di Google Java-to-JavaScript è stato probabilmente il più riuscito, ma non vedo i programmatori che per primo ha imparato una lingua diversa Java correre da usare Java come linguaggio di codice sorgente. In realtà, nessuno di questi progetti compilatore hanno maturato una significativa base di utenti a lungo termine. Almeno nelle parti del web che frequenti, con l'eccezione di GWT, è raro leggere di programmatori che utilizzano questi compilatori per i progetti reali. Ci sono diversi motivi legittimi per non utilizzare uno di questi compilatori.

Immaginate di costruire un grande progetto utilizzando uno di questi compilatori e parte attraverso trovare un bug nel compilatore. Quello manutentore del compilatore può avere interesse o tempo perduto. Vuoi mantenere un compilatore? Qualcuno della tua squadra ha le competenze per farlo? Che ulcera sta per arrivare abbastanza grande mentre vi preparate a spiegare al CEO che è ora necessario riscrivere l'interfaccia utente in JavaScript.

Solo il pensiero di debug del codice compilato quando un bug di produzione è archiviato mi fa rivoltare lo stomaco. Core dump. Quale linea numero nel codice sorgente corrisponde al numero di riga Firebug riporta per il codice compilato? AFFRETTATI! Questo bug deve essere risolto ora !!!!

Hai usato Objective-J per un grande progetto e ora è necessario assumere un nuovo buon programmatore. Quali sono le possibilità di trovare la persona giusta? Probabilmente sono molto bassi. Basta trovare un programmatore JavaScript disponibile è abbastanza difficile. Se si utilizza una di queste lingue alternative, è molto probabile che avrete bisogno di addestrare ogni nuova persona che si aggiunge al tuo team.

Anche senza questi progetti compilatore essere di grande successo, la lista delle lingue che compila a JavaScript ha continuato a crescere. Non vi è dubbio che scrivere un compilatore a JavaScript è un progetto molto cool. Vi prego di pagare di scrivere uno.

C'è una new entry notevole nella lista delle lingue che compilano a JavaScript che è in realtà causando un grande scalpore e sta forse cambiando il gioco per buona.

CoffeeScript

Vi posso dire in questo momento, non so perché CoffeeScript ha la magica combinazione di caratteristiche per raccogliere l'attenzione che ha quando altri progetti hanno fallito. Spazi significativi e sintassi della funzione freccia. La mia reazione istintiva è che schifo. C'è un sacco di cose per piacere: i valori dei parametri di default, i parametri di riposo, la diffusione, destrutturazione, che fissa tutto il casino globale implicito, anche le classi se siete in questo genere di cose e di più. Molte delle caratteristiche del CoffeeScript sono parte di Harmony e così potrebbe essere nei browser in futuro, ma se si utilizza CoffeeScript allora si può avere adesso. Non c'è nulla come una gratificazione immediata.

I programmatori sono pieni di affetto per CoffeeScript.

pyronicide
Essere in grado di utilizzare i valori di default per gli argomenti delle funzioni in #coffeescript mi ​​rende immensamente felice.
_jdpage
CoffeeScript è meraviglioso. Ora sono viziati e lamenterò ogni volta che devo scrivere JavaScript invece.
Alla conferenza TXJS 2011, Douglas Crockford apparentemente condiviso che pensa "CoffeeScript è chiaramente roba buona."

C'è un aspetto del progetto CoffeeScript che mi piace molto ed è riassunta dalle seguenti due citazioni. Il primo viene da Trevor Burnham, autore di CoffeeScript: Accelerated Development JavaScript .

trevorburnham
[...] Non si tratta di trasformare in JS Rubino / Python; si tratta di avere una sintassi più adatto alla bontà interiore di JavaScript.
Il secondo è da The Little Book on CoffeeScript .

CoffeeScript evita accuratamente queste [questioni JavaScript], solo esponendo una selezione curata di funzioni JavaScript.

L'atteggiamento espresso in queste citazioni è davvero grande e genio del marketing troppo. Non è CoffeeScript versi JavaScript. È CoffeeScript migliorare l'esperienza di programmazione JavaScript. Potrebbe un po 'diverso di sintassi e un sottoinsieme limitato di funzioni di JavaScript davvero essere migliore di Plain Old JavaScript?

Douglas Crockford sembra pensare così. Per anni, il suo JSLint è stato male i nostri sentimenti ed esigente che usiamo gli spazi e la sintassi molto specifico e che evitiamo funzioni JavaScript pericolosi. Il codice sorgente che passa JSLint ha accesso a un vero e proprio sottoinsieme di JavaScript: ". Le parti buone" il sottoinsieme che chiama Questo dialetto di JavaScript merita un nome. Forse GoodScript? Dopo tutto, è consentito utilizzare solo JSLint per il bene e non per il male.

Il Comitato ECMAScript pensa anche questa è una buona idea. Il "use strict" pragma introdotto in ECMAScript 5 non limita solo alcune caratteristiche del linguaggio, come con , anche in modalità rigorosa modifiche / fissa la semantica di alcune parti del linguaggio. A causa dei cambiamenti semantici, ECMAScript 5 rigorosa è una lingua diversa o almeno un dialetto diverso ECMAScript 5 non rigida.

CoffeeScript, GoodScript, e ECMAScript 5 rigoroso condividere obiettivi comuni di tenere lontano dalle parti pericolose JavaScript dando accesso alle parti, sicuro valore. Ognuno fa rispettare questi obiettivi in ​​modo diverso, ma la loro applicazione in un modo o nell'altro. Non si ottiene nuova sintassi con GoodScript. È già JavaScript e pronto per il browser. Non si arriva a usare ECMAScript 5 rigorosa perché non è disponibile in tutti i browser ancora e non sarà per anni.

Così CoffeeScript sembra mira un bisogno particolare di sviluppo web e forse è qualcosa di diverso da JavaScript compilatori non hanno fatto o non hanno fatto molto prima.

CoffeeScript è anche una pelle abbastanza sottile su JavaScript. Una conseguenza di questo è che il codice JavaScript compilato è ragionevolmente facile da leggere e non brutale di debug (così mi hanno detto.) Questa debug paura ridotta contribuisce agli interessi in CoffeeScript.

CoffeeScript sente quasi come un insieme di macro per la scrittura di programmi JavaScript.

Dal momento che i compilatori CoffeeScript sono nelle mani degli sviluppatori, piuttosto che i visitatori ai siti, di controllare la versione di CoffeeScript in uso. È possibile aggiornare a volontà. Questo significa anche CoffeeScript non ha bisogno di essere standardizzati e passare attraverso la successiva dolorosamente lenta crescita di un linguaggio standardizzato. CoffeeScript può crescere al ritmo dell'immaginazione di sua comunità e il desiderio. JavaScript standardizzazione è stato essenziale per il successo del web, ma gli stessi vincoli non si applicano a CoffeeScript.

Bene, allora ho