私は現在、約6人の開発者+ 1人のWebデザイナーのチームによって開発される大きなアプリのフロントエンドアーキテクチャを評価しているため、堅牢なSVNフレンドリーなアーキテクチャを持つことは必須です。これまでのところ、この2つのオプションを評価しています。
これは、アーキテクチャが満たす必要のある要件です。
前に述べたものはさまざまなレベルの要件のほとんどを満たしていますが、今のところそれらは私が見つけた唯一の要件です。他に不足しているものはありますか?
SVNの要件に混乱しています。 JSフレームワーク、ツール、またはライブラリがバージョン管理に問題を引き起こすことは聞いたことがありません。通常は、すべて静的ファイルです。
フロントエンドの武器庫で最も重要なツールは、ソースでのクロスブラウザの問題とDOM APIの問題を取り除くためのツールです。 jQueryはその面で優れた選択肢です。
jQは、フロントエンドのすべてがIMOに従うべき設計哲学に基づいて実行されます。それはあなたがそれをあなたの邪魔にならないようにしたいときにあなたの邪魔にならないままであり、それは他の人とうまく演奏します。
私はJQのライブラリとプラグインにそれほど感心しない傾向がありますが、それらの選択は開発者に任せます。
EXTJSは、正反対の正反対です。それは鈍いアンチパターンカスケード継承スキームのためにリバースエンジニアリングするのが非常に難しいヘビーハンドドフレームワークであり、DOMにひどいことを行い、CSSを完全にすべてスローし、すべてのボックスサイズのCSSを再定義しますページ上で、IDをまだ持っていないものすべてにIDを追加します。 EXTはお勧めしません。私たちはこの1年間、アプリから最後の痕跡を取り除くことを望んでいましたが、適切な時間のコミットメントを与えるのは非常に面倒です。オープンソースよりも少ないJSライブラリを作成したいと思っていた人たちが、その人気を享受するために最悪のものを書いたことは、私を悩ませています。
bootstrapの私の印象は、それがデザイナーツールであるということです。開発者とデザイナーにそれを望むかどうかを決定させてください。それが提供するJSコンポーネントは特別なものではなく、それよりも低いレベルの処理を行う人によって書かれています。あなたが対処することを計画しているように聞こえるよりも複雑です。私がそれについて嫌いなのは、非標準のHTML属性(現在はHTML5では問題ないと見なされていますが、私の本ではHTMLを読みにくくしている)に過度に依存していることです。コンポーネントタイプやコンテンツ階層ではなく、スタイルを記述するクラス定義のクラスです。HTMLにフックがあってもかまいませんが、フレームワークまたはライブラリでそれらを設定できるようにすると最適です。
バックボーンは使っていませんが、とても人気があります。私のターンオフは、それがロックインフレームワークとして記述されているのを見ていました。それによって、記事の著者は、次に進み、別の何かを使用することを決定した場合、既存の機能をそこから移植するのが難しくなることを意味しました。私は、EXTを解体することでその性質の頭痛の種が多すぎて、それを利益の受け入れられるトレードオフとして見ることができませんでした。
私が真剣にお勧めするのは、最初にクライアント側のチームを編成してから、バックエンドで使用しているものと、独自のフロントエンドの専門家が簡単に拡張できるものを作成するための良いアイデアと見なすものに関連するツールを決定することですコードが短期的ではなく長期的に記述されたアプリ。 JSアーキテクチャフレームワーク、UIウィジェット、および事前にスタイル設定されたHTMLライブラリが豊富にあるにもかかわらず、私自身の選択は、私が選択できる場合、独自のUIを記述し、jQueryスープをDIYアーキテクチャオブジェクトスキームでラップすることです。実装とデバッグを容易にすることを念頭に置いてください。また、厳密にクライアント側のコンテキストで正確に実装するよりも、一般的な原則の方がMVCパターンが好きだと思います。
複雑なフロントエンドアプリのシナリオでは、変更が容易ではないコンポーネントを生成したり、制限を設定したり、クライアント側の環境全体を汚染したりするツールや、フレームワークを切り離すことが非常に困難になる見込みをもたらす私の本では未来は大いに否定されます。しかし、塩のバレルでそれを取る。私のツールに関しては、私は少し厄介で、一部の本当に悪いもの(特にCMS)に我慢しなければならなかったために、それを喜ばせるのは難しいです。
結局のところ、私が気付いているものはDIYと同じ柔軟性はありません(UIのボイラープレートを実際に排除するjQueryを除く)。ただし、何らかの一貫したアーキテクチャの背後にいる開発チームがいることを確認してください。確かに、バックボーンやノックアウト、あるいはJS MVCを使う方がよいでしょう。
私はExtJSで書いており、2008年からSenchaスタックを使用しています。また、jQuery、YUI、Twitter Bootstrapを使用し、EmberJSを試しました。Senchaが推進するコンポーネントベースのアプローチが大好きです。一連の既製のコントロールからのUI。データをモデルに配置し、コントローラーを使用してそれらを結合します。グローバルAJAX呼び出し処理、エラー処理、i18nなどの追加のレイヤーを導入すると、多くのプロジェクトの優れた基盤を得ました。管理パネルやCRMなどのCRUDベースのプロジェクトは非常に迅速に実行できます。注意すべき点と注意点はありますが、ExtJS全体を使用すると非常に効率的です。しかし、重大な欠点があります:
結論として、UIが大きいが、ExtJSパレットにあるコンポーネントで構成されていて、大幅な設計の更新が必要ない場合は、ExtJSが間違いなく適しています。本当にカスタマイズされたものがある場合は、AndroidスマートフォンからMacbook Proの網膜画面に、カスタムコントロールを使用し、完全にユニークなルックアンドフィールを備えています。jQueryをチェックしますが、EmberJSのような構造フレームワークと組み合わせます。 BootstrapのようなCSS /コンポーネントフレームワーク。スタックが非常に優れていることを学べば、それで非常に効率的になります。
そして、決して、決して、決してExtJSマインドセットでjQueryを記述しないでください。フレームワークは、そのアーキテクチャとその方法の背後にあるコード+哲学です。それを学び、それに従ってください、そしてあなたは良い結果を得るでしょう。
私はこれが少し遅れていることを知っていますが、この投稿を最新に保つために、私は AngularJS を回答の1つとしてリストする必要があると思います。私はjQueryとAngularJSの組み合わせを好み、UI要件によってはBootstrap/Angular-UIを選択することもできます。