このハンズオンでやることJavaScriptによるフロントエンド界隈の全体像について簡単に紹介します。
想定時間1h
前提知識・用語特になし

# フロントエンド Overview

ここでは各フロントエンドのハンズオンに進む前に、フロントエンド界隈の全体像について簡単に紹介します。

# WebブラウザとWeb関連技術の変遷

現在に至るまでに、Webブラウザがどのような経緯を経て、どのように情況が変わってきたのかを振り返っていきます。

この文書では「Webアプリケーション」という言葉を、Webサイト・Webシステム・Webコンテンツと呼ばれるような、Webブラウザを介して利用できるサービスやコンテンツの総称として使うことにします。

# World Wide Web の始まり(1980年〜1993年)

1980年、欧州原子核研究機構(CERN)に在籍していた「ティム・バーナーズ=リー(Tim Berners-Lee)」は、数千人の研究者や職員の間で情報伝達や論文の共有を効率的に行うシステムの開発を行っていました。そこで彼は、CERN内の様々な環境、異なるシステム間でもネットワークを通じてデータをやりとりでき、文書と文書を関連付けて情報にアクセスできるハイパーテキストシステム開発します。

1989年、ティム・バーナーズ=リーはこの仕組みを世界中で広く使えるようにするため、グローバルハイパーテキストプロジェクトを立ち上げて HTML (HyperText Markup Language) の概念を提案します。翌年、1990年には具体的な提案書 WorldWideWeb: Proposal for a HyperText Project を公開し、同年12月に NeXTSTEP 上で動作する世界初のWebブラウザを完成させました。これが World Wide Web の始まりです。

最初のWebブラウザは特定のOS上でしか動作しないものでしたが、1993年にはクロスプラットフォームな(異なるOS上で動作する)ブラウザである Mosaic が登場しました。Mosaic は音データの利用や img 要素タグによるインラインの画像表示をサポートしており、現在のWebブラウザの発展に繋がっていきます。

その後は新しいWebブラウザも次々登場し、各ブラウザがシェア争いを繰り広げるブラウザ戦争と呼ばれる時代に突入します。

  • 第一次ブラウザ戦争(1994年〜2000年)
  • 第二次ブラウザ戦争:前期(2000年〜2007年)
  • 第二次ブラウザ戦争:後期(2008年〜2014年)
  • 第三次ブラウザ戦争(2014年〜現在)

# 第一次ブラウザ戦争(1994年〜2000年)

  • Netscape Navigator 1.0
  • Internet Explorer 1.0

Netscape Navigator と Internet Explorer の2強時代です。Mosaic と同様の機能をベースに、それぞれのブラウザが先進的な機能を独自に盛り込んでシェアを獲得しようとしていました。

1995年にリリースされた Netscape Navigator 2.0 では、ブラウザ上でスクリプトを動作させて動的にコンテンツを操作する仕組みが実装されました。これは LiveScript という名称で開発されていましたが、Netscape Communications Corporation と提携関係にあった Sun Microsystems(現Oracle)が開発し、当時人気を博していた Java にあやかって JavaScript という名称に改名されました。

Internet Explorer も負けじと JScript という名のスクリプト言語を実装していました。ライバル社同士が競って独自の機能開発を行ったため、Netscape Navigator 向けのスクリプトは Internet Explorer で動作しないといった状況が当たり前であり、スクリプトを用いてWebアプリケーションを開発する側は2種類のコードを書かざるを得ませんでした。

この状況と並行して、ティム・バーナーズ=リーが創設した World Wide Web Consortium (W3C) は各種技術の標準化を推進してきました。W3C の勧告に従ってWebブラウザの実装は徐々に標準化されていく……はずでしたが、その実現には長い年月がかかることになります。

# 第二次ブラウザ戦争:前期(2000年〜2007年)

  • Internet Explorer 6, 7
  • Netscape 7
  • Safari 1.0
  • Mozilla Firefox 1.0
  • Opera 5.0

2000年前後には HTML 4.01 や XHTML 1.0 の仕様が勧告され、インターネットが庶民にも普及したことも相まって、Webアプリケーションの利用や作成が身近に行われるようになりました。

