「CTO meet up〜JavaScript（Angular,React,Vue）〜」に参加してきました

• CTO meet up〜JavaScript（Angular,React,Vue）〜に参加してきました

flexy.connpass.com

flxy.jp

• 以下パネルディスカッションのメモです

JavaScript（Angular,React,Vue）進化しつづける技術について

• 林優一さん(フリーランス)
• 古川陽介さん(リクルートテクノロジーズ)
• 菅原孝則さん(ファームノート)

どうやって技術選定してる?

林さん

• 最近はAngularとReact使った
• Angularは管理画面
  • CRUDが多いから
  • ライブラリ選定する時間もなかったから
• Reactはvmeets
  • WebRTCとのやりとりやりやすいから
• 3rdパーティのライブラリの量が一つの指針
  • 以下に早く作るかを重視してるから
• ReactでもTS使ってる
  • Redux使ってるとTSの恩恵大きい
  • ビルドで気付ける
• 3rdパーティで型定義ちゃんとしてないやつはanyにしちゃう
  • そのうち切り離したいようなものだから
• AngularのVUPに合わせてライブラリVUP

古川さん

• 3年前に技術選定してReactを選択
  • 主流になってきていた
  • Reduxも採用
  • たまたまうまくいったからそのまま継続している
• ある程度の規模を想定して一度作ってしまう
  • ホットペッパー相当のものを作った
  • 当時はReact一択だったから他は試してない
• 世の中で使われてるかどうかは見る
  • githubスタートとか
  • twitterの情報とか
  • qiitaとか
• Flow使ってる
  • 80%くらい嬉しいけど20%くらいつらい
  • 3rdパーティのライブラリで型定義されてないとか
    • 3rdパーティのライブラリの型定義が間違ってると最悪
  • 開発体験としてあんまりうれしくない
  • 3rdパーティこそ型ちゃんとしててほしい信頼ならないから
• greenkeeper使ってる
• 改善day設けてそこでライブラリアップデートしてる
  • バージョン追従できてるのとできてないのもある

菅原さん

• 2年前入社時はBackboneだった
  • コンポーネントベースにしたい
  • Vueがやりやすかった
• 1ヶ月でios/android
  • ReactNativeで高速に
  • mobXを採用(Vuexに似てたから)
• エディタの対応書き心地の良さ
• 3rdパーティライブラリで悩まされるの嫌だから自前でやってしまう

今の技術の課題・解決方法

林さん

• 前任者のいないソースコード

古川さん

• エコシステムのライフサイクルが短すぎる(特にReact周り)
  • ついていけないとReactやめていっちゃうんじゃないか
• 従来の技術でなくSPAを作ってるのはパフォーマンスがモチベーションにあるから
  • だからパフォーマンスが悪いSPAだと本末転倒なんじゃないか

菅原さん

• チャートとか作ろうとすると仮想DOMが邪魔になってしまうこともある
  • それをガリガリやってくれるエンジニアも貴重
• コンポーネント単位の差分レンダリングmobXだとできるけど追いかけるのつらい

これからのフロントエンドのトレンド・動向を教えて

林さん

• WebComponents
  • WebComponentsでCSSのスコープができることがいい
    • 今も実現できてる
    • それを使ってビジネスにプラスになるか？薄い
• WebRTC
  • 最近使えるレベルになってきた
  • SPAでもリアルタイム通信が当たり前になってくるんじゃないか

古川さん

• WebComponentsに夢を見る？
  • 見ない
  • パフォーマンス速くなると思えない
  • パフォーマンス悪いと本末転倒
  • チューニングしなくてもそこそこ速いのはできるようになるかも
• PWAは？
  • オフラインで嬉しいアプリだったりそうでないアプリだったり
  • ホットペッパーは予約できるか見ないと意味ない
  • ServiceWorker使うという意味では必要
• 投機的先読み
  • guess.js
  • ga使って先読み

菅原さん

• デザインツールでReactコンポーネントをいじれるフレームワークがある

今、現場に最もほしいフロントエンドエンジニアとは？

林さん

• 技術+αで何か持ってる人
  • 技術+技術ではなくビジネス的要素とか
• フロントエンドエンジニアになりたい人に向けて
  • 作って人に見てもらうことが経験値になる
    • 徹底的に悩むこと
• デザインとJS両方やらせるか？
  • マネジメント視点では適材適所
  • 1エンジニア視点だと知れるものは吸収した方がいい
  • JSエンジニアでも最低限のデザインは知っておくべき
• フロントエンドエンジニアのキャリアパス
  • 技術以外も含めて＋１が求められる
  • nativeとweb両方できるとコンスタントに生きていける

古川さん

• フレームワークの奥で何やってるか調べられる人
  • ただ作ってみただけでなく深くまで入り込んで作ってきた経験値
  • ブラウザのレンダリングとかフレームワークのアルゴリズムの話とかできる人
• フロントエンドエンジニアになりたい人に向けて
  • 自分の中ではこうしたいのにうまくいかず悩む時間を経験することが重要
    • リクルートテクノロジーズでは新人に幅広く基礎を教えてる
• デザインとJS両方やらせるか？
  • どちらかが得意であってもいいが無関心であってはいけない
  • 垣根がないものとしてできないといけない
• フロントエンドエンジニアのキャリアパス
  • フレームワークで何かを作れるだけでなく＋αを求められてる

菅原さん

• フレームワークに関係なく能力の高いエンジニア
  • インタラクションを作るエンジニアが希少
• フロントエンドエンジニアになりたい人に向けて
  • まずデザインからで目線づくり
• プロトタイプバトル
  • 話し合ってもおさまらないから作ったもので決着をつける
• デザインとJS両方やらせるか？
  • 本人の志向次第
  • figmaでみんなでデザインの認識合わせ
• フロントエンドエンジニアのキャリアパス
  • ユーザがすごいと思えるものを提供できてれば勝ちがある