“The Sound of Music” は “非常に良いところから始めましょう” と説くかもしれません。 しかし、ほとんどすべての開発者は、それが愚かな計画であることを知っています。 始めるべき正しい場所は、オープンソース開発者の偉大なチームによって構築された堅固な基盤です。 彼らの努力の結晶をコピーし、それを自分のものにするために必要なコードだけを追加するのです。 誰もがやったことのあることを繰り返す必要はないのです。 残念ながら、その基盤を選択することは、最初から始めるのと同じくらい難しい場合があります。 Web フレームワークの世界は非常に活発な開発分野であり、プロジェクトにとって素晴らしいスタートとなる優れたオープン ソース プロジェクトが何十もあるかもしれません。
さらに悪いことに、これらの異なるプロジェクトを作成した異なるチームは、他の選択肢との深刻な哲学的相違があったため、異なる道を歩み始めたのです。 彼らは他のフレームワークを見て、自分たちはもっとうまくやれると判断したのです。 言い換えれば、彼らは理由があってそれを行い、あなたは彼らの決定に同意するかどうかはわかりません。
以下の開始すべき良い場所のリストは、物事を少し単純化するために、市場のリーダーである React、Angular、および Vue を意図的に除外しています。 だからといって、ビッグ 3 が悪いというわけではありません。 彼らはまだあなたにとって正しいものであるかもしれません。 ただ、これらは常に話題になっており、これらの議論では、他のいくつかの非常に良い選択肢が省かれています。
最も人気のあるものを選択する正当な理由はたくさんあります。 あなたのような立場の人の多くが周りを見渡し、その多くが正当な理由で React、Angular、または Vue を選択しました。 しかし、それは当時の話です。 その間に、賢い人たちが、より速く、よりシンプルで、より強力な、あるいは多くの最上級の言葉を並べた新しいフレームワークを作成しました。
以下の事例のほとんどで、チームはフレームワークの性質を再想像することにより、何か魅力的で強力なものを作成しました。 これは、フレームワークをより効率的にするために機能を削除し、必要なメモリの量を減らし、起動時間を短縮し、または一般的により軽快にすることに終始したことを言い表したものです。 または、いくつかのケースでは、将来標準になるかもしれない新しいアイデアを追加しました。
投資する時間があれば、他の興味深い選択肢のいくつかをリストアップします。 それらは人によっては必ずしも正しいとは言えず、またすべての人にとって最良の選択でないことは確かですが、あなたにとってはより良い選択となるかもしれません。 もしあなたがそれを受け入れることを選択するなら、あなたの仕事は、Web アプリケーションのしっかりとした説明を作成し、さまざまな使用例について比較的しっかりとした説明を書き留め、これを念頭に置いてこれらのツールを評価することです。
おそらく、コードを設計するための特定のアプローチがお好きなのだと思われます。 おそらく、コードを設計するための特定のアプローチが好きなのでしょう。おそらく、アプリケーションは、より太く、より人気のあるフレームワークの機能のいくつかを必要としません。 これらの他のパスの 1 つに投資する理由はたくさんあります。
Petit DOM
仮想 DOM のアイデアが好きだが、React、Vue、または他のビッグネーム フレームワークの人々の考え方を採用することで生じるすべての制約を望まない場合、Petit DOM がその方法となります。 タグの仮想的なコレクションを操作して、それを実際のDOMに移行するための、ごくわずかなコードを得ることができます。 それ以外のコンポーネントの構造やレンダリングについては、すべてあなた次第です。 コンポーネントが単純な場合や、自分だけの超複雑なレンダリング階層を作成する場合、DOM を仮想化するためのツールしか提供しないので、これが基盤となるでしょう。 スペースを取るので、操作がそれほど複雑でないなら、公式 DOM に直接指示を出した方がよいでしょう。 Surplus ライブラリはまさにそれを実現します。 みんなの大好きなマークアップJSXを、本物のDOMを操作するコードにコンパイルしてくれるのです。 広告業界で言われているように、中間マージンをカットするのだ。 差分なし。 秘密の余分なレイヤーもない。 本物のDOMを純粋に操作するだけです。 コードが単純で直接的で、DOM に対してほんの少しのことを行うだけなら、なぜわざわざ仮想的な邪魔をするのでしょうか。
RE:DOM
仮想 DOM にメモリを投資したくない人のためのもうひとつの選択肢は RE:DOM という小さなライブラリ (2KB) です。 RE:DOM には、いくつかの基本的なルーチンが含まれており、いくつかの簡単な JavaScript 呼び出しですべてのタグとコンポーネントを作成できます。 構文はCSSにかなり近いので、IDやクラスを含むかなり凝ったタグもわずかなキー操作で指定することができます。 less than” (<) と “greater than” (>) キーに感謝するでしょう。
Mithril
代替品のすべてが小さくて最小主義というわけではありません。 Mithril は、重さはわずか約 8KB ですが、この文脈では「中型」のフレームワークと呼ばれるかもしれません。 このコードはすべて、他のものと同様に効率的な更新メカニズムで仮想 DOM を構築しますが、ルーティングや XMLHttpRequest 呼び出しなどの標準的な課題の多くを処理するための標準化されたツール セットも付属しています。 プロジェクト設計者は Mithril プロジェクトが比較的標準化されることを望んでおり、このコードをメインライブラリに追加することで標準化が進むと実感しています。 12>
Bobril
React の仮想 DOM とステートフルなコンポーネントが好きで、TypeScript でプログラムするのが好きなら、Bobril またはその Angular フレンドリーないとこの ngBobril はちょうどチケットになるかもしれません。 このフレームワークは、いくつかのベンチマークで一貫してReactやAngularよりもずっと高速です。おそらく、より高速なdiffアルゴリズムと、同型のJavaScriptをサポートしていないことが原因でしょう。 CSS 操作のための省略記法関数や、必要であれば完全な状態管理レイヤーの BobX もあります。
Marko
もしあなたが Pez ディスペンサーや他の収集品の入札に時間をかけているなら、eBay がオープン ソース ライセンスを通じて共有しているスリムで高速なフレームワークである Marko の力を体験していることでしょう。 最も素晴らしい部分は、HTMLから余分な脂肪を巧みに取り除き、インデントとそれ以外のもので構造を定義する、非常に軽量なテンプレート構文であろう。 そして、レンダリング エンジンは非常に高速で、60fps よりも速く更新される、踊るような DIV の精巧な星座を動かすことができます。
Svelte
標準の Web フレームワークは、コンパイラーとダウンロードしたライブラリーが付属し、コンパイラーは生成したものをランタイムに処理します。 この 2 段階のプロセスにより、ページが開かれるたびにランタイム ライブラリがダウンロードされ、解析されるのを待つという代償を払って、非常に精巧なコードを作成することができるのです。 Svelte コンパイラは、新しいブラウザの一部 (例: Chrome, Firefox, Opera, IE10) でしか動作しないとはいえ、ほとんどそれ自体で実行可能な純粋に近い JavaScript を吐き出すことによって、この複雑さから解放されます。
Inferno
Inferno は、React が行うことのほとんどを行うために作成された別のフレームワークですが、ダウンロード数は少なく、実行時間はより速くなります。 これは、精巧な合成イベント機構を捨て、onClick のような最も重要なものだけに集中することによって達成されます。 12>
Preact
React の子孫の中で最も小さいものの 1 つが Preact で、仮想 DOM や洗練されたコンポーネントなど最も価値のある機能のほとんどを提供し、合成イベント ハンドラやプロップ継承のいくつかを取り払ったオマージュ作品です。 Inferno が onClick のような最も重要なイベントのみを実装しようとするのに対し、Preact はイベントに対して何もしようとせず、ブラウザのネイティブな addEventListener に依存することになる。 あまり追加されない（と彼らが考える）機能を省くことで、ダウンロードのサイズをさらに小さくしているのです。 ベンチマークによると、PreactはInfernoより少し遅いので、これはちょっとしたトレードオフです。 もちろん、あなたのアプリケーションは異なるかもしれませんし、あなたのマイレージは異なるかもしれません。 Reactとの純粋な互換性が本当に必要であれば、ビルド中にほとんどの問題を修正するライブラリ（preact-compat）もあります。
Hapi
多くのフレームワークが 1 つのチャンクで提供されています。 Hapi はむしろプラグインのコレクションであり、あなたが適切と考えるようにスタックに混ぜることができるコードのビットの数十の星座です。 認証、認可、ロギングなどは、いくつものオプションで解決できる雑用です。 API でいっぱいのマイクロサービス アーキテクチャを構築している場合、標準化された Swagger プラグインは、基本コードから Swagger ドキュメントを自動的に生成します。
Koa
時には、入ってくるリクエストをやりくりして、複数の変更、そのうちのいくつかに変換するルーチンのかなり複雑な集合が必要なことがあります。 Koa は、この作業のすべてを少し単純化して整理するように設計されています。 その秘密は、通常JavaScriptを支配するコールバック関数を、適切なタイミングで起動する非同期関数の集合に変えることです。
Nest
Nest チームは、コントローラー、パイプ、プロバイダーで満たされたアーキテクチャを提供し、秩序を保つためにガード、インターセプター、例外フィルターが追加されています。
Drupal, WordPress, and Rails
JavaScript で構築され Node.js 上で動作するフレームワークは、最近の Web 開発の世界の中心を占めています。 しかし、PHP で構築された前世代を無視するのは間違いです。PHP は、JavaScript のようなジャストインタイム コンパイラーも備えているため、これまで以上に高速な基盤となっています。 そして、Ruby とその Rails フレームワークは、強固な Web サイトの礎として機能し続けています。
前世代は、10 年以上の継続的な開発と作業によって傷つき、十分にテストされました。 アプリのテーマやスキンを作成できる洗練されたデザイナーがいます。 あなたが必要とする機能を持つモジュールを誰かがすでに作っている可能性が高いです。 したがって、巧妙な Node.js フレームワークを探求する前に、必要なもののすべてではないにしても、古いものの 1 つですでに多くのことができるかどうかを検討してください。
Vanilla JS
これを意地悪な掘り出し物と見るか、あるいは「皇帝の新しい服」のようなレベルの風刺として見るかもしれませんが、その成功には反論しにくいです。 Vanilla JS は、そのフレームワークが「jQuery、Prototype JS、MooTools、YUI、Google Web Toolkit-combined」より多くの Web サイトで使用されていると自慢している Web サイトです。 jQueryの普及を考えると、これは事実かどうかわからないが、やけに笑っておこう。 このサイトには、Math、DOM、クロージャ、正規表現など、さまざまなコンポーネントのカスタムアーカイブを束ねることができる、かわいいセレクタもついている。 何を選んでも、結果は気の遠くなるような0バイトの長さです。 12>
このジョークのポイントは、JavaScript の標準的な要素のいくつかを使用して、余分なものをスキップすることが理にかなっている場合があるということです。 jQuery や React のようなライブラリやフレームワークが始まったのは、部分的には、ブラウザー間の気の遠くなるような違いのためです。 12>
もちろん、Vanilla JS 支持者は、$() のような省略記法の関数が便利なだけでなく、私たち自身のコードのスペースを節約しているという事実を直視しません。 しかし、document.getElementByIdをたまにしか使わないのであれば、それは問題ではないかもしれません。 もしあなたがウェブページにいくつかの関数を追加し、それらの関数がいくつかの基本的なことを行うだけなら、プレーンバニラJavaScriptはあなたにとって最速のフレームワークかもしれません
。