読者です 読者をやめる 読者になる 読者になる

帰ってきたHolyGrailとHoryGrailの区別がつかない日記

はてなブログに帰って来ました

重くなる原因でもなければバージョンが変わるのはライブラリだけではない

javascript

昨日書いたエントリに次のような反応をいただきました。

反対する理由として

  1. 初期読み込みが重たくなる
  2. バージョンは変わる

ということでしたので、引用しつつ反論してみたいと思います。

最初に

aタグにonClick書いてる時点でなにか違うことをやっている気がしなくもない。
もともとこういうのは超苦肉の策で始めたものだ。
ボタンが嫌だ!リンクにしたいっていうご要望をうけいれるところから始まった。

これですが、もはや過去の経緯などは関係ありません。
今、ウェブを見ているユーザが一般的にクリックできると考える要素はアンカータグだと思います。
ユーザがアクションを起こすことができると考える要素にイベントハンドラをセットするのはごく普通の流れだと思います。
この時点で違うと言われてしまうとユーザに優しくないページだらけになってしまいます。
WEB標準といった流れも考慮するとこういった挙動に特に違和感は感じられません。

初期読み込みが重たくなる

ライブラリの物理容量が重たいなんてことは言わない。
画面の初期処理が重たすぎる。
最近のはてなスターもそうだけど、画面のイニシャライズに時間がかかりすぎている。

まずここではてなスターを例としてあげられていますが、あれはそもそもはてなスター自体が重いのであって、イコールonClickが重いというわけではありません。
はてなスターが重いのはそのサービスの性質上、ある程度は仕方ないもので実装方法が悪いというものでもありません。

画面を描画しながらイベントを割り当てることの不合理さは普通のアプリケーションを開発したことがある人ならまっさきにわかりそうなものだが、同じ轍をWebの人たちが踏んでいるように思う。

そもそもHTMLではスクリプトが実行されている間はレンダリングが中断されるため、画面を描画しながらイベントを割り当てるというのは不可能です。
はてなスターもその挙動を見る限り、イベントの割り当てられた描画すべき要素をあらかじめまとめてオブジェクトとして生成して、最後にHTMLに挿入しブラウザによってまとめて描画される、といった動きになっているのではないかと想像します。
描画を妨げないためのonDOMReadyであり、onLoadによる各イベントハンドラの割り当てなのです。

画面のロードが完了するまではユーザーは何もできない。
これはもっとも避けるべきことでユーザーインターフェイス以前の問題だとおもう。

そもそもここでは完全にはてなスターに対する単なる苦情であり、論点であるonclickとは関係ありません。
というのも、重い重いとおっしゃられるはてなスターが重い原因はonclickにといったイベントハンドラまわりによるものではないためです。

1.クライアントの画面描画の際におこなう
2.onClickで最初から書いてある
どちらが読み込みが軽いかは冷静に考えてほうがいい。
最近の重たさは許容できる範囲を超えつつある。

こちらですが、あまりブラウザの実装については詳しくないので、もしご存じの方がいたら教えていただきたいのですが、1と2ってイコールじゃないですか?
これは推測なので間違っていれば指摘してください。
ある要素にonClick属性などが指定されていた場合、ブラウザはイベントハンドラをその要素に割り当てる挙動を行います。
つまり、その要素が読み込まれた時点でスクリプトが実行されていることになり、レンダリングの挙動を妨げるのではないかと考えます。
となると、その行が読み込まれた時点でレンダリングをしつつもスクリプトが実行される、ということで、1とほぼ同義なのではないでしょうか?

つまりJavaScriptによるイベント制御においてはonDOMReadyやonLoadの状態でまとめて割り当てるのがもっとも効率がよいと考えられます。

バージョンは変わる

ライブラリは便利だ。
だけど世間のブラウザのバージョンも変わればライブラリのバージョンも変わる。
んで、よくサポートが切れる。

とありますが、これ最初に「ライブラリ」を主語としていますが、これを「ブラウザ」に変更しても全く同じですよね?

つかわんでも用がたりるのであったらあまり余計なものをいんくるーどしない方が余計なメンテナンスコストがでない可能性は高い。
もし穴があったときも同じライブラリを使ってれば共通の手法で速効攻撃されるし、かといって、どこに穴があるのかどのバージョンが悪いのか自分で追い切るのはなかなかに手間だ。
すべてのバージョンは変わり続ける。使わないですむのであれば余計なものは使わないほうが楽チンだ。

ブラウザのバージョンは変わります。
それに伴い実装も変わります。
さて、そうなった場合すでに完成されメンテナンスをされているライブラリを使っていた場合と、すべて自前で実装していた場合どちらが効率がよいでしょうか?
もし、ライブラリを用いず、すべて自分でまかなっているとそういった時、ブラウザの実装についてすべて自分で調べなくてはいけません。

また、穴があったとき、とありますが、穴があるのはライブラリだけではありません。
ライブラリでも自分で実装した場合でも穴が存在する確率は同じです。
むしろ、オープンソースによって開発されているjQueryといったライブラリの方がよっぽど信頼性があるのではないでしょうか?
配布されているライブラリであれば穴があればアナウンスされるでしょうし、バージョンによって管理されています。
これらをすべて自分でやっていたのでは、よっぽどのスーパーエンジニアでなければ賄うことはできないでしょう。

ライブラリだけでなく、ありとあらゆる全てのものが次々とアップデートされていく中で、必要なのはライブラリを避けることではなくそういった変化に追いついていくことだと思います。

そりゃおしゃれかもしれないけど。その分犠牲になるものがある。このバランスは無視しないでほしい。

別にエンジニアはおしゃれを目指してこういったことを日々考えているのではなく、どのような実装方法が、よりもっとも効率がよいのか、ということを考えています。*1
開発コスト・運用コスト・パフォーマンス・ユーザビリティ、ありとあらゆるもののバランスを考えるのがエンジニアの仕事です。
はてなスターといった、内容や用途含めて特殊な例を掲げて、onClickが一番だ、というような印象を与えるようなことは、できれば止めていただきたいなとも思いました。
少なくとも、私が上にあげたような内容については最低限調べた状態で言及をしていただきたかったと思います。

頭で考えながら文章におこしたため多少乱文乱筆な部分もございますが、ご了承ください。

最後に次のような記事を見つけたため最後に紹介させていただきます。

*1:スマートな実装方法を”おしゃれ”と呼称するのは別に構いませんが