2001年に Internet Explorer 6 が登場し、2002年に Netscape 7 が、2003年に Safari 1.0 が、2004年に Mozilla Firefox 1.0 が登場しました。2000年には無償利用が可能で Mac にも対応した Opera 5.0 が登場しました。

この頃から Internet Explorer 6, Netscape 7, Safari, Mozilla Firefox, Opera のシェア争いが始まりましたが、Internet Explorer 6 のシェア率が非常に多く、Webアプリケーション開発者は Internet Explorer で期待通り動作するように開発することが使命となっていました。2006年には Internet Explorer 7 が登場しました。

関連技術の標準化は W3C によって行われていましたが、2004年にはWebブラウザを開発するベンダー(Apple, Mozilla, Opera)によって WHATWG(ワットダブルジー;Web Hypertext Application Technology Working Group)という組織が結成され、W3C とは別軸でWebブラウザ開発側の視点から標準化が行われるようになります。

また、JavaScript で外部に非同期通信をしてデータを取得して利用する仕組み(Ajax)を活用した画期的なコンテンツが 2005 年に登場しました。Google Maps です。これをきっかけに、Webアプリケーション上で Ajax を利用した動的なコンテンツ作りが盛んになり始めました。

# 第二次ブラウザ戦争:後期(2008年〜2014年)

  • Internet Explorer 8, 9, 10, 11
  • Opera 10 以降
  • Safari 3 以降
  • Google Chrome 1.0 以降
  • Mozilla Firefox 3.0 以降

2008年に Google Chrome 1.0 が登場し、同年に標準化が大幅に進んだ Mozilla Firefox 3.0 が登場しました。Internet Explorer は、2009年に IE8 が、2011年に IE9 が、2012年に IE10 が、2013年に IE11 が登場しました。Safari と Opera も後継バージョンをリリースし、Internet Explorer, Safari, Opera, Google Chrome, Mozilla Firefox の5強時代に突入します。この頃を機に Internet Explorer 6 のシェア率は徐々に落ち始めました。

WHATWG による標準化や新しい技術の研究が進み、W3C が提唱する標準化よりも、WHATWG が考えるWebブラウザベンダーにとって価値がある仕様の策定が積極的に行われるようになりました。その成果として、2014年に HTML5 が登場しました。

この時期には利用できるブラウザの選択肢が広がったこと、モダンブラウザと呼ばれる比較的新しいブラウザの実装が標準化されてきたこともあり、古いブラウザ(レガシーブラウザ)を使う人が激減しました。そのためWeb開発者は古いブラウザを考慮する必要がなくなり、新しい技術を積極的に取り入れられるようになりました。

そうした背景もあり、2010年前後には JavaScript を中心にWebアプリケーションを開発するという手法が流行り始めました。これまでサーバ側で実現していたMVCアーキテクチャをクライアント側(JavaScript)でやってしまうというものです。そうした中で登場したのが Single Page Application (SPA) というものであり、それを実現するためのフレームワークである Angular や React, Vue.js の人気に火がつきました。

# 第三次ブラウザ戦争(2014年〜現在)

  • Safari 6 以降
  • Opera 15 以降
  • Vivaldi 1.0, 2.x
  • Microsoft Edge 13 以降
  • Mozilla Firefox 30 以降
  • Google Chrome 32 以降

HTML とその周辺技術を含む、広義な意味での HTML5 の登場によってWebブラウザの役割が変わってきました。

HTML5 と関連する技術仕様では、Webブラウザが単に HTML を文書として読むということに留まらせず、例えば Canvas 要素や WebSocket といったリッチな表現を行ったり、Local Storage 機能を利用したり、JavaScript によってより複雑で高機能な操作が可能となるような DOM (Document Object Model) の新しい仕様が考えられたりしています。CSS の仕様も発展し、3D Transition や CSS アニメーションを始めとする多彩な表現がブラウザ上で実現できるようになりました。

Webブラウザについては、2015年に Microsoft Edge と Opera の後継とも言える Vivaldi が登場しました。また、数年ごとだったメジャーバージョンリリースを6週間ごとのラピッドリリースに切り替えた Google Chrome と Mozilla Firefox については、2019年時点でバージョンが "70" 近くにもなっています。

