JavaScripterから見たJSX

私は2001年からJavaScriptを専門にして実装をしており、かなり長い間JavaScriptを使い続けてきました。ExGameをはじめとして、異常なほどにJavaScriptを使い倒したプロジェクトを何個か完遂させています。前の会社「ブロードテイル」がDeNAに買収されたのは、JavaScriptのプロダクトだけでなく、私たちのJavaScriptのスキルを生かしたいという側面も大きくあったと感じています。 そんな私ですが、正直に言うとJSXの開発にはほとんど関わっていません。JSXは基本的に一穂さんが主導し、gfxがフォローし、a_bickyがドッグフードを食べる（自分たちのプロダクトをまず自分たちで率先して使う）という形で進んできました。私が強くかかわったのは、主に3月の言語仕様を決めるときの議論程度です。なのでJSXについてそこまで詳しい訳ではないのですが、そばで開発を見てきた

[raimon49]

＞大規模な開発になると、途端にJavaScriptは弱さを発揮します。例えばthisの付け忘れ、例えばタイプミスなどなど、つまらないところで数時間判明しないバグを生み出したりします。 / JSXが解決しようとしている領域は、多

[hukuchosan]

もう一つのデメリットとしては、私のようなJavaScript専門家の才能を発揮する余地が少なくなってしまうことですね。保守性を保ちつつ可能な限りの高速化をするために四苦八苦することが出来るというのが大きな価値だっ

[ysk_lucky-star]

んー？と言うことはJSXを使う上での学習コストも肥大するってことにも繋がるのかな？

[t_a_o]

JSX

[rryu]

文法をAS3風にしたのはやっぱり既存コードからの変換を容易にするという意図があるのだろうか。

[ko-ya-ma]

「今のところ、大規模開発が可能で、かつJavaScriptに変換しても絶対に遅くならない言語はJSXしかないだろうと考えています」

[stealthinu]

JSXは『多人数での開発に向いた言語にする、JavaScriptの変換で遅くなることがないようにする』が目的と。今後、というか今や主戦場は携帯端末向けjavascript上と考えるべきなのか。

[sugyan]

重要な点は「速くなった」ことではなく「決して遅くならない」こと

[xorphitus]

Closure Compilerとの違いとか／素JSはゆるく軽くゴリゴリ書けるのが好きなんだけど、規模が大きくなるとそれはデメリットだしな

[burnworks]

『JSXは、企画の段階から「絶対に遅くならない」ことを念頭に設計 / 今のところ、大規模開発が可能で、かつJavaScriptに変換しても絶対に遅くならない言語はJSXしかないだろう』

[zorio]

IDEのサポートやマシなコンパイルエラーが出るなら、Closure Compilerでなくてこっちを使うメリットはありそうな感じ。

[ks1234_1234]

"ここでの重要な点は「速くなった」ことではなく「決して遅くならない」こと"

[escape_artist]

ちょっと興味沸いてきた

[teppeis]

Closure Compilerとの比較

[edo_m18]

「絶対に遅くならない」っていうのは確かにメリットかも。

[hiroshi_revolution]

JavaScripterから見たJSX » nmi.jp

[gae]

JS弱者なので気になるw