CoffeeScriptをめぐる議論 第1回 一律に使うのどう思う?

CoffeeScriptとはJavaScriptよりも比較的簡潔な書式で記述し、コンパイルするとJavaScriptを生成してくれるという言語です。この言語を社内で一律使用するか、しないかをめぐり議論になりました。第1回目はスタッフがメリット、デメリットを出し合う様子をお届けします。

発行

  • 中村 享介
  • 高津戸 壮
  • 外村 和仁
  • 德田 和規
CoffeeScriptをめぐる議論 シリーズの記事一覧

はじめに

4月にとあるブログ記事を発端に、CoffeeScriptという言語についての議論が活発化しました。CoffeeScriptとは、JavaScriptよりも比較的簡潔な書式で記述し、コンパイルするとJavaScriptを生成してくれるという言語です。JavaScriptの知識がなければ、ほぼ使えません。

ですからユーザーも、普段からJavaScriptで開発をしているエンジニア、あるいは別の言語に習熟しているプログラマがメインと思われます。

ここではCoffeeScriptの使い方を詳しく解説はしませんが、以下を見てもらうと概要が分かります。

CoffeeScript http://jashkenas.github.com/coffee-script/

Overviewを見ると、左コラムにCoffeeScriptの記述があり、右コラムにそのコンパイル結果=JavaScriptがあります。

CoffeeScriptの概要ページ。典型的なCoffeeScriptの書式とそれがコンパイルされるとどのようなJavaScriptになるかが概観できる。

TRY COFFEESCRIPTのタブをクリックすると、実際にCoffeeScriptを書いて、それがコンパイルされた状態を確認することができます。

CoffeeScriptはJavaScriptとは異なり、コンパイル作業が必要なため、インストールやコンパイルを行う開発環境を整える必要がある。ここではCoffeeScriptとコンパイル結果をWeb上で確認することができる。

CoffeeScriptを使うにはインストールが必要ですし、JavaScriptにするためにはコンパイルすることが必要なので、直にJavaScriptを書くのとは開発の工程が異なります。

主に議論の焦点となったのは、CoffeeScriptを実際の案件(個人的なプロジェクトは別にして)で使用すべきか、使用すべきでないか、といったことでした。使用するメリット、使用するデメリットなどが話題になりました。

さらっと見る程度ならほぼ全員がCoffeeScriptに触れています。高津戸、德田、外村はCoffeeScriptを使ってコードを書いた経験があります。なかでも高津戸は積極的にCoffeeScriptを試していました。

ある日、ピクセグリッドのチャットに高津戸から『CoffeeScriptをみんなで使うのがいいと思うが、意見を聞かせてほしい』と提案があったのです。

その発言をきっかけにピクセルグリッドでもCoffeeScriptをめぐる議論が始まりました。

この記事の元となったチャットは、CodeGridに掲載することを前提にCoffeeScriptの議論をしてもらったものではありません。ですので、スタッフが仕様や事実を調べまくった上で、整然と講演のように話しているわけではありません。

ですが、あえて荒削りな「生の声」を、ほぼリアルタイムで「取って出し」することで、読者のみなさんの参考にしていただければと思っています。

CoffeeScriptとSassを一律に使うのがいい—高津戸

高津戸:これから社内でやるプロジェクトとか、CoffeeScriptとSass*で書いていくのがいいと個人的には思ってるんだけど、どう思う? CoffeeScript使わない方がいいと思う?

德田:CoffeeScriptは悩ましいですね。

高津戸:CoffeeScriptの方がマジで楽だよ。細かいこと気にしなくていいし、人のコード読みやすいし。GitHubもJavaScriptのスタイルガイドはCoffeeScriptだよ。

スタイルガイドでは、「新規作成」と「既存のJavaScript」に項目が分けられている。新規作成分に関しては「CoffeeScriptで書く」となっている。また既存のJavaScriptに関しても「新たにjsファイルを追加することは避ける」とされている。