昨今では HTML5 の登場から数年経ち、多くの先進的な機能を安定して利用できるようになってきました。JavaScript アプリケーションとも言うべきコンテンツも増え、SPA フレームワークの活用が求められることも増えてきました。

# Webブラウザの情況:まとめ

  • 第一次ブラウザ戦争(1994年〜2000年)
    • 今の JavaScript の元となった独自言語である LiveScript と JScript が登場した時代。
  • 第二次ブラウザ戦争:前期(2000年〜2007年)
    • IE6 全盛期。JavaScript の仕様が少しずつ標準化され始める。
    • IEの標準化が遅く、IE向けとそれ以外のブラウザ向けに複数のコードを書く必要があった。
    • 各種ブラウザの実装差異を吸収するために prototype.js や jQuery が登場した。
  • 第二次ブラウザ戦争:後期(2008年〜2014年)
    • Chrome の登場。現在に近いレベルの標準化が行われた。
    • IE6 のシェアが低下し始め、先進的な機能を取り入れたWebアプリケーション開発が増え始めた。
  • 第三次ブラウザ戦争(2014年〜現在)
    • HTML5 の登場。JavaScript を中心としたWebアプリケーション開発が増え始めた。
    • Webブラウザの標準化も進み、旧来のライブラリ以外の選択肢も増えたことで jQuery を使う必要性が少なくなった。
    • Angular や React, Vue.js フレームワークの機能も充実したことで SPA 開発を採用することも増えてきた。

ここまでの説明ではデスクトップアプリケーション以外には言及しませんでしたが、モバイルアプリケーションでも同様に新しい時代の様々なWebブラウザが進化をし続けています。そのような環境にあるWebブラウザを使って我々は何を創り、どのような価値を生み出すことができるのでしょう。その答えを見つけられるように、フロントエンドの歴史や仕組みに興味を持ってもらえればと思います。

# フロントエンドとバックエンドの違い

「フロントエンド」と「バックエンド」、「クライアントサイド」と「サーバサイド」という風にシステムの役割や領域を区別して呼ばれることがあります。フロントエンドがどのようなものを指すのかについて確認しておきます。

# WebサーバとHTTPの仕組み

まずは HTTP 通信について触れておきます。抽象的な話になりますが、コンピュータ・ネットワーク上において、何らかのサービスを提供する側は「サーバ」、サービスを受ける側は「クライアント」と呼ばれます。

Webページを閲覧できるように配信するために「Webサーバ」を用意し、Webページを閲覧したい側(Webブラウザ)はWebサーバにリクエストを送ります。要求を受けたWebサーバは、要求を送ってきたWebブラウザ側に対してページの内容をレスポンスします。このような動作によって、Webブラウザは閲覧したいWebページの内容を取得できます。

データの取得(GETリクエスト)の例:

                (1) このURLのWebページを見せてください
[クライアント] -----------------------------------------> [Webサーバ]

                                                                  (2) 内部処理
                                                                  ┌───┐
[クライアント]                                            [Webサーバ]<──┘


                (3) Webページの内容をどうぞ
[クライアント] <----------------------------------------- [Webサーバ]

データの取得以外に、例えば SNS に投稿するといった、データの処理をリクエストするケースもあります。

なお、ここでは簡略化のために HTTP メソッドの種類として取得をGETリクエスト、処理をPOSTリクエストと示していますがこれは正確な分類ではありません。興味があれば HTTP メソッドの種類や、安全性・冪等性といった特性について調べてみてください。

データの処理(POSTリクエスト)の例:

                (1) このデータを登録してください
[クライアント] -----------------------------------------> [Webサーバ]

                                                                  (2) 内部処理
                                                                  ┌───┐
[クライアント]                                            [Webサーバ]<──┘


                (3) 完了しました
[クライアント] <----------------------------------------- [Webサーバ]

このように、クライアント(Webブラウザ)とサーバ(Webサーバ)の間で通信を行うことによってサービスの提供と利用が成立しています。このときに、クライアントとサーバがどういう通信を行えばよいかを定めているのがプロトコルであり、HTML などのコンテンツの送受信を行うための「Webサーバ」とのやりとりを決めているのが「HTTP」というプロトコルです。

