以下斜め読んだ内容

pseudo translation of useful posts, book reviews, remarks,etc. twitter: feeddict

Bruce Eckel「JavaScriptへの回帰、およびクロージャ」

  • The Artima Developer Community 2011.7.15の記事

JavaScript Redux (and Closures)

java/c++の本書いたり、flex/flashでUI開発長年したり、flexでの開発用にpythonでツール作ったりと別の言語では経験豊富なエンジニアが、flex/flashは将来性なし、でもhtml/css/jsのセットはクソ、js飼いならすにはクロージャ大事、js実行環境としてのブラウザの今後についてまで、サクサク書かれたエントリ

以下斜め呼んだ内容
  • サマリー
    • エンジニアは誰もがjsと向き合う必要あり
    • jsは醜いがよくなってきた部分もある
    • jsをテーマにした良いレクチャーや名著が色々ある
    • それを見たり読んだりしたらjsへの見方がかわると思う
    • クロージャを理解してない人にもこうしたレクチャや本は有益
    • 他の言語ではクロージャは「あったらうれしい機能」として言及される
    • jsを数多のjsのカオスな使われ方から抜け出るのにクロージャの理解は必須
    • クロージャはjsでは必須項目だが他言語よりもjsの世界の方が理解しやすい
  • UI開発を楽しんできた、色々よいUIデザインを求めて試行錯誤してた
  • これまでFlex+FlashプログラミングがUIデザインが自分にとって正攻法
  • Flex/Flashはスクラッチから始まり、UIデザイン上の問題を解決することに焦点当ててる技術
  • flashplayerという形をとってブラウザに組み込まれてたVMをもっていた
  • Flexを開発した会社をadobeが買収する以前からのFlexユーザ。Flexをネタにスピーカやってた
  • Flexの未来は超有望と思ってた。その頃は
  • 今その予測を再考しないといけない時期にあると思う
  • 現在の自分の感触では、Flexは長命ではないと感じてる
  • Flexに欠陥が、という話ではない。取り巻く状況が変わったことに起因してる
    • 携帯デバイスでの話。flashが求められてることに対応しきれてない
    • flashはデバイスのバッテリを一番食い尽くす存在になってる
    • ハードウェア技術が格段にアップしても状況は本質的には変わらない
      • もしハードウェアが発展してflashのバッテリ消費が気にならなくなるくらい性能が上がるとする
      • そうしたら軽量で薄いものが作られる
      • その軽量で薄いデバイスについて、再びflashのバッテリ消費量が問題になるだけ
  • さらにFlash/Flexに悪い流れ
    • Apple(というかJobs)がiOSではflash非搭載で行くことにした
    • デバイスマーケットでappleの路線の影響力は大きい
  • adobeはflash/flexへの逆風の中でがんばってる
    • flexhtml5へ変換するツールの開発。
  • chromeでflashの動作が不安定という声もきく
  • chromeと比べてflashは歴史のあるソフトウェア
  • 品質コントロールの維持はどんどん大変になってく
  • 個人的に驚いたのは、AdobeLinux向けにFlexを提供をストップしたこと
  • 私企業が提供してるプラットフォームなんだということ
  • 私企業であれ今後もサポートされるプラットフォームなんだと信頼できなければ、そのプラットフォームへコミットする人はいない
  • 自分はプラットフォームとしてのflash/flexへの信頼が薄れた
  • 別のより一般的なソリューションを求めて彷徨しはじめた
  • html/css/jsは代案としてはクソ。だが短期的には選ばざるをえない
  • 使えるところではFlexを使い続けてる
  • 携帯デバイス環境でも利用も含まれるより一般的用途をもったアプリケーション開発では、自分はhtml5を使いたい
  • AdobeがFlashBuilder 4.5 for PHPを出した件
    • 詳細はよく知らないが
    • 非flash環境向けコードの書き出し機能がある
    • flash無き世界へadobeは舵切ってる
  • adobeのツール作る技術は優れてる
  • adobeが持てる技術力を駆使して、html5アプリ用の優れたIDE出すのを期待してる
  • 数年前の話。自分のjsへの印象は最悪
    • ブラウザごとに文法が違うとか悪夢
    • もちろん改善されてるが、否定的な見解は払拭しきれてなかった
  • Douglas Crockford
    • 長年jsを研究
    • json発明者でもある
      • jsonはrpcプロトコルjson-rpcも作られてる
      • Go言語ではjson-rpcを標準でサポートしてる。xml-rpcはサポートしてない
    • jslintの人でもある
      • jslintはまずいjsの書き方してないか色々チェックしてる。ぜひ使うべき
  • 彼の"Javascript:Good Parts"
    • レクチャー版みて、それから同名の本読んだ
    • jsで開発するなら"good parts"は必読
    • jsの無数の欠陥と馬鹿げた部分を理解することに捧げられたレクチャー。ともいえる
    • jsがクソだと思ってる人は"good parts"読んだらその気持ちが軽減されるはず
    • Crockfordによってjsがいかにクソな部分が多いかが開陳されてるが、本当にびっくりした
    • 既存のサイトのソースからjsコピペしてjs書くことすましてる人たちが大勢いる。これも信じがたい
    • "good parts"はいかにjsを飼いならすかを教えてくれる
    • 他方でjsの欠陥やトラブルメーカーぶりについても教えてくれる
    • 「これまでに出たjs本を読めばjsの悪い書き方を学べる」by Crockford
      • ひどく尊大なコメント。でも自分は支持する
  • Alex Russelの"learn to love javascript"もみた
    • Learning to Love Javascript
    • jsに希望を持てる内容
    • Alex自身はGoogleでjsという言語を改善していくことに力注いでる
    • Googleはサービスの中でjsの亜種のような言語を作って使ってる
  • クロージャはjsにとって本質的
  • クロージャが一番jsで誤解されてる機能
  • 「無名関数=クロージャ」な人をたくさんみた
  • あるコードブロックがそのブロックの外側で定義された変数を束縛してること
  • コードブロックのスコープの外でに出た後も変数(の値)が維持されること
  • クロージャを理解したくて色々頑張った、前は色々と混乱して理解してた
  • javaの世界ではクロージャーと無名関数の区別がつかない人が結構な数でいた
  • jsが最悪な所の1つ
    • jsにはリンカー(linker)がない
    • グローバル変数が常に存在している
    • サクッと小さめのサンプルとかスクリプトを書いてる場合
    • jsが使われるのは、ブラウザ内部
      • ページ表示のためにサーバーから送られたコードは、集約的環境内部でアセンブルされ実行される
      • ページで読み込まれるjsコードそれぞれがグローバルオブジェクトやグローバル関数を生成する
      • 生成されたオブジェクト名と関数名が他のコードから生成されたオブジェクト名、関数名と重複する恐れがある
  • 名前の衝突リスクを回避するやり方の1つが、クロージャ
    • クロージャ使ってプライベートな変数を作れる。
    • クロージャ使って作られたプライベートな変数
      • クロージャ使ってる関数スコープの外部ではクロージャーからのみアクセスできる
      • クロージャーは無名関数の形をとることが多い
        • 無名関数=クロージャと混同する人が多い原因になってる
  • クロージャーは、jsを実用に耐えるレベルで使いこなすためには、マスターが必須
  • Crockfordの"Good Parts"はとことん、実用に耐えるjs利用にフォーカスを当ててる
    • "Good Parst"読めば、js誕生からajax登場までに長い時間がかかった訳がわかる
    • jsの問題と解決を理解するのにかかった時間
    • 解決方法を標準化するのにかかった時間
  • js使ったページ開発の理にかなった唯一の方法
    • 最良のajaxライブラリを見つけて使う
    • 探して使う点に関して自分はまだ初心者レベル
    • ajax+jsは別言語でのプログラミングと共通点が多い
  • jsの改良・発展プロセス
    • 企業の思惑とか遅いとか色々ごたごたしてるし遅いがその辺に批判する気はない
  • ブラウザへ抽象化のレイヤーを導入したい
    • ブラウザ共通のVM作る
    • ブラウザで使える言語はjs一択でいい
    • VMにはオプションを追加できるようにする
  • プラガブルなDOM
    • 現状のDOM操作での不自由さを取り除くため
  • VMとプラガブルDOMのデザインと実装は色々と課題あるし大変
    • 後方互換性の問題
    • VMとプラガブルDOMの連携をページレベルの実現
    • だがブラウザは世の中で重要なソフトウェアの1つ
      • ユーザにとってOSぐらいの役割
      • 問題があったら(難しいとかいわずに)とっとと解決しないといけない代物
  • js以外の何か
    • coffeescriptに注目してる。Alex Russelもオススメしてた
    • こういう短期的な解決が色々出てほしい
    • Google Apps Scriptiong languageでは、jsが色々と強化されてる
    • 学習コストは少なくそのコストに見合ったパワー持ってる、と思う
    • とはいえ、html/css/jsの泥沼で過ごすことに変わりなし
    • よいツールの出現待ち。泥にまみれるにしても膝下だけにしてくれるだけのよいツール