で、まじめにメモってみる

資料はこの辺から。以下長文注意。

Shibuya.js 結成にあたり(secondlifeさん）

言語として10年の歴史があるし、Ajaxの基礎となるXMLHTTPRequestも1999年には実装があったのに、二年前くらいまでは「コピペ言語」「最初にオフにする機能」扱いだった。
が、世間の手のひら返しでブームに。
Etech 2006でもJSの話ばっかりだった
なのにみんなで話をする場所がないのでShibuya.jsを作ってみましたよ、と

最後に生き残るのはJavaScriptかもな(えとさん)

まずは昔話
おそらく日本で最初にJSの記事を書いた(Net Travellers 96)
ふつうにHello, Worldから。Javaとともに必須になるだろうと書いたものの、その後はいまのWinnyと同じ扱い
ブラウザ戦争最大の被害者。ブラウザの差を出すために意図的に非互換機能が導入された
が、クライアントサイドでは競争相手が軒並み消えてしまい、結局生き残ったのはJS（とその派生物）のみ。しかも行き場を失っていたこともあって結構あちこちに顔を出している(Windows Scripting Host、Photoshop等など)
将来的にクライアントサイドではJS必須になるだろうし、開発者はなるべく楽したいと思うので、もしかするとサーバサイドでもJS必須になるかもしれない!?
実際JSとJavaが連携することでJSからWebサーバを立ち上げることすらできるようになっている
JSだけでブログのような画面遷移をつくることもできるので、サーバサイドの役割はデータのやりとりくらいになるかも
でも、JSはまだLLとは言いがたい。ライブラリ重要。テスト環境とか欲しいですね、と
- →JSAN

Prototype.jsは遅い!? JavaScriptの高速化(amachangさん)

かつてJSは重かった、いまでもそれなりに重い。だから高速化しよう
JSはマルチスレッドではない（複数の処理が同時に走ることはない）。イベントすら拾わないので、実行時間を短く、実行回数を少なくすることが重要
DOMは最適化するべし。DOMのドット解決はJSでもっとも重い処理。共通なノードがある場合は事前に別変数に取っておくと圧倒的に速くなる。ループの判定式に.lengthを使うときなども同様
テキストノードをごりごり作るより文字列をまとめてinnerHTMLに放り込んだ方がふつうは速い。小さなテキストの場合はノード作った方が速いことも。innerHTMLに+=で文字列追加するのは激重
使わなくなったsetIntervalはクリアするべし。しないとメモリリークすることも
setIntervalはなるべくひとつに。タイマ値も我慢できなくなるぎりぎりのところまで大きくした方がいい
Withは避けるべし
スコープチェーンの深追いもさせないように
文字列を事前に変数代入しておくと速くなることも
関数呼び出しは重いのでなんでも関数化するのは考えもの。ただしこれは保守性とのトレードオフ
Prototype.jsには重い関数が多いので使うところと使わないところの見極め重要。フレームワークとしては便利だが、mousemoveイベントや激しくタイマーが回っているところでは使わないのが吉。ノード探索もさせない方がよい(なるべくid属性をつけてid探索するべし)

はてなよりシャープでしょ(竹迫さん)

竹迫さんの発表はやっぱり画面があってこそですよねえ
JSを安全に運用するのはむずかしい
scriptaculous.jsはロードするモジュールをscriptaculous.js?load=hoge,fugaのように指定できる
ただし、scriptaculous.js?load=hoge,fugaのようにすると企業内プロキシ等でキャッシュされないことがあるので、scriptaculous.js#load=hoge,fugaのようにした方がよい
Last-ModifiedやExpiresを適切に使ってキャッシュと上手につきあおう

Agile Web Development with 萌ディタ(malaさん)

会社のFreeBSDはよくわからないのでVMWareにDebianを乗せて開発。ブラウザその他いろいろ入ってる
萌ディタであって萌エディタではない
設定ファイルがJSで書かれている。キーバインドなどもJSで指定できる
補完機能充実
タブ幅変えられて便利
Sleipnir API＋萌ディタをJSで連携させると最強
FireBugはJS使い必須
Safariの罠
Operaはブラウザというよりメーラとして。MLの振り分けを自動でしてくれたりと意外と高機能
デバッグのたびにCVSアップとかは面倒なので、WEBrickをプロキシとして使って通常のウェブアクセスとローカルファイルを合成できるようにしている。ので、人のサイトでも勝手にデバッグできたりする
鯖側ができていないときはJSONでダミーデータを用意するなどしてなるべくローカルだけで開発できるようにしている
SpiderMonkey入れておくと何かと便利

RJS Template, Jemplate(secondlifeさん)

名前は似ていても中身は別物
RJS TemplateはRails1.1から搭載されているJS Generator
Rubyコードを書けば正規化されたJSを吐ける
テキストを返すのではなく生のJSを返すことでJS側のBKを軽減できる
ドキュメントはActionView::Helpers::PrototypeHelper::JavaScriptGenerator::GeneratorMethodを見るとよい(結局はソース嫁)
./script/consoleで対話的に試すこともできる
メソッド19個。定義されていないものはcamelizeすることでJSっぽく変換
breakpointで動的にデバッグすることもできる
でもJS書ける人には無用かも
JemplateはTemplate-Toolkit風のテンプレ
JSは文字列クォートが大変なので、テンプレがあると楽できる
データをすべてJSONで管理できるのもいい
使い方はちょっと特殊で事前にコンパイルする必要がある
毎回コンパイルは面倒なのでフレームワーク側で対応してもらおう(いまのところ開発者向け)
もっともTemplateが必要になるかどうかはアプリの設計次第

以下ライトニングトーク。

JavaScriptを関数的っぽく(motemenさん)

コードを見やすくするための高階関数を用意
Prototype.jsだと関数の加工などはしづらいのでMochikitを使うと便利

GreaseMonkey を XPath で楽に(cho45さん)

GMを書くのが楽になる$Xという関数を作ってみましたよ、と

アニメーションエフェクトとJSAN(川崎さん)

JSでうねうねぐるぐると画像処理
JSANはCPANのJS版 http://www.openjsan.org/
JSAN.useするとライブラリのロードとかもできる(メリットないけど)
有用なライブラリもいくつかあがっている。テスト環境もある
まだ盛り上がってないし使いづらい部分もあるけどYAPCで紹介されたりもしたので今後流行るかも?!

モテル！XUL！(Piroさん)

XULは基本的にJSアプリ。HTMLがXULに変わるだけ
機能豊富。エフェクトとかはないけど、Simple is best
Agileに開発して余った時間でモテ活動?

ブラクラの歴史(youpyさん)

無音のビデオ上映
クラッシュ用のjsをかますことでShibuya.jsのサイトを開いたブラウザの挙動がおかしくなっていき、しまいにクラッシュ
ブラクラ被害にあったとほんとに障害報告していたあたりで微妙な笑い