通信プロトコルには他にも様々なものがあります。FTP, SSH, SMTP, DNS, HTTP, HTTPS, MySQL, PostgreSQL, ..., 適当に書き出してみましたが、サーバが提供するサービスや通信の方法の数だけ様々なプロトコルが存在しています。

HTTP においては、「(1)クライアントが HTTP リクエストをする」、「(2)Webサーバが内部処理をする」、「(3)サーバがクライアントに HTTP レスポンスをする」というやりとりを通じて、最終的に HTML や CSS, 画像の表示を行ったり、Webアプリケーション上でデータの投稿や保存といった処理を実現しています。

# フロントエンドの範囲

バックエンドとは、主にサーバサイドで行われている処理を意味します。上図の「(2)内部処理」の部分がバックエンドであり、クライアント(Webブラウザ)に渡されるデータを(データベース処理やサーバサイドスクリプトを利用するなどして)動的に生成することがバックエンドの仕事です。

フロントエンドとは、主にクライアントサイドで行われる処理を意味します。上図の「(3)Webページの内容」の部分がフロントエンドであり、クライアント(Webブラウザ)に渡されるデータそのものを使って表現することがフロントエンドの仕事です。

  • バックエンド
    • ソフトウェア・システムのうちクライアント(ユーザ)からは見えない部分。クライアントソフトに届けられる出力データを生成する部分。
    • 例えば、WebサーバのOS、Webサーバのミドルウェア、Webサーバと連携するデータベース、Webサーバ上で動作するスクリプト言語(Ruby, Java, Node.js, Go 等)によって構成される部分。
  • フロントエンド
    • ソフトウェア・システムのうちクライアント(ユーザ)に見える部分。クライアントソフトに届けられる出力データの部分。
    • 例えば、Webアプリケーションの場合であれば、HTML, CSS, JavaScript, 画像, 動画など、Webブラウザが実際に扱うデータによって構成される部分。
    • PCやスマートフォン上のネイティブアプリであれば、アプリ(クライアント)上で表示される View(プレゼンテーション)の部分、ユーザインタフェースの部分がフロントエンドです。

バックエンドについては、上記に書いた構成要素を表す LAMP(ランプ)という表現があります。OSとしての広義の「Linux」、Webサーバである「Apache HTTP Server」、データベースである「MySQL」、スクリプト言語である「Perl, PHP, Python」の組み合わせでバックエンドを構成することを表した言葉です。バックエンド開発といえば、この LAMP に相当するような要素を用いて裏側の仕組みの開発を行うことを指します。

一方、フロントエンド開発といえば、Webアプリケーションにおいては HTML, CSS, JavaScript での設計や実装を行う部分を指します。開発言語に関する知識だけではなく、ユーザインタフェース(UI)やユーザ体験(UX)に直結する部分でもあるため、情報設計(IA)やビジュアルデザイン、アクセシビリティやユーザビリティといった面に関する知識が求められることもあります。

# フロントエンド開発に関連する技術

フロントエンド開発に関わる技術要素と、JavaScript を中心としたWebアプリケーション開発が行われるようになった経緯について確認していきます。

# HTML と CSS

普段、Webブラウザ上で閲覧しているWebページは、次の単純なリソースの組み合わせで作られています。

  • HTML
  • CSS
  • JavaScript
  • 画像、動画などのメディア

WebブラウザであるWebページにアクセスすると、始めに HTML コンテンツが得られます。ブラウザはその HTML コードを解析して、CSS を読み込むような記述を見つけたら、その CSS を取得するためにWebサーバにリクエストを行います。JavaScript や画像なども同様です。

つまり、あるWebページにアクセスした場合には、ユーザの操作としては1回だけリクエストを送っているように見えますが、実際には CSS や画像などが参照されているリソースの数だけリクエストが行われます。Webブラウザは HTML で参照されている全てのリソースの受信完了を待ってから表示を開始するわけではなく、リソースを個別に受信し、受信が完了したデータから順に CSS を解釈したり画像を表示したりしています。

HTML はどのような環境、デバイスからでも利用できることを目的に作られた言語です。その最たる特徴はコンテンツデータをテキストフォーマットで扱えるところにあります。バイナリフォーマットと異なり、テキスト解析器さえあればデータを直接的に利用できます。

