JavaScript の死と生

JavaScript の成功は、適切なタイミングで適切な場所にいることによってもたらされます。 JavaScript の台頭はブラウザのサポートと密接に関係しています。ご存知のとおり、VBScript はそれほど幸運ではありません。

JavaScript は人気がありますが、本質的な欠陥があります。ブレンダン・アイヒはわずか 10 日間で JavaScript を設計しました JavaScript の父として、ブレンダン・アイヒは次のように言いました。これは、C 言語と Self 言語の一夜限りの関係の産物です。 18 世紀の英国の文学者であるジョンソン博士は、「JavaScript の優秀さは独創性ではありません。JavaScript の独創性は優秀さではありません。」

JavaScript の最も明白な欠点はその文法です。

オプションのパラメータとデフォルト値の貧弱で冗長な構文

function(a, b, option) {

optionoption = option ||

// ...
}
上記のコードでは、option はオプションのパラメータです渡されない場合、デフォルト値は {} ですが、渡されるオプション値は false 値 (偽値) である可能性があります。厳密に記述すると、次の判断が必要です:

function(a, b, option) {

option = argument.length > 2 ? option : {};

// ...
}
注: option = typeof渡される内容が未定義である可能性があるため、option ! == unknown ? option :{} も間違っている可能性があります。 b パラメータが不要で削除されている場合、arguments.length に基づいて判断すると、変更を忘れてエラーが発生しやすくなります。 option : {};
// ...
}

次の構文を追加できれば素晴らしいでしょう:

function(a, b, option = {}) {
// ...
}
Let

クロージャは強力で迷惑です:

for (var i=0, ilen=elements.length; i var element = elements[i];
LIB_addEventListener(element, click, function(event) {
alert(元々はnumber + i);

});

上記のコードは、面接の質問によく出てきます:

for (var i=0, ilen=elements. length; i var element = elements[i];
(function(num) {
LIB_addEventListener(element, click, function(event)) {
alert(元々はnumber + num);

} );

}(i)) ;
}
let 構文が直接サポートされていれば素晴らしいでしょう:

for (var i=0, ilen=elements.length; i var element = elements [i];
let (num = i) {
LIB_addEventListener(element, function(event) {
alert(元々はnumber + num);

});

};
}
Module
モジュールモードは無力です選択肢:

ネイティブにサポートされている場合 どれだけ素晴らしいか:

module event {

// プライベート変数

var listens = [];

export function addEventListener(f) {

listeners.push(f) }

エクスポート関数clearEventListeners() {
リスナー = [];

// ...
}

(function() {

インポートイベント;

// ...
}());継承
JavaScript はプロトタイプ チェーンを経由する必要があります 継承を実装するには:

function Employee(first, last,position) {
// スーパークラス コンストラクターを呼び出します
person.call(this, first, last)
this.position = Position ;
};
// Person
Employee.prototype = Object.create(Person.prototype);
Employee.prototype.constructor = Employee から継承します。// オーバーライドする toString() メソッドを定義します。 = function() {

// オーバーライドされたスーパークラスを呼び出します toString() メソッド

return Person.prototype.toString.call(this) +
is a + this.position
}; のように記述できれば素晴らしいでしょう。これ:

class Employee extends Person {
constructor(first, last,position) {
super(first, last)
}

update(camera) {
return super.update() + は + です
}
}
啓蒙
ECMAScript 委員会は、JavaScript には文法レベルで欠点があることに気づきました。 Harmony 仕様では、上記の構文はすべて提案されています。

上記の構文はいつ使用できますか?

マクロ(Macro)がある限り

Lisp言語のマクロ機能は非常に強力です。マクロを使用すると、独自の設定に従って目的の構文形式を定義できます。マクロ機能により、Lisp は「プログラム可能なプログラミング言語」になります。

JavaScript にはマクロがありません。 C 系言語にマクロ機能を追加することはまだ研究課題であり、非常に困難です。

マクロがある限り、構文をカスタマイズできます。しかし、JavaScript のマクロ機能はまだ遠いので、他の方法を見つける必要があります。

Harmony

Harmony 仕様の構文拡張は、私たち全員の夢かもしれません。 Harmony は ECMAScript 6 仕様になる可能性があります。それまでは、辛抱強く待つ必要があります。

