// サーバー側（Hono） app.get('/posts/:id', (c) => { const post = findPost(c.req.param('id')) return c.render('Posts/Show', { post }) }) // クライアント側（React） export default function Show({ post }: PageProps<'Posts/Show'>) { return <h1>{post.title}</h1> } post の型は Post として完全に推論される。間に API 定義も DTO も tRPC もスキーマ生成もない。サーバーで c.render() の第2引数に渡したオブジェクトが、そのまま React の props として、しかも完全に型付きで届く。 「API なし SPA」を謳う Inertia.j

.aspx がHTMLテンプレート、.aspx.vb がそのページのロジックという構成です。Reactでいうと、JSXとコンポーネントロジックが別ファイルに分かれているようなイメージに近いかもしれません。 ただし、MVCフレームワークのようにルーティングやコントローラーが明確に分離されているわけではありません。ページ単位でViewとControllerが1対1で結びついているのがWebFormsの特徴です。 ページライフサイクルという概念 WebFormsには「ページライフサイクル」という独自の概念があります。ページが表示されるまでに、サーバー側で決まった順序のイベントが発火します。 Reactでいうところのライフサイクルメソッド（componentDidMount や useEffect）に似ていますが、これはすべてサーバー側で実行される点が大きな違いです。 WebForms特有の仕組み

「古い技術」と聞くと、もう学ぶ価値がないと思うかもしれません。しかし、過去の技術が採用した設計思想を知ることで、現代のフレームワークがなぜ今の形になったのかを深く理解できます。この記事では、ASP.NET WebForms を主な題材として、古い技術から得られる設計の学びを整理します。 対象読者: React や Next.js など現代のフレームワークを使っている方で、設計判断の「なぜ」をもっと深く理解したい方を想定しています。WebForms の経験がなくても問題ありません。 この記事のゴール: 古い技術の設計思想を通じて、状態管理やアーキテクチャに対する視野を広げることです。 なぜ今あえて古い技術を学ぶのか 現代の Web 開発は便利なツールやフレームワークにあふれています。React の useState を使えば状態管理ができ、Next.js を使えばルーティングもサーバーサイド

CGI は本当に死んだのか？ CGI と聞いて何を思い浮かべますか。Perl のアクセスカウンター、掲示板スクリプト、cgi-bin ディレクトリ——2000年代の Web 開発を支えた技術ですが、今ではレガシーの代名詞のように扱われています。Ruby 4.0 では cgi が標準ライブラリから削除されるなど、言語レベルで CGI から離れる動きもあります。 しかし CGI という仕組み自体は死んでいません。Apache は今も CGI をサポートしていますし、レンタルサーバーでは当たり前に使えます。Go は net/http/cgi を標準ライブラリで提供しており、同じ http.Handler が CGI でもスタンドアロンサーバーでもそのまま動きます。 Go のシングルバイナリと SQLite を組み合わせると、CGI は再び実用的な選択肢になります。この記事では、実際に CGI 上

Let’s Encryptの短期証明書は、90日証明書の延長くらいの感覚で入るとかなり厳しいです。 サブドメインを含む複数の証明書を短い間隔で発行・更新する構成では、証明書発行まわりのレート制限に引っかかりやすくなります。短期証明書では更新回数が増えるので、その影響がかなり表面化しやすくなります。 まずステージング環境で試した方がよい 開発やテストでは、本番ではなくステージング環境を使った方がよいです。本番と同じ種類の挙動をかなり緩い制限で試せるので、証明書の切り方や更新方法を確認する段階では先にこちらを使う方が安全です。 環境 ACME directory URL 短期証明書はレート制限に当たりやすい 短期証明書は有効期限が160時間しかなく、Let’s Encryptは3日ごとの更新を勧めています。90日証明書より更新回数が大きく増えるので、レート制限に当たりやすくなります。 特に厳し

JSer.info #769 - pnpm v11.0.0 RC 0がリリースされました。 Release pnpm 11 RC 0 · pnpm/pnpm Pure ESMパッケージへ移行し、Node.js 18から21のサポートを終了しています。 .npmrcは認証/レジストリ設定のみに限定し、その他の設定はpnpm-workspace.yamlへ移行、pnpm serverコマンドの削除など多くの破壊的変更を含んでいます。 また、pnpm ciコマンドの追加、pnpm sbomでのSBOM生成に対応しています。 minimumReleaseAgeのデフォルトを1日に設定、blockExoticSubdepsのデフォルトをtrueに変更するなど、サプライチェーンセキュリティの強化も行われています。 その他にも、ストアのインデックスにSQLiteを使用するように変更、undiciの採用に

