Inside Frontend というフロントエンドのカンファレンスに行ってきました。話のレベルが高く、まだそういう領域にまでたどり着いていない現状ですがいろいろ刺激になりやっていく気持ちを持つことが出来ました。
以下面白いと思ったセミナーと感想とか。
Web over ServiceWorker
@jxck_ さんのService Workerについての発表。
ネイティブアプリと同じようなことが出来るAPIをサンドボックス化して、ブラウザで出来ることを増やしていこうという動きが2014~2016の間で活発になった。結果いろいろなAPIが提案されてきている。そのうちの一つにService Workerがあった。
Service Workerを開発した最初のモチベーションがポッドキャストで語られている。
Service Workerはブラウザがオフラインの状態をサポートするだけではなく、策定される様々なAPIの仲介をするために存在する。ブラウザの中のプラットフォームとして存在しているとのこと。使い道としては良くある使い方であるオフラインの状態をサポートする Proxy の役割や、プッシュを受け付ける役割、タスクマネージャのような役割もあるという話でした。
Service Worker はそういう技術があるということは知っていたけれど積極的には追っていなかったのですが、このセミナーを聞いてこれはだいぶ楽しくなりそうだと感じました。プッシュを受け付ける機能は仕事でも役に立ちそうですし、ネイティブアプリっぽいことをやれると良いけどリソースがない状況だとWebの技術の延長線上でネイティブアプリっぽいことが出来るようになるとだいぶ夢が広がりそうな気がします。学んで損はなさそうな技術でした。
そのあとのAMAブース（Ask Me Anything）で@jxck_さんの所にも行きました。
そこでSerivice Workerなどを使ってProgressive Web Application化することによって何が起こるでしょうか？という質問で、何のために実施するかがポイントだということ。何をするかが決まっていてもモバイルでは現状Safariが対応をはっきりさせて折らず、Androidしか対応出来ていないので、Service Worker前提で作るのではなくあるとちゃんと動くけど、無くても死なないぐらいの感じで実装していくのが良いという話でした。
プッシュ通知についての質問で、プッシュ通知でダイアログが出るのがうざいしWebとしてそれが必用なのか疑問という質問では、ダイアログが突然出る実装しているのがまずく、ダイアログが出ることを許可するコミュニケーションをちゃんとやらないといけない。今だとブラウザで拒否することは出来るが、いったん拒否されるとそのドメインで一切プッシュが送れなくなってしまうとのことでした。これを送れるようにするためにサービス側でなんとかする方法は今のところないとのこと。
ここで一番響いた答えとしてWebとしてそれが必要なのかという問いに対して、WebのAPIはユースケースでよりもまずCapabilityで、これが出来るとイノベーションがおこるかも知れないよね、という考え方で実装されているということ。これからいろいろブラウザで出来るようになって夢が広がっていくことを考えると、Webはもうずっとついていきたいと思える領域だなと強く思いました。これからもフロントエンドは追っていきたいですね。
Webフロントエンドにおけるコンポーネント化のアプローチ
少し前のWebのコンポーネント化についての話だとCSSのスタイルガイドが一般的だったけど、それは何を解決すれば良いか本質的な課題が見えていなかった。
クライアントサイドにおけるコンポーネントとは、最終成果物の価値を左右し得るものだということ。
スタイルガイドでは誰がメンテするかが問題になり、コンポーネント管理の方法としては最適ではなかった。そこでSketchなどのアプリケーションのデザインファイルで管理するのがよさそう。
デザイナーとエンジニアは考え方の方向が違う傾向があり、デザイナーとエンジニアが双方歩み寄りが必用だということ。協業できるようにお互いが楽になる方法を模索していきAtomic Desingなどのフレームワークを使うことによってコンポーネント管理を実践していくのがよさそう。
この発表ではデザイナーとエンジニアの協業が大事だということがわかってきました。いつものフローだとデザイナーがデザインしたカンプに従って画面を作っていくけど、簡単な画面だとしたら自分だけでなんとかしたいという気持ちもあります。そういうときちゃんとコンポーネントが管理されていればある程度はエンジニアだけでデザインが組めたりしてデザイナーの負担を減らせたりするのではないかと思いました。
このあたりのコンポーネントの話や各パーツのデザインをどう管理していくかの話は@yhassyさんのAMAでも話されていて、フロントエンドの課題をどう啓蒙していくかという話で各組織の大きさによって違うものの、まずは課題を認識することが大事で、そういうときは現在のデザインを印刷して要素ごとに切り出してどういう状況になっているかを見える化するというのが大事とのことでした。そうすることによってコンポーネントによってデザインが統一されて折らず成果物としての価値が既存されているということがわかってきそうでした。
ここでいわれていた中で面白いと思ったのは、デザインシステムを作ったとしてそれを維持管理できるリソースがないのであればやらないほうがいいかもしれないということ。逆に言えばここを維持管理できるリソースが割けないという現状そのものが課題で、組織としてコンポーネントの価値が認識できていないということになるのでそこをただしていくのがいいのかもしれないと思いました（とはいえ現場からだと草の根的にやるしかないというのが大変そうでした）。
感想
全体的に大変刺激を受けるカンファレンスだったと思います。Service Workerの話でWebで出来ることが広がりそうなイメージが持てたのが良かったですし、コンポーネント化の話ではデザイナーとの協業が大事だということがわかりました。かたや内部の実装の話、かたや直接視覚的に見る領域の話と同じWebの話でありながら話している内容に幅があったのでとても興味深く話を聞くことができ面白かったです。
いろいろ自分が出来ているかというと全然そうでもないし足下にも及ばないような感じが早くそのぐらいのレベルになっていきたいと思いました。
