gRPC-webは伸びしろがある
tadano：Q3.「みんなにもっと知ってほしい知識や、積極的に広めたいモノはありますか？」。
potato4d：それこそ今の話ですが、gRPC-webは伸びしろがあると思っています。あと、異なる言語間で通信できるというところで、IDLという概念がこれから重要になってくると思っています。BFF層も、これから過労死するぐらい使われていくことになると思う。
例えばBFF層がTypeScriptで、フロントエンドもTypeScriptだったら、最悪TSの型定義でもいいですけど。その裏に乗っているマイクロサービスが例えばGoだったら、通信プロトコルも異言語間での通信をどんどんやっていかなきゃいけない。
そういう時代になってきたと思うので、IDLという概念が広まればいいなと思っていますが、どうでしょう。
kahirokunn：IDL、gRPCは自分もすごく推していて、gRPC-webも完全にウォッチ範囲なので、その通りすぎてなにも言葉はございません（笑）。
（一同笑）
potato4d：kahiroさんは、広めたいものはありますか？
kahirokunn：自分はやっぱり、設計の知識とかスキルがあると、フロントの方はけっこう助かるんじゃないかと思っています。gRPCとGraphQLでも、実現できるものとか解決する課題の特徴がぜんぜん違うんです。どちらか片方が優れているわけではなく、業務のスタックや要件に合うものを選べばいいと思います。
それ以外にも、Vue.jsもReactもAngularも、例えばFlutter for web、たくさんあると思いますけど。それらも基本的に、業務のスタック・人員に合えばいいんですけど。例えばほかのフレームワークが導入している新たな機能とか、Vue.jsに新機能が入ったときとかに、設計の基本的な知識を持っていれば、それにあまり振り回されずに立ち回れると思います。
tadano：つまり「いろいろ知っとけ」と（笑）。
kahirokunn：そうです。波を乗り越えるために、設計をやっていると絶対に出会うような各種ノウハウをある程度おさえていれば、フロントの方はもう一段ステップアップできると思います。
potato4d：それでいうと、例えばこの会場に来てくれている方は、Vue.jsをふだん業務で使っていて「Vue.jsで慣れていたら、なにかプロジェクトを立ち上げるときも楽にできていいかもしれない」みたいなところがあると思うんです。
でも逆に、Vue.jsでやれることの範囲だけで考えが固まってしまう可能性がある。別の技術を1回使って、プロジェクトをぶっ壊してみるのもありかもしれない。言い方は悪いですが（笑）。
（一同笑）
tadano：大丈夫ですか（笑）。
potato4d：大丈夫だと思います（笑）。例えば大きな会社とか大きな組織なら、ReactのエキスパートやAngularのエキスパートの同僚がいると思いますので。そういうときに冒険的に技術を使ってみたり、設定を考慮してみたりする。
じゃあ例えば、最近はそれこそ「Vuexにそんなに寄せない」派閥がVue.jsも伸びてきている気がして、私もVuexになるべく寄せないかたちでの開発が増えているんですけど。今はみんな、とりあえずそのクラウドに対応するVuexのactionを作って、全部とりあえずmutationで突っ込んで、というやり方の人も多いと思うんですけど。
それはすごくscaffold的な世界観だと思うので、そこから離れる。多少設計ミスしてもいいから、次の糧になるようなことをする。事故ったとしても、ほかの人が同じ轍を踏まないための知識になるので、ぶっ壊してもいいと思うんです。挑戦は大事なんじゃないかな。このへんは意識改革的な意味で広めたいですね。
propsで型が違っててもエラー出ない問題にぶつかった
tadano：このへんで、Twitterを拾っていきたいと思います。
potato4d：OKです。
田口：「propsで型が違っててもエラー出ない問題にぶつかった」。僕はあんまりVue.jsとTSをゴリゴリ使っていないのでわからないんですが、エラーが出ないままいくものなんですか？
kahirokunn：たぶん、propsの型をTypeScriptで型定義したけど、Vue.jsのtypeの指定機能あるじゃないですか。type: Functionとかobjectの指定ではなく、TSのほうの型とは違ったからエラーが出なかった話かな。
potato4d：ちなみにそのTSの型をアタッチしたい場合は、いったんobjectと書いて、object asのあとにアローファンクションのカッコを書いて、戻り値のところに欲しい型を書いておくと、それでアサーションできます。
そういうテクニックをやればちゃんとスキーマ的な型のバリデーションも一応できますが、これもどうしても実行時になってしまう気がします。
kahirokunn：ktsnさんが前に、veturに一応propsと、そのpropsに合わせた型をちゃんと使っているかどうかというテンプレートのコンパイラが一瞬だけ入った気がするんですよね。そのとき、自分のVue.jsのプロジェクトは大量にエラーが発生しましたが。
（一同笑）
mixinとかいろいろあったせいで（笑）。今後のVue.jsでまた急にテンプレートが賢くなって、静的な検査が入るんじゃないかと予想しているので、正しい書き方に寄せていきたい。
田口：もう1つ。「Vuexに寄せない」という心をもう少し知りたいという方がいらっしゃいます。
tadano：（potato4d氏を指して）花谷さんがすごく言えそうですね。
potato4d：そうですね、私はめちゃくちゃこだわりがあります。シンプルな話だけをしておくと、シングルステートツリーの一番トップとか、VuexでいうとVuexのストアの中のstateはグローバル変数だし、actionはグローバル関数だということを、絶対に忘れないというだけだと思います。グローバル関数でグローバル変数だから、便利なのは当たり前なんですよ。絶対に便利なのはわかってる。
だからといって、ほかの言語とかほかのプロジェクトをフロントエンドじゃないときにやるときに、全部グローバルで定義しますかという話です。それはグローバルに本当に作用するのか、例えば「これは実はコンポーネントで閉じているのではないか」とか。
最近だと、コンポーネント内での状態の分割統治とかがトレンドになってきている。コンポーネント内で状態を持たせることで解決できないか、これは本当にグローバルにするだけの意義があるのかを考えておくというところだと思います。
もちろん、例えばモーダルのフラグ管理とかめんどくさいのでグローバルにしがちなんですけど、例えばfalseにし忘れたら別の画面でずっと出てたり、フェッチしたあとのフラグがずっとtrueのままで、次にフェッチが行われなくてバグったり。そういうところで簡単にデグレしている例もよく見るので、そこを押さえておくだけだと個人的には思います。
tadano：すごくごもっともだと思います。グローバルに置くかどうかは大事ですね。
（一同笑）
kahirokunn：自分も基本的にVuexは最後の最後まで使いたくない派なんですが、以前使ってはいたので。Vuexのモジュールシステムが、とくに嫌いです。
（一同笑）
あれ、本当に難しい（笑）。モジュールシステムを使うと、ステートツリーのstateの型定義とか難易度が上がるし、ただただ階層がネストして、実際actionはグローバルなのは変わらないし、ただnamespaceを付けてごにょごにょやってるんですけど、叩こうと思えば全部叩けるし、っていうのは間違いなくあって。
TypeScriptとかだと、とくにモジュールツリーの構築が難しいし。なので自分は、Vuexを使うときはモジュールシステムをオフにすることが多いですね。でもやっぱりVuexだと、サーバーサイドレンダリングするときのstate復元はどう考えます？
potato4d：そのへんでは、やっぱり便利という印象はありますね。そういうところで使うのは妥当性があると思います。
kahirokunn：そうですよね。SPAだけで通してると、自分は最後まで入れたくないですね。サーバサイドレンダリングなら、仕方ない。うん。
（一同笑）
potato4d：でも最近は、SSRのレンダラーのほうに「実はこういうふうに書くとコンポーネント単位でも状態を持ってくれますよ」みたいなものもはやってきているので。徐々にそのへんも、レンダラーのほうで解決される気がします。
kahirokunn：なるほど、了解です。
Vue.jsで開発はしたいけど、TypeScriptを入れたい問題
tadano：Q4.「最近の開発での悩みはありますか？」。
kahirokunn：「Vue.jsで開発はしたいけど、TypeScriptを入れたい」というクライアントさんが、たくさんいらっしゃるんですよ。
potato4d：めっちゃわかります（笑）。
kahirokunn：でも自分はVue.jsの良い部分も、未熟……いや違う、「伸びしろ」！
（一同笑）
伸びしろも、いろいろ経験しているので。とくにVue.jsの型の循環参照。Vue.jsのモジュールのオプション、例えばtemplate、computed、propsとか書く部分で型が循環参照してしまうので、computedには戻り値を明示的に書いときましょうね、というドキュメントがあるんですが、そこをやり忘れて1時間消えてしまう、という開発もよく体験している。
またそれってつまり、例えばcomputedの部分に外から持ってきた関数をつけたときの推論とかも、信用していいのかどうか懐疑的になってしまう部分ではあると思うんです。
でもVue.jsは例えばcomputedからもオプションの中の全部、methodとかも見えるし、methodからもcomputedが見えるので、循環的に使える半面、すごく便利な部分もある。いたしかたない部分ではあるので、クライアントさんには、できればVue.jsの開発は、JavaScriptはそのままのほうが、一番幸せにいけるんじゃないかとたまに言っています。
potato4d：TS入れるのは難しい、って感じですよね（笑）。
kahirokunn：あのオプションの部分だけはそうですね（笑）。でもVue.jsのfunction-based APIというものが最近Request For Comments、RFCで提案されているので、それがもしかしたらこの問題を解決するかもと思っています。
tadano：花谷さんは、最近の悩みはなにかあります？
potato4d： 2つあるんですが、サクッとだけ説明すると、1つは開発しているときに、Vue.jsでとりあえずアプリケーションは書けるけど、例えばスタイルガイドとマッチしてないコードを書く人がめっちゃ多い。
入ってアプリケーション書けるようになって、言い方は悪いかもしれないけど「書けるようになったつもり」から「書けるようになる」までの、そこのステップが整備し切れていない。自分も毎回同じ話をしている感覚が課題としてあります。
スタイルガイドのこの部分に準じてください、というLintみたいなことをよくやっているので、ステップ設計みたいなものに課題があると感じます。
もう1つ、SPAの波が来ているからだと思いますが、みんなデータフロー設計とかにこだわるようになった結果、あんまりプロダクトの話とかしなくなった。
例えば私、「めちゃめちゃ気持ちいいインタラクション」みたいなものを設計するのが好きなんですけど、ユーザ体験に直結する部分を考える人が減ってきている。どうすればプロジェクトを良くできるかが悩みです。
開発体験を選択できるVue.jsのデメリット
kahirokunn：スタイルガイドで、人力Lintをしなければならないじゃないですか。Vue.jsって、良くも悪くもプログレッシブなところがある。いろんな書き方、いろんなやり方を自分たちが選べて、その人が最も好きな開発体験を選択できるところが、Vue.jsのすごく好きな特徴です。
しかし逆にいうと、全員が好きな書き方をするとチーム内でバラバラになってしまって、なかなかにつらいものがある。
なので、自分もプロジェクトでスタイルガイドを用意していて、それに準拠できるチームかどうかもありますが、人力でやっている部分をシステムで自動化できないかと常に思っています。
potato4d：そうですね。せめて公式のスタイルガイドの「必須」「強く推奨」あたりまでは、自動でなってほしい気持ちはあります。
kahirokunn：あとこのCSSは例えばSCSSしか使えなくて、あのスクリプトはlang="ts"のみしか指定ができなくて、テンプレートのときはこういう書き方だけ、とかあります。関数はできたらこんな感じで、全部自動化できないかと思っている。設計界隈でも、そのへんはよく話題に上がります。
tadano：ありがとうございました。Q6.「最後に、フロントエンドの未来について」。本当にひと言でお願いしたいです（笑）。
（一同笑）
kahirokunn：フロントエンドは今、例えばハイブリッドのアプリケーションからWebAssembly、PWA、Web Componentsといろんなスタックが出てきていて。どれもこれもすごく盛り上がっていて、可能性に満ち溢れていると思います。時代の波に乗り遅れないように、がんばっていきたいです。
potato4d：どこかでこの話をできればと思うんですけど。今っていろんな都合でみんなSPAを当たり前のように使ってると思うんですけど、だんだんSPAで作らなくなっていくような時代が来るんじゃないかなと思ってます。それはもう今SSRしてることとかいろんなところから、そもそもSPAである意義みたいなのが薄れてきてる、みたいなところで。
みんなもともとはユーザー体験のためにSPAを作っていたけど、今は自分たちの開発体験のためになっていると思います。いつか、ユーザー体験のために揺り戻しがあると思うので、それに備えて「今、自分たちはなぜフロントエンドでSPAを作っているのか」「なんのためにこうやって作っているのか」を考えておかないと、今後まずいんじゃないかなと思っています。
tadano：ありがとうございます。時間になりましたので、本日のトークセッションはここまでとなります。花谷さん、kahiroさん、ありがとうございました。
（一同拍手）
