レトロエンジニアのための近代Webフロントエンド事情

フロントエンド開発という言葉があちらこちらから聞こえてくる。

「反対語はバックエンド開発だから、サーバとかCUIじゃない、アプリとかGUIあたりのことを指す広い意味の言葉だよね。」

・・・とか思ってたらとんでもない。

世の中ではJavaScript界隈を限定している風な使われ方をしている。
私のような C/C++ メインのレトロエンジニアは肩身が狭くなるばかりである。

本文は、近年のWeb技術に追いつこうと調査した結果のメモ書きである。
n番煎じの内容だが、Web業界にいない人間の視点 なので、私と同類のレトロエンジニア等、一部の人には新しい気付きが与えられるかもしれない。

詳しい人の添削・ツッコミは大歓迎。

詳細はリンク先に任せ、私が思う「わかりやすい順序」で、調べたことをざっと紹介していく。

きっかけ

読み飛ばしてもよい。

Reactを使うとなぜjQueryが要らなくなるのか

数年前、仕事で jQuery mobile をかじって、その設計に感心したこともあった。
あの便利な jQuery はもはや要らないらしい。

気になって読んでみたが、何を言っているのか全然わからなかった。
「こうなりゃわかるまで調べてみるか」 から _「せっかくだから投稿ネタにするか」_と思い至ったのがきっかけ。

ES2015 (ES6)

• ES2015 (ES6)についてのまとめ
• 【最低限知っておきたい】ES2015/ES6の基本構文とブラウザ対応状況

JavaScript の最新言語仕様。
いろいろな機能が増えるようだが、ブラウザの対応状況はまちまちのようだ。

概要を見ると、どうもコンパイル型言語に近づいてきているようだ。