2011 年 5 月の時点で、w3school によると、IE6 の市場シェアはまだ 2.4% です。 Net Market Share は、IE6 が 10.36% の市場シェアを持っていることを示しています。 IE7 も多くの市場シェアを持っています。 Amazon などの営利企業にとって、これらの古いブラウザが短期間に市場から消えることはありません。ひどい状況。 (中国本土はさらに悪化しており、IE6/7 は依然として市場シェアの 40% 以上を占めています)

ユーザーにアップグレードを促すために、「IE はクソだ」のような呼びかけに頼ることはできません。 「IE ユーザーは、コンピュータのハードウェアを変更するときにのみブラウザをアップグレードする」という格言を聞いたことがあります。残念なことに、一般のユーザーにとって、電子メールを受信したり、Facebook や Twitter にアクセスしたりするには、既存のハードウェアで十分です。彼らがお金を使う理由はありません。

Goggle Apps は最近、2011 年 8 月から IE7 のサポートを終了すると発表しました。

さまざまな保守的な見積もりによると、Amazon ウェブサイト開発者が Harmony 構文拡張機能を使用するには 2023 年まで待たなければなりません。

働き盛りのあなたは、これらの便利な文法を使用するまで 10 年以上待つつもりですか?

JavaScript は死んだ

死因: 半結腸癌。 (セミコロンガン。文法がJavaScriptを死なせるという意味の作者のジョーク)

上記の分析を通じて、マクロ機能の実装が難しすぎて、Harmony仕様の実装が遠いことがわかります。多くのプログラマーが JavaScript を書き始めていますが、その多くは JavaScript の長くて不適切な構文にうんざりしているか、うんざりし始めています。新しい構文が必要ですが、待ちたくないのです。ソースコード記述言語としての JavaScript は終わりました。

JavaScriptさん、あなたは輝かしい統治をしていました。私たちはあなたと楽しい思い出を作り、一緒に多くの興味深いアプリケーションを作成してきました。亡くなった方のご冥福をお祈りします。

JavaScript は今後も存続します

プログラマーは自分自身の運命をコントロールしたいと考えています。ソースコード記述言語としての JavaScript は終わりました。別のより優れたソース コード言語を選択または作成し、それを ECMAScript 3 構文形式にコンパイルすることができます。

JavaScript の新しい命はコンパイルのターゲットです。

JavaScript にコンパイルされる言語

JavaScript にコンパイルできる言語は数多くあります。 1997年に私はリストを集めました。含まれるもの:

JavaScript 拡張言語: 廃止された ECMAScript 4、Narrative Script、Objective-J

既存の言語: Scheme、Common Lisp、Smalltalk、Ruby、Python、Java、C#、Haskell など。
Web プログラミング用に特別に設計された、HaXe、Milescript、Links、Flapjax などの新しい言語もいくつかあります。
これらのコンパイラー プロジェクトの中で、おそらく最も成功しているのは、Goggle の GWT Java-to-JavaScript コンパイラーです。ただし、悲劇的なのは、実際のプロジェクトでは GWT がほとんど見られないことです。理由は以下の通りです:

1. メンテナンスコストが高い。コンパイラにバグがある可能性があります。大規模なプロジェクトでコンパイラにバグを発見したとします。メンテナは、ソース コードを保守するだけでなく、コンパイラも保守する必要があります。ああ、なんてことだ、必要なものは持っていますか？たとえあなたにそのような能力があったとしても、CEO はそのお金を使いたがりません。

2. デバッグが面倒。 Firebug はエラーを報告し、コンパイルされた行番号を報告しました。ボスがあなたの後ろに立っている: 急いでください、若者!しかし、このクソコンパイルされたコードはソースコードのどの行に対応するのでしょうか?

3. 人材を採用できない。 Objective-J を使用してプロジェクトを開発しているが、十分な人材がいないとします。急いで人材を採用してください。人事担当者によると、1,000 人中 Objective-J について聞いたことがあるのは 100 人だけで、残りの 900 人は JavaScript についてしか聞いたことがないということです。その結果、新しい人材を見つけるたびにトレーニングする必要があります。まず、これは本当にひどいことです。

コンパイラーには上記の欠点がありますが、依然としてさまざまなコンパイラーが多数登場しています。 JavaScript コンパイラを作成するのが非常に素晴らしいことであることは疑いの余地がありません。お金を払って、私も書きたいと思います。

