次のプロジェクトで Ember.js を使用すべきでない主な理由

新しいプロジェクトを開始し、どのフロントエンド フレームワークを使用するかを決定しようとしている場合は、この記事が役に立ちます。次のプロジェクトで Ember.js を使用しない私のトップ 7 の理由は次のとおりです。

1. あなたは野心的な Web 開発者ではありません

Ember は自らを「野心的な Web 開発者のためのフレームワーク」として宣伝していますが、正直に言うと、誰もが野心家、つまり Web 開発者であるわけではありません。野心的な開発者は野心的なプロジェクトに取り組み、野心的なプロジェクトには Ember がすぐに使えるインフラストラクチャが必要です。

1998 年に私は最初のウェブサイト「The Track Shack」を作成しました。それは、私が所属していた高校の陸上部に関するサイトでした。当時はコーディングの仕方を知りませんでした。 Microsoft Word 97 を使用して記事を作成し、「Web ページとして保存」機能を使用して記事を HTML にエクスポートし、それを自分の Geocities Web サイトにアップロードしました。ある日、コーチが私にウェブサイトを作成したかどうか尋ねました。どうやら、州内の他のコーチが私たちの地域から陸上競技のニュースを入手するためにそれを使用していたようです。 The Commercial Appeal (当時はオンラインではありませんでした) の試合結果も含めたり、地元の試合でのチームのイベントのドラマ化された説明を追加したりしました。

そのような単純なサイトがニーズを満たす場合は、すぐに Word の「Web ページとして保存」機能を使用してください。

2. 独自のフレームワークを組み立てたい

Ember は独自の意見を持つ、バッテリーを備えたフロントエンド フレームワークです。パッチのバージョンに至るまで各ライブラリを選択し、独自のオーダーメイドのセットアップを作成することに時間を費やしたい場合は、Ember には大いに失望するでしょう。

Ember では、次のコマンドを実行して新しいプロジェクトを開始します。

npm install -g ember-cli
ember new my-project

これで、新しいプロジェクトを実行する準備が整いました。

npm start

単体テストはすでに構成されていることに注意してください。これが理由 3 番目の理由になります。

3. 単体テストを書くつもりはない

Ember は、組み込みのコード ジェネレーターを使用するたびに、単体テスト、統合テスト、および受け入れテストを自動的にセットアップし、正しい場所にスタブを生成します。たとえば、ember コンポーネント生成ビッグボタンを使用して新しいコンポーネントを作成すると、Ember はコンポーネント ファイルとそのテスト スタブを生成します。コンポーネントをテストするには、これにアサーションを入力する必要があります。

テストが不要な場合は、コードレビューで眉をひそめるようなスタブが作成されることになり、実際にテストを作成するか、プルリクエストを送信する前にスタブを削除するために余分な時間を費やす必要が生じる可能性があります。確かに、コマンド ライン フラグを使用してテスト生成をスキップすることもできますが、それは覚えにくいため、お勧めできません。

4. あなたはネイティブ JavaScript が嫌いです

Ember はネイティブ JavaScript 機能を多用しており、DOM の管理に jQuery などのライブラリを使用することは一般に嫌われています。たとえば、クラスベースのコンポーネントは次のようになります:

npm install -g ember-cli
ember new my-project

ネイティブ JavaScript のファンではない場合、Ember は絶対に向いていません。

5. JavaScript からテンプレートを分離するのが嫌い

昔は、次のような古き良き JavaScript 文字列を使用して HTML ページを作成していました。

npm start

テンプレート言語はこの必要性を排除し、危険な値を自動的に回避し、ロジックとプレゼンテーション (HTML) の間で懸念事項の分離を強制します。これは一部の開発者にとって懸念事項です。

Ember のテンプレート エンジンに関するもう 1 つの潜在的に迷惑な点は、データが変更されるとアプリ内の HTML が自動的に更新されることです。これは「データ バインディング」として知られています。 DOM を手動で管理したり、文字列を連結したり、別のテンプレート エンジンを使用したりする場合は、Ember は適していません。

6. 依存関係を更新するのが嫌い

Ember コミュニティの中核となる価値観は「停滞のない安定性」です。フレームワークは、セマンティック バージョニングに従って、下位互換性のある増分で定期的に更新されます。非推奨の機能があると、開発中に警告が表示され、削除される時期と更新方法が通知されます。

マネージャーが警告なしのビルドを要求する場合、これらの非推奨メッセージにより作業が増える可能性があります。 Ember の更新は、特に定期的に行う場合は特に簡単ですが、何年も更新を無視してきた場合は、取り戻す必要があります。

7. Ember コミュニティは Discord を使用しています

Ember プロジェクトでサポートが必要な場合は、コミュニティの Discord サーバーが最適な場所の 1 つです。ただし、Discord が会社のポリシーに反する場合 (または単にあなたのスタイルに反する場合)、これは取引の妨げになる可能性があります。

Discord サーバーでは、Ember 初心者もフレームワーク開発者も同様に見つけることができ、助けを得たり、アイデアを共有したり、プロジェクトの将来についてチャットしたりすることもできます。ただし、注意してください。これらの会話は面白くなり、気が散ってしまう可能性があるため、一部の企業が Discord を禁止している可能性があります。

したがって、現実の人間よりも AI を好む場合や、専門家のアドバイスよりも Google 検索を好む場合、または Discord が本当に嫌いな場合は、手間を省いて Ember.js をスキップしてください。

結論

次のプロジェクトで Ember.js を使用しない理由トップ 7 は以上です。このアドバイスを無視して Ember に飛び込むことを選択した場合、Discord サーバーに潜んでいる私を見つけることになるかもしれません。質問があり、私がその答えを知っている場合は、お手伝いできるかもしれませんが、おそらくもっと知識のある人が私より先に答えてくれるでしょう。ということで、次のプロジェクトに Ember を選ばない理由についてもっと話し合ってもいいかもしれません!

以上が次のプロジェクトで Ember.js を使用すべきでない主な理由の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。