Togetterまとめ (ダブっているが完全に重複している訳ではないので両方載せておく)
togetter.com
感想
5月に転職してサーバサイド開発ばかりやるようになってから*1フロントエンド事情にだいぶ疎くなっていたので、GraphQLの事とかElmがバージョン上がる度に言語仕様が小さくなっている事とかは全然知らなかったし、静的型付き言語を含むスタックやFlowTypeを実際に使ってみての知見が結構蓄積されつつあるんだなあということを知ることができて大きな収穫を得られたと感じた。Elmはもう一度学び始めてみようかと考えている。
懇親会でGraphQLの話をしているのを聞いていたが、そこで聞いた感じGraphQLはクライアント側でリクエストを送る際の形式の一つで、データソース側は特に指定されていないという認識をしている。DB側がMySQLだったりMongoDBだったりとそこは関係がないらしい。この辺はもう少し調べて確かな知識をつける必要がある。
あとクライアント側でグラフ的な柔軟なクエリを作成できるが、その分サーバ側では簡単に許容外なレベルの負荷になってしまいがちで、規模が大きなサービスで使うなら、金にものを言わせてマッチョなサーバを用意するか、サーバ間でのリクエストなどある程度クエリをコントロールできる形で使用するかという感じらしい。結局クライアントがデータの関係性についてのクエリを自由に作れるようになったからといって、DB側はそれが不得意なままだし、という事か。DBがグラフデータモデルだと相性はいいのだろうか。ちょっと興味が出てきた。
以下メモ
セッション1: 株式会社オプト 伏見 大輔「フロントエンドが本当に必要だったもの」
スライド
http://sisisin.github.io/s_s/type/index.html#1
frontend?
- HTML/CSS/JS
近年のfrontend
- jQueryの次の時代
- jでは難しくなって来たことをしていく
- モダンブラウザの台頭
- gc, ff, edge
- jsエンジンの高速化
- 最新仕様への追従
- モバイル対応比重の激増
- GUI構築支援ツール・概念の登場
- node.js/npm
- packagingの実現、frontendでも使えるようになる
- WAF, library
- 人の手でDOM操作やdata bindingをしなくて済むようになった
- JSの進化 (ES2015~)
- node.js/npm
- AltJS, transpiler
- Coffee
- Type
- etc
- 静的型付きな言語でfrontendを開発できるようになった
静的型付き言語
- コンパイル時にしょうもないエラーは潰せる
- 大規模・多人数での開発
静的型付き言語の恩恵
- 安全性
- 実行時エラーの削減
- 自動テストのコスト削減
- チェック箇所を絞れる
本当に必要だったもの
- 型? 否!
- ユーザへの価値の提供
- 静的型付けは強力な武器の一つ
- 近年の進化で使いやすくなった
セッション2: 株式会社トレタ 吉田 徹生 様「型を使うと便利な開発」
スライド
speakerdeck.com
JSの歴史の話
- 愛生会
- Google Maps (Google shock): Ajax
- XHRとか
- DOMいじりまくり、prototype汚染の防止、長いfunction, alert無限ループ
- なるべくしてなるデスマ
- jQuery
- FireBug: inspector, style, etc...
- Chrome登場
- node.js登場
- taskrunnerとか色々
- AltJS
- Coffee, Type, JSX, Dart, etc...
- TypeScript
型を使うなら
- 厳密ではなくゆるくつかいたい
- 複数人でやるならほぼ必須
- 色々準備が必要なのが面倒
セッション3: 株式会社キュア・アップ 鈴木 晋 様「実践投入してわかったflowtypeのメリデメ」
スライド
speakerdeck.com
- cure app (CM)
- flow 51番目のコミッタ
ネットで拾える情報
- JSの静的型チェッカー
- annotationはbabelで取り除く
- 言語でない、徐々に導入できる
- nullに強い
- 公式の
- flowはJSのよくあるバグを未然に防ぐことができる
- nullableなオブジェクトへのアクセスのバグに注意してくれる、ガード節を認識してくれる (warningが飛ばない)
- flowはJSのよくあるバグを未然に防ぐことができる
- 言語ではないので実際のコードはシンプルに保たれる
- faebookとMSの思想の違い
- FB: libやツールを組み合わせる、選択肢の提供
- MS: All in One
使ってよかったflowの良さ
- 導入がシンプル
- とにかくnullに強い
- nullへの警告を防ぐためにnullを返しうるAPIをやめthrowするように変更
- NodeやBrowserのAPIのサポートが充実している: そいつらも警告してくれる
- 最低限のannotationを使うだけでも十分有効
- facebookのライブラリなら対応されているがflow-typedなライブラリはまだ少ない (100いくらか)
- 2回目以降のチェックが高速
- 裏でサーバが立ち上がったりキャッシュがあったり
- atom拡張
使ってわかったflowの辛さ
- node_modules以下も解析して警告を出してくる
- flowconfigにignoreを書く必要がある
- flowconfigに書くregexpがカオス(OCamlのregexpをエスケープしたもの?)
- まだ0.xなのでupdateするたびにエラーが増える
- @flowを忘れたら何もしてくれない
- editor補完で気づくかlinterが欲しい...
- overloadがない
- Enumっぽいことはできるのだがundocumented
- $Keys
で列挙型を表現したり $Shape で部分型が使えたり - Qiitaにまとめられた記事がある
- $Keys
- ライブラリにすると型情報が使えない
- ソースをそのままexportするとか (flow genflow-filesコマンドができた)
- experimentalなのは開発者の実装具合によってしまう
それでもflowを使う理由
- 辛いのを分類すると...
- 1回設定すればいい系
- 時が解決してくれる系
- もう解決したやつもある
- しようがない系
- experimentalだし
- すぐに導入できるし、やめられる
質疑応答
- @flowを忘れる
- flow coverageとかnuclideでできるっぽい
- flowを選んだ理由
- シンプルを組み合わせる思想に共感
セッション4: 株式会社ビズリーチ 竹添 直樹 様「Scalaによるタイプセーフなフロントエンド開発」
まとめ記事
takezoe.hatenablog.com
Scala Warriorを開発するのにScala.js, ScalaCSS, ScalaTagsを使った
- client上のScalaコードを実行させるためにScala.jsを使っている
- サーバ側でtranspileしてる
- Scala.jsのスタック
- scalajs-reactとかangular使えたりとか
- ScalaJS compiler pluginを使って中間言語を生成してからjsにする
- Scala.js is awesome!!
- scalaでつかえるものはつかえる
- IDEとか
- Type mappingはd.tsを使える
- ScalaTags
- ScalaCSS
- inline mode
- コンパイル時に参照チェック
- js framework
- scalajs-react
- angularの
- 困るところ
- 生成されたJSファイルが大きい (前よりはマシだけど)
- type mappingの作成とメンテのコスト
- 既存エコシステムに全く組み込めない
- npmとかbuild toolsとかに全く乗っかれない
- frontendの人がscalaを書くのか? ごもっとも
- The approach
質疑応答
- jserとscalaの住み分け?
- jserがUIやデザインに集中させるときは上記のが良さそう
- BFFと考えが近いかもね
- 生成されたjsは
- 一個のjsファイルに
- browserifyでは使えそうにない
- JSのimport/exportに対応する気配は...
scalaの人たちがそっちのやり方に向いてる感じがない動きもなさそう- サポートされているそうです
- source mapは吐き出される?
- する
- ScalaTagsはサーバサイド(Play)で使ってSSRはできる?
- できる。isomorphic的なこともできることはできる
LTs
*1:実際のところ開発すら稀にしかやらなくなってきているのだけど