外村:自社サービスならまだ使うのはありかなとは思いますけど、受注案件だと微妙かなあ。

高津戸:クライアントが運用するからってこと?

外村:まあそうですね。もちろん納品後運用しないケースもあるから一概にやめたほうがいいとは言えないけど、社内で一律CoffeeScriptにするってのは、どのみち無理かなと思う次第。

*注:Sassとは

Sassは(Syntactically Awesome StyleSheets)の略で、拡張CSSのような書き方ができる方法です。Sass用の拡張CSSを記述すると、内部では変数や関数などを利用でき、最終的には通常のCSSが出力されます。

SassやJekyllは編集可能。CoffeeScriptは?—外村

高津戸:でもSassは使ってますよね、かなり。

外村:例えばXXX(案件名)は、今はそういう話はないかもしれないけど、先方で運用する可能性ありますよね。SassとかJekyll*は、吐き出したコードを変更するのは普通のCSSとかHTML編集するのと同じじゃないですか。でもCoffeeScriptはそういうわけじゃないってのが理由ですかね。

高津戸:まあね。でも編集が難しいっていう点ではSassも全く同じだと思うけどな。Jekyllは完全に捨てられるけど。

外村:いやー、全く同じじゃないと思いますけどねー。

*注:Jekyll(ジキル)とは

Rubyで書かれたHTMLジェネレーター。HTMLよりは簡潔なMarkdown書式を使って書かれたテキストファイルをHTMLに変換し、サイトを構築してくれます。GitHubがプロジェクトページ作成などのために提供するサイト構築システムGithub Pagesのエンジンとしても使われています。

複雑なSassはCSS直接編集は難しくない?—高津戸

高津戸:Sassもmixinとかextendとか使っちゃったらかなり無理じゃない?

外村:まあ規模によりますよね。jQuery使うかどうかってのも案件によるから、CoffeeScript使うかどうかも社内一律よりは、案件ごとに決めればいいと思いますけどね。

ひとつのツールに依存しすぎるとだめかな—德田

外村:例えばのりさん(德田のこと)も、最近jQuery極力使いたくないみたいだし。

德田:自分のだめなところが見つかるので、使わなくてもいいときは使ってないです。

高津戸:jQueryに依存しちゃってるてこと?

德田:そうですね。jQueryなかったらこれ書けない……という状態。

高津戸:個人的には結局、underscore.jsなりなんなり使うし、工数減らすためのライブラリだから、そういうのって、そんなに気にしなくてもいいんじゃないかなーとは思うけど。

德田:それはそうです。僕の場合は依存しすぎるとだめだなーっていうだけです。ライブラリなしでできる範囲なら使わないっていうだけです。なので、絶対使わない!とかじゃないし、こだわってるわけでもないです。たぶんSassも使ってると、同じところに着地しそうです(笑)。

CoffeeScriptは敷居が上がってしまうかな—德田

高津戸:のりさんはあんまりCoffeeScriptでは書かんの?

德田:自分で作ってるやつでCoffeeScript使ってみたことありましたけど、最近使ってないですね。(自分の書いたものを)フォーク*してもらえたらしてほしいって思っているんです。CoffeeScriptで書いてたらフォークの敷居が上がってしまうのかなと思って。CoffeeScriptを使わなくても、フォークしてもらえてないですけど(笑)。

高津戸:まーそれはなんとも言えない(笑)。

外村:僕もSpineがCoffeeScriptで書かれていた時点で読むの諦めました(笑)。

德田:そういうのは少なからずありそう(笑)。

高津戸:まーSpineはばりばりCoffeeScriptだからなー。自分はSpineでCoffeeScript覚えたけど……。

*注:フォーク

直訳すれば分岐のこと。複数人が自由にコードにアクセスし、その改変ができるGitHubのようなソーシャルコーディングなどで、他人のコードを元に改変することを「フォークする」といいます。フォークが多いソースコードというのは、それだけ注目度が高く「多くの人のニーズのツボを押さえた」コードであることが多いのです。

