フロントエンドをViteからNext.jsに書き換えた話 〜パフォーマンス編〜 - 株式会社ヘンリー エンジニアブログ

こんにちは。4月にヘンリーに入社したSWE / アーキテクト / SETのsumirenです。 弊社ではレセコン一体型クラウド電子カルテの Henry を開発・提供しています。 今回、HenryのフロントエンドをReact + ViteからNext.jsに書き換えました。 この記事では、最初にNext.jsへの切り替えによってもたらされたユーザー体験の向上について説明します。次に、このユーザー体験の向上がどうして生じたのか、その背後にある技術的な要素をエンジニア向けに詳細に解説します。最後に、フロントエンドアーキテクチャに対する我々の長期的なビジョンについて述べます。 対象読者 Next.js導入によるユーザー体験向上 デモ 定量的なパフォーマンス比較 ユーザー体験がどう向上したか FCP高速化の技術的な仕組み Next.jsとViteの基本的なアーキテクチャの違い 補足：工夫しているポイ

[asip]

Viteの理解/知識の乏しいエンジニアの書いた記事、Viteと比較すべきはNext.jsではなくNext.js組込のWebpack。Vite、ではCSRのみが標準構成って、vite-plugin-ssr or vite-ssrを利用すればSSRできるんだよね(Next.js組込のTurbopackは現在ベータ)

[furu_ichi]

社内でチェックせずに公開しちゃったのかな。『React単体のSPA構成からNext.jsのSSR構成に変えました』だったらわかるけど、ViteとNext.jsはそもそもジャンルが違う。

[door-s-dev]

呼び方がおかしいから単純に理解してないと思われそう。 補足じゃなくて素直に「React + Vite構成をNext.jsに置き換えた話」と書いた方が良いのでは

[circled]

コンパイラをフレームワークに書き換えましたって言われてる気分になってる

[asiamoth]

おお！ と思ってリンク先のHenryを見てみると、Next.js*ではなく*Nuxt製だった……（ﾄﾞﾕｺﾄ?）。

[nilab]

「弊社ではレセコン一体型クラウド電子カルテの Henry を開発・提供」「HenryのフロントエンドをReact + ViteからNext.jsに書き換え」「Next.jsへの切り替えによってもたらされたユーザー体験の向上について説明」

[yasu-log]

便宜上「Vite」と呼称しても、技術レイヤーが違うので…

[Songmu]

入社したてなのに、いきなりこれ推進して実現したのすごかった

[Nyoho]

わしも比較している集合が違うかなあと思ったけど「Viteベースで作ったプロジェクトからNext.jsベースのそれに書き換えた」だったらいいかもと思った。

[kazokmr]

検証内容がとても参考になる。今後はコンポーネント構成の話もあるのかな。ただSPA(CSR)からMPA(SSR)への切り替えなのでタイトルからミスリードが起こりそう。Nextjsと仕組みが似てるSvelteKitはVite使ってるし

[emmeleia]

タイトルでミスリードを誘っているのはあるかもしれないけど、Vite+Reactくらいに直せばいいし、それを知識が乏しいと煽るのはいかがなものかと思う。

[t1000leaf]

Vite と Next.js じゃ比較対象がおかしい？もしかして本番で vite preview してた？

[dec123456789]

4月入社ってことは多分新卒っしょ？まあこのレベルの理解でもしゃーないっしょ。……新卒だよね？

[ghostbass]

よくわからんのだが、vite であることってそんなに実行パフォーマンスに影響するもの？

[eller]

昔はClosureToolsってのがあってね…とか言いつつも、reflow/redrawを減らすという基本はまだ変わってないのかもと思った。スクリプト分割とかminifyのための情報整理とか、考えることが減らせてるようにも感じる

[JackP]

タイトルからまたヘンテコな記事が出てきたなぁと思っちゃった。自戒を込めてだけど、技術用語をきちんと使おうという姿勢を持ちたい。エンジニアこそ国語力と表現力が必要だなと

[daigo0117]

Next.js (Turbopack)と書けばOKかな？