JSConf JP 2024の概要
今出川FMは、株式会社ヘルプフィールの今をお届けするポッドキャストです。
ということで、今日の進行は株式会社ヘルプフィールエンジニアのパスタKが務めさせていただきます。
今日の内容なんですが、JSConf JP 2024のタイムテーブルを眺めるということで、
一緒にこの方と眺めたいと思います。
大西さんです。よろしくお願いします。
こんにちは。コセンスチームで開発をしてます。エンジニアの大西です。よろしくお願いします。
お願いします。
これを取っているのが10月の末でして、11月の23日にあるJSConf JPに株式会社ヘルプフィールは
プレミアムスポンサーとして参加するわけなんですが、
スポンサーに向けて、我々は参加する予定ですので、
その辺で気になっているトークとかを、タイムテーブルを見ながらおしゃべりしていこうという回になっております。
早速なんですが、大西さん、タイムテーブル見てから来てもらったと思うんですけど、
気になっているトークあったりします?
そうですね。個人的に3つか4つぐらい見に行きたいなと思っているトークがありまして、
まず1つ目がリアクトへの依存を最小にするフロントエンドの設計という発表で、
僕個人の体験としては、ノードJSとかJavaScriptでアプリケーション開発をしていると、
結構いろんなライブラリに依存することになって、
メインの開発よりもライブラリのアップデートとかメンテナンスに結構な時間を割かれるような印象があるなと思っていて、
そういう体験があるから、できるだけ使うライブラリは少なくしたいなと思っておりまして、
これもそういう内容の発表が聞けるのかなとちょっと期待はしております。
概要を見ると、リアクトへの依存ということで、
我々最近はもうリアクトメインで使っていて、
なかなかリアクトから別のUIライブラリに乗り換えるってことも少ないとは思うんですけど、
そのメインで使っているリアクトへの依存を最小にするっていうところで、
どのような工夫をされているのかというのが個人的には興味があって面白そうだなと思いました。
なるほどね。
あれですよね、1級の人の小田さんのトークですよね。
はい。
今年の頭からNext.jsからリミックスに移行したみたいな、
Next.jsアップルーターからリミックスに移行したみたいな話を見た記憶があって、
その流れなのかなみたいなところは思ってません。
そうですよね、今まだディスクリプションしか持っていないのであれなんですけど、
引用すると、今のアーキテクチャはリミックスに留まらず、
リアクトへの依存も最小限となる形でデザインしており、
ほとんどのフロントエンドロジックがVanilla.js各タイプスクリプトにあるので、
例えばソリッドスタートやスベルトキットなどのリアクト以外のフレームワークに移行する決定をしても、
コンポーネント層だけを移植すれば良い構造になっていますということで。
でも結構ロジックは、コセンスとかも多分そうだと思うんですけど、
結構アプリケーション固有のいわゆるビジネスロジックみたいに言われるようなところって、
あんまりリアクトに関係ないというか、フックの形で実装されていたりするとあれですけど、
意外と乗り換えられるようになっていて欲しいと。
確かにそうです。
思っているんですが、結構そうするとライフサイクル、
データのライフサイクル自前でどうするのかとか、
そこら辺は今までといったらSWRとかだったりするし、
その辺が確かに意外とやれる気はするんですけどね。
そうですよね。
うっかりすると結構リアクトの機能をフルフルで使ってて、
なかなか他のフレームワークに乗り換えられないってことになっちゃいそうな気はしますけど、
その辺を結構工夫して何かいざ乗り換えるぞってなったときも、
手軽に乗り換えられるようになってるんですかね、多分。
そういう意味での依存の最小なんかと個人的には思ってるんですけど、どうなんでしょう。
じゃあこの辺を楽しみにというか。
そうですね、ちょっと期待していきたいなと。
関連するとリストを今見てて、
ウェブアプリのパフォーマンス向上
あ、でもこれまあいいか。
2人でそれぞれ気になってるトークをお互いで上げてたんですけど、
ちょっと話題は変わって。
JavaScript、違うな。
これですな。
Creating Fast-Feeding Web Apps。
Google Developer Expert E-Anglerの人のトークですね。
簡単にデスクリプションを要約すると、
感じられる速さこそが現実ということで、
メトリックスがどういう値であっても速く感じるウェブサイトは速いので、
どういうふうにパフォーマンスを近くさせるかをReactアプリケーションでやりますと。
ユーザー体験がそれで良くなれば満足度も上がるしコンバージョンも良くなる。
そのためにユーザーに瞬時に応答していると感じさせるテクニックを紹介しますみたいな感じで、
レイアウトジャンク、レイアウトシフトの削減解消とか、
ローディングインジケーターをうまいこと使うとか、
プリフェッチやったりブラウザキャッシュやったり、
画像の最適化とかそういうトークをしますよっていう感じのデスクリプションですね。
これはどの辺がどういう話を期待してますか。
期待してるポイントとか楽しみなポイントとか。
結構ウェブサイトの、
SPAのサイトってモバイルで見ると顕著だと思うんですけど、
やっぱり重いなって感じたり、
ナビゲーションしてるとちょっとガクガクしたり、
一瞬フリーズして反応してないのかみたいになりがちなことってあると思うんですけど、
そういうユーザーに感じられる速さというか細さというか、
そういうのを減らすのって大事だなって思っていて、
Senseでも結構いろんなチューニングをして、
できるだけユーザーがネイティブのアプリとかと比べるとまだまだっていうところはあるんですけど、
できるだけ都合とか遅さを感じないような実装にしていきたいなっていうのは日々工夫をしているんですが、
そういうメトリックスに現れないけど使っていると不便に感じるというか、
ちょっとモヤっとするような遅さをできるだけ減らすのは重要だなって思っていて、
そのあたりもこういうふうにするとすごい良くなるよみたいな、
具体的な最適化の例が知れたらいいなと、
そういうところを期待してます、個人的に。
僕も個人的なあれなんですけど、
先日仕事とは別で趣味みたいなウェブアプリケーションを書いてて、
友達に読み込みもうちょっと早くならないのって言われたんですけど、
ローディングインジケーターを出すだけで早くなったねって言われて、
そういうことあるんだなって思ったんですよね。
やっぱりUI1個出るだけでも体感って結構変わってきますよね。
そうですね。実際なんか反応があるっていうか納得感があるというか、
実際他にも上がっているトピックだとブラウザーキャッシュを使ったり、
最近だと画像のフォーマットの適切な選択とか、
ブラウザーキャッシュもそうだし、
例えばCDNでキャッシュするとか、
どのレイヤーでキャッシュするかみたいなのでも結構変わってきますよね。
そうですね。
いろんなところで細かい改善をしていって、
改善、体験をよくするのを積み上げていくっていうところになってくるかなって思うので、
その辺の話を聞けたらいいのかと思います。
そうですね。そういうあれだと事前の打ち合わせの順番が変わって、
大西さんがしゃべる予定のトークであるところで、
Cosenseのフロントエンドでのパフォーマンスチューニングも、
さっき雑談をしていると、
そういう数字より体感みたいな話をするという予定だと聞いたんですけど。
そうですね。
自分たちで触ってみていいかどうかっていうと、
開発進めていく上でというか、リリースの判断になっていたりもするので、
やっぱり自分が使いにくいと、
リリースしてユーザーの方々に使ってもらっても使いにくいと思うので、
その数値ももちろん大事ではあるんですけど、
使ってみて不都合があるというか、
使いにくいかみたいな。
そうです。
にならないように頑張って実装をしてということを話せればなって思ってはいます。
結構いくつか具体例を紹介するような感じのトークになるんですか。
そうですね。具体例を出して、
この機能の中ではこういう工夫をしてますよっていうのを紹介できればと思ってます。
でもあれですよね。
まだ今これが撮ってるのが10月の末で、
まだ開催まで4週間ぐらいあるから、
まだ詰めるのはこれ。
具体例の選出が結構これだけで、
まだ整理しきれてない部分は発表までには詰められたのだと思ってます。
逆にこれを話そうと思ったきっかけになったような、
関心したコセンスのパフォーマンステクニックとかあったりするんですか。
関心したテクニックですね。
僕もちょっと実装を手掛けていた、
トランスレーションモードの例を出したいなと思いまして、
トランスレーションモードというのはコセンス内で、
コセンスの中にあるコセンスの中に、
コセンスの中にあるコセンスの中に、
コセンスの中にあるコセンスの中に、
トランスレーションモードというのは、
コセンス内でページの本文だったり、
検索結果だったり、
各コンテンツを翻訳してくれるっていう機能なんですけど、
これは結構使い勝手が良くなるような工夫をいろんなところでしていて、
例えば、ページ本文って結構長くなりがちだと思うんですけど、
ちゃんとミューテーションオブザーバーとかを使って、
必要に翻訳をしないようにしたりとかっていうのをやってて、
裏側ではDPLのAPIを使ってるんですけど、
見えるもの全部バンバン翻訳していくと、
そのDPLのAPIの料金がどんどん上がっていっちゃうので、
それもできるだけ減らしつつ、
ただユーザーから見て使ってて、
すごい良い機能だって思われるような翻訳というか、
機能になるようにキャッシュをしたりとか、
その工夫をやってるっていうところを紹介したいと思います。
なるほど、そういうミューテーションオブザーバーとかで、
結構ビューポートっていうのは、
ユーザーに対して今表示してる領域みたいなのをうまく検出したり、
その変化を検出して、
APIのキャッシュとかルームを見て、
結局レンダリングの領域が大きいと、
レンダリングのパフォーマンスに影響、書き換えに影響が出るし、
APIも、さっきはコストって話もありましたけど、
ネットワークは結構ヘビーなので、
そこをうまく削っていくみたいな感じですかね。
そうです。
そこら辺のうまくやる話が今後うまく、
ここからお兄さんが4週間ぐらいかけて話をまとめていくと。
ちゃんとまとめたいと思います。
結構でも、
コセンスのチームだけじゃなくて、
うちの会社だとヘルプフィールとかギャゾーとかももちろんそうですけど、
やっぱりミランでドッグフーディングしながら、
結構手触り感っていうか、
手触り感、特にスクロールしたときの手触り感とか、
クリックしたときの切り替えのトランジションの手触り感みたいなところの、
そこのパフォーマンスの感じとかは割と気にする機会が多いですよね。
そうですね。
みんな、目の前にある機能を実装して終わりじゃなくて、
全体を見てパフォーマンスがどうだとかを気にしたり、
ちゃんとしていると思うので。
みんなパフォーマンスとか全体的な使い勝手のこととかは意識して開発はされてます。
そういうテクニックの話をいろいろ盛り込んだ30分のトークを。
そうです。
また皆さんが参考にできるような内容を発表できるように頑張りたいと思います。
ぜひいいトークをお願いします。
はい。
あれですよね、結構社内でも定期的にパフォーマンスチューニング、
特にDOMとかレンダリングとかは割と話題に上がりがちで、
数年に一度ブームが来るみたいな印象がありますね。
じゃあちょっとパフォーマンスの話が続いたので、
タイムテーブルの話に戻って、
僕がいくつか気になっている話というか、
これですね、これ結構楽しみにしてたっていうか、
トークっていうかという機能を楽しみにしてたんですけど、
イテレーターヘルパーの総助鈴木さんがやるんですけど、
イテレーターヘルパーがついにステージ4になったので、
そこを改めて現状の把握をしたいなと思っているので、
ここは割と期待をしています。
イテレーターの利便性
イテレーターヘルパーっていうのはすいません、ちょっと専学で知らないんですけど、
具体的にはどういうものなんでしょうか。
JavaScriptのイテレーターってこれまでも結構存在はしてて、
多分大西さんも触れることはあると思うんですけど、
あんまり使わないっていうか、使いづらいじゃないですか。
そうですね。
APIのインターフェースが悪い。
あんまり使わないような気がしますね、イテレーター。
最近だとフォームとかスプリントで割とまともに扱えるようになったんですけど、
それでも結構不便があるので、ある結果みんな諦めて配列とかをそのまま使って、
配列で重厚長大なデータを作ってしまったりする。
外部のライブラリを使って、レイジーJSとか、
古い他のライブラリを作って解決してると思うんですけど、
イテレーターヘルパーズはイテレーターに対して、
マップとかフィルターとか、あとテイクとか、
一覧読み上げとドロップ、フラットマップ、リデュース、
あとトゥアレイとフォーイチとサム、
いわゆるアレイにあるようなやつを一式生やしておきましたので、
インターフェースとしては比較的使いやすいんじゃないですか、みたいなことですね。
Rubyだと結構イテレーターが充実してて、
よく使ってた覚えがあるんですけど、
それが同じような感じでJavaScriptでも使えるようになるというイメージですか。
ざっくり言うとそんなイメージですね。
これまでだと巨大なアレイを使って、
しかもアレイのマップだと全部コピーが走るので、
それでメモリがすごい大爆発してNode.js辛いみたいな、
Node.jsでパフォーマンスが辛いみたいな話があったと思うんですけど、
そこでちゃんとイテレーターも使えるようになる。
インターフェース的にも便利に使えるようになるみたいな感じで、
結構API的にも期待をしてたので、
これでどうなるかなというところで、
楽しみにというか。
これ入れるときに結構問題があったということも聞いてて、
特定のウェブサイトが壊れてみたいな話もあったというのが聞いてるので、
ステージ3のとき、そこら辺の話がいろいろ概要から、
健康とJavaScriptの関連
タイトル通り概要・課題・未来みたいなところでうまく把握して、
あわよくばうまいこと社内にも持ち帰ればいいかなと思っています。
あと個人的にはWebMidiでシンセサイザー操作するというLTがあって、
なかなかWebMidiをあんまり使ったことはないから、
面白そうな話です。
WebMidiとかWebBluetoothとかは結構遊び場合があるので、
朝の早い時間に聞くセッションとしては、
わりとエンタメ感があって結構楽しいはずなので、楽しみに期待します。
結構趣味でDJやったりとかするので、
たまにMIDIコントローラー繋いでいろいろ遊んだり、
ちょっとしたシンセサイザーほどじゃないけど、
音が鳴るグッズを作ったりとかたまにしているので、
そういうのを利用したいなという気持ちもあります。
いいですね。
MIDIいいですよ。
MIDIの全然JavaScript関係ないですけど、
MIDIコントローラーって基本的にいっぱいボタンが付いているのと、
いっぱい大量のボタンと大量のスライダーと大量のつまみみたいなのが付いているので。
あれをMIDIコントローラーって言うんですか。
そうです、ああいうのが大体。
形を見たことあったんですけど。
ああいうのが大体MIDIを喋ってて、
USBで繋いで今はWebMIDI APIで大体おしゃべりできるみたいな。
なるほどね。
し、WebMIDI API受け取りもできるし発出もできるので。
そうなんですね。
MIDIを受け取るようなやつにおしゃべりできるみたいな。
そういう話題。
この辺は円溜め。
しかに。
面白そうです。
そういう意味では、
筋トレ健康テクニックみたいなとこも、
それについてあるみたいなので。
ステイフィットコードベター。
アンスポーツマンシップス10プラティカルアドバイス
for JavaScript Developers。
この講演では健康に関する10の実践的なヒントと、
JavaScriptを使用してこれらの習慣を追跡整理、
日常生活に導入する方法について説明します。
運動は大事です、エンジニアにとって。
年を取るたびにどんどん重要性を理解してくるというか。
これをJavaScriptでどうやって整理しているのかというのは、
興味深いです。
何かウェブサービスを作っているとかなんですか。
どうなんですかね。
そういう話題なんですかね。
ちょっと気になりますね。
でも自己紹介なんか書いてあるな。
I strive to integrate healthy habits into my daily routine as a developer。
実践的なテキスト。
昔FITなんだけど、
たまに腕時計のアプリとかがJSで書けるみたいな。
はいはい。
昔ありましたよね、なんだっけ。名前忘れちゃったけど。
何でしたっけ。
フィットビットの、僕は昔やってたのはフィットビットのAPIを
Node.jsで適当いただいて、
普段の運動をグラフにプロップするみたいなことは一時期やってましたけど、
飽きてプロセスを止めたので終了しました。
そういう、
スマートウォッチと連携してどうこうっていう感じの話なんですかね。
どこにこれJavaScriptがやってくるのか。
どういう、
どうこうコネクト、コネクティングドットがあるのかをちょっと期待します。
JavaScriptエコシステムの変化
お兄さんなんか他に気になってるトーク楽しみにしてるのあります?
漫才?
JavaScriptを支えるエコシステム、漫才というのはちょっと気になってます。
エクマボーイの。
そうですね。
JavaScriptのエコシステムって、
個人的な印象であれなんですけど、結構物理変わりが早いなって感じてて、
昔って言ってももう5年とか10年くらい前になっちゃうんですけど、
パッケージマネージャーでNPMとYARNどっち使うかみたいな話が盛り上がってたことがあって、
一時期は僕もYARNを使ってたことがあるんですけど、
結局今はNPMに戻ってきてて、
そういう物理変わりはあるけど、
じゃあ今どうなのかとか、
どういう基準でどっちのツールを使ったほうがいいみたいな、
そういうのがあるのかないのかって、
普段JavaScriptを使ってはいるけど、
そういうエコシステム周りのキャッチアップって、
僕はなかなかできてなくて、
いざ相談を受けたりすると、
多分自分も分かんないなって思うんですよね。
どれを基準に何を選べばいいかって。
そういうところの知見を得られると、
すごい嬉しいなと感じてます。
趣味でいろいろちっちゃいコード書いたり、
検証自体がうまいこと仕事の一部になってると、
いろいろ検証できるんですけど、
なかなか普通にウェブアプリケーション開発者として暮らしてると、
そんなに技術選定をやるタイミングってあんまりいないから、
なかなかパッケージマネージャー選んだりとか、
バンドラ選んだりとか、
僕とかは割とバンドラ差し替えたら嫌派なので、
割と差し替えて動かそうとしてみたいとか、
割とやってる気がしますけど。
あと漫才としてそもそも完成度が、
どのようなものが出てくるのか。
確かに。漫才ですよね。
どちらがボケでどちらがツッコミなのかみたいなところもね。
ちょっと楽しみにしていきたいと思いますね。
あんまりそのカンファレンスで、
僕も結構JSコフィーからいろんなカンファレンス出てますけど、
漫才ってタイトルに書いてあるのは初めて見たかな。
あんまり見ないですよね。
掛け合いで2人で喋りますみたいなのは結構見るんですけど、
漫才がやっぱりセンターマイクが立ってるのかなとか、
いろいろ期待することはありますね。
確かに。
なんかよくあるコテコテの漫才なんか、
ちょっと変わったやつなんか。
色見ついたスーツにでかいネクタイで出てきてほしいですね。
確かに。
そんなことを言っている間に、
時間もいい感じになってきましたので、
何か話し足りないこととかがあれば聞こうと思いますけど。
そうですね、話し足りないこと。
うちの会社でブースも出るんですか?
確かブースも出るはず。
どっかに書いてあった。
まだ1ヶ月前なので収録してるのがイベントの。
おそらくブースも出るっていう話はしてたけど。
詳細は多分これが公開される。
同時くらいにはヘルプフィールテックのXアカウントかブログに詳細が載ってると思いますので、
皆さんぜひそちらを見てもらって、
当日ぜひ会場で、
ブースもそうですし、
大西さんのトークとかも楽しみにしてもらえればなと思います。
僕はこの日、最初は予定がちょっと入る予定だったんですけど、
やんごとなき出来事により、
この日暇になってしまったので会場にフラッと行こうと思いますので。
よろしくお願いします。
見かけた方はよろしくお願いします。
余裕は感じで良いですかね。
はい、じゃあ、
今日はJSConf2024、
JSConf2024をご紹介したいと思います。
こんにちは。
今日はJSConf2024、
JSConfJP2024のタイムテーブルを大西さんと2人で眺めながら雑談を、
バスクリート雑談をお届けしました。
大西さんありがとうございました。
こちらこそありがとうございました。
今出川FMは過去の全エピソードも、
Spotifyなど各ポッドキャストプラットフォームでお聴きいただけます。
ぜひ感想お待ちします。
皆さんXでハッシュタグシャープ今出川FMで投稿してください。
この投稿結構楽しみにしてますので、
ぜひぜひ皆さんお願いします。
ではまた次回もお楽しみに。