メリットをどのくらいでかいと思うかは個人次第—外村

高津戸:わからんなーやっぱり、CoffeeScript使うべきなのかどうか。個人的にはクライアントが直接CSSとかJavaScriptいじりたいって言わない限りは、CoffeeScriptもSassもじゃんじゃん使うべきと思うな。

外村:CoffeeScriptを使うのは全然いいと思うんですけど、会社のルールに持ち込むほどメリットはないかなー派。Sassはそのメリットがあるかなーと思う派。

高津戸:CoffeeScriptいらないでしょうっていう意見でよくあるのが、『JavaScript書くにもJSLint使ってるし、スニペットとかいろいろ用意してるしー』とか、自分で使いやすい環境を整えてるからいらない、っていうのがあると思う。でも、個人的には、そういうのこそ無駄だと思うんだよねー。それは書きづらいJavaScriptをみんな自分なりになんとかしてやってるっていう、まばらなノウハウなので。まばらなノウハウではなくて、CoffeeScriptという「言語」としてカバーしてるのが、結構でかいと思うんだけどなー。

外村:そのメリットがどのくらいでかいと思うかって、個人によって違うと思うんですけど、僕の場合はそのメリットよりデメリットの方が大きいって思うわけです。

高津戸:コンパイルとかの手間ってこと?

外村:それもあるし、cho45さんが書いてたやつが一番大きいですかね。まあ、そういうのもろもろ含めたデメリットです。

外村:のりさんがさっき言ってたフォークしてくれないってのも、cho45さんが言ってることに含まれると思います。

德田:確かに。

高津戸:まーねー。でもやっぱりあれは保守的過ぎだなーって思うかなー。おそらく次のバージョンでSource Maps*にも対応する。『なぜ面倒くさい方法でJavaScriptを書き続けるのか』って感じだな、自分としては。

外村:何度も言うように、あれが保守的と思うか、普通のJavaScriptが面倒くさいと感じるかは人それぞれなので、CoffeeScript使用を会社全体のルールにするのはどうかと思うって話です。

*注:Source Mapsとは

実行速度を速くするために、改行コードを取って圧縮されたJavaScriptや、CoffeeScriptなどがコンパイルした結果のJavaScriptから、圧縮前やコンパイル前のソースコードにたどり着ける技術。技術的にはJavaScriptだけでなく、CSSなどでも同様のことが可能だと言われています。INTRODUCTION TO JAVASCRIPT SOURCE MAPSという記事(英語)で紹介され、注目を集めています。記事では、Source Mapsのデモや、FirefoxやChromeなどのブラウザで始まっている実験的な実装についても触れています。

一緒にやる人は会社の全員の可能性がある—高津戸

高津戸:んじゃー例えば「次のこの案件、俺がCoffeeScriptで書きますよー」っていうのはアリ? そしたらそれいじる場合、他の人も自動的にCoffeeScriptでいじることになるけど。

外村:まあそれは一緒にやる人がOKであればいいんじゃないでしょうか。実際、XXX(案件名)でやってるし、それが悪いとは思わないです。

高津戸:一緒にやる人って、それつまり会社の全員って可能性があるわけだよね*。だから、会社で決めとく必要があると思ったわけですよ、CoffeeScriptで書くのはアリかナシかってー。俺だけCoffeeScriptで書いてしまっていてはまずいわけだし。

外村:んーまあたしかにそうですね。決めが必要ですね。

*注:会社のルール

ピクセルグリッドの場合はエンジニアが5名なので、高津戸が言うように「グループ(一緒にやる人)=会社」となります。もっと大人数の会社であれば、外村が言うように「グループ(一緒にやる人)」単位での取り決めになる可能性もあります。

外村:でも今、この2人でだけ決める問題じゃないからみんないるときがいいかなと思います。

高津戸:そっすなー。まーそこでwhy not!って思うのがワタシと、そういうことです(笑)。

ここまでのまとめ

