Webの潮流から考える、フロントエンドの溢れんばかりの 魅力とフロントエンドエンジニアの役目
31K Views
August 24, 24
スライド概要
札幌市でフロントエンドエンジニアとして働き、Sapporo Engineer Baseの運営をしている_n13u_さんが、Webフロントエンドエンジニアの役割と魅力について、その歴史から考えるセッションです。Webの潮流を知ることでなぜを理解し、未来や自身たちの役割を考える大切さについて話します。Webの誕生期から現在までの歴史、Webフロントエンドの流れが早い理由や、Webフロントエンドエンジニアが持つべき役割について、紹介します。
札幌のウェブエンジニア
関連スライド
各ページのテキスト
Webの潮流から考える、フロントエンドの溢れんばかりの 魅力とフロントエンドエンジニアの役目 ＠_n13u_ / 2024.08.24 / #fecondo2024 1
自己紹介 ● ● 2002年生まれ、札幌市北区生、厚別区育、中央区在住 西村航（_n13u_） ○ ○ ○ ● 好きな言語 ○ ● ECMAScript 好きなWebフロントエンドフレームワーク ○ ● ちょっと株式会社でフロントエンドエンジニアしています 札幌市のSapporo Engineer Base 運営 今日はスポンサー兼スタッフ兼登壇です✌ Next.js（App Router） 好きなウイスキー ○ Whisk”e”yの方ですね. バーボンうめぇ！ 2
お断り ● 調べた限りのことで話します。間違いやそれはその解釈じゃないね。みたいな部分があればforteeで フィードバックいただけると嬉しいです！ ○ 現時点ではWikipediaと個人ブログと仕様書だったり当時のリリースのつぎはぎです。一次情報にでき る限り触れていますが、当時の人の気持ちとか当時の人たちがどう考えていたかはわかりません！ ● 2002年生まれで、PCに触り始めたのが2015年、Google Chromeの動画プレイヤーがAdobeからHTMLに 移行したくらいの年です ● 自分はWebフロントエンドでの開発が大好きです ● 特定の技術やフレームワークに対して批判的な意見を投げたいものじゃないよ！ ● 本当はバックエンド技術の歴史の話もしたい、というか本来であればしなければいけないしインター ネットそのものの進化とかも大事なんだけど涙の割愛！ ● よもやま話も多いです 3
今日の目標 4
⭐北海道・札幌にWebが好きでWebが強強なエンジニアが増える ⭐ 5
今日のお題目 Webの潮流から考える、フロントエンドの溢れんばかりの 魅力とフロントエンドエンジニアの役目 6
「Webの潮流から考える」って何？ 7
Webの潮流を知る＝Why(なぜ)を知る ● ● ● Webの潮流＝Web技術がどんな経緯・歴史を辿って今に至ったか＝Whyを知る なぜを知ると、納得できなかったことを納得できたり、同じ理由で次にどうな るかを予想できるようになる ○ 本質からはずれるけど、公式を暗記するよりも導出方法を知る方が応用が 効くという話 自分が考える「技術に強いエンジニア」はWhyを考える力がつよい ○ 👉今日のセッションをきっかけに考えるようになってくれると嬉しい 8
Webの潮流から考える ＝ Why(なぜ)を知って未来や自分たちの役割を考える 9
全体の流れ ● 歴史パート ○ Webの誕生期 ○ リッチなWebの発展 ○ 開発者フレンドリーなWeb技術 ○ ユーザー体験とWeb技術 ● 考えるパート ○ Webフロントエンドは流れが早いのか？ ○ “JSON色付け”係は不名誉な称号か？ ○ n13uが考えるWebフロントエンジニアの役割 10
歴史パートについて ● 1989年にWorldWideWebが提唱されてから今に至るまでの標準化や技術や技術が採用されてき た領域の流れ ● 当時何が大事にされていて、何のために技術が生まれたかをザックリおってみることで今私た ちWebフロントエンドエンジニアがどう技術に取り組むかを考える材料にしたい ● ブラウザとかブラウザ戦争の細かい話はしない（したいけど多分時間がなくなるのと、商業的 な流れもあるので割愛） ● 2015年くらいからの歴史はかなりあっさりめ ● あくまでも2024年現在から見た結果論の話が基本 11
Webの誕生期 12
ところで、これが何かわかりますか？ （わかりますね？） CC 表示-継承 3.0, https://commons.wikimedia.org/w/index.php?curid=436453 13
NeXT Computer製のNeXT Cubeというワークステーションで す CC 表示-継承 3.0, https://commons.wikimedia.org/w/index.php?curid=436453 14
実はWeb世界の立役者なんです... ということで歴史の話始まります CC 表示-継承 3.0, https://commons.wikimedia.org/w/index.php?curid=436453 15
Web誕生 ● 1989年 Tim Berners Lee によりWorld Wide Webが提唱される ○ 有名だけど提唱ってどういうこと？ ○ プロポーザルが出ています https://www.w3.org/History/1989/proposal.html ○ 要約すると、当時Leeが所属していたCERNでは部署がいっぱいあって情報もいっぱいあって抜け漏れすることが あるから、適切に管理する手法が欲しかったんだけど、いい手法がないから新しく「インターネット上でHyperText を使ってドキュメントを管理する手法」を提案するね、というもの ○ 提案自体はあくまでもドキュメントや情報管理手法の提案、個人的な解釈は「メタ的ではあるけどこうしたらいいん でね？を考えたからみんなどう？」的なもの ● その後、1990年に超初期のブラウザであるWorldWideWebが彼自身の手によって作られます（） ○ https://worldwideweb.cern.ch/browser/ CERNが2019年に公開しています。ブラウザ環境上で WorldWideWebが触れます ○ 同時にHTTPとHTMLの初期版（1.0ではない）が同時に提案されます ■ HyperText Transfer ProtocolとHyperText Markup Languageなので、どちらもHyperText に関する技術なんですね（大事なことなので...） ○ 最初期のHTTPはGETメソッドのみ、HTMLタグはドキュメンテーションに焦点を当てられたタグのみです ○ https://info.cern.ch/hypertext/WWW/MarkUp/Tags.html ○ このWorldWideWebや初期のhttpd（CERN httpd）が開発された時に使われたいたのがNeXT Cubeです（さっき の画像） Web誕生期 16
まとめると.... Webの始まりは 大量かつ関係性が複雑な情報を適切に管理するための解決手法 であったこと 今でいう、情報設計（information architect）に繋がるような話な訳です 17
WorldWideWebってこんな画面なんですね https://worldwideweb.cern.ch/browser/ 18
原初のブラウザNCSA Mosaicにより広まるWeb、CSSの登場 ● ● ● 1993年にMarc AndoreesenによりNCSA Mosaicが開発される ○ AndolesenはNCSA（米国立スーパーコンピュータ応用研究所）の当時学生だった ○ テキストへの色付けやインライン画像、戻る・進むボタンを実装など今のブラウザの基礎を作ってい る ○ 1995年にその後Netscape Communicationsとなる会社を設立し、Mozilla ProjectにてNetscape Navigatorをリリース ○ NCSA Mosaicよりも前の1992年ごろにViolaWWWと呼ばれる、スタイリングとスクリプティングを初め て実装した世界最初のグラフィカルブラウザが登場した 1995年当時IETFが管理・策定を進めていたHTMLについて、新しくLeeにより立ち上げられたW3Cに移管し HTMLについて管理を進めることになった ○ この頃からHTML2.0の仕様策定が始まる 1994年にW3CにてTim Berners Leeの同僚だったHåkon W LieによりCSSが提案される ○ https://www.w3.org/People/howcome/p/cascade.html ○ 1996年にCSS1.0として勧告 ○ LieはOperaの開発・創業者でもあり、Acid Testの提唱者でもある ○ 1998年にCSS2.0が勧告され今のCSSの原型が出来上がる（2011年にCSS 2.1として修正版が公開） ○ 複雑なWebのスタイリングをカスケード＝数珠繋ぎで表現する新しい仕組みの提案 Web誕生期 19
まとめると.... ViolaWWWやNCSA Mosaic、CSSの登場によって Webがドキュメント管理の仕組みから 画像とスタイリングで情報（コンテンツ）を届けるメディアの１つ になるきっかけが生まれた 20
W3CによるHTML標準化の流れ ● 1989年の技術提唱からNCSA Mosaic登場までに、Webそのものが急速に普及・進化 したことで、HTMLそのものの仕様（＝HTMLをどう解釈してどう描画するかを決 めたもの）がブラウザにより異なったりするなどこれから普及・一般化していくに は厳しい状況になっていた ● 1994年、Tim Berners Leeが主導し、急速な進化を遂げるWeb全体をまとめ必要な 部分を標準化・議論する ためのコンソーシアム、World Wide Web Consortium こと W3Cが設立されます ● 1995年には当時IETFが管理・策定を進めていたHTMLについて、新しくLeeにより立 ち上げられたW3Cに移管しHTMLについて管理を進めることになった ○ この頃からHTML2.0の仕様策定が始まる Web誕生期 21
HTML バージョン別 仕様変遷まとめ（歴史的に勝手に重要だと思ってる関連技術 も） ● WorldWideWeb上でのHTML ○ ○ ● HTML 1.0 （1993年） ○ ● https://info.cern.ch/hypertext/WWW/MarkUp/Tags.html anchor、title, heading, listが提供されている 正式なバージョン1.0は存在しないが、DTD（Document Type Definition）がIETFにドラフトとして提出されている（Dan Connollyによる）。この時 明確な仕様がないため、様々な制約条件やすでに存在しているありとあらゆるWebに対して定義を作っていく必要があった HTML 2.0（1995年 / RFC1866） ○ ○ 最初の“標準”としてのHTML2.0、仕様提案はIETFにより行われ、その後 RFC2854に含まれる形でW3Cに移行する 国際化（RFC 2070）, ファイルアップロード（RFC 1867）, テーブル（RFC 1942）などが同時期に補助的機能として提案される ● HTML 3.0（1995年） ● HTML 3.2（1996-97年（勧告が97年）） ● HTML4.0（1997年） ○ ○ ○ ○ ○ 1995年9月に提案されたがその規模の大きさから破棄され、HTML3.2に引き継がれる 当時分散していた規格の統一のために制定されたもので大きな機能的変更はない 3.2で保留にされていたメディアとしてのWebの機能、国際化などを標準化したもの フォームやフレームの強化、ActiveXを前提とした機能追加も行われる XHTMLも同時にリリースされる ● HTML4.01（1999年） ● XHTML1.0（2000年） ○ ○ ○ HTML4.0で発生した不整合を解決するために勧告されたHTML より機械的に解釈しやすいよう、XMLを用いて文章を定義するHTMLがW3Cにより提案 その後XHTML2.0という新たなマークアップ言語をW3Cは進めようとするが、HTMLそのものの進化を望むものたちも... ● XForms（2003年） ● HTML5（2014年） ○ ○ XML文書上に埋め込める完全にブラウザ上で動くXML仕様、XHTMLにより実現可能となった 別章に続く... 22
まとめると.... 標準化団体の設立、標準化に対して積極的に取り組むことで より多くのエンジニア・ユーザー・企業にWebを使ってもらう 環境が整備されるきっかけが生まれた 23
リッチなWebの発展 24
重要な２つのキーワードDHTML・RIA ● DHTML ○ ○ Dynamic HTMLの略、主要なブラウザ群が提唱していた「HTML・CSS・JavaScript」で動的にブラウ ザのコンテンツ制御ができる概念を指す言葉。当時は画期的だった Microsoft社から1997年4月8日に出たInternet Explorer 4のリリース文でも言及されています ■ ■ ● Dynamic HTML also provides Web designers the flexibility to incorporate business data and multimedia effects, enabling Web sites to rival high-quality interactive CD-ROM games and business productivity applications.(https://news.microsoft.com/1997/04/08/microsoft-announces-microsoft-internet-explorer-4-0/) 機械翻訳：Dynamic HTMLは、Webデザイナーにビジネスデータやマルチメディア効果を取り入れる柔軟性を提供 し、高品質なインタラクティブCD-ROMゲームやビジネス生産性アプリケーションに匹敵するWebサイトを作成す ることを可能にします。 RIA ○ ○ Rich Internet Applicationの略で、ドラッグ＆ドロップができたりWYSWIGエディタがついていたり、多 機能なWebアプリケーションを指す。現代のSPA（技術的な要素を除く）が持つニュアンスに近いか も？ 具体的な言及として2002年のMacromedia社のwhite paperで出てきている リッチなWebの発展 25
機械翻訳：Dynamic HTMLは、Webデザイナーにビジネスデータやマルチメディ ア効果を取り入れる柔軟性を提供し、高品質なインタラクティブCD-ROMゲーム やビジネス生産性アプリケーションに匹敵するWebサイトを作成することを可能 にします。 リッチなWebの発展 26
機械翻訳：Dynamic HTMLは、Webデザイナーにビジネスデータやマル チメディア効果を取り入れる柔軟性を提供し、高品質なインタラ クティブCD-ROMゲームやビジネス生産性アプリケーションに匹 敵するWebサイトを作成することを可能にします。 リッチなWebの発展 27
Webデザイナーに ビジネスデータ 機械翻訳：Dynamic HTMLは、 やマルチメディア効果を取り入れる柔軟性を提供し、高品質なイ ンタラクティブCD-ROMゲームやビジネス生産性アプリケーショ ンに匹敵するWebサイトを作成することを可能にします。 リッチなWebの発展 28
1997年時点ではWebはもうすでにデザイナーと 共同して作るメディアとして認識されていた リッチなWebの発展 29
Netscape NavigatorへのJavaScript登場とIEによる独自実装と標準化、DOMの 登場 ● 1995年、Brendan Eichの手によって数日間で作られたスクリプト言語JavaScriptがNetscape Navigator2.0に搭載される ○ ○ ● 1996年に登場したIE3.0にMicrosoft印のなんちゃってJavaScript言語JScriptが搭載される ○ ○ ○ ● ● あくまでもWindowsネイティブ環境で動くことを前提とし、ActiveXと組み合わせたOS機能へのアクセスや、 Windows Server上での実行も可能であった 独自拡張機能も多く見た目はJavaScriptの全くの別言語となっていた（らしい） 特にJavaScriptとは違い、DOMへのアクセス手法が異なっていた（というよりもDOM 1.0が勧告されたのは1998 年） この頃からブラウザはただの文書管理ソフトウェア以上の役割を果たせるようになってきていた これらスクリプト言語標準化のため、Netscapeが標準化団体ECMA Internationalに持ち込み1996年12月 から標準化が開始し1997年にECMA 262 1.0が公開される ○ ● リリース当時はサーバーサイドをJavaで、クライアントサイドをJavaScriptで記述し動的な処理をブラウザ上 で行うことでより柔軟なアプリケーション開発ができることを目指していた（Netscape CommunicationsとSun Microsystemsの業務提携によるもの） Javaアプレットの同梱や、HotJavaの登場も同年 https://ecma-international.org/wp-content/uploads/ECMA-262_1st_edition_june_1997.pdf 翌年1998年にはブラウザ上の構造を抽象化しスクリプト言語から扱いやすくするための技術として DOM 1.0がW3Cにより勧告される リッチなWebの発展 30
まとめると.... JavaScriptとDOMの登場・標準化によって Webが動的なコンテンツや情報を扱えるようになったことで、 メディア媒体からゲームやアプリケーション開発にも 利用できるようになった ＝ 活躍の幅がかなり広がった！ 31
AdobeとjQuery、SPAの登場 ● 1996年にMacromedia社からShockwave Flashが登場 ○ ○ ● ゲームだけでなく、Flash技術を活用したリッチなWebコンテンツがリリースされるようにな る ○ ● FONTPARK 2.0 | MORISAWA https://ics.media/entry/16171/ 同時期である1999年にはMicrosoft社がIE6からActiveXに基づくXMLHttpRequestを使ったサー バーサイドとの通信よる動的なWebコンテンツの更新を行う技術を提供する。これはその後 AJAXと呼ばれるようになる ○ ● 98年にはバージョン３が登場、2000年にはActionsScriptが登場し、Web上でのFlash Playerをによる動 画配信やFlashゲームにより多くのユーザーがブラウザ上でFlash技術をベースとした 2005年に競合となっていたAdobe社によりMacromedia社ごと買収され、Adobe Flash Playerとなる GoogleがGmail（2004年）、Google Maps（2005年）を当時主流であったFlashではなくブラウザ標準の 技術となっていたXMLHttpRequestを利用し開発、その利用体験により世界を驚かせると共にブラウザ の可能性を見出した 2006年1月にブラウザ上でのDOM操作、CSS操作をより容易にするためのライブラリjQueryが リリースされる リッチなWebの発展 32
まとめると.... JavaScriptやFlashといった高度な技術が ユーザーの手元に届き目に見える範囲でその価値がわかるようになったことで Webでのゲームやメディア、ウェブサイト、アプリケーションが より一般的になった ＝ より大衆的なIT技術の一員に 33
Google Maps の Ajaxに言及した当時の記事 Google Mapsの真価！アイデア勝負で革命はまだ起きる| リクナビNEXT https://next.rikunabi.com/tech/docs/ct_s03600.jsp?p=000701 34
開発者フレンドリーなWeb技術 35
ES HarmonyとES5, ブラウザの進化 ● 1999年にES3が登場して以降ES4に向けて仕様策定が進められたが結果としてそれはうまくい かなかった ○ ○ ● ● 2008年にES3.1 / ES4の仕様策定を中止、ES Harmonyという名称で仕様考案を継続 2009年にES5が策定される。おおよそ10年ぶりの更新 ○ ○ ● 色々な理由があるらしいがBrendan EichがCoders at WorkのインタビューでMicrosoftをどう ECMAScriptに招き入れ同じJavaScriptを扱わせるかということに焦点をおいていたっぽい 当時Microsoft社はJScriptをJScript.netとしてCLR（Windowsの共通言語ランタイム）上で動く、いわ ゆる.NET系の言語としてIE8に取り入れようとしていたらしい JSON対応やstrictモードはこの頃から、TypeScriptのtargetなんかでも目にする 2011年に5.1として修正等を追加した版が標準化される おおよそ同時期となる2008年にGoogle社によりオープンソースブラウザChromiumとその Google社独自実装のGoogle Chromeが公開される ○ ○ 他ブラウザに比べより安定かつ高速、洗練されたUIにより（個人の感想を含む）多くのユーザーの心 を掴みシェアを伸ばし続ける Chrome DevToolsにより今表示されているブラウザがどのようなDOM、CSSで動いているのかをリアル タイムでデバッグできるようになった 開発者フレンドリーなWeb技術 36
まとめると.... JavaScriptの標準化、より安定的なブラウザの登場により エンドユーザーの利用体験でなく、 開発者フレンドリーであることや開発者体験 に 目が向けられるようになってきていた 37
HTML5とXHTML2.0, WHATWGとHTML Living Standard ● 時は遡り2004年ごろW3CのworkshopにてMozilla, OpeaのメンバーからHTMLの進化について提案され、HTML5 の策定について議論が始まる ○ ○ ○ ○ ● ● 2010年にSteve Jobsが出した公開文書「Thoughts on Flash」 によるAdobeディスとHTML5ヨイショ ○ ここからAdobeが衰退する 2011年にHTML５がLast Callとなり2014年の勧告を目指したテストケースの作成がW3Cで進む ○ ○ ○ ○ ● 当初W3CはXHTMLにお熱であり、HTMLそのものの進化には興味がなかった（らしい） 2004年HTML5の策定を提案したMozillaとOpera、そこにApple, Googleが加わりWHATWGが設立、独自でHTML5の仕様策 定を進める。 2006年にはW3Cも議論に加わり、HTML５に向けて仕様策定を進めるようになる 2008年にはWorking Draftが公開され2009年以降のブラウザはHTML5に準拠するようになる（というかWHATWGのメン バーが開発している会社のメンバーなので...それはそうという気持ち） と同時にWHATWGはHTMLは継続的に更新されるべきとの意図から「HTML Living Standard」を策定。完全分裂 2014年に勧告され2017年には5.2が出る 結果としてHTML5はHTMLの進化系として多機能さを持ち、より標準的な技術として確立された この時からWeb API と呼ばれるスクリプト言語により様々な機能にアクセスするためのAPIをW3Cが別仕様として策定を 進めるようになる 2019年、分裂したことによる仕様差異を埋めるためW3CはHTMLの管理をWHATWGに譲渡、マージされその後 Living Standardが唯一の標準となる 開発者フレンドリーなWeb技術 38
まとめると.... 誰の、何のためのHTMLなのか色々な議論は重ねられたが結果として HTML5の登場によりWebの標準化が進み （Web API も登場し） ユーザーにとっても開発者にとって も Web技術が扱いやすくなった 39
ところで、これが何かわかりますか？ （わかりますね？） 40
Node Package Manager, そうnpmです. CC 表示-継承 3.0, https://commons.wikimedia.org/w/index.php?curid=436453 41
Node.js, AltJS, ReactやVueなどのUIライブラリ、待望の ES2015 ● 2009年〜2014年にかけてのJS系ライブラリ・AltJS怒涛の登場 ○ 2009年 ■ ○ ○ ○ ○ ○ ○ 2009年 2010年 2010年 2012年 2013年 2013年 ■ ○ ○ 2013年 2013年 ■ ■ ● Node.js / npm 登場 以降npmはその後10年以上JavaScriptエコシステムを支え続ける Coffee Script登場（stableは2010年） Angular Backbone.js grantの登場 Vue.js （初版リリースは2014年） React（FaxJS） Facebook Ads の肥大化に伴い、DOMとCSSの変更が多重化・複雑化していく中でそれらを解決する手法として登場 gulp 従来のタスクランナーに変わるJSバンドラーとしてwebpackが登場 背景としてHTTP1では複数ファイルを並列してリクエストすることができず１つのファイルにまとめる方が結果としてパ フォーマンスが良かったため（という認識でいますが間違っていたらマサカリお待ちしてます！#frontendo） プラグインによるSassやTypescriptのトランスパイル、core-jsによる古いバージョンへのESそのもののトランスパイルな ど多機能だった 待望のES2015（ES6が登場） ○ ○ Arrow function, Classサポート, let / const, Promiseなどあげればキリがない... 以降バージョニングが数字から西暦になる 開発者フレンドリーなWeb技術 42
まとめると.... jQueryの流れから始まり, 標準化団体でなくコミュニティ主導で JavaScriptでの開発効率化ライブラリやソフトウェアが増えた. npmの登場以降、それらライブラリを簡単に共有し合えるエコシス テムができたことでJavaScriptユーザーが増えるきっかけ になるとともにES2015によって JavaScriptがより使いやすい言語となった. 43
SPAの台頭とUIライブラリの登場、レンダリング手法の分化 ● １枚のHTMLをJavaScriptを使って制御することで擬似的にマルチページライクなWebアプリケーションを開発 するSingle Page Applicationが主流になる. ○ Webブラウザにおけるナビゲーションのパラダイムシフトとして2003年にはNetscapeのエヴァンジェリストが「単一の ページ内で全てのナビゲーションが起きるモデル」について言及している https://web.archive.org/web/20030810102320/http://devedge.netscape.com/viewsource/2003/inner-browsing/ ● 2006年のjQuery, 2010年のAngular, Backbone.jsの登場時では、コンポーネント志向やフロントエンドMVCの導入 などそれぞれの手法を用いてSPAを開発する必要があったがプログラム全体の肥大化やブラウザの対応不足な ど様々な問題があった ● 2013年~2014年にかけては当時のSPAの問題だったプログラムの肥大化や設計の難化を解決するために独自の手 法をとりいれたUIライブラリが登場する ○ ○ ● Evan Youが取り組んだAngularの良いところだけを詰め込んだ「Vue」 当時PHPのHTMLコンポーネントライブラリだったXHPに影響を受け（その後のJSX）、関数型プログラミングの手法を 取り入れた「React.js」 そして、それらのJavaScriptがどこでも動くように（当時は難しい問題だった。IEがご存命ですので...） Node.js上でReactやVueのJavaScriptを事前にバンドル・処理しブラウザにJavaScriptで構築済みのHTMLと一 緒に渡す初期のServer Side Renderingが登場するなどしていた... 開発者フレンドリーなWeb技術 44
まとめると.... JavaScriptを中心としたエコシステムの発展により Web上でユーザー体験を重視したSPAの開発が進むようになったが, 当時のライブラリでは解決できなかった、コードの肥大化 設計の難化に対応するためそれぞれの思想に基づくUIライブラリが登場 ブラウザ間の差異を埋めることも当時の課題となったがそれはまた別のお話... 45
ユーザー体験とWeb技術 46
大規模SPAとレンダリング手法の多角化 ● 2016年、Node.jsでのServer Side Renderingの登場は大きな影響をあたえた。それらをより横断的かつ網羅する ための仕組みとしてWebフロントエンドフレームワークとしてReactベースのNext.jsをVercel CEOのGuillermo Rauchが開発を始める ● 後追いの形でVue.jsベースのWebフロントエンドフレームワークNuxt.jsが登場する ● サーバレスの登場やCPUリソースが比較的潤沢になり、4G, 5Gが一般化したことで、サーバーサイドでのレン ダリングでも問題が少なくなったり、SPAがより大規模なものとなる。また連続的にレンダリングを行うISRな ども登場する ● SPAの大規模化によって生じた問題として、そもそもJavaScriptが動かない環境では表示できない機能やウェ ブサイトがあること、バンドルサイズの大きなJavaScriptは読み込みに時間がかかることが上げられるように なる ○ ● またサーバーサイドでレンダリングすることでクローリングがうまくいかないケースなども発生しビジネス上の価値も 失うことが起きていた 逆にサーバーサイドレンダリングではサーバーのレンダリング時間の長期化や、CPUリソースの消費によるコ スト増なども問題となる ユーザー体験とWeb技術 47
まとめると.... 技術の進歩によりWebで表現可能なアプリケーションの幅はさらに広がったが... リソースを潤沢に使いすぎたことによる体験の悪化や コスト増が問題に 48
Progressive Enhancementとアクセシビリティ ● 前項の問題は開発者やSEO観点だけでなく、ユーザーの体験を損ねかねないということが問題 になった ○ ○ ○ ● 例えばJavaScriptを無効化しているユーザーだってあるしみんながみんな5G回線の下にいるわけでは ない SPAでWebが読み込まれるまで、表示されないDOMではアクセシビリティが担保されない 画面が表示されたけどクリックしてアプリケーションが動けるようになるまでは1分かかる... これらを解決するために「Progressive Enhancement」という手法が注目されている ○ ○ 段階的な強化👉つまり、できることを少しずつということ Webアプリケーション全体でJavaScriptを使う必要はないので固定の場所はレンダリングしてHTMLで 返却。動的な部分にのみ限りJavaScriptをロードするが、例えばformなどはHTML標準のものでも動く ように... ■ ○ ReactのServer Componentやisland architectureなどはこの流れ HTMLが残っているため正しくマークアップできていればアクセシビリティ的にも👌 ユーザー体験とWeb技術 49
まとめると.... 様々な課題が進化によって表面化するようになった 標準に立ち戻り基本的なHTMLを動かしつつ 必要な部分だけJavaScriptを動かすという方式が できるようになった 50
歴史パート終わり・まとめ 51
Webの潮流を整理 ● ドキュメントなどの情報を管理する手法として始まったWorld Wide Web ● NCSA Mosaicを筆頭にスタイリングの仕組みによりメディア化するWeb ● JavaScript / Flashの登場によって動的なWebが実現できることでユーザーに対して届けられ る体験・価値の幅が広がる ● 扱いやすいとはお世辞にも言えなかったHTML, CSS, JavaScriptが時代の流れとともにコミュ ニティに合わせて成長することで多くの技術者がWebに触れられるようになった ● 多様なライブラリとそれらを支えるNode.js / npmのエコシステムがWebでのアプリケーショ ン開発の可能性をさらに広げた ● Web技術が進むにあたって今まで取り残してきていたユーザーや、失われてしまったユーザー 体験を取り戻す動き始まっている 52
考えるパート 53
潮流を知ったところで フロントエンドの魅力と役目を再確認 （考えるパートです） 54
まずは、ちょっとした問いから 55
Webフロントエンドは流れが早いのか？ ● はい、でもいいえ、でもない ○ より正確を期すなら、部分的にそう ● Web自体は登場から数年で普及したが、HTML4からHTML5まではかなりの時間がかかっている ● JavaScriptに至っては10年間かけてES Harmonyになるという迷走もある... ● 潮流全体を思い出してほしい、早い時も遅い時も理由がある... ● 全てが全て早いわけではないので、着実に１個１個覚えるのが良いと思う ● Webの技術進化＝開発者のため or ユーザーにより良いWebを届けるため ○ ○ むしろゆっくりより多くの人が使うWeb技術、どんどん進化してほしいよね！ ほしいWeb APIを #frontendo でつぶやこう！ 56
流れが早い部分も遅い部分もあるが 全てはユーザーか開発者のためだよね？ 57
“JSON色付け”係は不名誉な称号か？ ● いいえ ● Webはユーザーが直接触れて体験して感動して価値を感じられるインターフェース ● 同じ塗り絵でも塗り方が違えば与える影響や抱かささる感想が違うように、むしろJSON 色付けのプロフェッショナルとして誇りを持ってベストな色付けを探し ていくことがWebフロントエンドに向き合う私たちの役目 なのでは？ ● というかJSONってJavaScript Object Notationの略だし、JavaScript以外の言語に色付けさせ てていいってわけ！？ 58
JSON色付け係は名誉 お前のJSONはお前が色をつけるしかない. 59
Webフロントエンドエンジニアの魅力と役目を考える前に ● Webは30年近い標準化の歴史によってブラウザがあればアクセスできる無限大のプラット フォームになっている ● ネイティブ技術におけるクロスプラットフォームの夢はある種ブラウザがOS的な役割を果た すことで実現している ○ マシンスペックを大きく要求しない（マシン自体の性能向上もあるが）のも個人的推しポイント ● ブラウザ技術が進化しているもののそれに伴いEvilな技術や、取り残される環境・人が出てく るがそれらを解決できるのはWebに精通したエンジニア ● 進化した技術を最大限活かせばユーザーに対する価値創造が可能になる ○ ○ 例）リッチなUIを活かしたクロスブラウザでのアプリケーションにより、OSやデバイスの差異がなく 同時に大人数が直感的にコンテンツを編集・閲覧できる 例）今までうまく取り扱えてなかったデータをWeb上で可視化することで新たな発見が得られる 60
n13uが考えるWebフロントエンドエンジニアの魅力と役目 価値と体験を同時に、多くの人に届けられる 最高の技術とプラットフォームに携わるエンジニアであり それら技術とプラットフォームの守り手 61
おまけ Webフロントエンドエンジニアは指名されてなるものではなく、 Webフロントエンドに携わる意識によって生まれる役割なので この会場に来て興味を持ってセッションを聞いてそれを 日々の開発に活かしユーザーに価値を届ければ 立派なWebフロントエンドエンジニアなのです（長文お気持ち表 明） 62
宣伝 今日の話を聞いて、自分と仕事をしたいな〜 と思ってくれた人、北海道・札幌で フロントエンドエンジニア目指したい人！ 63
宣伝 ちょっと株式会社カジュアル面談やってます 64
ご清聴いただきありがとうございました 65