Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
15分で知(った気にな)る最近のフロントエンド事情
Search
mugi / Hajime Mugishima
September 27, 2018
Technology
250
2
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
15分で知(った気にな)る最近のフロントエンド事情
2018.09.27 もくテク
mugi / Hajime Mugishima
September 27, 2018
More Decks by mugi / Hajime Mugishima
See All by mugi / Hajime Mugishima
AIと乗り切った1,500ページ超のヘルプサイト基盤刷新とさらにその先の話
mugi_uno
2
440
サイボウズフロントエンドの活動から考える探究と発信
mugi_uno
1
160
フロントエンドエキスパートチームの解散は 「いい話」なのか?
mugi_uno
8
2.4k
サイボウズフロントエンドの横断活動から考える AI時代にできること
mugi_uno
4
2k
令和7年版 あなたが使ってよいフロントエンド機能とは
mugi_uno
14
7.3k
New Order in Cascade Sorting Order
mugi_uno
3
4.3k
Deep Dive into React Stream/Serialize
mugi_uno
8
2.3k
Next.js App Router での MPA フロントエンド刷新
mugi_uno
40
26k
コロナ禍 Frontend おさらい
mugi_uno
1
490
Other Decks in Technology
See All in Technology
40代で“やっとエンジニアになれた”――閉じた学びを開き、空の青さを知る / 20260628 Naoki Takahashi
shift_evolve
PRO
4
1.4k
初めてのDatabricks勉強会
taka_aki
2
210
フルAIで個人開発して学んだあれこれ / yuruai vol.1
isaoshimizu
0
160
アラート調査向けAIエージェントの本番導入とその後/AI Agents for Alert Investigation: Production Deployment and After
taddy_919
1
290
#エンジニアBooks 30分でわかる 「技術記事を書く技術」 / engineer-books 2026-06-30
jnchito
1
150
「軸足」は 固定しなくていい - 熱量と強みで描く、しなやかなキャリアの形
kakehashi
PRO
1
300
「ビジネスがわかるエンジニア」とは何か?
ryooob
0
420
Agile and AI Redmine Japan 2026
hiranabe
4
550
スタートアップにAmazon EKSは早すぎる? マルチプロダクト戦略を加速する Platform Engineeringの実践 / Is Amazon EKS Too Soon for Startups? Practical Platform Engineering to Accelerate a Multi-Product Strategy
elmodev09
1
1.9k
プライバシー保護の理論と実践
lycorptech_jp
PRO
1
130
5分でわかる Amazon Connect_20260608
hwangbyeonghun
0
150
フルカイテン株式会社 エンジニア向け採用資料
fullkaiten
0
11k
Featured
See All Featured
jQuery: Nuts, Bolts and Bling
dougneiner
66
8.5k
Ethics towards AI in product and experience design
skipperchong
2
320
Product Roadmaps are Hard
iamctodd
PRO
55
12k
How to build an LLM SEO readiness audit: a practical framework
nmsamuel
1
790
VelocityConf: Rendering Performance Case Studies
addyosmani
333
25k
Leo the Paperboy
mayatellez
7
1.9k
How GitHub (no longer) Works
holman
316
150k
Gemini Prompt Engineering: Practical Techniques for Tangible AI Outcomes
mfonobong
2
450
Digital Ethics as a Driver of Design Innovation
axbom
PRO
1
330
Bash Introduction
62gerente
615
220k
WCS-LA-2024
lcolladotor
0
660
So, you think you're a good person
axbom
PRO
2
2.1k
Transcript
15分で知る 最近の フロントエンド事情 2018/9/27 もくテク 最近のWeb技術についてワイワイ語る会 (った気にな)
麦島 一 (むぎしま はじめ) @mugi_uno 自己紹介
フロントエンド、ついていけてます?
None
よく聞くワード 「Javascriptは初心者向け」
現実
一気におさらいしてみよう!
〜はじめに〜
15分じゃ無理
〜目標〜 1. 言語自体の話 2. JSと静的型付け 3. よく聞くフレームワーク 4. 状態管理 5.
モジュール管理 を知った気になってもらう
言語自体の話
ECMAScript • ESxとも呼ばれる(e.g. ES6) • 実装状況はブラウザによる https://kangax.github.io/compat-table/es6/ • 提案状況→tc39/proposals •
Javascriptの標準仕様
ECMAScript • ESxと呼ばれたりする(e.g. ES6) • 実装状況はブラウザによる https://kangax.github.io/compat-table/es6/ • 提案状況→tc39/proposals •
Javascriptの標準仕様
レガシー環境に合わせる必要がある • 要するにIE11で動かないといけない 参考: MDN 「クラス定義」 サポート状況 https:// developer.mozilla.org/ja/ docs/Web/JavaScript/
Reference/Classes
新しい仕様があるのに 使えない…
Babel • ECMAScript 2015+のコードを 未実装の環境でも動く形に変換する • コードをtransformする際に、 ついでに色々できるので混乱しがち (代表例: JSX→JSの変換)
AltJS • ECMAScriptに変換可能な言語 • 混同しがちだが、ECMAScript自体 は仕様なので、AltJSではない
AltJSの例 • TypeScript - Microsoft製 / よく聞く • Dart -
Google製 • ReasonML - Facebook製 • CoffeeScript - あんまり元気がない
なにを選べばいい?
• 私なら、可能ならTypeScriptを選ぶ • フレームワークによってはつらいので、 その場合はES2017 (async/await) • Proposalのstage0-2は避ける
JSと静的型付け
JSと型 • JSは動的型付言語 • データ型は7種類のみ • String • Number •
Boolean • Object • null • unde ned • Symbol (ES2015+)
静的型検査を したくなることがある
よくある問題 • APIのレスポンスはわかっているけど… • タイポで動いてませんでした const user = response.uesr; //
user === undefined
レスポンスを型定義できれば…
型を強化する色々 • TypeScript • Flow • 静的型付けのできるAltJS • 対応ライブラリが多い •
個人的にオススメ • ES上に静的型付けのみを提供する • コメントで定義できる
必要?
• 可能なら使ったほうが良いと思う • リファクタリングの敷居がグッと下がる • わ、わたしも導入しないと…(焦)
よく聞くフレームワーク
jQueryのコード例
e.g. 追加ボタンでタスクを追加 $(‘#add-button’).on('click', () => { const input = $('<input>');
input.attr('type', 'text'); $(‘#todo-list').append(input); }); クリックすると タスクを追加
e.g. 追加ボタンでタスクを追加 $(‘#add-button’).on('click', () => { const input = $('<input>');
input.attr('type', 'text'); input.addClass('todo'); $(‘#todo-list').append(input); }); 仕様変更 →classの追加
e.g. 追加ボタンでタスクを追加 $(‘#add-button').on('click', () => { const todo = $('<div>');
todo.addClass(‘wrapper’); const input = $('<input>'); input.attr('type', 'text'); input.addClass('todo'); todo.append(input); $('#todo-list').append(todo); }); 仕様変更 →divで囲む
e.g. 追加ボタンでタスクを追加 $(‘#add-button').on('click', () => { const todo = $('<div>');
todo.addClass(‘wrapper’); if($(‘.todo’).length % 5) { const separator = $(‘<hr>’); todo.append(separator); } const input = $('<input>'); input.attr('type', 'text'); input.addClass('todo'); todo.append(input); $('#todo-list').append(todo); }); 仕様変更 →5件ごとに区切る
e.g. 追加ボタンでタスクを追加 $(‘#add-button').on('click', () => { const todo = $('<div>');
todo.addClass(‘wrapper’); if($(‘.todo’).length % 5) { const separator = $(‘<hr>’); todo.append(separator); } const input = $('<input>'); input.attr('type', 'text'); input.addClass('todo'); todo.append(input); $(‘#todo-list').append(todo); if($(‘.todo’).length === 20) { $(‘#add-button’).hide(); } }); 仕様変更 →20件を上限
e.g. 追加ボタンでタスクを追加 $(‘#add-button').on('click', () => { const todo = $('<div>');
todo.addClass(‘wrapper’); if($(‘.todo’).length % 5) { const separator = $(‘<hr>’); todo.append(separator); } const input = $('<input>'); input.attr('type', 'text'); input.addClass('todo'); todo.append(input); $(‘#todo-list').append(todo); if($(‘.todo’).length === 20) { $(‘#add-button’).hide(); } }); Q. 最終的なDOMの形は?
• 気軽に描画結果を変更できない • CSS適用に一苦労 • 実際にはこんなものではない • 機能の追加・修正の難易度も高い
• React • Vue • Angular
• Viewを事前に定義する • 状態とViewを分離する 共通している考え方
さっきの例をVueのtemplateで書くと? <template> <div id='todo-list'> <div class='wrapper' v-for='(todo, index) in todoList'>
<input type='text' class='todo' v-model='todo' /> <hr v-if='index % 5' /> </div> <button id='add-button' v-if='todoList.length < 20’> Add Todo </button> </div> </template> DOMを 宣言的に定義
React Facebook / VirtualDOM / JSX • 事例・情報が多い • 他ライブラリとの依存が薄い
• JSX書くのがつらい • 結局他ライブラリが必要になる (Redux, React-Router, など) • トータルで記述量が多くなりがち
Vue コミュニティ / VirtualDOM / SFC • 日本語ドキュメントが充実 • 学習コストが低め(と思う)
• 関連ライブラリとの一体感 • 型付けがつらい • 大企業の後ろ盾がないので、 人によっては不安になるかも
Google / フルスタック / DI • 全部入りなので慣れると強いらしい • TypeScriptとの相性が良い (公式で推奨)
• 独自の概念が多い • 学習コストが高い Angular (経験が薄いので偉そうなことを書けない)
どれにしたらいいの?
いまゼロから学ぶなら Vueから入ると良さそう (個人の意見です)
状態管理
• データ(状態)が散らばったまま • ドメインロジックも散らばっている • SPAだと特につらくなる Reactなどを使って、 Viewは宣言的になったけど… e.g.) アプリケーション全体で使うFlashメッセージ
状態管理だけをきれいにまとめたい (脱オレオレ実装)
• Redux • Vuex
• Reactでの採用例が多い • 単一Store / ReadOnly • 変更時は純粋関数のみを使う Redux
• Vueに特化した状態管理 • Vueならこれにしとけば良い Vuex
必要なの?
• 規模が大きくなってからの 状態管理ライブラリ導入はキツい 入れるなら早めに • 早い段階で判断したほうがいい
モジュール管理
• Javaで言えばimport • Cで言えばinclude • Rubyで言えばrequire • ES5以前はモジュールの概念がない → コード間の依存関係を表現できない
• みんな工夫してがんばってた (RequireJSというものがあってじゃな…)
• Node.jsの登場 • CommonJSの採用 const sub = require(‘./sub.js’);
ブラウザでも使いたい…!
• webpack • Parcel • ES Modules
• CommonJSで書いたコードを ブラウザで動く形に変換できる • 他にできることがめっちゃ多い • uglify(コード圧縮・難読化) • PostCSS/SASSの変換 •
画像変換 など..
• webpack同様のモジュールバンドラ • 特徴 : Zero Con guration Parcel
ECMAScript単体で モジュール管理できないの?
• ES6(2015)以降の仕様 ES Modules import sub from ‘./sub.js’; • webpack/Parcelは
ESModulesも変換できる
結局どうすればいいの?
• ESModulesで書くのが主流 • やりたいことが増えてくると webpackじゃないと厳しくなる • とりあえず考えたくない場合は Parcelが圧倒的に楽 • 不要になる未来は到底来ない気がする
その他
• ESLint, Prettier • Mocha, Jest • puppeteer • SSR
• Next.js • Nuxt.js • Service Worker • PWA
時間切れ
まとめ
15分はあまりにも短すぎる
よく聞くワード 「フロントエンドは変化が速い」
facebook/react - Releases • v16.0.0 - 2017/09/27 • v15.0.0 -
2016/04/09 • v0.14.0 - 2015/08/08
ECMAScript • 2017 - 2017/06 • 2016 - 2016/06 •
6(2015) - 2015/06
そこまで速いわけでもないのでは?
なぜ速く感じるのだろう?
現実
現実 変化するものが多い
私たちは忙しいので、 すべてを常に追うのは難しい。
現実的な話、 新しいものを一気に導入するのは 容易じゃない
ひとつずつやっていこう!