本連載では、フロントエンド開発に必要な知識・技術を解説しています。
HTML・CSS・JavaScriptについてはある程度知識のある方、もしくは書籍や他サイトにてそれらの知識を習得中の方を対象としています。

1. 拡張言語

近年のフロントエンド開発では、生のHTML、CSS、JavaScriptを記述してゆくことはあまり多くはありません。HTMLであればHamlやJadeなどのテンプレートエンジン、CSSであればSASSやLESSなどのCSSプリプロセッサ、JavaScriptであればCoffeeScriptなどのaltJSなどを使用することが多くなっています。
テンプレートエンジンもCSSプリプロセッサもaltJSも、全てそれぞれの言語を生成するための言語や仕組みになります。ここではまとめて拡張言語と呼んでいます。

2. テンプレートエンジンとは

テンプレートエンジンは主に、HTMLの共通部分をパーツ化することで、構築や更新を楽にするためのものです。

例えば合計で100ページにものぼるサイトを構築するとして、その全てをHTMLで納品しなければならない場合、共通するナビゲーションメニューやフッターに修正が出た場合、100ページ分のHTMLファイルを修正する必要が出てきます。実際にはそのようなサイトの場合、サーバーサイド言語によって共通部分を別ファイル化することで解決しますが、サーバーや納品先の都合上HTMLしか扱えない場合、テンプレートエンジンを使用します。テンプレートエンジンを使用する場合、最終的にはプレーンなHTMLが生成されます。

また、ほとんどのテンプレートエンジンでは変数や条件分岐・ループが使用でき、記述方法もHTMLより簡潔であるため、共通部分の少ないWebサイトにおいてもテンプレートエンジンを使用するメリットがあります。

代表例として以下のものがあります。

  • Haml
  • Slim
  • Pug(Jade)
  • EJS
  • Handlebars
  • Mustache
    ・
    ・
    ・

と、あげてゆくとキリがありませんが、それぞれのテンプレートエンジンはRuby製、PHP製、JavaScript製など様々な言語で作られており、得意な言語やプロジェクトごとに使い分けてゆく必要があります。

3. CSSプリプロセッサとは

CSSプリプロセッサもテンプレートエンジンと同様、CSSをより簡潔に記述するためのものになり、変数や条件分岐などが使用できます。

また、CSSとの大きな違いが、ネスト構造で記述できることです。
CSSではセレクタに要素の親子関係を指定する際、同じ親要素のセレクタを何度も記述する必要があります。
CSSプリプロセッサを使用すると、以下のように簡潔に記述できるようになります。

■CSSでの記述
.container {
  color: #000;
}

.container .text {
  color: #666;
}

.container .text a {
  color: #f90;
}
■CSSプリプロセッサ（SCSS）での記述
.container {
  color: #000;

  .text {
    color: #666;

    a {
      color: #f90;
    }
  }
}

CSSプリプロセッサの代表例は以下の通りです。

  • SASS
  • SCSS
  • LESS
  • Stylus

4. altJSとは

JavaScriptはHTMLやCSSのマークアップ言語とは違い、プログラミング言語ですのでもともと変数や条件分岐の機能があります。ではなぜJavaScriptを拡張する必要があるのかというと、他の多くのプログラミング言語にはあってJavaScriptにはないClassの構文を使用するためになります。厳密にはJavaScriptでもClass（的なもの）は定義できるのですが、記法が他のプログラミング言語とは大きく異なります。また、JavaScriptは変数の型が自動的に変換される動的型付けを採用しており、altJSによっては他の言語で採用されている静的型付けにしているものもあります。

数年前までは上記のような考えだったのですが、ES2015(ES6)が策定されてからはES2015の文法に準拠したaltJSをトランスパイルする流れになっています。
その点では、現状以下のaltJSが一歩リードしているように思われます。

  • Babel
  • Buble
  • TypeScript

5. 何を使えばいいか

現在拡張言語は過渡期にあり、次から次へと新しいものが出てきています。まずは人気のものを使用してみて、使いづらいなと感じたら、別のものを試してゆくのがいいかと思います。
参加プロジェクトごとにチーム全体で開発言語を合わせてゆく必要もあるかと思いますので、その際に柔軟に対応する必要がありますが、一つ二つ使えるようになればそのノウハウが他の拡張言語にも活かせるはずです。