ゴーファーくんたちと辿るフロントエンドの潮流/tide-of-frontend

若手メンバー向けのミニ勉強会の資料です。

Transcript

1. 先端技術勉強会 技術講習会 2023/8 @iwasiman Advanced -STUDY GROUP- 第8回 ゴーファーくんたちと辿る フロントエンドの潮流 Technology TECH-SESSION
2. 2 この技術講習会(先端技術勉強会)について ゆるくやっていくので、気軽にいきましょう! ⚫ 新年度開始、メンバー15人に増加。グループを超えて部門の活動となりつつあるので、 今まで通り続けていきます!! ⚫ 頻度は不定、基本1H+α、だいたい夕方にやっています。 ⚫ とりあえず始めてみて様子を見ながら続けます。 ⚫ 説明中も適宜ブレイク(間)を挟むので、リアクションはその都度音声でもチャットでもOKです! ⚫ テーマはフリー、参加者から聞いたりして決めていきます。 ⚫ 次回テーマは [いよいよPythonかも?] 。 その後のテーマ候補も募集中です! ⚫ 皆さんが講師をしてくれるのも大歓迎です! 第1回 ゴーファーくんと学ぶGo言語の世界 [再開催中] 第2回 AWSの基本情報の歩き方 第3回 ゴーファーくんと学ぶAWSサーバーレスの世界 第4回 ゴーファーくんと辿るプログラミング言語の歴史 [再開催中] 第5回 ゴーファーくんたちと学ぶRust言語の世界 [再開催中] 第6回 ゴーファーくんと探るMendixの有用性 第7回 ゴーファーくんたちと辿るJavaScriptの潮流 [再開催中] 第8回 ゴーファーくんたちと辿るフロントエンドの潮流 ★今日はここ★ 第X回 某先生がPythonの機械学習コンペ(Kaggle)の話をいつか語ってくれるのでは…?
3. 第8回 ゴーファーくんたちと辿る フロントエンドの潮流 なんとなく案内役 ゴーファーくんと フェリスさんです 目的： 変化の大きいJavaScript・フロントエンドの 歴史とキーワードを全体の視点から概観し、 理解の助けにしてもらう。 前編：JavaScript実行環境とツールチェーン中心に 概観からスタート 後編：今回はTypeScriptやReact、その他の話題
4. 1. ツールチェーンの位置づけ(再掲) 2. TypeScript 3. フロントエンドのフレームワーク小史 4. ３つの主要フレームワーク 5. 根本的な考え方：宣言的UI 6. 考え方：コンポーネント指向 7. バックエンドのWebフレームワーク群 8. JavaScript以外の試み 9. WebAssembly 10.おまけ：動いているアプリの例①②③ 11.おまけ：アプリ開発での選択肢まとめ 12.本日のまとめ ゴーファーくんたちと辿る フロントエンドの潮流
5. 5 これらを使いアプリ開発 1. ツールチェーンの位置づけ(再掲) いろんな パッケージ (≒モジュール, ライブラリ) を管理 ファイル群をまとめる モジュールバンドル モジュール同士の依存性解消 プロジェクト作成支援の 「ボイラープレート」 JavaScript実行環境 すべての土台 (Denoは元からNode.jsよりカバー範囲が広い) JavaScript界隈は特に モジュール≒ライブラリ≒パッケージ が豊富で、あるモノとあるモノが同列だったり、含んでいて包含関係だったり、 別のモノを中で呼んでいたり、置き換わる新しいモノが出てきたり、複数の役割を兼ねていたり…と関連がややこしい。 開発に必要な一連の技術要素を「ツールチェーン」と呼んだりする。実体の基本はターミナルから動かすJavaScript製のCLIアプリ。 (最近はJavaScriptよりも速い他言語の採用も) JS/TS→JSに変換 トランスコンパイル AltJS言語 で 型サポート コードフォーマッター 静的解析のリンター テストの 仕組み 「ビルドツール」という言葉でまとめたり さらに抽象度を上げ、ツールチェーンを全部 大統一しようというこころみも (まだフォーマッターとリンターだけらしい) バックエンドのFW群 フロントエンドのFW群 両方というアプローチも →エコシステムの新陳代謝、流行り廃りが激しいが、今も進化中… 技術要素同士の位置関係をイメージすると理解の助けに 開発に使う各種のツールチェーン 開発対象の アプリケーション (詳細は次回) オレンジが 今回扱うところ
6. 6 2. TypeScript ◆ JavaScriptは誕生の頃は大規模開発を想定しておらず、変数の型がない。データ構造はJSオブジェクト(≒連想配列)の {} で表現したりしてきた。しかし2010年代により大規模開発が進む中で、人々は型に相当するものの必要性に気付いていく。 ◆ [2014-] Facebook(現meta)はflowという型チェッカー的なライブラリを公開。その後続くも、結局TypeScriptの方が流行り廃れる。 ◆ [2012] Microsoft発のAltJS言語 TypeScript始動。[2014] にv1で安定。設計した人が同じなので実はC#に似ている。 ◆ 当初はJSと違う言語に進化させていくつもりもあったそうだがなくなり、JavaScriptの「スーパーセット」、構文の正当拡張の言語へ ◆ JS実行環境ではNode.jsの場合は他のライブラリと同様にインストールして使用。Denoでは最初から入っている。 ◆ 実装時：型によるサポートでJSの欠点を補い生産性を向上 ◆ 開発ツールに制限はないが、特にVisual Studio Codeの拡張機能のサポートが初期から手厚く、実質一択 ◆ 型が違う時に即座に警告、サジェスト表示などが親切。開発者体験(DX)が特に良い言語として知られる ◆ 型の表現力が高く、’let data: string | boolean;’ のようなUnion型など高度な使い方が様々 ◆ 実行時：「トランスコンパイル」されるのでJavaScriptに変換されて動作 ◆ 実行速度、特徴などの諸元は完全にJSとイコール ◆ TypeScriptにあってJavaScriptにない組み込み関数などは存在しない ◆ こうした他の言語に変換されて動く言語はAltJS言語特有(他はDartぐらい)で、面白い着想の言語 C#やTSの産みの親 アンダース・ヘルス バーグさん 言語設計の達人 トランス コンパイル 実装時：型で 強力サポート 実行時：JSと イコール JavaScript(ECMAScript)の仕様面での検討： もし将来型が導入されることがあったら、TypeScriptは 不要になるのではという意見も →そんな未来もあるかもしれないが、今の所その気配はなし →以前から注目。2020年代の現在では、複数人 チームで本格開発するなら最初からJSよりTS導入 で始めた方が良いよ…というぐらいに主流に // TypeScriptで書いた関数例： function bmi(height: number, weight: number): number { return weight / (height * height); }
7. 7 3. フロントエンドのフレームワーク小史 ◆ JavaScript復権開始、HTML5に各社ブラウザが先行対応、2009年のNode.js登場後、SPAが徐々に認知。公式ではないが世代で分けることも ◆ 第1世代：フレームワーク未満の原始的なライブラリjQueryを指すことも ◆ 第2世代：バックエンドのMVCアーキテクチャを適用してみたり様々な試行錯誤。Backbone.js, Ember.js, Knockout, Aurelia等々 ◆ 第3世代：その後の3つのFW群、Angular, React, Vue.js。4位以下Svelteなど諸々も健在だが、入れ替わるほどではなかったといわれる ◆ [2009] Google発のAngularJS登場、2012にv1.0。この頃のFW群の中では後発、機能性と安定性あったがまだ課題あり。 ◆ [2011頃] Facebook社内でコードネームFBoltで開発されたFWがReactとなり、2012年のInstagram買収後の実画面で実戦投入されて 鍛えられる。2013にOSS化して認知、2014にv0.10.0(ほぼv1)。 ◆ [2015] 元GoogleのEvan You(尤雨溪)さんが作ったVue.jsのv1.0.0。翌年2016にv2.0。PHP言語のLaravelコミュニティで評価されたり して知名度が上がっていく。 ◆ [2016/9] AnguarJSのv2がアーキテクチャレベルで中身を大幅変更、互換性なしで名称Angularに変わり登場。推奨言語はTypeScriptに。 NoSQL DBのMongoDB、バックエンドのFWはExpress、フロントエンドのFWがこのAngular, JS実行環境がNode.jsという組み合わせが 「MEANスタック」と呼ばれた時期もあった。Angular, React, Vue.jsの3つを指して3大フレームワークと呼んだりも ◆ [2018] Vue.jsが本格的に日本上陸、商業本が出始めて一気に認知度が上がる。2020-2021年頃?まで、国内の最新の商業本に限っては ReactよりVue.jsの方が豊富という面白い状況が続く。(ネットの情報は両方とも豊富) ◆ [2019/2] Reactのv16.8.0から新機能React Hooks (リアクト・フックス)が登場、Redux (リダックス)などの状態管理のライブラリが必ずしも必須で なくなる。クラスコンポーネントでなく関数コンポーネントを正式推奨、大きな転換期。 ◆ [2019] Angularの最後の日本語商業本が出て後発なし。世界的なトレンドでもReactが圧倒的トップ、次がVue.jsで、だんだん2択に… ◆ [2020/9] Vue.js 3.0リリース。Reactに後れを取った理由のひとつともいわれるTypeScript対応を強化。新機能も関数型のアプローチを ◆ [2021] 長く使われてきたライブラリjQuery、本体は続くがjQuery UIとjQuery Mobileは遂に開発停止。CSSフレームワークの 代表格Bootstrapもv5で「脱jQuery」。JavaScriptの進化と共に時代は変わりReactとVue.jsに世代交代… Angular
8. 8 4. ３つの主要フレームワーク DL数から算出しているnpm trendsより ◆React: [2013-2022 v18.2.0] (リアクト) from Facebook(現meta) ◆ 宣言的UI、仮想DOMを用いた高速描画、データのやり取りは単方向フロー、TypeScriptとも親和性高し…などを特徴に首位に。 ◆ JSのクラスもしくは関数で書く「Reactコンポーネント」の中に処理を書き、HTML描画もJSX(JavaScript Syntax Extension, JavaScript+XML)という構文拡 張技術で一緒に書く。ここに学習コストがあるが乗り越えるとスケールしていく大規模開発でも耐えられ、リファクタリングや設計改善でこのコンポーネン ト分割が有効に働く。 ◆ JavaScriptの新文法や関数型プログラミングの思想も取り込んで進化中。世界レベルの有名なサービスは軒並みReactというぐらい人気。 ◆Vue.js: [2014-2023/2 v3.2.47] (ビュー・ジェイエス) from 元GoogleのEvan You(尤雨溪)さん＋開発チーム ◆ これまでの思想の良い所を取り入れ、Progressive Web Frameworkという思想。最初は簡単にJS読み込みだけでも動き、ビルドシステムを導入すると単 一ファイルコンポーネント記述にルーティングに…と段階的導入が可能。ReactがSimpleなのに比べるとVue.jsはEasyな思想ともいわれる。 ◆ 実装単位の「Vueコンポーネント」はJS/HTML/CSSそれぞれ書くところが別。ReactのJSXの壁を乗り越えられなかった初級者層、HTMLメインのデザイナー 寄りの層、手軽な用途などにも人気に。アジア圏、日本国内で特に人気。Web制作寄りの初心者向け含め、商業本も豊富。 ◆ コンポーネントを細かく分割、複雑化する大規模本格開発ではReactの方が向いているとも言われるが、別にVue.jsでも本格開発は十分できる。 ◆Angular: [AnguarJSは2009, -Angularが2016-2023/3 v15.2.1] (アンギュラー) from Google ◆ 最初からTypeScript必須、TSのクラスでモジュールを定義、ロジック部分は別、UIはコンポーネントとして定義、依存性注入の仕組みあり、テストの仕組み も同梱…と大規模本格開発を最初から前提にした、機能豊富な「フルスタックな」フレームワーク。 ◆ 一時期デファクトともいわれたが導入の敷居の高さもあってか、日本ではあまり流行らず…。 「機能全部載せ」 の構成(Angular) vs 「シンプルな本体」＋ 「周辺ライブラリ」 の構成(ReactとVue.js)でどちらが有効かは背景によるが、フロントエンドでは、後者が結局マッチしていった。 →現状はReactが首位、次点でVue.jsが定番。 新Verでも根本思想はもう変わらず、内部の 高速化や発展的機能追加が主と言われる。 HoneyPotのYouTubeの ドキュメンタリーが面白いです 2022年１２月にVue.jsが突出しているの はバグだともCDNからの直接DL数だとも 4位ぐらい?のSvelte (スヴェルト)も最近話題に
9. 9 付随したコード： 5. (いちばん)根本的な考え方：宣言的UI ジェイキューさん 仕事中 ▼ なまえ ステータス ”ステータス”の選択値が変わったら”なまえ”テキストボックス の色を変えるとしたら、onChangeなイベントで素の JavaScriptやjQueryで実装。これは簡単にできるが… ★なまえの色を元に戻すイベントは?初期値はどこに持つ? ★画面内の他のイベントでもなまえの色が変わるとしたら? …「命令的UI」の方法だと、込み入った仕様や複雑化した高度 な画面になってくると設計が破綻しやすい。 jQueryは「こう書くと当時のJSより短いコードでDOM操作で きるよ」「こう書くと非同期通信できるよ」というAPI(≒関数) が集まったライブラリなので、設計面のアプローチはない。 フェリスさん お休み ▼ なまえ ステータス JavaScript(TypeScript も)によるコンポーネント内： なまえの変数 ステータスの選択肢の変数 ステータスによるなまえの色 決定ロジック 最終的に生成される HTMLの定義 (コンポーネントがHTMLを描画) index.html 「宣言的UI」(declarative UI)の考え方だと、データの実体はJS側。 「状態の保持」がJS側になり、HTML側は最終的な表示だけすればよ い。(本来のHTMLの仕事) 丸ごと再描画でなく差分だけ再描画する 仕事は、FW側でやってくれる。(技術的には仮想DOMを使用) コンポーネント内でも状態(ステート)とUIを分けることができロジッ クがすっきり。高度なアプリケーションの複雑さを「状態管理」という 部分に限定できる→大規模アプリでも設計が破綻しにくい。 おまけ) 初心者向けのWeb情報でReact/Vue.js/jQueryを一緒の表にした りして jQuery＝悪! としている記事がありますが、厳密には誤りになります。 ★そもそも誕生した時代背景がまったく違うので、仕組みとしての目的が違う ★jQueryは「ライブラリ」なので、アプリ全体に設計面の統制をもたらす 「フレームワーク」としての機能は元から持っていない なお、この「宣言的UI」はReactの思想ですが、Vue.jsでも 根本の考え方は（大まかには）似ています。 “なまえ”、”ステータス”の データの実体はHTML内に ある。 HTMLの仕事が表示だけ でなく「状態の保持」もして しまっている。 →この宣言的UIの思想が進化していくWebにマッチし、 スケールしていく開発にも耐えられるように 主 従 主 従 NEW!! OLD…
10. 10 6. 考え方：コンポーネント指向 /** * 絞り込まれたお友達一覧を動的表示するFilteredFriendListコンポーネント。 */ const FilteredFriendList: React.FunctionComponent<FilteredFriendListProps> = ({filteredList}) => { // CSS用の変数宣言は省略 //const trEvenStyle: CSSProperties = {}; … // 偶数奇数の色分けロジック const evenOdd = (index: number): CSSProperties => { return index % 2 === 0? trEvenStyle: trOddEvenStyle; }; // 戻り値でJSX記法で表示するHTMLを書く return ( <table style={tableStyle}> <thead style={tHeadThStyle}> <tr> <th style={tHeadThStyle}>なまえ</th> <th style={tHeadThStyle}>種族</th> </tr> </thead> <tbody> { filteredList.map((friend: Friend, index: number) => { return ( <tr key={index} style={evenOdd(index)}> <td>{friend.name}</td> <td>{friend.race}</td> </tr> ) }) } </tbody> </table> ); }; Reactコンポーネント： 元はクラスコンポーネントor 静的 関数コンポーネントだったが、 2019より関数コンポーネント (Function Component)が 正式推奨に。 引数に親コンポーネントから受け取 るデータを取り、中にロジックや WebAPIでの通信を書き、戻り値 にHTMLの表示部分を書く。 バックエンドの設計では「ロジック」と「UI表示」は別にするのが定石。(MVCモデルなど) これをフロントエンドでもそのまま再現を試みた初期のFWもあったが一般化せず。 Reactは「ロジック(≒状態管理)＋UI表示」をひとつのコンポーネントに閉じ込めるという 逆転の発想を採用。 そしてコンポーネントを親子関係で細分化してどんどん小さくできるようにして変更容易性 を確保する→スケールする大規模開発にも耐えられる、という設計思想を持つ。 JSX記法があまりに斬新なため登場した頃はかなり反発を受けたが、徐々に人々がその便 利さに気付き、受け入れられるようになった。 さらに2019年の新機能React Hooksの登場で、コンポーネント内のロジック部分を別の 関数に外出しにしやすくなり、より良いコード設計が可能に。 React開発のポイントと言われるところ： ①コンポーネント設計 画面をどう分割し、どう親子関係で結びつけるか… ②状態(ステート)≒データ をどこでどう持たせるか ※Vue.jsでは「Vueコンポーネント」と「Vueインスタンス」というものが相当。 JS/HTML/CSSで書くところが別。根本の考え方は（大まかには）類似。 →バックエンドの設計とは思想がまた違う、コンポーネント指向 がフロントエンドにマッチ。コンポーネント設計が重要 親コンポーネント(App.tsxが通例) 条件部のコンポーネント 検索結果部のコンポーネント … 親→子へpropsで データ渡し Reactブームの頃：状態管理は状態管理 ライブラリに外出しして一元管理が当然！ とも言われたが… →2019にReact Hooksが登場： 必須ではなくなってきている ? ? ?
11. 11 7. バックエンドのWebフレームワーク群 ◆Node.js自体 : 標準モジュールのhttpがあるので、実は単独でもAPIサーバー程度は実装できる ◆Express: [2010- v1,現v4] (エクスプレス) 昔からあるデファクト。ミニマム(最小限)のFWで、 URLルーティング、ミドルウェア(そのルートに来た時に実行される関数)の機能しかない。 DB接続はまた独立パッケージ、HTMLを返したい時はejsパッケージ…と各種追加して組み合わせて構築 ◆NestJS: [2017- v1,現v9] (ネスト・ジェーエス) 中にExpressを内包したTypeScript製の多機能のフルスタック・メタなFW。 TypeScriptで書きやすく、GraphQL(Web APIの規格技術)と親和性が高い。時折紹介されるが、日本語の情報が少ない… OSとアプリケーションの間に位置するモノ(DBなど)を 指す一般的な「ミドルウェア」とは別の意味。 PHPのLaravel FWでもこの名前の機能があったり ◆Next.js : [2016-,現v13] (ネクスト・ジェーエス) Vercel社発、フロントエンド側のReactを内包したメタフレームワーク&バックエンドの フルスタックFW。バックエンド側で初回描画するSSR: Server Side Rendering、事前に静的HTMLを作っておいて表示する SG,SSG: Static Site Generation、中間のISR: Incremental Static Regeneration、ルーティングやReact関連で出てくるモノを最初から 含んで設定を簡素化、独自の機能も...と下位の技術要素をラップした位置づけ。バックエンドもJSで本格的にやる場合に充実。 バンドラーに新技術Turbopackも導入と進化を続けている。Vue.jsにも同様のアプローチでNuxt.js (ナクスト・ジェーエス) ◆Gatzby: [2017- v1,現v5] (ギャツビー) 同じくReact内包、データ取得はGraphQL必須、SSGで画面を作る方式のFW。 ブログやコンテンツメインの静的サイトなどWeb制作寄り、小規模寄り? ◆Remix: [2021-,現v1.15] (リミックス) React内包、キャッシュサーバーで配信できるのでSSGはやめてSSR方向、 Reactの新機能も取り入れた新しいFW。出たばかり 以下全て、Node.js実行環境下で動くFW群。機能が豊富な本格的FWを「フルスタック」と称したりする フロントエンド バックエンド メタFW 別のFWを中に含むFWをメタ・フレームワークと呼んだりする。だいたいReactを内蔵し、フロントエンド・バックエンド両方に跨るアーキテクチャに →ExpressとNext.jsが最も知られる定番。最小限、全部 載せ、フロントエンド/バックエンド両方と、各種アプロー チで進化中… フロント エンド バック エンド Next.js ① ② SSRの仕組み： ①Reactコンポーネントの中身をバックエンド で生成、HTMLでGETのレスポンスで返す ②その先はReactがバックエンドと通信しつつ 自分でレンダリングの通常動作 メタFW フルスタックFW ﾐﾆﾏﾑFW
12. 12 8. JavaScript以外の試み バックエンドのサーバー側に何かを配置→HTMLやCSSと一緒にダウンロード→ダウンロード後にブラウザ上で その何かを動して画面を動かす、という方法はJavaScript以外にも可能ではある。人類は様々に試みてきたのだが… ◆Java Applet: [1995-2000年代] (ジャバ アプレット) ◆ 専用クラス継承のJavaコードで実装、.classファイルを生成、<applet>タグでHTML内に書くと、ダウンロード後にブラウザ上でJavaアプリが動く仕組み。 ◆ インタラクティブなWebページが可能だった。ブラウザ側で専用プラグインサポートが必須、当時の回線速度ではダウンロードに時間が掛かる、ブラウザ が固まるなど問題多し。2000年代のJava全盛期でも避けた方がよい技術とされ、Javaのマイナスイメージの原因のひとつに。 ◆ 後発のFlashで同じようなことができ、さらにHTML5/CSS/ES6以降のモダンJavaScriptの発展で不要に。2018のJava11で完全廃止… ◆ActiveX: [1996-2000年代?] (アクティブエックス) ◆ Microsoft社のインターネット関連技術の総称、特にブラウザのプラグイン的に使うものを「ActiveXコントロール」という。 ◆ ブラウザが動いているWindowsマシンに直接アクセス可能。IEでしか動かない、Windows Vista[2006]までは動作制限がなくセキュリティ問題に。 ◆ レガシーWebアプリや古いバージョンのIEと関連付けられることも多く、当時の悪のMS帝国のイメージの原因のひとつに。徐々に滅び、 Windows10[2015]搭載のEdgeで削除され、完全消滅… ◆Adobe Flash: [1996-2000年代] (アドビ フラッシュ) ◆ Futurewave社→Web制作でお馴染みだったMacromedia社→Adobe社。動画の規格技術とアプリ群のこと。専用アプリで.swfファイルを出力、 HTML内に<embed>タグなどで書くとFlash Player搭載のブラウザ上だと動画やゲームがグリグリ動いて表示。Shockwaveという似たソフトウェアも。 ◆ ActionScriptという専用言語でプログラミングも可能。サイトの全面置き換えも可能。2chやYouTubeなど2000年代のインターネットの盛り上がりを支えた。 ◆ しかしセキュリティ問題、再生にマシンパワーが必要なことなどからiPhone[2007]では搭載されず、モバイルの世界に参入できず。急速に衰退し、2020年 のWindowsパッチで完全消滅… ◆Microsoft Silverlight: [2007-2012頃] (マイクロソフト シルバーライト) ◆ Flashと似たような競合技術。Windows Phoneに採用されたり話題になったが、v5で開発終了。 藍澤光という公式イメージキャラの美少女がいた! (お堅いMSなのに!) →JavaScriptの発展と共にRIAは消えていったが、 ブラウザ上で動かせる有望な技術がもうひとつ… これら柔軟なインターフェイスを持つWebアプリ技術をRIA(Rich Internet Application) と称した。HTML5[2014]→HTML LS[2019-]、ES2015以降のモダンJavaScript、CSS の進化によりやがて不要に…。また、1社独占の技術はだいたい長続きしなかった。 新しいMicrosoftの 姿勢として当時話題に
13. 13 9. WebAssembly (略してWasm) ◆ブラウザや様々な環境で動作する仮想マシンに対する命令セットであり言語。2015発表、2019にブラウザ上で 動くプログラミング言語として公認のWeb標準に。JavaScriptに次いで2番目!( HTMLとCSSも含めると4番目) ◆低水準言語でアセンブリ言語として設計されているが組み込み関数などはなく、他の高級言語からWasm向けにコンパイルした *.wasmファイルをJavaScriptから動かすのが普通。ブラウザ以外のデスクトップなどでも動く。 ◆解釈して実行するのにWasmランタイムというものが必要、Chrome,Firefox,Safariなどには搭載済み。切り離された専用領域 「サンドボックス」の中でのみ動き、外側に影響を与えない。セキュリティを十分に考慮している。 ◆JavaScriptより高速動作、置き換えられる!?と過度の期待をも寄せられて来たが、JSを「補完する」のが正しい姿勢とのこと。 ◆ ブラウザAPIコールやDOM操作はJavaScriptの方が高速らしく、やりとりの回数を減らし計算量の多い処理、画像や動画処理、暗号化などに ◆ バイナリのダウンロード時間があるので、各言語のランタイムライブラリが大きいと時間が掛かってしまうとのこと ◆ JavaScript製のReactやVue.jsが担っている領域の完全置き換えまでは(まだ)至らないのかも…? C, C++, Rust: ランタイムライブラリが小さく、Wasm分野で期待される最有力。 RustはDOMオブジェクト操作やWebAPIと連携できるライブラリに注力しているとのこと Go: v1.11[2018/8]からコンパイル時にWasmが指定できるように。バイナリは大きめ C#: BlazorというJSなしのC#のみで開発できるWebフレームワークがある。フロントエンド 部分はC#→ビルドしてWasmで動かしている模様(いまいち話題にならないが実は凄い?) Ruby: v3.2[2022/12]から対応。コード以外にRuby本体も込みでWasm化する方式 Python: あまり話題なし。Python自体はC言語実装なのでこれをWasm化し、 ブラウザ上でPythonを動かせるようにしたPyodideという仕組みがニュースに[2019] Kotlin: v1.8.20[2023/4]でKotlin/Wasmを実験提供開始 Java: 実験的に提供中のライブラリあり ～Wasmの活用事例～ Google Meet: ブラウザ上で動く会議ツール。背景ぼかしや音声フィ ルタに Google Earth: ブラウザで動くバーチャル地球儀 Figma: ブラウザ/デスクトップで動くUIデザインツール AutoDesk: CAD系の図面作成ツール SQLite: アプリに組み込んで動かす軽量RDB。Wasm版をChrome 開発チーム共同で開発、ブラウザのみで動くように ほか、Disney+やアマプラでも導入 →各言語・技術で取り組み中。実験中的な段階だが、 今後の発展が期待。特にRuｓｔ言語が有望！ 何か.wasm HTMLやJS一式 DL後に実行 各言語で処理を書き、 各言語での方法で Wasm用にビルド ウェブ・アセンブリ、ワズム
14. 14 10. おまけ：動いているアプリの例① ◆React + TypeScript でお友達一覧を検索するアプリ (React Hooks 使用) 親コンポーネント(App.tsx) 条件部を描画するコンポー ネント(Conditions.tsx) フィルターした検索結果一覧 を動的表示するコンポーネント (FilteredFriendList.tsx) 親→子へpropsでデータ渡し ・条件のチェックボックスのチェック状態 ・フィルターした検索結果一覧 ページ全体の描画(index.tsx) バックエンドと通信してJSON 形式で取得する設定…の、 ダミーのお友達一覧 React Hooks: useEffect APIで初期表示時に取得 React Hooks: useState APIでお友達一覧、現在の検索条 件、種族名一覧を保存 →関数コンポーネントが再実行されても保持 されている。状態管理ライブラリは不要。 ⚫ 純粋なReactアプリならWebサーバーは問わないので、実演 例ではIIS上で稼働中。ApacheでもNginxでも可能。 ⚫ TypeScriptで実装しても言語的な長所が効果を発揮するの は開発中まで。トランスコンパイルされるので、動作する際 の実体はあくまでJavaScriptファイル。 ⚫ 最初からReact+JavaScriptで開発しても、まったく同じ機能 のアプリは作れる。(実際に作りました) ⚫ 別フレームワークのVue.jsでも同じ機能のアプリは作れる。 ⚫ フレームワークなしのJavaScript/TypeScriptのみでも、(がん ばれば) 同じ機能のアプリは作れるはず… Reactによる１つのWebアプリケーション
15. 15 AWS Cloud 10. おまけ：動いているアプリの例② ◆バックエンドのJavaメインのWebアプリの一部の画面に、Vue.jsを導入する RDBに１レコード=１回分で 情報記録 検索条件に応じてSQL文を発行、結果を HTML形式で返す。伝統的な バックエンド主体のアプリ xxx.jsp 結果を表示するだけ →リクエストで検索条件 ←レスポンスでHTML 検索条件に応じてSQL 文を発行、結果をJSON で返すだけに xxx.jsp+JavaScript Vueインスタンスが画面の大部分を担当。 最初の1回でデータ取得、後はフロントエンド だけで結果表示を自在に変更 →ﾘｸｴｽﾄで検索条件をJSON ←ﾚｽﾎﾟﾝｽもJSON DynamoDB Lambda API Gateway Simple Storage Service (S3) →リクエストで検索条件をJSON ←レスポンスもJSON xxx.html + JSにして静的Web サイトホスティングで配置 ロジックは書き直し NoSQLに データ移行 SPAでない複数画面の既存 Webアプリの一部を置き換 えるなら、ReactよりVue.js が導入は手軽。 この例はVue.js ｖ２で、 Node.js等のビルドシステム 未導入で実現。 2021/2社内ハッカソンでやってみた サーバーレス構成への移行成功!! ひとつのWebアプリケーション フロントエンド バックエンド
16. 16 10. おまけ：動いているアプリの例③ ◆バックエンド主体のPHPのWebアプリだが、部分的に使っている例 RDBにいろいろ保持 検索条件に応じてSQL文を発行、結果を HTML形式で返す。ふつうの バックエンド主体のWebアプリ PHP用のHTMLテン プレート 結果を表示、さらに JSでいろいろ制御 →リクエストで検索条件 ←レスポンスでHTML JSONで受け取りJSON で返すAPIを作る部品も FWで用意、両方やれる 子画面用の仕組み を部品化、ここだ けJSで描画 ・検索条件を集めてJSON化、バックエンドに投げる ・結果が返ってきたら空のテーブルに行を追加して描画 ・クリアのタイミングでテーブルの行を消す という一連の流れをある程度部品化、1画面に幾つ子画面が あっても大丈夫な構成に。 事情によりjQueryを使っているが、問題なく稼働中。 →jQuery=必ずしも悪ではない ひとつのWebアプリケーション フロントエンド バックエンド →ﾘｸｴｽﾄで検索条件をJSON ←ﾚｽﾎﾟﾝｽもJSON バックエンドのフレームワーク群でも、現在はAPI形式をサポートするものが多い。 Java言語のSpring boot: APIに対応 C#言語のASP.NET MVC: APIに対応 PHP言語のLaravel: Controllerクラスを作る際にAPIオプションを使える Python言語のDjango: Django REST Frameworkというライブラリあり Ruby言語のRuby on Rails: プロジェクト作成時にAPIモードが選べたり、 専用のGem(ライブラリ)があったり JavaScript/TypeScrpt言語のFW群： 元からAPIに対応 Go言語のecho: 元からAPIに対応 Rust言語のActix-web: 元からAPIに対応
17. 17 11. おまけ：アプリ開発での選択肢まとめ フロントエンド バックエンド 始めるぞ! 開発言語 ①JavaScript ②TypeScript アプリ規模、規模拡大の 可能性、2人以上のチーム 開発するか、型の恩恵が どれだけ有用か… フレームワーク ①React ②Vue.js ③その他 ④未使用(Pure JS, バニラJS) アプリ規模、SPA/MPA、 既存アプリへの導入か… JS実行環境 ①Node.js が基本 ②Deno を試す Denoを選ぶと他の要素 が諸々揃ったり プロジェクト作成支援(ボ イラープレート) ①CRAやVue CLIを ②慣れてる人が手動で ①を選ぶと他の要素が 諸々揃ったり トランスコンパイラ ①他の選択肢で揃ったり ②新技術を導入 (esbuild, SWCとか) モジュールバンドラー ①他の選択肢で揃ったり (Webpackが有名) ②新技術を導入 (Turbopackとか) ビルドツール類 ①他の選択肢で揃ったり ②新技術を導入 Viteが知られる フォーマッター、リンター ①他の選択肢で揃ったり ②個別に導入 Prettier, ESLintがデ ファクト。別途CI/CDの 仕組みを工夫したり テストのサポート ①他の選択肢で揃ったり ②個別に導入 ユニットテストはJestが デファクト。結合テスト、 e2eテストでも 色々。規模による 開発言語 ①JS/TSで揃える ②他の言語にする APIの通信先は複数もok ・クラウド フロント/バックを分業す るか、技術要素、チームメ ンバのスキル構成…など で分岐 JS/TSで行くならフレームワーク選択 ①ミニマムにexpress ②フルスタックにNext.js （Vue.jsならNuxt.js） ③その他を試す アプリを構成する技術要素、規模、プロ ジェクトの周辺状況…で分岐。 JS実行環境はフロントと普通合わせる APIの受け口を他の言語で開発 ①インタプリタ型： Python, Ruby, PHP ②コンパイル型: Go, Rust, Kotlin, Java, C#... それぞれの言語圏でのFW、ライブラリを選定。大体API対応 APIの受け口をクラウドに ①AWS： API Gateway+Lambda ②Azure: (API Management)+Azure Functions サーバーレスアーキテクチャが可能。仮想マシン、コンテナの手も こっちも やるよ 選択肢が多く互いに関連、かつ 増減や流行り廃りがあるのが 初学者の混乱の元にも
18. 18 12. 本日のまとめ ◆フロントエンドの源流を辿るとインターネットの夜明けとブラウザ登場の頃 から始まり、様々な技術が互いに影響しあいながら、現在進行形で発展が 続いています。 ◆変化の激しい領域ですが、それぞれの技術キーワードの立ち位置や背景を 踏まえながら見ていくと、理解の助けになります。 ◆今後もまた大きな変化があるのかも…? Creative Commons Attributions 3.0 The Gopher character is based on the Go mascot designed by Renée French. それではまた次回！ 資料中の様々なロゴやマスコットはその言語や技術の公式・非公式のものです。書影はその書籍・雑誌のものです。 ぼくらもブラウザの中で動けるようになるかな 次回以降の テーマ 募集中です!!