noteのフロントエンドのざっくり歴史まとめ
この記事では、noteがリリースされた2014年当初から現在までのフロントエンド技術の移り変わりをざっくりと振り返ります。
Angular 1.x 系からスタートしたnoteは、その後Nuxt.jsへの移行、さらにはNext.js + Svelteを活用したリアーキテクチャの道を歩んできました。
フロントエンド領域がめまぐるしく変化する中で、なぜこれらの選択をしてきたのか、どんな課題があったのかなどをまとめました。
※ この記事で扱う内容は、2014年〜2025年1月時点での内容です
Angular 1.x系でnoteをリリースした背景
2014年当初の状況
noteがリリースされた2014年は、フロントエンドフレームワークがまだ混沌としていた時代でした。Reactは登場していたものの、企業での採用実績やノウハウがそこまで多くはなく、Vue.jsはまだ黎明期。AngularJS（Angular 1.x）のコミュニティは大きく、多機能なフレームワークとして知られていました。
なぜAngular 1.x系を選んだのか
複雑なUIを少ない労力で構築できる
双方向データバインディングをはじめとするAngularJSの仕組みは、入力フォームの多いUIやSPAのような複雑な画面を素早く作るのに適していました。当時のトレンドと大規模なコミュニティ
ドキュメントやサンプルが豊富で、学習コストを抑えやすかったという点も大きなメリットでした。
課題：パフォーマンス面での悩み
リッチな機能を多数実装する中で、JavaScriptによる処理の負荷が高くなりがちでした。とくに古いスマートフォンやPCではパフォーマンスに難が出てしまい、ユーザー体験にも影響する場面が増えていました。
関連記事
Nuxt.jsへの刷新
移行検討のきっかけ
大規模化していたAngular 1.xプロジェクトをそのまま保守・拡張していくには、限界を感じるようになりました。特に以下の点が課題でした。
実行効率の悪化
CPU負荷が高くなり、ユーザビリティが下がる。5年でフロントエンド技術が大きく進化
ReactやVue.jsをはじめとした新しいフレームワークが進化し、SSR（サーバーサイドレンダリング）や静的サイトジェネレーションなどのベストプラクティスが確立してきた。
なぜNuxt.jsを選んだのか
当初はAngular 2系（現：Angular）へのアップデートも検討していましたが、最終的にはVue.jsベースのNuxt.jsを採用しました。
SSRへの対応のしやすさ
Nuxt.jsはSSRを取り入れやすく、SEOやページの初期表示速度に有利でした。Vue.jsの学習コスト
Angularより軽量なVue.jsを学習することで、開発者の参入障壁が低くなるメリットがありました。
Nuxt.jsへの完全移行
2021年にNuxt移行が完了
大規模なリプレイスにもかかわらず、Nuxt.jsによる開発効率向上を実感しながら移行が完了しました。Nuxt2系から3系への壁
Nuxt 3系が登場した際、2系からの移行コストや互換性の問題が大きいことが判明しました。
結果、今後のメンテナンス性や機能拡張を考慮し、段階的にNext.jsへ切り替えていく方針へと舵を切ることになりました。
関連記事
noteのNuxt.jsへの移行が完了し次世代のフロントエンド構築を進めています
Next.js + Svelteによるフロントエンドの再構築
Next.jsとSvelteを選択した理由
Next.jsの成熟とエコシステム
ReactベースでSSR/SSGが標準搭載されているため、柔軟かつ拡張しやすい構成がとれる。Svelteを共通コンポーネントに採用
VueやReactと並んで近年注目度が上がっているSvelteは、ランタイムのフットプリントが小さく、パフォーマンスにも寄与する。NuxtとNextのどちらでも同じコンポーネントを使えるように、Svelteを使って一部を共通コンポーネントとする試みを行っている。
実際の移行進捗
機能ごとの切り出し
エディタや設定ページなどをNext.jsで独立したアプリとして構築。ビルド・デプロイが高速化。開発工数の削減
ページ/コンポーネント単位で移行を進めることで、いきなりすべてをリプレイスするよりも安定的かつ計画的に進められている。パフォーマンス向上
CPU負荷が下がり、表示速度や操作性が向上。特に古い端末での表示速度が改善。
関連記事
Next.js + SvelteによるnoteのフロントエンドApp分割
モノレポ化による開発体験の向上
モノレポ導入の背景
フロントエンドの複数アプリを同時並行で開発・運用するにあたって、依存関係や共通設定の管理が複雑化していました。モノレポ化することで以下のようなメリットが得られます。
依存パッケージの一元管理
開発者体験（DX）の向上
各アプリ間のコード共有や更新が簡単になる
ESLintからBiomeへの移行
統一的なコードスタイルと品質チェック
これまではESLintを活用していましたが、Biomeへの移行により、さらに軽量かつ高速な静的解析が実現できました。モノレポと組み合わせた効率化
依存関係やルール設定を一括管理し、開発チーム全体の生産性を上げています。
関連記事
デザインシステムとアクセシビリティへの取り組み
デザインシステムの導入
「誰もがつかえる」プロダクトを目指して
コンポーネント指向のフロントエンド設計が進む中、一貫したUI/UXを提供するためのデザインシステムを導入しています。発端と現在
初期はバラバラに管理されていたデザインルールも、現在はFigmaやStorybookなどを活用し、チーム全体で共有できる仕組みを整えています。
アクセシビリティ向上
ユーザー中心のプロダクト開発
多様なユーザーが快適に利用できるよう、WCAGなどのガイドラインに即した改修を継続。モノレポやデザインシステムとの相乗効果
デザインシステムにアクセシビリティ要件を組み込むことで、個々の開発者があらためて対策する手間を削減し、結果として品質が高まっています。
関連記事
「誰もがつかえる」を目指したnoteのデザインシステムの導入とこれから
まとめ
noteのフロントエンド技術は、Angular 1.x系による初期リリースから始まり、Nuxt.jsへと移行し、さらにNext.js + Svelteによるコンポーネント単位の再構築へと歩みを進めてきました。
技術進化のスピードが速いフロントエンド領域で、常にユーザビリティと開発効率を両立させながら挑戦を続けています。
Angular 1.x系のメリットと限界
Nuxt.jsによるSSR対応とパフォーマンス改善
Next.js + Svelteで実現する段階的なリプレイス
モノレポ化とBiome導入による開発体験向上
デザインシステムとアクセシビリティへの継続的な取り組み
今後も、フロントエンド技術やユーザー要件の変化に合わせ、最適解を模索しながらnoteのUI/UXを高めていく予定です。引き続きご注目いただければ幸いです。
▼noteの技術記事が読みたい方はこちら