Subscribed unsubscribe Subscribe Subscribe

nashcft's blog

時々何か書く。

『市ヶ谷Geek★Night「型のあるフロントエンドの世界〜フロントエンド・フロンティア〜」』メモ #ichigayageek

イベント

ichigayageek.connpass.com

Togetterまとめ (ダブっているが完全に重複している訳ではないので両方載せておく)
togetter.com

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?

近年のfrontend

  • jQueryの次の時代
    • jでは難しくなって来たことをしていく
  • ダンブラウザの台頭
    • gc, ff, edge
    • jsエンジンの高速化
    • 最新仕様への追従
  • バイル対応比重の激増
    • iOS, Android
    • native app相当のGUIを求められるようになった
      • PWA/AMPによって実現可能に
      • できることが多くなった
  • GUI構築支援ツール・概念の登場
    • node.js/npm
      • packagingの実現、frontendでも使えるようになる
    • WAF, library
      • 人の手でDOM操作やdata bindingをしなくて済むようになった
    • JSの進化 (ES2015~)
  • 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登場
    • onload上書き防止、DOMいじりまくり、SVNコンフリクトしまくり、JSできます == jQUery使ったことあります => false
    • 無名関数でクロージャ、クライアントMVC, イベント伝達、難読化、ライブラリ利用で素のJSはあまり触らない、疑似クラス
  • node.js登場
  • taskrunnerとか色々
  • AltJS
    • Coffee, Type, JSX, Dart, etc...
  • TypeScript
    • 静的型付、JSのスーパーセット、対応エディタ多い (IDE支援)、etc
    • Generics: class/interfaceのパラメータ化
    • Decorator: @Componentと記述することでclassやmethodに付加情報を付与することができる

型を使うなら

セッション3: 株式会社キュア・アップ 鈴木 晋 様「実践投入してわかったflowtypeのメリデメ」

スライド
speakerdeck.com

  • cure app (CM)
    • flow 51番目のコミッタ

ネットで拾える情報

  • JSの静的型チェッカー
  • annotationはbabelで取り除く
  • 言語でない、徐々に導入できる
  • nullに強い
  • 公式の
    • flowはJSのよくあるバグを未然に防ぐことができる
      • nullableなオブジェクトへのアクセスのバグに注意してくれる、ガード節を認識してくれる (warningが飛ばない)
  • 言語ではないので実際のコードはシンプルに保たれる
  • 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がカオス(OCamlregexpをエスケープしたもの?)
  • まだ0.xなのでupdateするたびにエラーが増える
  • @flowを忘れたら何もしてくれない
    • editor補完で気づくかlinterが欲しい...
  • overloadがない
  • Enumっぽいことはできるのだがundocumented
    • $Keys で列挙型を表現したり $Shapeで部分型が使えたり
    • Qiitaにまとめられた記事がある
  • ライブラリにすると型情報が使えない
    • ソースをそのまま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でつかえるものはつかえる
  • Type mappingはd.tsを使える
    • scala-js-ts-importer
      • 完全に対応しているわけではない (Union typeとか、コンパイルが通らない)
    • js.Dynamic (not type-safe)
  • ScalaTags
    • Scalaでhtmlとかxmlを生成する...けど...辛い
    • scalajs-reactを使うときはこれを使わないといけない
  • ScalaCSS
  • js framework
    • scalajs-react
    • angularの
  • 困るところ
    • 生成されたJSファイルが大きい (前よりはマシだけど)
    • type mappingの作成とメンテのコスト
    • 既存エコシステムに全く組み込めない
      • npmとかbuild toolsとかに全く乗っかれない
    • frontendの人がscalaを書くのか? ごもっとも
  • The approach
    • server-side: scala
    • frontend: js
    • interface for frontend: scala.js
      • error handlingとか?
    • 二槽式

質疑応答

  • jserとscalaの住み分け?
    • jserがUIやデザインに集中させるときは上記のが良さそう
    • BFFと考えが近いかもね
  • 生成されたjsは
    • 一個のjsファイルに
    • browserifyでは使えそうにない
  • JSのimport/exportに対応する気配は...
  • source mapは吐き出される?
    • する
  • ScalaTagsはサーバサイド(Play)で使ってSSRはできる?
    • できる。isomorphic的なこともできることはできる

LTs

qiita.com

speakerdeck.com

qiita.com

*1:実際のところ開発すら稀にしかやらなくなってきているのだけど