SPAサービスサミットとは
ホットスタートアップ、グッドパッチ、ピースオブケイク3社主催のイベント。 http://peraichi.connpass.com/event/42288/
3社のプロダクト（ペライチ、Prott、note）はいずれも知っているものだったのでその裏側の開発話などを聞ければと思って参加した。
React / Angular2 のような目新しいトレンドっぽい話はなく、Backbone.js や Angular.js、jQuery からの移行、CoffeeScript の負債化など、わりと泥臭い話・苦労話が多かった。弊社も Backbone.js から React.js への過渡期なので共感できる面は多い、というか大体同じような悩みがどこにでもあると再認識。
所感
SPA にすべき理由
ペライチや Prott のような、ユーザーの入力が多い、かつ直感的な操作を有するツール系のアプリでの使用例はわりとかっちりハマるというか理にかなっている。一方、読み物中心の静的に近いサイトではほぼ必要ない。
Quipper ではユーザーが触るアプリケーションはほぼ全て SPA。もちろんリッチな画面の実現による UI / UX 向上も目的にはあるが、SPA たる最も大きな理由を聞かれたらマーケットである新興諸国（フィリピン、インドネシア）の貧弱なネットワーク環境への対抗策と答える。
API を共有することにより iOS / Android とともに開発効率を上げる効果もある。
Isomorphic
Google のクローラが Ajax を使ったアプリケーションもちゃんと考慮するようになったと随分前に発表があったが実際の効果を見たところダメっぽく、やっぱり Server Side Rendering が必要なシーンはあるらしい。それが以前なら難しかったが、2016年時点では Server Side rendering は決してチャレンジングではなく現実味のある選択とのこと。
個人的にはまったく必要性に駆られていないのでまだまだ手を付ける気はしてない。（読み物中心の note のようなアプリケーションではもちろん必須）
Browser Support
SPA と直接関係ないが、どこまでサポートするかという話もあったが、ペライチは Chrome のみ、Prott もユーザーにクリエイター系が多いのでモダンブラウザのみというのに驚いた。（IE でアクセスすると Chrome download リンクを表示しているらしい。これは Quipper のプロダクトでもやっている）
Quipper のプロダクトを使うユーザーの中でも特に日本の学校は IE のシェアが高く決して無視できない。Pull Request の review の段階で Windows + IE での挙動を確認することもあるし、過去の経験から「このメソッドは IE で動かないよ」みたいな指摘もあったりする。そうした review やテストは存在するが、自動テストでは検出できない領域があるのがクライアントサイドと知っているので、リリース前には人力での IE テストも苦しみながらやっている。
それに比べて、「Chrome にしてね」でしてくれるユーザーが集まる優しいインターネットがあるとは…。
CoffeeScript
ES2015 以降、CoffeeScript が負債というのが共通認識になっていると思った。本体が Active でないだけでなく言語を取り巻く様々なものが相対的に劣化して見えるという不安を多くの人が抱いていた。
登壇者の話だと「ES Lint に比べて CoffeeLint は全然いけてない。そのぶん人間が review でカバーしなければならず、結果的に生産性を落とすことになる」というのも興味深かった。
フロント専業
他社の話を聞くと結構な割合で、フロントエンド（web）・サーバサイドのエンジニアが分業している開発スタイルを採用しているようだが、そんなにフロントエンドエンジニアを採用できるのだろうか…とふと疑問に思った。
弊社も以下のような求人を Wantedly に掲載しているが、フロントエンドエンジニアの募集は応募者数 / PV 比率が圧倒的に低い。PV はそこそこあるので関心は集めていそうだが応募が少ない。
英語を身に着けたいサーバーサイドエンジニア募集 - Web Engineer jobs at Quipper Ltd - Wantedly
（教育☓グローバル）フロントエンドが得意なweb developer募集！ - Engineer / Programmer jobs at Quipper Ltd - Wantedly
この謎を解いて採用につなげたい。（仮説はある）
その他
知らなかった技術要素など。
