Der Tod und das Leben von JavaScript

for (var i=0, ilen=elements.length; i var element = elements[i];
(function(num) {
LIB_addEventListener(element, click, function(event) {
warning(I was original number + num);
});

}
Es wäre toll, wenn die let-Syntax direkt unterstützt würde:

for (var i=0, ilen=elements. length; i var element = elements[i];
let (num = i) {
LIB_addEventListener(element, function(event) {
warning(Ich war ursprünglich number + num);
} ;

// private Variablen
var listeners = [];

export function addEventListener(f) {
listeners.push(f );
}

export function clearEventListeners() {
listeners = []
}

// ...

(function() {

import event;

// ...
}());
Vererbung
JavaScript muss die Vererbung über die Prototypenkette implementieren :

function Employee(first , last, position) {
// rufe den Superklassenkonstruktor auf
Person.call(this, first, last); 🎜>};
// erben von Person
Employee.prototype = Object.create(Person.prototype);
EmployeeEmployee.prototype.constructor = Employee;

// Definieren Sie eine Überschreibung toString()-Methode
Employee.prototype. toString = function() {
// überschriebene Superklassen toString()-Methode
return Person.prototype.toString.call(this) +
ist ein + this.position;
}; Es wäre toll, wenn es wie folgt geschrieben werden könnte:

class Employee erweitert Person {
Konstruktor(erster, letzter, Position) {
super(erster, letzter);
öffentliche Position = Position;
Update( camera) {
return super.update() + is a + position; }
}
Impression
Das ECMAScript-Komitee hat festgestellt, dass JavaScript Mängel auf grammatikalischer Ebene aufweist. In der Harmony-Spezifikation wurden alle oben genannten Syntaxen vorgeschlagen.

Wann können wir die obige Syntax verwenden?

Die Makrofunktion der Lisp-Sprache ist sehr leistungsfähig. Mit Makros können Sie das gewünschte Syntaxformat nach Ihren Wünschen definieren. Die Makrofunktion macht Lisp zu einer „programmierbaren Programmiersprache“.

JavaScript hat keine Makros. Das Hinzufügen von Makrofunktionen zu C-ähnlichen Sprachen ist immer noch ein Forschungsthema und sehr schwierig.

Die Syntaxerweiterung in der Harmony-Spezifikation könnte der Traum von uns allen sein. Harmony hat das Potenzial, eine ECMAScript 6-Spezifikation zu werden. Bis dahin heißt es abwarten und geduldig sein.

Stand Mai 2011 zeigt w3school, dass der Marktanteil von IE6 immer noch 2,4 % beträgt. Der Nettomarktanteil zeigt, dass IE6 einen Marktanteil von 10,36 % hat. Auch IE7 hat große Marktanteile. Diese alten Browser werden kurzfristig nicht vom Markt verschwinden. Für kommerzielle Unternehmen wie Amazon ist es unmöglich, diese Benutzer aufzugeben. Schreckliche Situation. (Festlandchina ist sogar noch schlimmer, IE6/7 macht immer noch mehr als 40 % des Marktanteils aus)

Todesursache: Semikolonkrebs. (Semikolon-Krebs. Der Witz des Autors, was bedeutet, dass die Syntax den Tod von JavaScript verursacht)

Aus der obigen Analyse ist ersichtlich, dass die Implementierung von Makrofunktionen zu schwierig und die Implementierung von Harmony-Spezifikationen weit entfernt ist weg. Viele Programmierer haben begonnen, JavaScript zu schreiben, und viele von ihnen sind der langen und schlechten Syntax von JavaScript überdrüssig oder werden langsam müde. Wir brauchen eine neue Syntax und wollen nicht warten! JavaScript als Quellcode-Schreibsprache ist tot!

Programmierer bestimmen gerne ihr eigenes Schicksal. Als Sprache zum Schreiben von Quellcode ist JavaScript tot. Wir können eine andere bessere Quellcodesprache auswählen oder erstellen und diese in das ECMAScript 3-Syntaxformat kompilieren.

Das neue Leben von JavaScript ist als Kompilierungsziel.

Es gibt viele Sprachen, die in JavaScript kompiliert werden können. 1997 habe ich eine Liste zusammengestellt. Beinhaltet:

JavaScript-Erweiterungssprachen: totes ECMAScript 4, Narrative Script, Objective-J.
Vorhandene Sprachen: Scheme, Common Lisp, Smalltalk, Ruby, Python, Java, C#, Haskell usw. .

Unter diesen Compilerprojekten ist Goggles GWT Java-to-JavaScript-Compiler wahrscheinlich das erfolgreichste. Die Tragödie ist jedoch, dass GWT in realen Projekten selten vorkommt. Die Gründe sind wie folgt:

1. Die Wartungskosten sind hoch. Angenommen, Sie finden einen Fehler im Compiler in einem großen Projekt. Als Betreuer müssen Sie zusätzlich zur Wartung des Quellcodes auch den Compiler warten. Oh mein Gott, hast du das Zeug dazu? Selbst wenn Sie über diese Fähigkeit verfügen, ist der CEO nicht bereit, dieses Geld auszugeben.

In der obigen Liste der Compiler gibt es einen sehr berühmten, der für viel Aufsehen gesorgt hat: CoffeeScript. Lass uns darüber reden.
CoffeeScript
Warum ist CoffeeScript so beliebt? Ich habe es bis jetzt noch nicht herausgefunden. Liegt es an der Bedeutung, die Leerzeichen gegeben wird, oder an der Funktionssyntax mit Pfeilen? Jedes Mal, wenn ich darüber nachdenke, wird mein Magen unruhig. CoffeeScript verfügt über viele neue Funktionen: Standardparameterwerte, Restparameter, Ausbreitung, Destrukturierung, Behebung des gesamten implizierten globalen Chaos ... Viele Funktionen von CoffeeScript sind Teil der Harmony-Spezifikation und werden möglicherweise in zukünftigen Browsern direkt unterstützt. CoffeeScript sorgt für sofortige Befriedigung.

@pyronicide sagte auf Twitter: #coffeescript unterstützt Funktionsstandardparameterwerte, was so aufregend ist.
Auf der TXJS 2011-Konferenz sagte Douglas Crockford auch: CoffeeScript ist zweifellos eine gute Sache.

Der Autor des Buches CoffeeScript: Accelerated JavaScript Development sagte:

@trevorburnham
[...] CoffeeScript wandelt JS nicht in Ruby oder Python um, sondern durch eine Reihe von Syntax . Um die inhärente Exzellenz von JavaScript besser zu nutzen.

Douglas Crockford glaubt, dass JavaScript gute Aspekte hat und hat das JSLint-Tool entwickelt, um sicherzustellen, dass Entwickler die schlechten Aspekte von JavaScript meiden. Die von JSLint erlaubte Teilmenge der Syntax verdient einen eigenen Namen, wir könnten sie genauso gut GoodScript nennen.

ECMAScript 5 führte die „use strict“-Direktive ein, um die Verwendung von Syntax wie z. B. with einzuschränken.

CoffeeScript, GoodScript und ECMAScript 5 haben das gleiche Ziel: sich vom Mist fernzuhalten und Ihnen gleichzeitig nützliche, sichere Sprachfunktionen bereitzustellen.

GoodScript bietet keine neuen Funktionen. Die meisten Browser unterstützen den strikten Modus von ECMAScript 5 noch nicht. Wir wollen jedoch nicht warten.

Die verbleibende Option ist CoffeeScript. Vorteile:

Besonders geeignet für die Webentwicklung. Dies kann etwas sein, was andere JavaScript-Compiler nicht oder nicht gut können.
CoffeeScript kapselt JavaScript entsprechend. Dadurch ist der kompilierte Code leichter lesbar und das Debuggen weniger schwierig.
CoffeeScript sieht aus wie eine Reihe von Makros zum Schreiben von JavaScript-Code.

Der Compiler von CoffeeScript stellt eine Client-Version bereit. Auf diese Weise können Anwender frei wählen und Entwickler können schnell neue Funktionen entwickeln, ohne durch Standards eingeschränkt zu sein. Es ist schön, dass CoffeeScript von der Vision und den Bedürfnissen der Community angetrieben wird.

Erfinden Sie Ihre eigene Sprache
Sie können es schaffen, es wird eine gute Übung sein. Als Entwickler von JavaScript-Compilern wird Ihnen eine große Ehre zuteil.

Die Gefahr, eine eigene Sprache zu erfinden, besteht darin, dass man glaubt, sie irgendwann besser zu können als JavaScript. Sprachdesign ist schwierig, und ich wette, Ihre Sprache wird es schwer haben, Marktanteile zu gewinnen. CoffeeScript ist noch nicht in der Pubertät und es gibt bereits Beschwerden.

Sie können stolz darauf sein, dass Ihr Compiler einfachen, lesbaren Code kompilieren kann. Wenn Sie jedoch auf besondere Umstände stoßen, werden Sie so deprimiert sein, dass Sie am liebsten gegen die Wand gefahren wären.

Redewendungen werden in Ihrer Sprache angezeigt. Dann werden Sie bald jemanden finden, der diese Redewendungen bricht (es sei denn, Ihre Sprache unterstützt zufällig Makros).

Keine sarkastischen Bemerkungen mehr. Entwickeln Sie jetzt Ihre eigene Sprache und Sie werden ein sehr guter Programmierer.

Was fehlt JavaScript als Kompilierungszielsprache?
Als Kompilierungszielsprache erhält JavaScript neues Leben. Im Vortrag von JSConf.US sagte Brendan Eich: Der Zweck der Harmony-Spezifikation besteht darin, JavaScript zu einem besseren Kompilierungsziel zu machen.

Kompiliertes JavaScript läuft möglicherweise weniger effizient als handgeschriebenes JavaScript, genauso wie kompiliertes C möglicherweise weniger effizient läuft als handgeschriebene Assemblersprache. Glücklicherweise liegt der Flaschenhals von JavaScript hauptsächlich bei DOM-Operationen, und der Effizienzverlust der Sprache selbst ist relativ akzeptabel. Obwohl dies gesagt wird, können einige effiziente Quellcodesprachen aufgrund von Problemen mit JavaScript selbst nach der Kompilierung äußerst ineffizient sein, sodass sie nicht in realen Umgebungen verwendet werden können. Die Harmony-Spezifikation enthält bereits einige Funktionen, die sicherstellen, dass solche Probleme vermieden werden.

Angemessener Tail Call
function isEven(number) {
if (number === 0) {
return true;
else {
return isOdd (Zahl - 1);
}
}

Funktion isOdd(Zahl) {
if (Zahl === 0) {
return false; > else {
return isEven(number - 1);
}
}

isEven(100000); // InternalError: too much recursion
Der obige Code wird derzeit ausgeführt In einem Browser kommt es zu einem Stapelüberlauf.

Kann mit Trampolintechnik optimiert werden:

function bounce(ret) {
while (typeof ret === function) {
retret = ret();
}
return ret; >function isEven(number) {
if (number === 0) {
return true;
}
else {
return function() {
return isOdd(number - 1);
};
}

function isOdd(number) {
if (number === 0) {
return false;
else {
return function() {
return isEven(number - 1);
}
}

bounce(function() {return isEven(100000);}); // true
Wenn isOdd(99999) ausgeführt wird, wurde isEven(100000) abgeschlossen und vom Stapel verlassen, sodass es nicht zu einem Überlauf kommt.

Glücklicherweise hat ECMAScript Harmony dies berücksichtigt und wird es automatisch optimieren. Dies ist sowohl für Programmentwickler als auch für Compiler-Entwickler von Vorteil.

Lambdas
Lambdas sind nicht magisch. Kurz gesagt, Lambda ist etwas, das aufgerufen werden kann, beispielsweise eine Funktion, muss jedoch TCP (Tennents Korrespondenzprinzip) entsprechen. TCP-Anforderung: Das Kapseln eines Ausdrucks oder Codeblocks mit einem angrenzenden Lambda ändert nichts an der Bedeutung des gekapselten Codes.

return 1;

Nach der Kapselung hat sich der Rückgabewert geändert:

function one() {
(function() {
return 1;
}());
one(); // undefiniert
Für einen Codeblock, der zwei Parameter akzeptiert und diese summiert, wird der Lambda-Syntaxvorschlag wie folgt geschrieben: {|a, b|

Im obigen Beispiel stellt die Verwendung der Lambda-Verpackung sicher, dass der Rückgabewert derselbe ist wie vor der Verpackung:

function one() {
({||
return 1;
} ());
}

Lambda-Block wurde noch nicht zur Harmony-Spezifikation hochgestuft, lasst uns zusammenarbeiten.

Was fehlt dem Browser?
Der Aufstieg und Fall von JavaScript lässt sich nicht vom Browser trennen. Das neue Leben von JavaScript erfordert auch eine zuverlässige Unterstützung durch Browser.

Mozilla hat ein SourceMap-Projekt gestartet, das es ermöglicht, beim Debuggen von kompiliertem Code die entsprechenden Codezeilen wieder dem Quellcode zuzuordnen. Das ist so cool und kann die Debugging-Kosten erheblich reduzieren.

Ich habe gehört, dass die Jungs von Webkit das Gleiche tun, aber leider kann ich keine Beweise dafür finden.

Mit mehreren Sprachen vertraut

Diese Meinungsverschiedenheit ist unvermeidlich. Es gibt zum Beispiel C, aber auch verschiedene Sprachen wie C++ und Objective-C. Das Gleiche gilt für Java. Sie können auch Clojure oder JRuby basierend auf JVM wählen. Microsoft ist sich dessen bewusst und hat C#, Basic, IronPython usw. entwickelt, die alle auf CLR laufen können.

Kommunikationsbarrieren im Frontend sind nicht neu. Für einen Dojo-Programmierer ist es schwierig, auf jQuery oder YUI basierenden Code sofort zu verstehen.

Die Verwendung mehrerer Quellcode-Schreibsprachen wird die Kommunikationsbarrieren in der Community erhöhen. Programmierer müssen noch JavaScript beherrschen, zumindest für eine Weile. Aber in nur wenigen Jahren beherrschen sie möglicherweise andere Ausgangssprachen besser.

Zusammenfassung
Es ist großartig, die Gelegenheit zu haben, Zeuge des neuen Lebens von JavaScript zu werden. Im Wettbewerb um die JavaScript-Kompilierung ist es schwer zu sagen, wer letztendlich Marktanteile gewinnen wird, aber es besteht kein Zweifel, dass es interessant sein wird. Heute steht CoffeeScript kurz vor dem Durchbruch, aber ich bin mir sicher, dass viele andere erfolgreiche Quellcodesprachen folgen werden.