上記のコンパイラーのリストには、多くのセンセーションを引き起こした非常に有名なコンパイラーがあります。それは、CoffeeScript です。では、それについて話しましょう。
CoffeeScript
CoffeeScript はなぜ人気があるのですか?今までそれが分かりませんでした。空白に与えられた意味によるものでしょうか、それとも矢印を使用した関数構文でしょうか?このことを考えるたびに、私の胃はざわめきを感じずにはいられません。 CoffeeScript には多くの新機能があります: デフォルトのパラメーター値、残りのパラメーター、拡散、構造化、暗黙のグローバル混乱全体の修正... CoffeeScript の多くの機能は Harmony 仕様の一部であり、将来のブラウザーで直接サポートされる可能性があります。 CoffeeScript は即座に満足感をもたらします。

@pyronicide on Twitter: #coffeescript は関数のデフォルトのパラメーター値をサポートしています。これはとてもエキサイティングです。
TXJS 2011 カンファレンスで、Douglas Crockford 氏も次のように述べています: CoffeeScript は間違いなく良いものです。

『CoffeeScript: Accelerated JavaScript Development』の著者は次のように述べています:

@trevorburnham
[...] CoffeeScript は JS を Ruby や Python に変換するのではなく、一連の構文を使用して JavaScript 本来の優れた機能をよりよく活用します。

Douglas Crockford は、JavaScript には良い側面があると信じており、開発者が JavaScript の悪い側面から遠ざかるよう JSLint ツールを開発しました。 JSLint によって許可される構文のサブセットには、独自の名前が付けられており、GoodScript と呼ぶこともできます。

ECMAScript 5 では、with などの構文の使用を制限する「use strict」ディレクティブが導入されました。

CoffeeScript、GoodScript、および ECMAScript 5 は同じ目標を持っています。それは、便利で安全な言語機能を提供しながら、くだらないものから距離を置くことです。

GoodScript は新しい機能を提供していません。ほとんどのブラウザは ECMAScript 5 の厳密モードをまだサポートしていません。しかし、私たちは待ちたくありません。

残りのオプションは CoffeeScript です。利点:

特に Web 開発に適しています。これは、他の JavaScript コンパイラーでは実行できないこと、またはうまく実行できないことである可能性があります。
CoffeeScript は JavaScript を適切にカプセル化します。これにより、コンパイルされたコードが読みやすくなり、デバッグが難しくなくなります。
CoffeeScript は、JavaScript コードを記述するためのマクロのセットのように見えます。

CoffeeScript のコンパイラーはクライアント バージョンを提供します。これにより、ユーザーは自由に選択でき、開発者は規格に制限されることなく新しい機能を迅速に開発できます。 CoffeeScript がコミュニティのビジョンとニーズによって動かされるのは素晴らしいことです。

自分の言語を発明してみませんか
それはできます、良い練習になります。 JavaScript コンパイラの開発者として、あなたは大きな名誉を受けるでしょう。

独自の言語を発明することの危険性は、最終的には JavaScript よりもうまくできると考えていることです。言語設計は難しく、あなたの言語が市場シェアを伸ばすのは難しいと思います。 CoffeeScript はまだ思春期に達しておらず、すでに苦情があります。

あなたは、自分のコンパイラがシンプルで読みやすいコードをコンパイルできることを誇りに思っているかもしれません。しかし、特別な状況に遭遇すると、壁にぶつかりたくなるほど落ち込んでしまいます。

あなたの言語でイディオムが表示されます。そうすれば、これらのイディオムを破る人がすぐに見つかるでしょう (あなたの言語がたまたまマクロをサポートしていない限り)。

これ以上皮肉な発言はありません。今すぐ独自の言語を開発してください。そうすれば、あなたは非常に優れたプログラマーになれるでしょう。

コンパイル対象言語として JavaScript に欠けているものは何ですか?
コンパイルターゲット言語として、JavaScript に新たな命が与えられました。 JSConf.US の講演で、Brendan Eich 氏は次のように述べています: Harmony 仕様の目的は、JavaScript をより良いコンパイルターゲットにすることです。