もしPCブラウザで利用することしか想定しないのであれば、HTML コードを書かずとも PDF ファイルや画像データにコンテンツを詰め込んで、そのファイルを表示するだけでも良いかもしれません。しかし、それではスマートフォンやスマートウォッチのようなデバイス、あるいはコマンドライン上からコンテンツを利用することが困難になってしまいます。また、検索エンジンがコンテンツに含まれる情報を解析できなくなってしまったり、目や不自由な方がスクリーンリーダといったツールを用いてコンテンツを利用するといったことができなくなってしまいます。

HTML は、情報と構造のみをテキストデータとして表現することで、利用環境に依存せずに環境に応じてコンテンツを利用できるという特性があります。例えば、Webブラウザ上でWebページを表示する場合と、Webページを印刷する場合では求められる表示形式が異なるかもしれません。

それを実現するために、視覚的な表現は CSS (Cascading Style Sheets) で行うことが提案されました。これにより環境に応じた表示形式の指定が可能になります。なお、CSS は HTML のためだけの言語ではありません。CSS という独立した言語仕様があり、それを HTML でも利用しているということです。

HTML ではコンテンツに「情報構造的」な意味付け(マークアップ)を行います。ここが「見出し」だとかこれは「表データ」だといった感じです。HTML で定義されている意味付けのための要素としてどのような種類のものがあるのか、また HTML の象徴的な機能であるハイパーリンク(およびページ内リンク)の特性を理解し、要素および属性により適切な意味付けを行うことが重要です。

CSS では主に視覚的なスタイルの定義を行います。どの要素をどのくらいの大きさや色で表示するか、要素の周りに余白をどのくらいつけるか、どこに枠線や背景色を設定するか。そうしたスタイルの指定は利用環境に応じた切り分けが可能で、例えばウィンドウ幅が広い場合には3カラムで広く表示させ、スマートフォンのようにウィンドウ幅が比較的狭い場合には1カラムで表示させ、印刷時には補助的なメニューを非表示にするといったことが可能です。見栄えを環境ごとに最適化することも、HTML と CSS を適切に分離することで実現できます。

# DOM (Document Object Model)

DOM(ドム)は Document Object Model の略で、HTML ページの要素を表現するためのモデルです。

JavaScript では HTML コンテンツを動的に操作できますが、これはWebブラウザが HTML コードをもとに DOM を構築し、JavaScript では DOM を操作することによって行われます。なお、CSS でスタイルを適用することに関しても、Webブラウザの内部では DOM に対してスタイル情報を割り当てています。

DOM のモデルは HTML 文書を論理的なツリー構造で表現します。

<html>
  <head>
    <title>What is DOM?</title>
  </head>
  <body>
    Hello!
  </body>
</html>

このような HTML は次のような DOM が構築されます。

[Document]
  └ [HTML]
       ├ [HEAD]
       │   └ [TITLE]
       │        └ (TEXT) "What is DOM?"
       └ [BODY]
            └ (TEXT) "Hello!"

ツリー構造で要素の構造が表現されています。

なお、HTML ソースコードがそのまま DOM ツリーになるわけではありません。もし HTML が不完全な(壊れた)記述であったり、HTML として認められていない入れ子関係になっていた場合、DOM を構築する時点でその要素の構造は修復されます。また、省略可能な HTML 要素タグといったものがありますが、HTML を記述する際に省略したとしても DOM を構築する時点ではその要素が補完されます。

CSS や JavaScript を記述する際に、HTML 記述だけに注目してセレクタ(対象とする HTML 要素を表す文字列)を記述してしまうと、構築される DOM 構造が異なるためにセレクタがマッチしないといったことがあるかもしれません。

JavaScript では DOM を操作することで HTML コンテンツを動的に操作しているということを覚えておいてください。DOM という概念を知ることが、CSS や JavaScript で要素を操作するための第一歩です。

# JavaScript:DOM Manipulator ライブラリ

複数のWebブラウザが登場した第2次ブラウザ戦争:前期(2000年〜2007年)の時代、各ブラウザの JavaScript の実装状況はバラバラでした。第1次ブラウザ戦争時代にあったような「こっちのブラウザでは動くけど、あっちのブラウザでは動かない」という状況は解消されていませんでした。

