こんにちは、内製開発グループの山下です。
フロントエンドエンジニアという仕事
「フロントエンドエンジニア」という職業がわりと人気のようです。
業務内容としては「WebアプリケーションやWebサイトのフロントエンド部分を担う」や「HTMLやCSS、JavaScriptを使って、Webサイトやサービスを実装する」といった説明がされています。私はずっと「Web技術者」と自己紹介してきましたが、フロント周りの仕事が多かったので、この「フロントエンドエンジニア」に属すると思っています。
今回は、この領域において私が経験した「最大の驚き、ギャップ、技術的な飛躍」である「トランスコンパイラ」について投稿します。
存在する大きなギャップ
現在ではフロントエンドエンジニアの領域は非常に広くなっています。さきほどご紹介した説明はだいぶ過去のものですね。フロントエンドエンジニアの担当領域のごく一部だとおもいます。
フロント周りの開発では JavaScript 言語が主に用いられます。この開発環境には様々なバリエーションが存在します。この開発環境ですが、ひとつ大きな世代(時代)のギャップがあって、私はそれを「バベル前」「バベル後」と呼んでいます。これが今回の投稿の主題です。
以後、ちょっと JavaScript の歴史をふまえての話になります。
バベル前
JavaScript の黎明期、まだ IE や Netscape という Webブラウザが覇権を争っていた頃、開発者を悩ませていたのはブラウザ間の非互換性でした。各ブラウザが競って機能拡張し、また ECMAScript のような標準への準拠も弱かったため、ブラウザごとの専用ロジックを用意するのが普通でした。このころの JavaScript はWebページの構成要素のひとつ、といった感じで開発言語としてはあまり注目されていなかった気がします。
2005年ぐらいと記憶していますが、Google MAP などを契機に、Ajax を中心とした JavaScript 言語のブームがありました。
JavaScript が活用されていくにつれ、ブラウザ間の非互換性も減らす方向で対策が進みました。Prototype、jQuery、Mootools、YUI、Dojo などのフレームワークが登場し、ある程度は差異を吸収するようになりました。また古いブラウザーで最近の機能を使えるようにするための仕組みとして、ポリフィルと呼ばれるライブラリ群も開発されました。
これらの流れを経てやっと、JavaScript は開発言語として十分に使える状況になった、とおもいます。
しかしこれらの技術は、環境ごとの差異を完全には隠ぺいしてくれません。JavaScript 処理系による差もありますし、新しく追加される機能はブラウザごとに対応状況を気にする必要があります。なので JavaScript 開発者は Mozilla の MDN Web Docs ページなどを開き、各機能の普及状態をひたすら調べます。各機能の説明ページの末尾にある「ブラウザーの互換性」表を常に確認して、案件の対応ブラウザが全て実装済みなことを確認してから、やっと利用する感じ。
この時点での JavaScript 開発者の行動は基本的に「最大公約数」的ですね。なるべく小さい機能セットで開発を進めようとします。
「新しい機能が追加された？いいね！でもそれ、実務で使えるのは何年後よ？」といった感じです。。
バベル登場
JavaScriptトランスコンパイラの登場が全てを変えました。これまでの互換性の制約がなく、新しい機能をほぼ制限なしで使えます。
開発者は、トランスコンパイラを使用して新しいJavaScript言語機能を使用し、発展途上のブラウザが処理できるバージョンの JavaScript にソースコードを変換できる
著名なトランスコンパイラであるバベルについて、以下を参照してください。
バベル後
フロント側が停滞している間に、Node.js など JavaScript を利用できる領域が広がっていました。これらの環境では互換性による制約が少なかったため、驚くほどの勢いで言語仕様、標準ライブラリ、ミドルウェアなどが進化しています。
トランスコンパイラの登場により、これらの数年間の進歩と、その文化が一気にフロント側にもたらされることになりました。まさに文明開化のごとく。。
現時点だと React (Next)、Vue (Nuxt) フレームワークの利用が主流でしょうか。周辺ライブラリも含めて、それぞれ大きなエコシステムを形成しています。しかし新たなフレームワークが続々と登場しています。
また大規模開発では JavaScript を拡張して静的な型チェックなどを追加した TypeScript 言語が多く使われています。JavaScript の特性を生かした緩やかな拡張ですが、そのメリットを生かそうとすると設計段階からの考慮が必要におもわれます。
できる事が一気に広がったので、開発者としてはいろいろ楽になりました。しかしその便利さに比例して、学ぶこともかなり増えている気がします。
開発者へのメッセージ
さて、私の視点からの「バベル前後」の歴史の振り返りはここまで。最期にこの投稿でお伝えしたいことをまとめます。
若いフロントエンドエンジニア、またはそれを目指している方にお伝えしたいのは、トランスコンパイラという技術のもつ力です。その登場以前の歴史を少し知ってほしかった。
ビルド後に dist フォルダなどに生成された js ファイル。普段はあまり見ないでしょうし、人間の読むコードには思えないその処理のなかに、過去のJavaScript開発者のノウハウが凝縮されていることを知ってほしい。また小規模もしくは長期的な案件では、まだトランスコンパイラを用いない「バベル前」の開発プロセスが残っている現場もあるかもしれません。
そして経験のあるWeb開発者の方にご提案したいのは「トランスコンパイラを用いた開発環境を体験しておきましょう」です。
私が初めて体験した時は、カルチャーショックを受けましたし、これまで蓄積したノウハウの多くをリセットされたと感じました。新しく学ぶことが数多くあり、キャッチアップ大変でした。。
特にトランスコンパイラを利用した経験なく「フロントエンドエンジニア」として新しい案件に参加しようとしているWeb開発者の方。バベル前のWeb技術で頑張っている、熟練の開発者の方。バベル後になってからも環境の進化は続いており、ギャップは日々どんどん大きくなっています。なるべく早く、事前に体験しておくことをお勧めしたいです。
というわけで
フロントエンド開発におけるトランスコンパイラ技術について、またそれにより私の受けた衝撃について、簡単にお話させていただきました。
読んでいただきありがとうございました。マネックスグループの採用にご興味のある方は、ぜひ以下募集をご覧ください。