HTMLの属性値をCSSから参照できるattr()関数は、これまで::beforeや::afterといった疑似要素のcontentプロパティで使える機能として知られていました。 attr()関数の拡張構文は、CSSの値や単位の扱いを定義する仕様書「CSS Values and Units Module Level 5」で定義されています。さらに、Chrome・Edge 133（2025年2月）以降では、この拡張構文をcontentプロパティ以外でも利用できるようになりました。 拡張されたattr()関数には、次のようなメリットがあります。この記事では、デモを交えながら紹介します。 個別のstyle属性やクラスを減らせる HTMLの属性値をCSSの値として直接利用できる ※注意：本記事のデモは、Chrome・Edge 133以上でご覧ください。 1. HTML属性で色・サイズを指定するデモ

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 本記事は筆者の考えをベースに、ChatGPT 5.4 を用いて構成・推敲したものです。 内容の主張と判断は筆者によるものであり、文章表現の整理に ChatGPT 5.4 を活用しています。 Blazor は .NET Core 3.0 のタイミングで主流の流れに入り、2019 年 9 月 23 日の .NET Core 3.0 正式リリースとともに広く知られるようになりました。2026 年の今から見ると、もう約 6 年半が経っています。普通、フレームワークが本当に強ければ、このくらいの時間があれば複雑な商用システムの現場で広く定着してい

JSer.info #768 - TypeScript 6.0がリリースされました。 Announcing TypeScript 6.0 - TypeScript 現在のJavaScriptコードベースによる最後のリリースで、Goで書き直されたTypeScript 7.0への移行を準備するリリースとなっています。strictがデフォルトでtrueに、targetのデフォルトがes2025に、moduleのデフォルトがesnextに変更されています。target: es5や--moduleResolution node(node10)、--outFileなどが非推奨となりエラーに変更されました。新しい機能として、es2025ターゲットの追加、Temporal APIの型定義、Map/WeakMapのgetOrInsert()/getOrInsertComputed()メソッドの追加、Type

はじめに 「WebSocket って結局なんなの？ HTTP と何が違うの？ 接続が切れたらどうなるの？」 動いてるから深く考えなかったけど、この機に仕組みを理解しようという記事です。 この記事は、WebSocket を「なんとなく」から「ちゃんと」理解する ための記事です。 この記事で分かること HTTP の限界と WebSocket が生まれた理由 WebSocket の仕組み（ハンドシェイク〜双方向通信） HTTP と WebSocket のプロトコル層の位置づけ WebSocket のリスクと落とし穴（7 つ） 接続が切れたときのメンテナンス戦略 SignalR / Socket.IO が WebSocket の上に何を足しているか ローカル vs サーバ構成の違い 1. HTTP の限界 — なぜ WebSocket が必要なのか HTTP は「聞かれたら答える」しかできない H

Livewire vs Inertia.js この記事を読んでいる方はご存知だと思いますが、Laravelの新規プロジェクト作成時にどういう構造のアプリが欲しいのかプロンプトがいくつかあります。その中から、比較するのはLivewireとInertiaJs。より良い選択できるように長所と短所を説明していきます。 1. 根本的な仕組みの違い まず、両者の決定的な違いを理解しましょう。それは「どこでHTMLが作られるか」という点です。 Livewire: サーバーサイドでHTMLをレンダリングします。ユーザーが何か操作をするたびに、裏側でAjaxリクエストが飛び、サーバーが新しいHTMLの断片を送り返し、ブラウザがそれをDOMに反映させます。 Inertia.js: クライアントサイド（ブラウザ）でHTMLをレンダリングします。サーバーはJSONデータのみを返し、VueやReactがそれを受け取

