Webフロントエンドエンジニアの戦い〜歴史と現在、そして未来
•Télécharger en tant que PPTX, PDF•
4 j'aime•4,929 vues
webフロントエンドエンジニアとして仕事を始めてからこれまで、どういう立場でどんな苦労をしながら生き残ってきたか、それを踏まえてこれからどうなるか、みたいな点から、これからどうなるか、どうしていったら良いかを悶々と。
Recommandé
Recommandé
Contenu connexe
Tendances
Tendances (20)
Similaire à Webフロントエンドエンジニアの戦い〜歴史と現在、そして未来
Similaire à Webフロントエンドエンジニアの戦い〜歴史と現在、そして未来 (20)
Dernier
Dernier (8)
Webフロントエンドエンジニアの戦い〜歴史と現在、そして未来
- 1. IWD2016 - Women Techmakers in Kyoto Webフロントエンドエンジニ アの戦い −歴史と現在、そして未来− 2016.4.2(Sat) MATSUDA Emi
- 2. 本日のメニュー Today’s special 1. さらっと自己紹介 2. 「Webフロントエンドエンジニア」ってなに？ 3. フロントエンドの戦いの歴史 4. 休戦 5. 現在 6. 未来展望: 「Webフロントエンド」って、結局どうなる ？
- 3. 1. さらっと自己紹介
- 4. 1. さらっと自己紹介 ❖ 氏名: MATSUDA Emi ❖ 職業: Webフロントエンドエンジニア
- 7. 2. 「Webフロントエンドエンジニア」ってなに？ ❖ Web業界では、単に「フロントエンドエンジニア」って言 われる場合が多いです。 ❖ ただ、スマホ等アプリ制作の現場でも「フロントエンド」 の仕事があるため、Webに特化している場合、その仕事は 「Webフロントエンド」って言った方がよさげ。 ❖ もちろん、両方できる人もいます。 ❖ ココでは、以降「フロントエンド」とします（長いので） 。
- 8. ❖ 主にHTML, CSS, JavaScriptを使用して、Webのコンテ ンツを組み立てたりインタラクションを作ったりする 仕事。 ❖ それを担当する人を「フロントエンドエンジニア」と いうふうに言います。 2. 「Webフロントエンドエンジニア」ってなに？ 「フロントエンド」って？
- 13. 3. フロントエンドの戦いの歴史
- 14. 3. フロントエンドの戦いの歴史 1. 第2次ブラウザ戦争 2. 第1次JSフレームワーク戦争 3. 「とりあえずHTML5って言っとけ」の呪い 4. 「レスポンシブでやったら管理簡単なんだよね？」爆弾 etc…
- 16. 3. フロントエンドの戦いの歴史 2007年当時のブラウザ ❖ InternetExplorer 6〜7 ❖ InternetExprorer for Mac 5.x ❖ Firefox2〜3 ❖ Opera9.x 第2次ブラウザ戦争 ❖ Safari 3.x ❖ Safari for Windows 3.x ❖ NetscapeNavigator（瀕死） ❖ （Google Chromeはβ版）
- 17. 3. フロントエンドの戦いの歴史 2007年当時のWeb技術 ❖ Tableレイアウト→CSSレイアウト ❖ 「Ajax」というコトバが浸透してくる？ ❖ 「Web2.0」というコトバがまだ平和の幻想を抱いている 第2次ブラウザ戦争
- 18. 3. フロントエンドの戦いの歴史 エンジニアの戦い ❖ Tableレイアウトの謎のスキマ ❖ CSS不備すぎるブラウザバグ ❖ JavaScriptのブラウザごとの挙動の差異 ❖ 「jQueryとPrototypeを両方入れたいんだけど」問題 ❖ コード軽視の風潮 第2次ブラウザ戦争 etc…
- 19. 3. フロントエンドの戦いの歴史 2012年頃に決着がつき停戦か。 ❖ MacへのIEの提供が終了し、SafariがWidowsから退去。 ❖ 一時はFirefoxがエンジニア層を中心に支持を受けたが、最終的には Mac, WindowsともChrome勢力が驚異的に上がる。 ❖ OperaはガラケーやNintendoDS等へと落ち延びた後、Chromeのレ ンダリングエンジンWebkit陣営へ。分裂後もChromeとともにBlink へ。 第2次ブラウザ戦争
- 21. 3. フロントエンドの戦いの歴史 2007年当時のフレームワーク事情 ❖ Dreamweaverのビヘイビアを使用したMM_SwapImageとか が現役 ❖ 「jQuery1.2.x系」 v.s. 「Prototype.js1.5.x系」 ❖ 「LightBox」の実装が流行。 ❖ 他、YUIやMooTools等、ライブラリが乱立 第1次JSフレームワーク戦争 etc…
- 22. 3. フロントエンドの戦いの歴史 エンジニアの戦い ❖ JavaScriptのブラウザごとの挙動の差異 ❖ 「jQueryとPrototypeを両方入れたいんだけど」問題 ❖ 書き方を両方覚えなきゃいけない ❖ バッティングを避けたつもりがバグ発生 第1次JSフレームワーク戦争 etc…
- 23. 3. フロントエンドの戦いの歴史 2011年頃にjQueryが圧倒的勝利を上げて終戦 ❖ PrototypeでできることはほぼjQueryのプラグインとして実 装された。 ❖ その代わりと言ってはなんだが、jQueryプラグインの乱立 と実装内容の複雑化によりエンジニアの負担は減ることは なかった。 第1次JSフレームワーク戦争
- 25. 3. フロントエンドの戦いの歴史 HTML5が現実化し始めた頃 ❖ 2008年にHTML5のドラフト発表。各ブラウザが対応開始。 ❖ 2010年のiPhoneにてFlash非対応となる。 ❖ 2011年InternetExplorer9にてIEもHTML5対応開始 「とりあえずHTML5って言っとけ」の呪い
- 26. 3. フロントエンドの戦いの歴史 エンジニアの戦い ❖ 「HTML5ならFlash使わなくても簡単に実装できるんでしょー？」の認識 がエンジニア以外に蔓延 ❖ そもそも「HTML5」というのが何なのか、エンジニア以外にはわかって いない。 ❖ ここでも各ブラウザの対応がまちまち ❖ FlashコンテンツをPCとスマホ両方で見れるように、という作り変え依頼 が発生 「とりあえずHTML5って言っとけ」の呪い etc…
- 27. 3. フロントエンドの戦いの歴史 現状、ほぼ呪いは解かれている様子 ❖ ちまたで大まかに「HTML5」と呼ばれていたWeb技術は JavaScriptによる実装となるため、JavaScriptのエンジニア の需要が一気に高まった。 ❖ 2015年頃には「よくわかんないけど、動いてるものは HTML5」みたいな憑き物はほぼ見られなくなっている。 「とりあえずHTML5って言っとけ」の呪い
- 29. 3. フロントエンドの戦いの歴史 レスポンシブウェブデザインとブラウザ技術 ❖ ブラウザサイズによってレイアウトを変化させるテクニックが 2004年頃には発表される ❖ 2009年頃に「CSSメディアクエリ」技術がブラウザ搭載 ❖ 2010年にAndroid,iPhoneが日本で発売 ❖ 2011年頃には制作にレスポンシブウェブデザインが用いられ始め る 「レスポンシブでやったら管理簡単なんだよね？」爆弾
- 30. 3. フロントエンドの戦いの歴史 エンジニアの戦い ❖ レスポンシブに適したデザインというものがまだ模索中であ り、実際に要求されるデザインでは実装不能なことが多々。 ❖ エンジニア側も、実装してみて初めて不可能なことが解る等 もあり、実装が難航。 ❖ どうしようもない場合にはCSSではなくJSで実装すること も。 「レスポンシブでやったら管理簡単なんだよね？」爆弾
- 31. 3. フロントエンドの戦いの歴史 エンジニアの戦い ❖ HTMLの構造がどうしても複雑になり、管理コストもかなりかかる 。 ❖ レスポンシブでかなり消耗した挙句、ややこしいインタラクショ ンを求められる。スクロール位置や画面幅とるタイミングがつら い。 ❖ スマホのバグで撃沈。 ❖ 「なぜ実装できないか」を説明するのが非常にたいへん。 「レスポンシブでやったら管理簡単なんだよね？」爆弾
- 32. 3. フロントエンドの戦いの歴史 経験値による平和的解決 ❖ 「レスポンシブにしても、どうやらさして簡単・安価ではないらし い」ということが伝わり始めており、被弾することも減ってきてい る。 ❖ デザイン・マークアップとも経験値を上げてきたため、適度な対応 ができるようになってきている。 ❖ でもややこしいインタラクションはレスポンシブでは避けてほしい ...。 「レスポンシブでやったら管理簡単なんだよね？」爆弾
- 33. 4. 休戦
- 34. 4. 休戦 1. なんでもかんでもjQuery時代の到来 2. 侵食される「JavaScript」と、「ECMAScript6」の思想 etc…
- 36. 4. 休戦 ❖ フレームワーク戦争を勝ち残ったjQueryの勢いはとどまる ところを知らず、プラグインも次々と生まれてくる。 ❖ ブラウザによる実装差異を飲み込んでくれる強力さに jQuery依存症が急増。 ❖ jQueryMobileで簡易なスマホサイトが作れてしまう。 なんでもかんでもjQuery時代の到来
- 37. 4. 休戦 ❖ レスポンシブで倦み疲れた案件でもインタラクションや AjaxはjQueryでなんとでもできてしまう。 ❖ ディレクター・デザイナーからの実装要求は難易度を増す 。お手本となるものもjQuery使用のものばかり。 なんでもかんでもjQuery時代の到来
- 40. 4. 休戦 ❖ JavaScript案件が増えるにつれ、プログラマーがJavaScript界に侵食 してくるようになる。 ❖ ほかの言語の思想をJavaScriptに持ち込まれるようになる。 JavaScriptを他の言語の思想で書けるようにフレームワークが作られ 始める。jQueryをdisられるようになる。 ❖ JavaScript標準となるECMAScriptのバージョン6で、ClassやSymbol 、Arrow関数等が定められる。JavaScriptの一つの時代の終焉 侵食される「JavaScript」と、「ECMAScript6」の思想
- 41. 5. 現在
- 42. 5. 現在 1. 第2次JSフレームワーク戦争 2. なんでもかんでもコンパイル時代 etc…
- 45. 5. 現在 Backbone ❖ フロントエンドMV*の走りとなった古参。 ❖ ライトウェイトだが縛りもすくなく、実装者によってコー ドに差が大きい。 ❖ HuluやTrello等、多くのサービスにて採用されている。 第2次JSフレームワーク戦争
- 46. 5. 現在 Angular ❖ 独自の書き方になり学習コストが高く他への応用が利かな い。 ❖ 現状、1,2の移行期。Google製で、今後はTypeScriptとの連 携が期待されている。 ❖ 今の所一番強い？印象。 第2次JSフレームワーク戦争
- 47. 5. 現在 React ❖ ここ数年で人気が出てきたフレームワーク。 ❖ Facebook製。Web版のFacebookもコレを採用。 ❖ MV*ではなくViewのみ。 第2次JSフレームワーク戦争
- 48. 5. 現在 ❖ 他、様々なフレームワークがある中、決め手となるものが ない状況。 ❖ MV*モデル自体がバックエンド言語から来ている思想。 ❖ バックエンドと同じやり方でフロントエンド実装をしよう とするとやりやすい、という考えの元でのフレームワーク 。 ❖ 元々のJavaScriptにはなかった展開。 第2次JSフレームワーク戦争
- 50. 5. 現在 JavaScript ❖ CoffeeScriptが走り。Java等の他の言語の人が書きやすい 書き方で書き、JavaScriptにコンパイルする、という流れ ができた。 ❖ TypeScript等、AltJSと呼ばれるJSコンパイル言語が発達。 なんでもかんでもコンパイル時代
- 51. 5. 現在 他への影響 ❖ CSS側でも発生。Sass, Less, StylusがCSSプリプロセッサと してフロントエンドに投入される。 ❖ バックエンドフレームワークにセットアップすることが可能 。 ❖ バックエンドフレームワークのViewで使用されていたJadeや Slimを単独でコンパイルしてHTMLを書く、という流れも生ま れている。 なんでもかんでもコンパイル時代
- 52. 5. 現在 タスクマネージャーの誕生 ❖ コンパイルを中心としたタスクを管理するツールが広く使 われ始めている。 ❖ コンパイル前提でフロントエンド作業が完結する時代。 →フロントエンド以外の人（≒バックエンドの人）が使いや すいように進化している。 なんでもかんでもコンパイル時代
- 55. 6. 未来展望: 「Webフロントエンド」って、結局どうなる ？ 現状 ❖ 新デバイス ❖ HTML5,ECMAScript6/7 ❖ 他言語からの思想・技術・技術者の流入 ❖ コンパイル言語としてのHTML,CSS,JavaScript
- 56. 6. 未来展望: 「Webフロントエンド」って、結局どうなる ？ 今後 ❖ Webの技術自体の適用範囲・注目度は上がっていく。 ❖ HTMLやCSS,JavaScriptは、今と違った形へと変わってい く。言語自体が新しいものに引き継がれて消えていくので はなかろうか。 ❖ バックエンドとフロントエンドの役割が融合・再編成され て、今の職業区分はなくなっていきそう。
- 58. 6. 未来展望: 「Webフロントエンド」って、結局どうなる ？ エンジニアとして生き残っていくためには ❖ これまでも常に学び続けていたが、やっぱり技術の動向をしっかり見 つめていくべき。必要な時に、必要な技術を使えるように。 ❖ 過去に苦労したことは、今後の新技術でも同じターンは必ず来る。歴 史は繰り返す。今当たり前になっていることを、たまには振り返って 進化を確認するとよさそう。 ❖ 変化を恐れない。恐れてもいいけど、薄眼を開けてでも直視する勇気 が必要。 ❖ 必要があったら、新しい戦場に飛び込んでいく度胸を持つ。
- 60. ご清聴、ありがとうございました。
Notes de l'éditeur
- はじめまして。松田と申します。 今日は「Webフロントエンドエンジニアの戦い」っていうなんか物騒なタイトルもってきましたが、今回、あんまりどういう職種の方が来られるとかっていうのがあんまりよくわからなかったので、技術的なお話じゃなくて概論的なお話をさせていただこうかなと思います。
- 物騒なテーマではあるんですが、Web業界以外の方にも「フロントエンド」っていう職種が、webでどういう役割してて、どういう問題意識もって今後に臨もうとしてるか？っていうのをなんとなくほんわり感じられるようなお話にできたらな。っておもいます。
- ちなみにフロントエンドエンジニアっていうのは和製英語というか、日本での通称って感じです。国外だと通じないと思っていいと思います。 国外では「web developer of frontend」って名乗ってました。
- web業界に入ってからの流れはこんな感じです。 今はお声がけいただいたら受託対応する、みたいな感じになっています。
- で、私が名乗ってる職名、webフロントエンドエンジニア、についてですね。
- ちなみに私の親兄弟は、未だに私が何してるか知りません。
- ここからは、フロントエンドがこれまで何をしてきたか、どういう歴史があったかというのを軽くご紹介しつつ、フロントエンドってどういう仕事なのかなっていうのをなんとなく雰囲気わかってもらえればなぁ。って思います。
- 当時はオーサリングツールとしてはDreamweaverが主流でしたね。数年後には壊滅的な状況になるんですけど…。 JSではLightBox.jsが流行って、LightBoxが依存していたPrototype.jsの勢力もかなり強かったんですよね。
- 「○●を実装して」って言われると、自分が使えるフレームワークでプラグインがあるかどうかを調べる生活をしていました。 実装が必要なものが複数になるとjQueryベースのものとPrototypeベースのものが混在したりすることもあったりして。 とりあえずプラグイン入れてコピペ。っていうのがよくありました。 んで、いくつかプラグイン入れるとバッティングするっていうのが結構あって。それを避けようとしてバグを生むっていうのもありましたね。
- jQueryで決着が着く頃には、実装の要求が複雑化してきて、プラグインだけだと対応しきれなくなってきてて、jQueryで手書き、っていうのが増えてきた頃と一致します。
- 「HTML5」が結構早い時期から言われていたのにエンジニア側で実装に移れなかったのは、IEの存在ですね。実践で使うようになったのはほんとここ数年の話です。
- そもそもこの時期は「何か動いていたらAjax」「何か動いていればHTML5」とかいう、コトバを理解しない誤解・用語の誤用が蔓延していたんですよね。「Ajax」とか「HTML5」とか言われるたびに「一体このディレクターは何を要求しているの？？」って理解するのに無駄な血をながしたなぁと。
- 元々JavaScript以外の言語から入ってきた人たちの思想によるものなので、既存のJavaScriptの作りに合うわけがないんですよね。なのでJavaScriptでの決定打が生み出せないんです。そういう意味ではReactが新しい考え方持ち込んだかなっては思うんですけど、これもなんかスッキリしないので…しばらくはいろんなフレームワークがはびこることになるんだろうなと思います。
- HTMLが静的じゃなくてコンパイル言語になってきてる、っていう時点で、正直HTMLって生き残らないんじゃないかなって思うんですよね。 マークダウン含めた感じで、バックエンドでレンダリングまで持っていくような感じに、最終的にはなっていくんじゃないかなと。 案外、XMLが復権してくる気もしてますし。
- CSSでIE6で苦労したと思ったら、スマホ、特にAndroidの初期ブラウザもそれ以上に苦労したりとか、Flashがサイコーだと思われていたのに終焉を迎えてJSでリッチコンテンツつくるようになったりとか、やっぱ短いスパンでも歴史は繰り返してるんですよね。 繰り返しはしますけど、やはりテクノロジーは変わっていくので。それをちゃんと意識して、新しい技術の中で自分が何ができるのか、何がしたいのかっていうのを見極めて、立ち位置取っていくのがいいんではないかなぁと。