米Yahoo!で議論された、フロントエンドエンジニアリングの将来(前編)
米Yahoo!が11月8日から3日間にわたり開催したWebテクノロジーのイベント「YUIConf 2010」。主にWebアプリケーションのフロントエンド技術を中心にしたセッションが並ぶ中で、著名人によるパネルディスカッション「The Future of Frontend Engineering」が開催され、そのビデオが公開されています。
Web標準の進化、HTML5が抱える課題、サーバサイドJavaScript、そしてエンジニアの採用など幅広いトピックが活発に話し合われました。米国の第一線で活躍するWebデベロッパーたちがいま何を考えているのか。Webはどんな方向に向かって進化しているのかを知ることができる貴重なディスカッションになっています。
この記事ではそのディスカッションの主な内容を紹介します。非常に長いディスカッションなので、内容を省略したり意味を変えずに分かりやすく変えて訳したりしています。詳細についてはぜひビデオとトランスクリプトをご参照ください。
フロントエンドエンジニアリングの将来
Dion Almaer みなさんこんにちは。このディスカッションでは、ここにいるBen Galbraithと、私Dion Almaerで司会をします。まずパネリストを紹介しましょう。
私とBenのとなりにいるのが、Tantek Çelik(テンテク・チェリック)。IE 5.5の開発に携わり、その後Web標準に関する活動もしてきました。
Joe Hewitt(ジョー・ヒューイット)はFacebookに所属していますが、Firebugの開発者でもあり、Facebook for iOSの開発もしています。もともとはNetscapeからMozillaになるときのFirefoxのオリジナルメンバーでした。
Elaine Wherry(エレイン・ウェリー)、Meeboの共同創業者でフロントエンドアーキテクト。Meeboは、Ajaxのインスタントメッセージクライアントで、AIMやYahoo! Messenger、ICQ、Facebook Chatなどをまとめてサポートしています。
Doug Crockford(ダグ・クロックフォード)は紹介する必要もないでしょう。Web業界のチャック・ノリス(笑)。JSONの発明者でYahoo!のJavaScriptアーキテクトです。
Thomas Sha(トム・ショ)はYahoo!のYUIファウンダー。
Ryan Dahl(ライアン・ダー)はNode.jsの作者です。Node.jsはサーバサイドのJavaScript実装として最初に成功したソフトウェアといえます。これはもちろんフロントエンドエンジニアリングではありませんが、JavaScriptへのフォーカスという点で彼にも参加してもらいました。
Webは「最先端」ではない。ゆっくりと進化するべき
Dion Almaer ではディスカッションをはじめましょう。このところWebからアップルのiOSプログラマへと向かう人もいます。iOSのようにWebの外で大きなエコノミーが存在するようになった現在、あらためてWebプラットフォームをどう見ていますか? 逆に、Web以外のプラットフォームで開発するときに何が失われ、あるいはWebはこれからなにを得ていくのでしょう?
Joe Hewitt Webでは「最先端の機能」を使っていると感じることがない点ですね。ネイティブアプリケーションでは毎年、あるいは半年ごとに大きな進歩があって、最新のハードウェアやガジェットのようなものが登場します。一方でWebの進歩はゆっくりとしたものです。
例えば、3~4年前からモバイルではタッチスクリーンが使えていましたが、Webではまだです。理由はわかりませんが、Webではそういう状態です。
Ben Galbraith Web標準やMozillaの経験を持つTantekは、いまのネイティブアプリケーションに対してWebには制限が多いという議論を聞いてどうですか?
Tantek Çelik Webのいちばん不利な点というのは、例えば大企業がやるような「Webはすごいですよ、もうすぐ次バージョンのWebが出ますよ」といったことがないところでしょう。Webは少しずつ進化するもので、こんなにもゆっくりで、一貫性もありません。でも、5年前の携帯電話とに比べれば、いまWebでできることは非常にパワフルになっています。みんなそれを忘れがちです。
Ben Galbraith Doug、あなたはいつもセキュリティの重要性を説いていて、Webの進化については慎重でしたね。
Doug Crockford ええ。Webはあらゆるものよりも技術的にはゆっくりと進むべきです。それで得られるもの、そうでないものというトレードオフがあります。そのもっとも大きいものは互換性でしょう。ほとんどあらゆるデバイスで利用できるはずです。そして、あらゆるものよりもセキュアに保つこともできるでしょう。一方で機能面でのパワフルさはないのかもしれませんが。
しかしそれは同時に、ブラウザで何かを動かすときに、それでマシンが壊れることはないのだと確信が持てるようになります。IDを盗まれることもない。とりわけ、携帯電話に重要な情報を入れておいたとしても、ソフトウェアがそれを盗んだりしてほしくないでしょう。
Ben Galbraith たしかに、だれだってWebに盗んでほしくはありませんね。Joe、Webがネイティブアプリケーションに機能面で後れを取っているとしても、君は次世代のユーザー体験を作ろうとしているよね。Webは君が作ろうとしているような体験をいずれは実現できるようになるのでしょうか?
Joe Hewitt いずれは、Webは多くの人が望んでいるような機能を備えるようになると思います。ただ、それにどれだけ時間がかかるのかは分からないですね。
Dion Almaer どれくらいかかるんでしょうね?
Doug Crockford そうした標準がいつ完成するのかを予想するのは危険なことです。急いで作られた標準というのは、どこかで間違いをはらんでいるし、いつかはその代償を払わされることになります。
サーバサイドJavaScriptの登場
Ben Galbraith 少し話題を変えましょう。私たちはここ、Yahoo!で、WebやWebブラウザの進化について話してきました。Thomas、もし話せるのなら、YUIが考えている将来像、YUIの進化やその機能について教えてくれませんか? 技術的に見てYUIの方向性などについて。
Thomas Sha YUIがサーバサイドといった新しい領域にも努力を広げようとしているのは本当です。研究段階から脱しようとしています。これはとても重要なものになるでしょうし、短期間で終わるものでもないと思っています。
Dion Almaer いまサーバサイドの話がでましたが、Ryan、同じ言語がどこでも走るようになればいいのに、という夢が以前からあって、Node(Node.js)はそれを実現しようとしていますね。Nodeがこれだけ盛り上がっていて、またNodeとはどんな風に使えるものなのか、話してくれませんか。
Ryan Dahl Nodeにこれだけ人気があるのはサーバでもJavaScriptが使えるためで、それは僕が意図したことでもあります。と同時に、それはサーバサイドを書く手段として望まれていたことでもあったんです。それは大きな断絶だったんです。実はサーバを書くエンジニアはクライアントサイドを書くエンジニアと同じだったのですから。
そしてこのシングルスレッド化されたサーバサイドのプログラミングスタイルこそ、サーバを書くのに求められていたものなんです。
これがどうやってクライアントサイドと統合されるのか? Webに低レイテンシーなリアルタイムアプリケーションをもたらすものとしては、Nodeは目新しいものではなかったけれども、それ以上に広がったのは、単にJavaScriptを使うことができたからでしょうし、完全なノンブロッキングの世界があって、サーバーサイドプログラミングについてそれほど広い知識が必要とされないためだろうと思います。それですぐにリアルタイムアプリケーションが作れる。だから、NodeはWebのリアルタイム化にも貢献しているのだろうと考えています。
Ben Galbraith Ryan、ぼくは君がJavaScriptよりもC/C++のプログラマだと聞いたことがあるのだけれど、JavaScriptはサーバサイドのアプリケーション開発に適しているのでしょうか、どうですか?
Ryan Dahl そうですね、ぼくはJavaScriptとの関係を好ましく思っています。JavaScriptはすごい言語だと思っていることもあるし。
この言語はそれほど多くの機能を詰め込んでいないのがいいところです。さっきもDougに言ったことなんだけれど、ECMAScriptに追加される新たな機能、Proxiesなんかを見ましたが、僕の意見としていえば、getter/setterからずいぶんきたなあと。ぼくは明示的な実行が好きで、何かを呼んだらマジックのように何かが起きるというのは好きではありません。同じ理由でC++は好きではないんです。
だからつまり、JavaScriptはOKなんです、とても。僕たちは人のためにソフトウェアを作ります、よね? JavaScriptはとてもヒューマンな言語、広く知られています。それから、サーバについてどうすればよいかという先入観がないところもいいです。JavaScriptは素晴らしいです。
JavaScriptの進化の方向
Douglas Crockford それを聞いて、数年前のEcmaScript 4の頃の議論を思い出しました。それはJavaScriptの機能を大きく拡大するというもので、他にもスレッド機能も追加したいという人たちがいました。
幸いにも私たちはそれらすべてに反対し、そうした間違いを正すことができて、複雑になりすぎることはありませんでした。だから彼がいったことには同感するし、JavaScriptにはこれ以上複雑なものを追加する必要はないと思っています。
Ben Galbraith RyanとNodeコミュニティは、バイナリデータタイプのようにサーバのニーズに合わせて、JavaScriptの可能性をとても広げています。これをECMAでの標準化とどうやって適合させていくとよいのでしょう。この方向性をどう思いますか?
Douglas Crockford 私はバッファを追加するようなこのアプローチは好きです。例えば、Node.jsサーバは言語を拡張せず、環境として新しい能力を付加しています。もしバッファが必要なら、それが実現され、インターフェイス経由で操作できるし、それを使わないでいることもできます。言語に新しいシンタックスを追加するよりもよいアプローチですね。
言語に新しいint型を追加するようなことは間違いだし、Nodeは完璧に適切な方法だと思います。
もしもこのアプローチが正しいと証明されたならば、ECMAScript委員会はこの方法をとるのが適切だと思います。私たちはそれをすべての環境で利用可能なように、言語仕様として組み入れていくべきなのでしょう。
Ben Galbraith そのほかのひとたちはJavaScriptについてどう思いますか? 特にJoeは違った環境でのプログラミングに多くの時間を費やしていると思いますが。
Joe Hewitt ぼくはJavaScriptに大きな不満はありません。個人的には好きなのはPythonだといえますが。ぼくは実はgetters/settersのような種類のマジックは好きで、だけどそれは個人的な好みです。
実を言えば、ECMAScript 4にも非常に期待していました。個人的には多くの機能追加を支持していましたが、それらが適用されなかった理由も分かります。
Dion Almaer つい最近Silverlightについて話題になりました。マイクロソフトがHTML5を前面にだしたので、影が薄くなってきたことについて。Silverlightがすべてのブラウザをサポートすることはないでしょう、だとするとJavaScriptにすべきなのでしょうか?
Tantek Çelik イエス。JavaScriptは勝ったんです、議論の余地がありますか?
Douglas Crockford あらゆる期待に反して、JavaScriptは世界でもっとも重要なプログラミング言語になりました。誰も望んでも期待もしていなかったけれど、そうなったんです。(笑)
Tantek Çelik 僕の仮説なんだけれど、JavaScriptが勝った理由はこの二言だと思う「ソース読め」
アプリケーションのためのCSSとは?
Dion Almaer 話題を変えましょう。もう1つみんなが楽しんでいる言語、CSSについて。
私たちは多くのコンテンツプロバイダやメディア企業とレイアウトについて話したことがあるのですが、彼らは自分たちのニーズをまだ満たせていないことに不満です。CSSのコミュニティではいま何が行われていて、私たちは彼らを助けるためになにができるのでしょうか?
Tantek Çelik CSSは、アプリケーションではなく、間違いなくドキュメントをデザインするためのものなんですね。それがコンセプトであり、そのように動作するわけです。
それをアプリケーションに対しても活用できるようにしているわけですが、それほどうまくできるわけではありません。以前Dougと、なぜこうした課題を解決してアプリケーションのためのCSSというのがないのだろうかと話したことがあります。
答えはたぶん2つあります。1つは、クロスプラットフォームに対応したUIというのは実のところ難しいということ。YUIを見ればわかりますが、それは本当に難しく、それを標準にするのはさらに困難でしょう。
2つ目は、アプリケーションが必要としているのはグリッドレイアウトの仕組みだということです。例えばインターフェイスビルダーを見ると、あの機能はCSSではできません。
そこで、Dave Hyattと私たちの仲間と、最近ではマイクロソフトと共同で、CSS Grid moduleというのを策定中です。もしCSSによるアプリケーションレイアウトに興味があるのでしたら、このCSS Gridに注目しておいてください、もうすぐドラフトとブラウザのプロトタイプ実装ができると思います。
Joe Hewitt もしもCSSなしでレイアウトをすることになれば、例えばネイティブアプリケーションを作るときなどは、カスケーディングモデルやセレクタのあるCSSが恋しいときもあります。ネイティブアプリケーションですべてのコンポーネントのスタイルを1つ1つ設定するときなどにね。WebデベロッパーはCSSがどんなにいいものか気づいていないんです。
(後編に続く)