コンパイルされた C が手書きのアセンブリ言語よりも効率的に実行できないのと同様に、コンパイルされた JavaScript は手書きの JavaScript よりも実行効率が低い場合があります。幸いなことに、JavaScript のボトルネックは主に DOM 操作にあり、言語自体の効率の低下は比較的許容範囲です。とはいえ、いくつかの効率的なソースコード言語をコンパイルした後、JavaScript 自体の問題により、非常に非効率になり、実際の環境では使用できない場合があります。 Harmony 仕様には、この種の問題を確実に回避するためのいくつかの機能がすでに組み込まれています。调 合理的な末尾呼び出し

{
if (number === 0) {
Return True;
}
else {
Return isodd (number - 1) } }Function isod D (number) {
if (number === 0) {
return false;
}
else {
return isEven(number - 1) }
}

isEven(100000); // InternalError: 再帰が多すぎます
現在のブラウザで実行するとスタック オーバーフローが発生します。

トランポリンテクニックを使用して最適化できます:

function bounce(ret) {
while (typeof ret === function) {
retret = ret(); }
return ret;
}

function isEven(number) {
if (number === 0) {
true を返す; {
if (number === 0) {
false を返す; ,,; Even(100000);}) // true
isOdd(99999) が実行されると、isEven( 100000) は完了してスタックから出ているため、オーバーフローは発生しません。

幸いなことに、ECMAScript Harmony はこれを考慮しており、自動的に最適化します。これは、プログラム開発者とコンパイラ開発者の両方にとって有益です。

ラムダ
ラムダは魔法ではありません。つまり、ラムダは関数などの呼び出し可能なものですが、TCP (Tennent の対応原則) に準拠する必要があります。 TCP 要件: 式またはコード ブロックを隣接するラムダでカプセル化しても、カプセル化されたコードの意味は変わりません。

明らかに、JavaScript 関数はラムダではありません:

function one() {
return 1;
}

one() // 1
カプセル化後、戻り値は変更されます:

function one() {
; (function() {
}());
}

one(); // 未定義

2 つのパラメーターを受け入れてそれらを合計するコード ブロックの場合、ラムダ構文は次のように記述することが提案されています。 b| a + b}

上記の例では、ラムダ パッケージ化を使用すると、戻り値がパッケージ化前と同じになります。

function one() {

({||

}());
one(); // 1
lambda ブロックのストローマン提案はまだ Harmony 仕様に昇格されていません。一緒に取り組みましょう。

あなたのブラウザに何が欠けていますか?
JavaScript の盛衰はブラウザーから切り離すことはできません。 JavaScript の新しい生活には、ブラウザからの信頼できるサポートも必要です。

Mozilla は、コンパイルされたコードをデバッグするときに、コードの対応する行をソース コードにマッピングし直すことができる SourceMap プロジェクトを開始しました。これは非常に優れており、デバッグ コストを大幅に削減できます。

Webkit の人たちも同じことをしていると聞きましたが、残念ながら証拠は見つかりません。

複数の言語に堪能
JavaScript がブラウザーで独占しているということは、フロントエンド プログラマーが全員同じ言語を話すことを意味します。ただし、コンパイラーの違いにより、CoffeeScript プログラマーが Traceur に基づく JavaScript コードをすぐに理解することが困難になります。

この意見の相違は避けられません。例えばCもあれば、C++やObjective-Cなど様々な言語があります。 Java についても同様で、JVM に基づいて Clojure または JRuby を選択することもできます。 Microsoft はこれを認識しており、開発された CLR は C#、Basic、IronPython などすべて CLR 上で実行できます。

フロントエンドにおけるコミュニケーションの障壁は新しいものではありません。 Dojo プログラマーが jQuery または YUI に基づくコードをすぐに理解することは困難です。

複数のソースコード記述言語を使用すると、コミュニティ内のコミュニケーション障壁が増加します。プログラマーは依然として JavaScript を知る必要があります。少なくともしばらくの間は、プログラマーは依然として JavaScript を知る必要があります。しかし、ほんの数年のうちに、彼らは他のソース言語についてもっとよく知るようになるかもしれません。

まとめ
JavaScript の新しい生活を目の当たりにする機会を得られてとてもうれしいです。 JavaScript コンパイルの競争で、最終的にどこが市場シェアを獲得するのかを言うのは難しいですが、興味深いものになることは間違いありません。今日、CoffeeScript は離陸する準備ができていますが、他の多くの成功したソース コード言語が後に続くと私は確信しています。