Subscribed unsubscribe Subscribe Subscribe

Kengo's blog

Technical articles about original projects, JVM, Static Analysis and JavaScript.

Reading source of Hatena Blog

javascript CSS HTML Maven

 Today I read a source (HTML, JS, CSS) of this blog. This entry is my impression.
 このブログのソースを読んでみたので、感想をまとめておきます。

CSS/JS isn't pre compressed?

 To load basic CSS files and JS files, this blog uses very long URI which includes paths of file. We can get a compressed file by accessing this URI. I think it's not pre compressed one, but compressed dynamically by program (maybe cached).
 基本的なCSSやJSを読み込むために、ファイル名を含んだとても長いURIを使っているようです。このURIは複数のファイルが連結・圧縮されたものを返すのですが、たぶんこれは事前に圧縮されたものではなくプログラムによって動的に作られているものではないかと思います(キャッシュはされているはずですが)。

<link rel="stylesheet" type="text/css" href="http://hatenablog.com/.shared.css:da060be37d4909f571e895e7bf80e043:/css/theme/base.css,/css/prettify.css,/css/globalheader.css,/css/blogs.css"/>

 Because we can change its ordering by changing URI. Its default ordering is base.css → prettify.css → globalheader.css → blogs.css, but we can change/reduce them like blogs.css → prettify.css → globalheader.css.
 根拠は、URIを書きかえることでCSSの連結順や構成要素を変更できることです。デフォルトはbase.css → prettify.css → globalheader.css → blogs.cssですが、例えばblogs.css → prettify.css → globalheader.cssなどにも変更できます。

 This is interesting approach for me, because I always create pre-compressed file by Maven plugin or build script. I think pre compression is better than dynamically compression. It has any reasons? To provide many design for user?
 これは自分には興味深いアプローチです。特別な理由がない限り、Mavenプラグインによる事前圧縮とかビルドスクリプトによる事前圧縮とかを選ぶと思うので。実際事前圧縮の方がメリットが多いと思うのですが、どうなんでしょう。デザイン設定によって変化するから?

async JS loading

 To load JS, it uses async attribute.
 script要素のasync属性を使っていますね。へー。

<script type="text/javascript" src="http://b.st-hatena.com/js/bookmark_button.js" charset="utf-8" async="async"></script>

Using trunk directly

 This blog loads a JS file from trunk of Google Code. I'm afraid this trunk may be broken. I know this html5shiv project recommends to use their code like this, but...
 Google Codeのtrunkからコードを取ってきていますね。これtrunk壊れたらどうするんだろう。こういう利用を推奨しているプロジェクトだというのはわかっていますが……。

<!--[if lt IE 9]>
<script src="http://html5shiv.googlecode.com/svn/trunk/html5.js"></script>
<![endif]-->

 If I were them, I want to host this file at my own domain -- this may be a difference between B2B developer's mind and B2C (especially Web) developer's mind.
 私ならこのスクリプトを自分のドメインで管理するか、せめてfallack機能を持たせたいと思います。たぶんこれはB2B開発者ならではの感覚で、Web系B2C開発者としては普通の発想なのかもしれません。

I felt its JS isn't elegant

 I think writing JS in this blog is very hard work, and I respect its authors. But, why its naming isn't unified? Priority? Or, my mind is too strict?
 ここまで大きなサービスを作っているのは素直にすごいと思いますし尊敬しますが、意外といろんなところに突っ込みどころありそうな感じです。命名規約統一されてないとか==使ってるとか、確かにどうでもいいんだけどまずはそこ押さえたいよね、と思うところが。優先度を吟味した結果なんでしょうか。自分のマインドが例外排斥に傾いているのか。

 And I found that Hatena Blog uses many codes from Hatena Diary. Reading this code may help me to learn.
 あとはてなブログは「ダイアリーがこんがらがったのでイチから作り直す」わけでは決して無いんだな、というかダイアリーのコードをかなり流用してるんだな、ということがわかりました。一時的な流用なのかもしれませんが。もっと読むといろんなことが学べる気がします。