そのような状況で JavaScript で DOM を操作して動的な処理をどのブラウザでも期待通り動作させるコードを書くことは非常に骨の折れる作業でした。

その状況を改善するために登場したのが、異なるブラウザ間の実装の差異を吸収して1つのコードで DOM を操作できるようにする DOM Manipulator ライブラリです。

中でも有名なのが、2005年に登場した prototype.js と、2006年に登場した jQuery です。これらはライブラリと呼ばれたりフレームワークと呼ばれたりしますが、後に登場する SPA フレームワークとは開発された背景が異なります。

リリース時期は上記の通りですが、これらのライブラリの必要性が高まったのは第2次ブラウザ戦争が後期に突入した時代(2008年〜2014年)であり、jQuery が有名になったのも2009年にリリースされたバージョン1.3の頃からでした。

prototype.js は jQuery の人気に火が付くまでの間に人気のあったフレームワークでした。ブラウザ間で異なるコードの記述を条件分岐で切り分ける程度の比較的シンプルな実装となっていて、JavaScript の学習をするために prototype.js の実装を読むといったこともされていました。

一方、jQuery は高機能性を重視しているライブラリであり、要素を扱う際にも「jQueryオブジェクト」という jQuery 専用に拡張されたオブジェクトを扱う設計になっています。jQuery にはネイティブな JavaScript では提供されていない便利な機能も積極的に実装され、それらがネイティブの JavaScript に逆輸入する形で取り込まれることもありました。jQuery は高機能ですが、jQuery を使って複雑な演出や処理をやりすぎて、動作が非常に重くて使いづらいWebページになってしまうという問題もありました。

jQuery をうまく使うためにも、ネイティブの JavaScript や DOM といった概念をきちんと理解して、内部でどのような処理が行われているのかを想像できるようになることが重要です。

# Single Page Application (SPA) の登場

Webアプリケーションはバックエンドでの実装を主としたサーバサイドアプリケーションが一般的で、クライアントサイドでの処理は、例えば、ボタンをクリックするとメニュー一覧が表示されたり、複数の画像をスライドショーとして操作できるようにするといった、操作性の向上のために行われる部分的なものといったものが大半でした。

Webページの URL にアクセスするとサーバから HTML コンテンツがレスポンスされ、それがブラウザ上に表示されます。ページ中にはリンクがあり、リンクを選択(クリック)するとそのページを指す新しい URL に遷移します。別のページにアクセスした場合には画面遷移が発生しますが、新たなページの内容がレスポンスされてブラウザが表示するまでの間、ユーザは僅かながら画面の表示を待たされることなります。

Webブラウザの標準化や HTML5 の登場により JavaScript を用いてよりリッチな表現が可能になった昨今では、ユーザ体験を向上させるために画面遷移を極力行わずにコンテンツを利用できるような設計が模索されてきました。具体的には Ajax や WebSocket による通信を利用して、ブラウザ上ではページ遷移することなくシームレスにコンテンツを利用できるようにするという設計が考え出されました。

そうした中で、Webアプリケーションの全てのページを画面遷移なしで操作できるようにするコンテンツが登場し、それを実現するためのフレームワークも開発されてきました。そのような設計のWebアプリケーションは Single Page Application (SPA) と呼ばれています。

SPA では、ページ遷移を全て JavaScript で擬似的に実現します。ブラウザ上では従来の画面遷移が発生しないため、シームレスな画面の切り替わりやデスクトップアプリケーションのような操作感をユーザに提供することができます。

一方で、従来はサーバ側で実装されていた URL ごとのルーティングをクライアント側で実装する必要があるため、全体的に JavaScript コード量が多くなり設計も複雑になってしまいます。そこで、それを補うための様々なフレームワークが登場してきました。

# JavaScript:SPA フレームワーク

