【メモ】市ヶ谷Geek★Night「型のあるフロントエンドの世界〜フロントエンド・フロンティア〜」 2016/11/4 @株式会社オプト
これに行ってきたのでそのメモ。
市ヶ谷Geek★Night「型のあるフロントエンドの世界〜フロントエンド・フロンティア〜」
型の話だ
TypeScriptの勉強を個人的にやっているだけでまだ業務で使ったことがないので導入事例を聞きたいというそういうあれです。
市ヶ谷Geek NightはいつだったかScalaの回に参加したとき以来だったので久しぶりの会場でした。
そんなわけでメモを投下していきます。
目次
- フロントエンドが本当に必要だったもの
- 型を使うと便利な開発
- 実践投入してわかったflowtypeのメリデメ
- Scalaによるタイプセーフなフロントエンド開発
本編
残しといたメモを貼りつつ感想を付け加えていくスタイルで。
フロントエンドが本当に必要だったもの
スライド： http://sisisin.github.io/s_s/type/index.html#1
内容
近年のフロントエンドは「jQueryの次の時代」
- モダンブラウザの台頭
- モバイル対応の比重の激増
- フロントでやる幅が増えた
- GUI構築を支援する様々なツール・概念の登場
- npm
- トランスパイラ・AltJSの登場
- 静的型付けがフロントでできるようになった
静的型付け
実行前にコードの整合性をチェックできる
静的型付けの恩恵
- 実行しなくともコンパイルの段階でしょうもないミスを発見できる
- クラスがどこで使われているか、どこで定義されているかなどが参照できる
何を与えてくれるのか
不安定な世界に安定をもたらしてくれる
フロントエンドが本当に必要だったもの
「型」ではなく、ユーザーへの価値の提供だ！
オプトのTypeScript導入事例
感想
フロントエンドの歴史と静的型付けについての解説に関しての話でした。
特に実践的な話ではなかったのですが、導入事例としてあげていたブログの記事の内容がとてもためになりました。
型を使うと便利な開発
@teyoshさん
内容
歴史の話
- ちょこっと動きをつけるだけ
- 昔はページが重くなるのでjsは基本offの時代
googleショック => google map
↓
webアプリ大航海時代に入る
その頃の開発環境
- prototype.js
デバッグはalert
DOMいじりまくり
- prototype拡張
- デバッグalert無限ループで終わらない
なるべくしてなるデスマ
救世主の登場
それでもまだIE6対応は続く…
時は経ちgoogle chromeが登場
その頃の開発環境
革命
Node.js
AltJSの台頭
- CoffeeScript
- TypeScript
- Dart
TypeScriptの登場
- 型がある
- javascriptのスーパーセット
- 対応エディタが多い
- ジェネリクス
- デコレーター
JavaScriptのコードをそのまま利用することができる
- リストを作るのに型が多いとその分作らないといけないのか？
- クラスやインターフェースをパラメータ化できる
デコレータ
@Componentと記述することでclassやmethodに付加情報を投与することができる
型を使うなら
- 厳密ではなくてゆるーく使っていきたい(型を使うのが目的になってはいけない)
- 複数人でやる場合はほぼ必須
- 色々準備が必要なのが面倒
感想
こちらも現在のフロントエンドに至るまでの歴史と、TypeScriptに関しての説明と言った感じでした。
JSの歴史の中で「愛生会病院」が出てきたときはやっぱウケてました。みんな好きすぎなんだなあ。
僕がエンジニアになったときはIE7の対応をするってなったら「まじか」ってなる雰囲気くらいの時代だったので僕は辛い世界を知らずに生きているのか、とそういう気持ちになりました。
実践投入してわかったflowtypeのメリデメ
@shinoutさん
内容
キュア・アップからきた
- 業務でも積極的なOSS活動
- flowにも3commit出している
ネットで拾えるflowの特徴
JSのよくあるバグを未然に防ぐことができる。
undefined is not a function を取り除く。
アノテーションのための文法は実行時にはすべて取り除かれる。
使ってわかったflowの良さ
- 導入がシンプル
- とにかくnullに強い
- NodeやBrowserのAPIのサポートが充実(基本的なAPIは網羅されている)
- React / React Native周辺技術の型もサポートされている
- 初回のflowコマンドでサーバが立ち上がり、2回目以降は必要な部分だけ型チェックするのではやい
クライアント側でflowに怒られないようにするnull対応が毎回めんどくさいので、nullを返さずにthrowするって形でAPI側を変更した。
=> APIの見通しがよくなった。
使ってわかったflowの辛さ
- node_modules内にあるエラーで怒る(空のjsonファイルに対するparse error) -> ignoreを一つ一つやる
- 設定ファイルの正規表現がカオス
- バージョンが変わるたびにエラーが増える -> バージョンの変化に自動的に追従しないように変更
- @flowを忘れると何もしてくれない
- オーバーロードはない -> 型のある言語のパラダイムが全部あるのかというとそういうわけではない
- Magic typeがドキュメントされていない(のに便利)
- ライブラリにすると型情報が使えない
- experimentalな文法の一部は解釈できない -> stageが低い記法は対応してなかったりする(OCaml製ゆえに)
- 依存モジュールのflow versionに縛られる
Magic typeに関しては以下を読めばok
それでもflowを使うべき理由
- 1回設定すればいい辛さは1回頑張って乗り切る
- 時が解決するやつ -> バージョンが1になることで解決しそう
- しょうがないやつ -> 我慢するしかない(我慢し得る)
- すぐにやれるし、やめられる
導入も簡単だし、flowのコードを抜くのも簡単。
進化を続けるJSのスピードについていくのはロックインされない「ツール」ではないのか？
感想
とても実践的な内容ですごく参考になった。
やっぱり導入しやすいし捨てやすいってのは気持ち的にも障壁が少なくて良い。
僕も趣味開発だとReactのプロジェクトはやっぱflowかなあーと思う。
Scalaによるタイプセーフなフロントエンド開発
スライド見つからず。見つけたら貼ります。
内容
Scala.js
Scala.jsはbabelのようなトランスパイラ。
Type-safe frontend development with Scala.js.
一つのscalaのコードを書くと、サーバで使えるjavaのclassファイルとjsのファイルを両方生成する。
scala.jsはscalaの機能が多く使えて、scalaのIDEも使える。
scalaだけで完結できるわけではなく、既存のJSとの相互運用が必要になってくる。
型のマッピングのファイルを作らないといけない。
scala-js-ts-importer=> tsのマッピングからscala.jsのマッピングを自動生成できる。
ただ、表現力の差があるので、そういう部分はコンパイルが通らなかったりする -> そこは手でなおす。
js.Dynamicというものを使うと、マッピングファイルがなくてもJSのメソッドをよびだせる。
ScalaTags -> JSX的なやつ ScalaCSS -> CSSをscalaで書ける(sassっぽい感じ)
問題
- 生成したjavascriptのファイルサイズがでかい
- マッピングファイルを生成するコストが高い
- フロントエンドのエコシステムが使えない
- フロントエンドの人がscala書くのが
別のアプローチ
scala.jsはサーバ側でフロントとのやり取りのインターフェースとして使うのが良い。
いわゆる二槽式的な考え。
まとめ
scala.jsは全部scalaを使うかというとそういうわけではない。
フロントエンドの人が使いやすいようなAPIの提供を可能にするという使い方。
感想
Scalaパズルの人と聞いてびっくり。すごい人がJSの勉強会にやってきた。
Scala.jsって初めて聞いたときはネタかと思ったけど結構いろんな人の話を聞く中でなかなか良いっぽいという噂は聞いていた。
やっぱり全てをScalaで完結させるというのは厳しいっぽくて(特にフロントの既存のエコシステムが使えないというのがやばい)、でもサーバ側の中でクライアント側とのやりとりをする部分をScala.jsで書くっていうアプローチの仕方は確かにとても良さそうな感じだった。
自分がScala.jsを使うとは思わないけれど。
LT
今回LTがとてもよくって、特に@ovrmrwさんのGraphQLの話が面白かった。
例によってLTの時間は食事をするので精一杯だったのでメモはとってないのでスライドだけ共有しておきます。
まとめ
今回はTypeScriptとFlowの導入事例を聞きたかったのでとても満足した。
実際にはTypeScriptの導入事例的な具体的な話はなかったけれどオプトさんの記事を発見できたので良し。
最大の成果はGraphQLほんとすごいなあって気持ちになれたこと。
僕の観測範囲のAngular界隈の人たちはほんとアウトプットが活発で素晴らしいなあと思う。
とりあえずAngular2 + GrapuQLってのはやってみよう。
もちろんTypeScriptで。
