Heim > Web-Frontend > js-Tutorial > Der Tod und das Leben von JavaScript

Der Tod und das Leben von JavaScript

高洛峰
Freigeben: 2016-11-25 11:32:25
Original
1097 Leute haben es durchsucht

Der Erfolg von JavaScript beruht darauf, dass man zur richtigen Zeit am richtigen Ort ist. Der Aufstieg von JavaScript hängt eng mit der Browserunterstützung zusammen. Sie sehen, VBScript hat nicht so viel Glück.

JavaScript ist beliebt, weist jedoch inhärente Mängel auf. Brendan Eich hat JavaScript in nur 10 Tagen entworfen. Als Vater von JavaScript sagte Brendan Eich:

Es ist besser zu sagen, dass ich JavaScript hasse, als dass ich es liebe. Es ist das Produkt eines One-Night-Stands zwischen C-Sprache und Selbstsprache. Dr. Johnson, ein britischer Literat im 18. Jahrhundert, brachte es auf den Punkt: „Seine Exzellenz liegt nicht in seiner Originalität; seine Originalität ist nicht herausragend.“
Der offensichtlichste Mangel von JavaScript ist seine Grammatik.

Schlechte und ausführliche Syntax für optionale Parameter und Standardwerte

function(a, b, option) {
optionoption = option || {};
}
Im obigen Code ist Option ein optionaler Parameter. Wenn er nicht übergeben wird, ist der Standardwert {}. Der übergebene Optionswert kann jedoch ein falscher Wert sein. Streng genommen muss folgendes Urteil gefällt werden:

function(a, b, option) {

option = arguments.length > 2 ?
}
Hinweis: option = typeof option !== undefiniert ? option :{} kann auch falsch sein, da das, was übergeben wird, möglicherweise undefiniert ist. Wenn der b-Parameter nach dem Löschen nicht erforderlich ist, kann die auf arguments.length basierende Beurteilung leicht dazu führen, dass vergessen wird, ihn zu ändern, und ein Fehler gemacht wird:

function(a, option) {

option = arguments .length > 2 ? Option: {}; option = {}) {

/ / ... 
}
Let
Verschlüsse sind mächtig und nervig:

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

Der obige Code erscheint häufig in Interviewfragen. Die Lösung besteht darin, ihn in eine andere Ebene zu packen:


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);
});

}(i));

}
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?

Solange es Makros gibt (Makro)

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.

Solange es Makros gibt, können wir die Syntax anpassen. Da die Makrofunktion von JavaScript jedoch weit entfernt ist, sollten wir andere Wege finden.

Harmony

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)

Wir können uns nicht auf Aufrufe wie „IE sei verdammt“ verlassen, um Benutzer zum Upgrade zu bewegen. Ich habe ein Sprichwort gehört: IE-Benutzer aktualisieren ihren Browser nur, wenn sie ihre Computerhardware ändern. Leider reicht für normale Benutzer die vorhandene Hardware aus, um E-Mails zu empfangen und auf Facebook und Twitter zuzugreifen. Es gibt für sie keinen Grund, Geld auszugeben.

Goggle Apps hat kürzlich angekündigt, dass es ab August 2011 die Unterstützung von IE7 einstellen wird.

Nach verschiedenen konservativen Schätzungen müssen Amazon-Website-Entwickler warten, bis sie die Harmony-Syntaxerweiterung 2023 verwenden!

Sie befinden sich in Ihrer Blütezeit. Sind Sie bereit, mehr als 10 Jahre zu warten, bevor Sie diese nützlichen Grammatiken verwenden können?

JavaScript ist tot

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!

Herr JavaScript, Sie hatten eine glorreiche Herrschaft. Wir hatten schöne Erinnerungen mit Ihnen und haben gemeinsam viele interessante Anwendungen produziert. Möge der Verstorbene in Frieden ruhen.

JavaScript wird bleiben

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.

Sprachen, die in JavaScript kompiliert werden können

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. .

Es gibt auch einige brandneue Sprachen: HaXe, Milescript, Links, Flapjax, die speziell für die Webprogrammierung entwickelt wurden.

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.

2. Das Debuggen ist mühsam. Firebug hat einen Fehler gemeldet und die kompilierte Zeilennummer gemeldet. Der Chef steht hinter dir: Beeil dich, junger Mann! Aber welcher Quellcodezeile entspricht dieser verdammte kompilierte Code?

3. Es können keine Leute rekrutiert werden. Angenommen, Sie entwickeln ein Projekt mit Objective-J, haben aber nicht genügend Leute. Beeilen Sie sich und rekrutieren Sie Leute. Die Personalabteilung sagte, dass von 1.000 Leuten nur 100 von Objective-J gehört haben und die anderen 900 nur von JavaScript. Das Endergebnis ist, dass Sie jedes Mal, wenn Sie eine neue Person finden, sie schulen müssen Erstens, was wirklich schrecklich ist.

Obwohl Compiler die oben genannten Nachteile haben, tauchen immer noch verschiedene Compiler in großer Zahl auf. Es besteht kein Zweifel, dass das Schreiben eines JavaScript-Compilers ziemlich cool ist. Bezahlen Sie mich und ich möchte auch eines schreiben.

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.

Offensichtlich ist die JavaScript-Funktion kein Lambda:

function one() {

return 1;

one(); // 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;
} ());
}

one(); // 1 Der Strawman-Vorschlag für den

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

JavaScripts Monopol auf Browser bedeutet, dass Front-End-Programmierer alle dieselbe Sprache sprechen. Aufgrund der Unterschiede bei den Compilern wird es für CoffeeScript-Programmierer jedoch schwierig sein, Traceur-basierten JavaScript-Code sofort zu verstehen.


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.

Verwandte Etiketten:
Quelle:php.cn
Erklärung dieser Website
Der Inhalt dieses Artikels wird freiwillig von Internetnutzern beigesteuert und das Urheberrecht liegt beim ursprünglichen Autor. Diese Website übernimmt keine entsprechende rechtliche Verantwortung. Wenn Sie Inhalte finden, bei denen der Verdacht eines Plagiats oder einer Rechtsverletzung besteht, wenden Sie sich bitte an admin@php.cn
Beliebte Tutorials
Mehr>
Neueste Downloads
Mehr>
Web-Effekte
Quellcode der Website
Website-Materialien
Frontend-Vorlage