CoffeeScriptを使おうよ!と言う高津戸と、個人で使うのはともかく、会社全体のルールにする必要はないのでは?と言う外村のやり取りが続きましたが、最後には、使うとすれば会社全体のルールにする必要があるね、という意見で一致しました。

ここまでで出てきた個人個人が感じているメリット、デメリットを簡単にまとめておきます。

メリット

  • これまで個人がなんとかやりくりしてきたJavaScriptの書きにくさを「言語」としてカバーしようとしている(高津戸)
  • 書きにくさがある程度解消されるのは確か(外村)

デメリット

  • クライアントがコードをメンテナンスする可能性がある場合は使えない(高津戸・外村)
  • メンテナンス性が低くなる(外村)
  • CoffeeScriptで書くと、それを読めない人が出現する。例えば、コードのフォークがしにくくなるなど(德田)
  • ひとつのツールに頼りすぎると素のJavaScriptが分からなくなる危険性が自分にはある(德田)

次回はこの議論に中村が加わってきます。ちょっと長いので、今回はこれにて。

中村 享介
PixelGrid Inc.
Jamstackエンジニア

2009年、JavaScriptの会社として株式会社ピクセルグリッドを設立。 多数のWebリニューアル、新規立ち上げを取り仕切った経験を持ち、情報設計、フロントエンド、クラウド活用、開発フローの効率化を得意とする。 Webをより発展させるため、新しくブラウザに実装された機能の活用事例を数多く生み出しつつ、日々、クラウドサービスを利用した効率のよい制作・開発手法の試行錯誤を続けている。現在の興味はWeb Componentsを使ったマークアップの改善とJamstack。 著書に『WebクリエイティブのためのDOM Scripting』(単著:毎日コミュニケーションズ、2007年)など。ここ数年は書籍の執筆をせず、フロントエンド技術情報メディア「CodeGrid」で精力的に執筆活動を行っている。

高津戸 壮
PixelGrid Inc.
テクニカルディレクター

Web制作会社、フリーランスを経て、株式会社ピクセルグリッドに入社。数多くのWebサイト、WebアプリケーションのHTML、CSS、JavaScript実装に携わってきた。受託案件を中心にフロント周りの実装、設計、テクニカルディレクションを行う。スケーラビリティを考慮したHTMLテンプレート設計・実装、JavaScriptを使った込み入ったUIの設計・実装を得意分野とする。 著書に『改訂版 Webデザイナーのための jQuery入門』(技術評論社、2014年11月14日)がある。 CSS Nite 2011ベストセッションにおいて、全170セッションの中から、ベスト10セッションに、CSS Nite 2013ベストセッションでは、全278セッション中、ベスト20セッションに選出。

外村 和仁
フロントエンド・エンジニア

HTMLコーダー、JavaScriptプログラマ、PHP、Perlのプログラマといった職務を経験後、2010年に株式会社ピクセルグリッドに入社。大規模サイトの運用、開発の経験を活かしてバックエンドからフロントエンドまで幅広く担当。2015年、退社。好きな言語はJavaScriptとRuby。 著書に『ノンプログラマのためのJavaScriptはじめの一歩』(単著:技術評論社、2012年11月7日)があり、共著も多数。このほか、WEB+DB PRESS、Software Designなどにも寄稿。

德田 和規
PixelGrid Inc.
テクニカルディレクター

HTML/CSSコーダーとしてWebに触れ、その後WebディレクターとしてJavaScriptの特性を活かしたサイトのテクニカルディレクションからUI開発までを経験。2011年にフロントエンド・エンジニアとして株式会社ピクセルグリッドへ入社。 著書に『jQuery逆引きマニュアル』(共著:インプレスジャパン、2010年12月17日)などがある。

Xにポストする Blueskyにポストする この記事の内容についての意見・感想を送る

全記事アクセス+月4回配信、月額880円(税込)

CodeGridを購読する

初めてお申し込みの方には、30日間無料でお使いいただけます