始めに React と Vue をどちらも使っていて、 Vue と比べて React はあまり好きではないなと思うことが多いので、自分が思う React の嫌なところをまとめてみました。 コメント欄でこれらの嫌なポイントを改善する方法を教えてもらえると嬉しいです。 1. 依存関係を定義するフックの API が微妙 React の useMemo や useEffect 、useCallback などのフックは、第一引数にコールバック関数を取り、第二引数に依存配列を取ります。 const memoizedValue = useMemo(() => computeExpensiveValue(a, b), [a, b]); const memoizedCallback = useCallback(() => doSomething(a, b), [a, b]); useEffect(() =>

Web Components × Litが便利! ReactでもVueでも、どこでも使えるコンポーネントを作ろう Reactで作ったコンポーネントを、Vue.jsのプロジェクトに持っていくには書き直しが必要です。Vue.jsで作ったものをSvelteで使うのも同様で、フレームワークが違えばコンポーネントは動きません。 この問題を解決する選択肢のひとつが、Web Componentsウェブ コンポーネンツです。Web Componentsはブラウザの標準仕様であり、<my-component>タグという形で定義したコンポーネントは、ReactでもVue.jsでもSvelteでも、素のHTMLでも動きます。そのWeb Componentsを実用的に書くためのライブラリがLitです。 本記事では、Litで作ったコンポーネントを各フレームワークから使う際の具体的な方法と注意点を解説します。コード例

2026年3月31日、HTTP クライアントライブラリ axios の npm パッケージが侵害されました。攻撃者はメンテナの npm アカウントを乗っ取り、マルウェアを含むバージョン 1.14.1 および 0.30.4 を公開しました。axios は npm エコシステムで週間約1億ダウンロードを誇る主要パッケージです。本記事では公開情報をもとに、事象の概要を記録します。また、対応指針を示します。 TL;DR - 対応指針 axios への直接依存に限らず、間接依存（transitive dependency）でも postinstall フックは発火します。 自身のプロジェクトが axios を直接利用していなくても、依存ツリーのどこかに axios が含まれていれば影響を受け得ます。npm ls axios で確認してください。 npm ls axios や lockfile により

自己紹介 はじめまして。クイック・ネットワークでフロントエンドエンジニアをしているジョン・ユジンです。 「目に見えるものを作ること」に興味を持ち、フロントエンドのキャリアを始めました。UI/UXやAIにも関心があります。 前職では韓国のAI企業でデータPMとして、さまざまな企業のAI開発に携わってきました。 現在はリプレイスプロジェクトに初期から参加し、約1年7ヶ月取り組んでいます。 本記事では、その中で考えてきたコンポーネント分割について整理します。 コンポーネント分割は、どこまでやるべきか フロントエンド開発をしていると、自然とこんなことを考えるようになります。 「これはコンポーネントに分けるべきかな？」 「今このタイミングで分割するのが正しいのかな？」 「再利用しやすいように、もっと汎用的に作るべきかな？」 私も最初は、「重複が見えたら分けよう」くらいに考えていました。 でも実務でい

JSer.info #767 - Vite 8.0がリリースされました。 Vite 8.0 is out! | Vite (main branch) Vitest 4.1 is out! | Vitest esbuild + Rollupの二重バンドラー構成をRustベースの統合バンドラーであるRolldownに置き換えています。lightningcssがpeerDependencyから直接的な依存関係へ変更され、ビルトインのDevtools、TypeScriptのパスエイリアス解決(resolve.tsconfigPaths)のサポートが追加されています。WebAssemblyのSSRサポート、ブラウザのコンソールログをdevサーバーのターミナルに転送するserver.forwardConsoleの追加なども含まれています。同じタイミングでVitest 4.1もリリースされており、Vit

PHPerKaigi 2026 2026-03-21 10:40 - Track B / レギュラートーク(40分) プロポーザル: https://fortee.jp/phperkaigi-2026/proposal/a16d700c-23b2-4345…

Vite 8リリース ―バンドラーをRolldownに統一⁠⁠、tsconfigパス解決⁠⁠、emitDecoratorMetadataをサポート Vite開発チームは2026年3月12日、高速フロントエンドビルドツールViteの新バージョンVite 8.0をリリースした。Vite 8.0はMITライセンスの元、GitHub上でオープンソースとして公開されている。 Vite 8.0 is out! | Vite ⚡️ Vite 8.0 is here! The most significant architectural change since Vite 2. ⏬ Powered by Rolldown bringing faster production builds and more consistency 🛤️ New features such as tsconfig path

年末年始の行事や雑用が重なって前回から少し間が空いてしまいましたが、今回も「らじる★らじる」の「聴き逃し配信」を楽しむ方法の続きです。 前回紹介したように、「⁠らじる★らじる」の聴き逃し配信ページではondemand_detail.jsというJavaScriptを使って番組情報データベースにアクセスし、HLS（HTTP Live Streaming）形式のデータ配信用URLを含む番組情報を入手して音声を再生しています。この手順をPythonでなぞることで、データ配信用のURLを入手できることも確認しました。 このAPIからは番組のタイトルや放送日時、出演者、簡単な番組情報等は得られるものの、あくまで聴き逃し配信のプレイヤー用なので、放送された曲目リストや演奏者、作曲者といった細かい情報を得ることはできません。 図1 聴き逃し配信のプレイヤー 一方、各番組のホームページを見ると、より詳しい楽