2019年4月現在、フロントエンド開発で使われる主要なSPAフレームワークは以下の3つとなっています。各フレームワークの詳細はそれぞれのハンズオンで紹介しますが、簡単に特徴をまとめると以下のようになります。

  • Angular
    • フルスタックなフレームワークで、Angular のみでフロントエンド開発に必要な機能が揃う。
    • Typescript が標準で使えるのもあって比較的大規模な開発向け。
    • Angular 独自の概念を覚える必要があったりするため学習難易度は高め。
    • 半年に一度メジャーリリースが安定して行われており、最新技術が積極的に取り込まれている。
  • React
    • VirtualDOM という仮想的に HTML DOM を扱える機能を持っており、高パフォーマンス。
    • ライブラリの組み合わせを考慮する必要があるが、自由度が高く最適な構成を作りやすい。
    • 開発用ツールなどエコシステムが最も充実しているが流行り廃りも激しい。(最近はそうでもない?)
    • 小規模から大規模まで、組み合わせ次第で比較的どこにでも適用できる。
  • Vue.js
    • とにかくとっつきやすくて、どちらかと言うと小規模な開発向け。
    • ドキュメントも充実しており、学習難易度は一番低い。
    • その分大規模なアプリケーションになるときちんとした設計が必要になり、比較的苦手。

ちなみに google trend によると、人気順は Vue.js > React > Angular となっている(2019年4月時点)。

# JavaScript:AltJS(メタプログラミング言語)

AltJS (Alternative JavaScript) とは、JavaScript を生成するためのメタプログラミング言語の総称です。

JavaScript はWebブラウザの歴史上で誕生した言語ですが、いわゆる一般のプログラミング言語と比べるとプログラミング言語として機能が不足していると思われる部分が存在しています。例えば Class の構文や静的型付けといった概念がなく、別のファイルをインポートするといった機能もありません。これは JavaScript がそういうプログラミングパラダイムだと言えばその通りですが、プログラミング言語として記述力が乏しい、開発がしづらいという面がありました。

JavaScript 自体の言語仕様は ECMAScript (ES) という名称で策定されている標準仕様を追従していますが、実際に JavaScript としてどのような記法が利用できるかというのは、Webブラウザの実装状況により異なります。また、ECMAScript の仕様は更新が遅く、1999年に 3rd Edition が公開された後、複雑化により破棄された 4th Edition を経て、2009年に 5th Edition が公開されましたが、その次の 6th Edition が公開されたのは2015年でした。

ECMAScript は 6th Edition からバージョンに年号が付加されるようになり、6th Edition は ECMAScript 2015 とも呼ばれます。それ以降は更新の頻度も上がり ES2016, ES2017, ES2018 が登場しています。ES2015 以降は Edition 表記よりも年号表記で呼ばれることが多いようです。

前述した Class 構文については ES2015 で取り入れられましたが、ES2015 以降の仕様をサポートしていないWebブラウザもあるため、広い環境(多少古いバージョンのブラウザ)でも動作するように JavaScript 開発を行う場合にはこうした最新の機能をネイティブの JavaScript 開発に取り入れることができませんでした。

こうした状況を解決するための仕組みとして、メタプログラミングが考えられました。メタプログラミングとは、プログラムによってプログラムを書くことです。Class が書ける言語を用いてコードを書き、それを従来の JavaScript コードに変換するといったことを行います。メタプログラミング言語は JavaScript に限らず、他の言語にも存在しています。

具体的な AltJS としては、Hexe(ヘックス), CoffeeScript, Dart, Kotlin, JSX, TypeScript などがあります。

# JavaScript で大規模な開発を行うには

上で挙げたフレームワークもそうですが、JavaScript である程度の規模のWebアプリケーションを実装する際には様々な外部のライブラリを利用することがあります。また、Class を用いたプログラミング経験のある方であれば想像できると思いますが、開発している自身のプログラムのために JavaScript のファイル分割や Class 定義を行って開発することも多いです。

その際に、外部ライブラリやファイル分割して開発したコードをWebブラウザ上で読み込んで動作させる必要がありますが、その手段として一番簡単なのは script 要素タグで自分のプログラムよりも前にライブラリやクラス定義を行なった JavaScript ファイルを読み込む方法です。これは HTML の仕様上、JavaScript を読み込む唯一の方法であり従来から行われている方法ですが、以下のデメリットがあります。

  • JavaScript ファイルを読み込む順番によって動作が変わる可能性がある
  • JavaScript ファイル同士の依存関係を考慮して読み込む必要がある
  • 読み込もうとしているファイルの数だけ HTTP リクエストが発生してしまう
  • 読み込まれた JavaScript はそれぞれグローバルで動作するため変数や関数の名前が衝突する可能性がある