• ブロックスコープ、const が使える
• クラス構文、クラス継承、可変長引数、デフォルト引数・・・
• アロー関数 (C# のラムダ式と同じ感じ。むしろ違うところを教えてくれい。)

Web業界が、大規模開発に向かない旧JavaScriptから卒業したがっていることが感じ取れる。

トランスパイル　(transpile)

ある言語で書いたソースコードを別の言語のそれに変換する機能。
この機能をもつものをトランスパイラ ¹ という。

コンパイラがソースコードを吸ってバイナリを吐くのと同じように、スクリプト言語界では、トランスパイラがソースコードを吸ってソースコードを吐く。

このトランスパイラが、近年のWebフロントエンド開発の要の一つとなっているようだ。
これらはどのように使われるのか。

babel

そんなトランスパイラの代表的なものの一つ。

• Babelの手ほどき 第1回 Babelとは

次世代のJavaScriptの標準機能を、ブラウザのサポートを待たずに使えるようにするNode.js製のツールです。次世代の標準機能を使って書かれたコードを、それらの機能をサポートしていないブラウザでも動くコードに変換（トランスパイル）します。

トランスパイラの大きな役割のひとつがこれ。
つまり、トランスパイラが現状のブラウザに合わせたコードを吐いてくれるから、 ES2015/ES6 のブラウザ対応状況なんて関係ないぜ、ということらしい。

AltJS

• フロントエンドエンジニア必読！AltJS選定・導入前に気をつけるべき３つのこと

AltJS（Alternative JavaScript）とは、その名の通りJavaScriptの代替言語です。

さらに、ES2015/ES6 に限らない JavaScript 以外のもっと安全・便利な言語で開発していこうぜ、というのが現代的らしい。

代表的なものを名前だけ挙げておく。

• CoffeeScript
• TypeScript
• Dart
• Haxe
• jsx

Googleトレンド によれば、TypeScript が一人勝ち、jsx　が上昇中で、他は下降気味っぽい。(2016年11月現在)

ちなみに冒頭の React は jsx と相性がいいらしい。(jsxでなくても書けるが、jsxを前提としているフシがある。)
そして TypeScript (のトランスパイラ) や babel は jsx をトランスパイルできるらしい。

(2016/11/14 追記: AltJS としての JSX と React のJSX は異なるものだとの指摘あり。上記記述は React JSX に対するものである。)

きっとデキるWebエンジニアは、複数のAltJSを状況に応じて使い分けているのであろう。

SASS

• とほほのSass入門 ²

トランスパイラは、JavaScript以外にも使われる。
SASSは、CSSの代替言語³として今一番人気のもの。やはりトランスパイルによって、ブラウザが対応する CSS に変換して使うことになる。

***

ここまでが、トランスパイラを中心とした脱旧JavaScriptの流れの話。

次はモジュールの話である。自分なりの解釈として、
「上をコンパイラの話とすれば、次はリンカの話」
と思って読むと割合すっと頭に入るかもしれない。⁴

---

モジュール分割・モジュール結合

モジュールという言葉は、私の脳内辞書では「機能的なまとまり」を表すややあいまいな言葉⁵であるが、JavaScript界ではわりと明確で、 「機能的なまとまりごとに切り分けた各JavaScriptソースファイル」 を指しているようだ。

つまり、モジュール分割とは 「JavaScriptソースファイルを分割すること」 を指し、モジュール結合とは 「分割されている各種JavaScriptソースファイルを1つのWebアプリケーションにまとめ上げること」 を指す。

私が知る時代の JavaScript のモジュール分割・結合とは以下の様なことだった。

• コードを機能的なまとまりごとのファイルに分けて記述する
• 分けたファイルを順番にHTMLファイルの <script> タグで読み込む

どうも、この方法はいろいろ問題があるらしくて、みんなもう使いたくないらしい。

そこで、ES2015/ES6 で新しい分割・結合のルール = モジュールAPI が加わることになった。

「じゃあみんなでこれに準拠した JavaScript 書こうぜ」 で済めば話は簡単なのだが、残念ながら、それではWeb上に散らばる無数のJSドキュメントを読み解くことはできない。

なぜなら、ES2015/ES6 でモジュール仕様が策定される前に、別の標準仕様を作っちゃった人たちがいて、それを採用しちゃった人たちがいるからである。

これらの仕様は、長い目で見れば廃れていくのだろうが、何しろ既に広まってしまっているので、一応知っておかないと、それを前提にしたドキュメントが頭に入らない。

• JavaScriptのモジュール管理(CommonJSとかAMDとかBrowserifyとかwebpack)

ここで紹介されている2つの仕様が代表的なものらしい。

AMD / Require.js

AMD という仕様に基づいて作られたJSモジュールを結合してくれるのが Require.js というツールである。どうも死んだらしい。

• AMD & RequireJS

CommonJS / Browserify

上記と同様、 CommonJS のモジュール仕様に基づいて作られたJSモジュールを結合してくれるのが Browserify というツールである。

• 旧石器時代のJavaScriptを書いてる各位に告ぐ、現代的なJavaScript超入門 Section2 ～CommonJSモジュールと仲良くなろう～

かの有名な Node.js が CommonJS (の派生)を採用しているからか、世間的にはこちらの方が優勢のようだ。
browserify を _「ブラウザ上でNode.js用モジュールを使えるようにするもの」_と説明しているドキュメントを見かけるが、本質は 「Node.js と browserify は同じ仕様をベースにしている」 ということか。

ES2015 / Babel

require.js, browserify に対して、 babel でならES2015/ES6のモジュールAPIが使えるらしい。

• (Babel 5における)ES6のモジュールを解説してみた

2015/11/25 追記
Babel単体ではES2015モジュールを結合できないと指摘があった。別にリンカが必要 ⁶らしい。
詳細はコメント欄か、以下のリンクを参照のこと。

• Babel: import / export をブラウザ向けに Browserify で実現する
• 春からはじめるモダンJavaScript / ES2015

これから新しく始める人達が取りうる選択肢は、おそらく2択。

• 「ああ、昔の人はそう書いてたらしいね」 と流して、 ES2015/ES6 モジュール仕様を使う。
• 現時点でドキュメントを手に入れやすく学びやすい CommonJSモジュール仕様 を使う。

*** さて、**コンパイラ**と**リンカ**があれば一応実行ファイルはできるが、 実際の製品開発ではその他にも、パッケージングとかコードサイニングなどの作業がある。 そして、それらを一括して行うことを**「ビルド」**と呼んだりする。

次は、JavaScript におけるビルドツールの話。

---

タスクランナー

この言葉の定義を知りたくて Web をさまよったが、なかなかしっくりこない。

「タスクを自動化するツール」って言われても、そんなもんこの業界にはいくらでもあるわ。そもそも大抵のソフトウエアは何らかのタスクを自動化するために作られとんのじゃ。

至る所で 「Grunt / Gulp はタスクランナーの一種である」 という言葉を目にするが、どんなに調べても 「タスクランナーとは、Grunt や Gulp のことである」 と言っているようにしか見えない。

とにかく、代表的なタスクランナーとして今は　Grunt(グラント) と Gulp(ガルプ) があって、どうやら Grunt は死んだらしい。

そしてそれらは、トランスパイルやモジュール結合など、ビルドに関するさまざまな作業を一括し、自動化してくれるらしい。

• Gulp.js入門 – コーディングを10倍速くする環境を作る方法まとめ
• タスクランナーGulpでWeb制作を効率化しよう
• フロントエンド開発を加速する　各タスクランナーの長所短所

「タスクランナーとは何か」みたいなところでいちいち突っかかっていては、秒進分歩の Web 業界ではやっていけないということだろうか。
・・・と思ったが、Web業界にもモヤモヤを感じる人達もいるようだ。

• 最近のビルドツールって何なの？
• [意訳]私がGulpとGruntを手放した理由

私のモヤモヤは直感的なものだが、上記の方々は実体験から語られているので説得力がある。
前者の make との比較の話が面白い。

まあ、make や shell と違って全部 JavaScript で書けるところが便利と言えば便利か。

Webpack

そんなわけで、今最も上り調子のビルドツールらしい。

• 5分でわかるWebpack入門
• webpack で始めるイマドキのフロントエンド開発
• WebPackを使ってJavaScriptを効率的に書くチュートリアル【入門編】

流し読みしたくらいでは違いはよくわからないが、もし使うことになったら Grunt/Gulp は飛ばしてこれだけ調べればいいような気がする。

しかし、これもタスクランナーの一つだという人もいれば、いやいやちょっと違うという人もいるし、これがあれば、browserify も gulp もいらん、という声もあれば、いいとこ取りで併用していくんだぜ、という声もあったりする。

なんか、気持ちはわからんでもないが、「もう少し落ち着けよ」と言いたくなる。

・・・いや、そんなこと言っちゃいかんな。おそらく今はWeb業界の試行錯誤期間なのだろう。こういう活気のあるところから、次世代の基盤技術が生まれてくるに違いない。

個人的には「枯れている」ことをありがたがるよりよほど好ましい。異論は認める。

---

長くなった⁷ので、一旦終わりにする。続けるかは未定。
ほんとはこのあと、フレームワークの話があったりして、そこでようやく React も出てくることになるが、そこまでいかなかった。

代わりと言ってはなんだが、最後に類似のテーマで書かれた先人のドキュメントをいくつか紹介しておく。

• 春からはじめるモダンJavaScript / ES2015
• これを選んでおけば間違いない2016年流行りのCSS・JavaScript・タスクランナー
• JavaScript フロントエンド開発環境の私的まとめ
• 僕なりのフロントエンド開発環境 (アップデート版もある)

1. translate + compile と思われる。エンコードからトランスコードという言葉が派生したのと同様か。 ↩

2. このサイト今でも現役で更新してるんだ・・・。すげー。 ↩

3. AltCSSという言葉はみたことない。 ↩

4. 実際は gcc がコンパイルもリンクもやってくれるように、以下で紹介するツールもリンクだけに特化したものではないようだ。 あくまでも「そう捉えるとわかりやすい」と私が思ったということで。 ↩

5. あいまいでない方の言葉は「クラス」とか「ライブラリ」とか。 ↩

6. 所詮 Babel はコンパイラということか。 ↩

7. 文章が、というより、私がこれを書いている期間が。文章書くのが得意でないため、推敲ばかりでなかなか前に進まない・・・。 ↩