ここ数年ずっと FireFox使ってきたんですがー、さすがに重くなったというのが理由のひとつ。
W3C準拠のレンダリングエンジンの行儀の良さと、便利なプラグインも多いってところが魅力で、手っ取り早く起動させたい時は IE起動させれば済むわけだしー、とか考えて併用してたのですが。
一度 Chromeの「速さ」を体感しちゃったら、うん、もう無理。
ちなみにこの「速さ」というのは、正確には「体感」で早いだけなんだけどね。
初見でもっともインパクトがあるであろうシンプルなインターフェイスこそが、この「速さ」の秘密なのだと思われる。
例えばもはやブラウザの必須機能とでもいうべき「検索バー」がアドレスバーと共通化している部分とかが目鱗。
一応 IEや Firefoxでもアドレスバーから検索エンジンにリダイレクトはしてくれますが、基本はあくまで URLとしての解釈を優先しており、スキーマとサフィックスを補完した結果
アドレスが有効ではありませんとか言われちゃったりすることが多々。FireFoxなんか今となっては
「何もかも懐かしい」Punycodeな日本語アドレスに変換したりしますし。
そこを Chromeではデータ解釈が賢いのか、単に検索を優先しているのか、検索ワードはきっちり Googleさんにリダイレクトしてくれます。
ユーザーが直接入力を行う場合、直アドレスよりも検索文字列である事のほうが多い、という実情を鑑みての処置なのでしょう。そこに検索サイト屋である Googleの思惑もあるんだろうけど、二度手間になる部分を省いてくれる分「体感」で早くなっているのは事実。
また、いわゆる Windows標準の MENUバーがないというのは戸惑う部分も大きいですが、そこは慣れればなんとやら。正直、Webサーフィンの最中は、ぶっちゃけ「戻る」「進む」「更新」「設定」ぐらいで殆ど済みますし、こんなのはツールバーだけで充分事足ります。それに昨今のディスプレイ事情は HDTV的にワイドなケースが多いでしょうから、「縦幅」というのは貴重なのですよ。
よりマニアックで技術的な方向性で言えば、Greasemonkey用のスクリプトがほぼそのまま使えるというのも大きかったりします。
JavaScriptベースだし、XMLベース言語である XULよりは開発環境も含めて敷居が低く、技術習得までの時間が「速い」。プロファイラみたいなものと、デバッガも標準搭載されてますし。ちょっとしたフィルタリングなんかも簡単に作れます。
ちなみに某ツールも早速チュートリアルがてらに Chrome用の拡張に対応させてますし。
またコンパイルしてオブジェクト実行してくれるのも嬉しいところ。もっともFireFoxのプラグインのようなプリコンパイルじゃなく JITなので、でかいプロジェクトはさすがにオーバーヘッドが目立つようですが、Try&Errorな開発スタイルが主であろうにわかプログラマにとっては、むしろいちいちコンパイル環境をいじらなくて済む分これも「体感」の速さに繋がるわけです。つかそこまでかいものはまだ拾ってきたことないし、もちろん作る暇も気力もない。
ちなみに「でかいプロジェクト」の中の「一部機能」だけが欲しい、なんてケースは間々あると思うけど、その場合は一部を切り出した機能縮小版を作るというアプローチが正しいと思われる。そういうのをやるにも、Chrome拡張の開発環境というのは凄く向いていると思われる。
ということで、わたしが FireFoxに求めていた機能はほぼ網羅してます。
レンダリングエンジンも Gecko系なので素直ですし。
不満点というと……やっぱりマイナーだということでしょうかねー。サードパーティによるサポート情報が思いのほか少ないというのは欠点。本家が充実してればいいじゃんという気もするんだけど、わたし日本人なので、ええ。
それと先述どおり、レンダリングエンジンは Safariと同じ AppleWebkitで、HUAでも Geckoコンパチブル……というか、
like Geckoだとか微妙な言い回ししてます。それで HUAの集計時に
Gecko系でまとめられて「体感」でマイナーに感じるんじゃないか、なんて思ったりもするけど、まあまず間違いなくただの思い違いであり、ほんとにマイナーだと思われる。
それはさておき、その「微妙な言い回し」の意味するところなのか、同じ Gecko系でも微妙に挙動が違うのですね。
レンダリングエンジンの挙動というと、大別すれば HTMLの「解釈」と「表現」って感じになると思うんだけど、前者は OpenSourceなんだしそうそう変わらないにしても、後者にはやはり微妙に「クセ」みたいなものが出たりします。
もっとも、それも本来個性というべきもので、あって当然ではありますが、残念ながら悪いほうに「違う」のですね。
例えば FireFoxの好きな機能のひとつであった、画像を含めたクライアント領域全体の拡大縮小は Chromeも搭載しています。しかし変形時に誤差がある所為か、結果は微妙に歪んでたりします。
静止画ならまだ目立ちませんが、Animationパーツなんかがあると、うねうねと波打って気持ち悪いというか。これが 83%だとかの素数的に微妙な比率ならまだ酌量の余地はありますが、50%縮小でもなるというのはどーにも。丸め誤差でも発生しているのだろうかねー?
これはフォントの描画にも影響が出る事で、同じフォントでも微妙に形状が違ったりします。どっちかというと、読みにくい方向にorz
この手の仕組みはデフォルトサイズのフォントをストレートにストレッチするのではなく、アウトラインフォントならばそれに対応するフォント……すなわちポイント的に近似サイズのフォントをベースにサイズ調整して表示しているのでしょう。フォントの専門家がデザインしたものですから、小さく表示したって読みやすいのは当然といえますし。
でもそのへんの調整が上手く行ってないのか、Chromeは FireFoxに比べて微妙に読みにくい字形になるのです。
またレイアウトでも横方向はいいんだけど、縦方向にはズレがあるというか、縮小すると上下の文字が重なったりします。広告バナーみたいな IFRAMEの中身とか拡大しない時があったりもしますし。
多分 HTMLのブロック要素レベルで影響を受けているのだと思いますが……なんにせよ、ここらへんは多分、後発故の作りこみの甘さなんでしょう。
その点、FireFoxは長年の蓄積がありますし。Netscapeの正統後継と考えるなら WWWの創成期まで遡れますし、その重みはだてじゃないですね。
でも挙動の軽さと、シンプルなインターフェイスはそれらを負って有り余るほどに魅力なのです。
先述した Greasemonkeyのスクリプトをそのまま使えるようにしたのも含めて、この手のこまごまとした「改革」の結果が、Chromeという結果になって現れたということなんでしょう。
そこら辺は Internetユーザーに対する
強いて言うなら FireFoxは「技術屋の作品」であり、Chromeは「商売人の商品」って感じでしょうか。
ちなみに IEは何かに喩えること自体間違っている気がします……。
技術的に見て驚くべきブレイクスルーとかがあるわけでは決してないんだけど、こういう「ありもの」を最適に組み合わせるというアプローチには結構好感がもてたりします。日本の技術者の真骨頂って発明よりも「魔改造」だと思ってますし(w ……いやまあ、Chromeの開発は海外なんだろーし、わたしは技術者でもないですが。(←ここ重要)
0 件のコメント:
コメントを投稿