こうした問題を解決するために、一定規模の JavaScript 開発環境においては外部ライブラリを事前に読み込むためのパッケージマネージャを使うことが一般的になりました。様々なパッケージマネージャが作られましたが、現在では npm を利用するのが一般的です。

開発時にはフレームワークを用いつつファイル分割をしながら保守性や可読性の高い状態で開発を行い、実際にWebブラウザ上で利用するときには npm で読み込んだライブラリと自分のコードを webpack などをモジュールバンドラを用いて、一つの JavaScript ファイルに結合することで読み込み順序の管理や読み込み処理の高速化を行えるようにしています。結合時にはコンパイル処理を行う必要がありますが、そうした処理を管理するためのタスクランナーというものも存在します。以前は Grunt や Gulp といったタスクランナーが有名でしたが、最近ではより高性能なタスクランナーも登場しています。

JavaScript はもともと大規模な開発をするための言語として開発されていないため、モジュール化、ライブラリやファイルのインポート、名前空間の定義といった仕組みがありません。JavaScript 開発をする上ではこれらの機能を補うためにメタプログラミング言語やフレームワーク、パッケージマネージャ、モジュールバンドラ、タスクランナーといったものを組み合わせて開発を行う手法が生み出されています。

しかしながら、JavaScript を用いたWebアプリケーション開発を行う上ではそれらは必ずしも必要ではありません。開発する対象の規模や JavaScript を書く目的によっては、ネイティブな JavaScript を直接記述したり、2019年においても jQuery を用いることが適している場面もあるかもしれません。これらはあくまで手段であるため、自分に適した手段が何であるかを判断することを判断することが大切です。

# 最後に

最近の JavaScript 開発は様々なツールや手段が登場しており複雑に感じられる場面も多々あります。フロントエンド開発の経験が少ない方は、まずは jQuery を用いた非常に小規模なサンプルコードの実行や、DOM やイベント処理(イベントリスナー)の概念といった基本的な知識、あるいは HTML, CSS の性質を改めて理解することから始めてみましょう。

それらの知識を応用してWebアプリケーション開発をしたいと思ったときに JavaScript の機能が貧弱であると実感できているのであれば、あなたがどのようなツールを使うべきか判断できるはずです。必要性を感じる前からツールに触れてもその良さに気付くことは難しいと思います。もし、最新の技術や手法が何のためにあるのか理解できないときには、基礎や歴史を調べてみるとよいかもしれません。

フロントエンドのハンズオンでは、次の内容を予定しています。

  • jQuery を触ってみよう
  • Vue.js を触ってみよう
  • react を触ってみよう
  • Angular を触ってみよう

SPA フレームワークに触れることが中心になっています。SPA フレームワークでやろうとしていることは複雑なように感じるかもしれませんが、実際は単純なことが組み合わさっているだけです。その単純なことを一つ一つ理解することで、複雑な全体像を理解することができると思うので、まずは身近なところから、仕組みや機能を学習していきましょう。

また、開発をする上で最も重要なことは「知識があること」ではなく「調べられること」、そして「疑問を持つこと」です。分からないことがあれば、何が分からないのかを明確にした上で調べてみましょう。「知識を身につける」ことを目的とせず、「興味や疑問をもって調べること」を目的にしてみてください。学びたいものに興味を持つことがその物事を理解することへの近道です。

本などを読んで勉強するような場合も、全てのページを読んで体系的に知識を得ることよりも、興味のあるページだけを読んだり気になったことをインターネットで調べてみるという方が楽しく継続的に勉強を続けられると思います。体系的な学習は、周辺知識がある程度身についてからやると効率的にできるかもしれません。

上記のハンズオンのテーマに関連する情報について、興味を持ったことがあれば自分でとことん調べてみてください。ハンズオンでは、その知識の確認やあなたにとっての新しい発見につながるような体験ができるようにしたいと考えています。


CC BY-SA Licensed | Copyright (c) 2019, Internet Initiative Japan Inc.