どうもこんばんは、マイクです。FMラジオ「zenncast」お送りします。
今日は2026年2月17日、火曜日の朝7時。みなさん、そろそろ一日が動き出す時間でしょうか。通勤・通学中のあなたも、これから寝るよ〜というあなたも、少しの間お付き合いください。
この番組では、Zennに上がっているトレンドの記事の中から、気になるトピックをピックアップしてご紹介していきます。
さて、今日は全部で5本の記事を紹介していきます。フロントエンド、バックエンド、インフラ、パフォーマンス、そしてデザインツールと、かなり幅広いラインナップになってますよ。
まず1本目。タイトルは「useEffect で API を叩くのを卒業しよう」。
React 触ってる方なら、useEffect の中で fetch 書いて、useState でデータ・ローディング・エラー…って、もうお決まりの“儀式”みたいになってませんか? 筆者は、この「毎回同じこと書いてる問題」の正体は、そもそもサーバーが正として持っているデータ、いわゆる“サーバー状態”を、フォームの入力値みたいな“クライアント状態”と同列に扱っていることにある、と指摘しています。サーバー状態って、「古くなる」「キャッシュしたい」「再取得タイミングを制御したい」っていう性質があるのに、それをただの useState に押し込めると、画面遷移のたびに毎回 fetch、毎回ローディング表示、エラーハンドリングもコピペ地獄…と。そこで登場するのが TanStack Query。useQuery に queryKey と queryFn を渡すだけで、取得・キャッシュ・再取得・ローディングやエラー管理まで、全部いい感じに面倒を見てくれる。記事のポイントは「特定のライブラリを崇拝しよう」ではなくて、「サーバー状態とクライアント状態は別物。性質の違うものには、それ専用の道具を使おう」という考え方なんですね。React 書いてて useEffect が増えすぎてきた…と感じている人には、設計の視点から刺さる内容になっています。 。。。
続いて2本目。タイトルは「【RPC比較】tRPC・oRPC・Hono・Elysia 結局どれを選ぶべき?」。
最近、型安全な API 通信ってすごく注目されていて、State of JavaScript でも Hono や tRPC、ElysiaJS といった、いわゆる RPC 機能を持つフレームワークが高評価を集めています。このあたり、“名前は聞いたことあるけど違いがわからない”って人も多いんじゃないでしょうか。この記事では、tRPC / oRPC / Hono / ElysiaJS を、「開発体験」と「OpenAPI 生成」にフォーカスして比較しています。結論をざっくり言うと、「OpenAPI が必須」の現場なら oRPC か ElysiaJS、「軽くて覚えやすくて Cloudflare と相性いい」のは Hono、「Next.js の App Router や Server Actions をゴリゴリ使う」なら oRPC、「パフォーマンス・拡張性・総合力」で見ると ElysiaJS がかなり強くて、多くのケースで第一候補にできるよ、という整理になっています。おもしろいのは、tRPC は単体だと OpenAPI 周りが弱くて、実質 oRPC の下位互換的な位置づけだと評価されているところ。実際の実装例を見ながら、「同じことをやるのにどれくらい記述量が変わるか」とか、「OpenAPI とどううまく付き合えるか」が具体的に語られていて、フレームワーク選定で悩んでいるチームにも役立つ内容です。 。。。
3本目は個人開発・学生さんにかなり刺さりそうな記事。「モダンで爆速。月額0円でWebアプリを開発・公開する技術構成(Hono/Neon/Drizzle/Cloudflare Pages)」です。
タイトルからしてワクワクしますけど、「お金あまりかけずに、とにかくモダンな構成でWebアプリを出したい」というニーズに、がっつり応えてくれています。スタックは、エッジ対応で高速な Hono、サーバーレス PostgreSQL の Neon、型安全な TypeScript 向け ORM の Drizzle、そしてホスティングに Cloudflare Pages。これを組み合わせて、匿名のひとこと掲示板を作る手順が、UI から API、DB、デプロイまで一通り追えるようになっています。おもしろいのが、フロントとバックをがっつり分けずに、Hono JSX だけで UI と API を一体的に書いていくスタイル。AWS で似たことをやろうとすると、サービス多すぎ問題と料金の不安で心が折れがちなんですが、この構成なら学習コストも月額コストもかなり抑えられるよと。記事の最後では「ここからさらに、バリデーションを厳密にするとか、CRUD を拡張するとか、認証を入れて本格アプリにしていく、あるいはリッチなフロントエンドを別で乗せていく」といった発展案にも触れていて、ポートフォリオづくりの道筋がイメージしやすくなっています。月額ゼロでどこまでやれるのか知りたい人には、すごくいいロードマップになりそうです。 。。。
4本目、ちょっと毛色が変わってパフォーマンスネタ。「結局 Python は遅いのか」。
エンジニア界隈で定期的に話題になるテーマですよね。「Python は遅い」とよく言われるけど、じゃあどこが、どれくらい遅いのか? この記事ではモンテカルロ積分を題材に、Python と C++ をガチ比較しています。N を 1e5 から 1e7 まで変えつつ乱数を事前生成して、単一スレッド・200回計測の中央値で速度を比べる、というかなりまじめな検証。結果として、素朴な for 文、リスト内包表記、ジェネレータあたりの「ザ・Python 的な」実装は、C++ のざっくり 23〜27倍くらい遅い。一方で、NumPy でベクトル化した実装や、Numba の JIT を使ったものは、内部でネイティブコードが走るので、C++ とほぼ同じくらいの速度まで迫ると。つまり、「Python という言語が本質的に遅い」んじゃなくて、「Python でループを回すのが遅い」と理解したほうが正確だよね、という結論なんですね。高速化したければ、計算のコア部分は NumPy や Numba を使う、あるいは必要に応じて C++ と組み合わせる、といった設計の考え方が大事だよと。データサイエンスや数値計算をやっている人はもちろん、「プロトタイピングは Python、本番は別言語」といった使い分けを考えるうえでも参考になる内容です。 。。。
そしてラスト5本目。デザイン&AI好きな方には気になる話題。「Figma MakeでClaude Opus 4.6を使ったら凄すぎた件」。
Figma に最近追加された AI プロトタイピング機能「Figma Make」、もう触ってる方もいるかもしれませんが、この記事では、その中で実験的に提供されている「Claude Opus 4.6」を試してみたレポートがまとまっています。検証のお題は「Slack の完全クローンを作れ」という、かなり無茶ぶりなプロンプト。同じ指示を、デフォルトモデルと Claude Opus 4.6 に投げて比較しています。デフォルトモデルでも、それっぽい画面は出てくるんですが、レイアウトが微妙に崩れていたり、本物と比べると「似て非なるUI」になってしまうことが多い。一方で Opus 4.6 は、見た目の再現性がかなり高くて、「あ、これ Slack だ」と一目でわかるレベル。さらにすごいのが、機能の部分。デフォルトモデルだと、入力欄やボタンは見えるけど実際には動かない、みたいなケースが多いのに対し、Opus 4.6 は投稿・リアクション・検索といった主要な機能が、実際に動くプロトタイプとして生成されることが多いそうです。シンプルな一発プロンプトでも「ちゃんと動くプロトタイプ」を最初から出してくるレベルで、「もうここまで来たか…」っていう感想。著者は Figma Make を使っている人に対して、「モデルを Claude Opus 4.6 に切り替えて一度試してみてほしい」とかなり強くおすすめしています。デザイナーとエンジニアの境界がまた一段と溶けていきそうな、そんな未来を感じさせる記事でした。
というわけで、今日のzenncastでは、
・useEffect でサーバー状態を抱え込むのをやめよう、という React の設計の話。
・tRPC / oRPC / Hono / ElysiaJS の RPC 比較と、要件別の選び方。
・Hono / Neon / Drizzle / Cloudflare Pages で、月額0円・モダン構成の個人開発スタック。
・「Python は遅いのか?」を、モンテカルロ積分で検証したパフォーマンスの話。
・Figma Make で Claude Opus 4.6 を使ったら、UI も機能も“ちゃんと動くプロトタイプ”が出てきてびっくりした、という体験談。
この5本をご紹介しました。
気になった記事があれば、ぜひショーノートから元の記事もチェックしてみてください。ここではざっくりしか話せていないので、実際のコード例や図解、より詳しい考察は、ぜひ本文でじっくり味わってもらえればと思います。
zenncast では、番組の感想や、「こんなテーマを扱ってほしい」「この技術が気になっている」といったリクエストも募集しています。日々の開発で感じたモヤモヤや、最近読んで面白かった技術記事など、気軽に送ってください。
それでは、そろそろお別れの時間です。
今日も良い一日になりますように。お相手はマイクでした。
また次回の zenncast でお会いしましょう。