質問

MooTools v1.11 に依存するかなり大規模なコードベースがあり、バージョン 1.2 に変換しようとしています。これはかなり大規模な見直しであるため、jQuery に変換するというアイデアを検討しました。

jQuery に更新するべきか、それとも MooTools を使い続けるべきかについてアドバイスがある人はいますか?

私は主に、Ajax、ドラッグ アンド ドロップ、およびいくつかのマイナーなエフェクトに MooTools を使用します。

役に立ちましたか?

解決

アップグレードする場合 ともかく, 、それなら検討してみる価値はあるかもしれません。

jQuery は、One True J​​avascript ライブラリになる方向に順調に進んでいるように思われます (MS やその他の企業が jQuery を採用することを決定したことを考えると)。そのため、これがしばらく作業するつもりのコードである場合は、おそらく切り替えることをお勧めします。 (それは、しばらくは人気が続く可能性が非常に高いため、ヘルプやプラグイン コードを入手できる場所が増えるためであり、コードの長期的な柔軟性と保守性を確保するのに役立つからです)。したがって、とにかく変換​​する必要があることを考えると、今がそれを行うのに最適な時期である可能性があります。

jQueryになると思います 使用するフレームワークは良いことです。それは私の選択ではなかったでしょう (私も MooTools が好きです) が、これは確かに優れたコードであり、少なくとも競合他社の能力を備えた目的には間違いなく適合します。一貫性が保たれていることを嬉しく思い、いつかコードを jQuery に移行するつもりです。

他のヒント

破損していない場合。修正しないでください。

jQueryにはXまたはYがありますが、すべてがMooToolsに依存している場合は、MooToolsから変換するために多くの作業を事前に行う必要があります。

サイト全体で広範囲に使用した場合は、MooToolsを保持します。ただし、わずかな効果のある2〜3ページしかない場合は、変更する価値があるかもしれません。

切り替えを行う理由コードベースを1.11から1.2に変換しましたが、非常に迅速かつ簡単です(そして、いくつかの効果以上に使用しています)。

jQueryはMSに採用される可能性があり、IEでより良いパフォーマンスを発揮するサイトが1つありますが、これはIEでのパフォーマンスに関するものではなく、サイトでの動作に関するものです(IEはサイトの主要なプレーヤーですか? ?)。

jQueryを知っていますか?そうしないと、コードを最初から書き直さなければならず、コードを完全に書き直すことになります。

または、マネージャーに「jQueryでこれを行う必要がある」と伝える理由を考えていますか?あなたはそれを学びたいのですか?

「唯一の真のフレームワーク」に関する限り、 -これは、開発者ではなくユーザーのみが行うというばかげた主張です。

MooTools 1.1.1から1.2.1への切り替えはそれほど大したことではありません。 http://github.com/mootools / mootools-core / wikis / conversion-from-1-11-to-1-2

MooTools 1.1.1コードを1.2.xで機能させる互換性レイヤーもあります。あちこちでいくつかのことを手動で修正する必要があるかもしれませんが、それは比較的マイナーです。

jQuery、YUI、DOJO、またはその他に切り替えるには、所有しているすべてのコードを完全に破棄し、説明する必要があります。私のクライアントはそのような無駄を許しません。

また、適切なMooToolsクラスを使用したコーディングに慣れている場合、jQueryはシステムに大きな衝撃を与える可能性があります。 jQueryを使用して読み取り不能で保守不能なコードを作成する必要があるわけではなく、非常に読み取りやすく保守可能なコードを任意の言語でコーディングすることは確かに可能です。ただし、jQueryにはユーザーを支援する組み込みのクラスシステムがありません。

特に大きなコードベースでは、コードをきちんと整理しておくことが重要です。

もちろんかなり偏見があります。

哲学の違いを説明するサイトがあります jqueryvsmootools.com

それは最終的にはそうなると思います。機能的なDOM中心のアプローチまたはオブジェクト指向のJavaScriptアプローチ。

他の人が指摘しているように、jQueryは(ほとんどDOMを操作するための)ライブラリであり、Mootools(1.2)は、オブジェクト指向の方法でコードを整理し、保守を容易にする本格的なjavascriptフレームワークです。 。

これを読んで、それぞれが実際に何であるかを本当に理解することをお勧めします(jqueryvsmootools.com)

そしてこの他のリンクは、あなたが両方の世界から最高を得る方法を知っているので;):

http://ryanflorence.com/object- oriented-jquery-with-mootools-pigs-take-flight /

最終的には、必要なものに要約されます。私の一般的な推奨事項:簡単なスニペットを取得し、Webアプリケーションを空にする必要がある場合は、jQueryだけで十分です。 JavaScriptを中心に開発する場合は、実際にmootoolsを試してください。コードは スケールし、準備ができているはずです。

Mootools 1.1からコードをアップグレードするには、アップグレードヘルパーを使用できます。javascriptコンソール(mootools.net/blog/2009/12/31/mootools-1-1-upgradeを介して競合するコードを特定するのに役立ちます。 -layer-beta /)

[アクティブなリンクを1つしか投稿できません。これが最初の回答です]

それは、jQueryをどれだけよく知っているか、および期限が何であるかによって異なります。よく知っていれば、コードの行数が少なくなるため、顧客の帯域幅が少なくなります。

もご覧ください。このサイトでは、主要なブラウザIEでjQueryのパフォーマンスがMootoolsより優れていることがわかります。

とはいえ、すべてがMootools v1.11で機能している場合、なぜスクリプトを更新するのですか?前のポスターにあるように、壊れていない場合は...

Mootools v1.11で正しく動作しない場合、Mootools v1.2またはjQueryで動作することをどのように確認しますか?多くの開発時間を費やし、同じバグをいくつか抱えているか、使用しているフレームワークのために新しいバグを導入するのは残念です。

この時点でSlickspeedはまったく重要ではなくなり、セレクターはとにかく速すぎます。また、ご存知のように、Mootools開発チームのメンバーであるHerald KirschnerのSlyは、Sizzleに勝るセレクターエンジンであるSlyをリリースしました。アニメーションがポスターの1つによって残されたmootoolsを選択しないことを決定する要因であるということは、基本的に後向きでした。Mootoolsは、長年アニメーションの王様でした。どんなものを選んでも、すべて機能します。 Mootoolsにはもっと古典的な感覚があり、私は整理されていると思います。jQueryはより機能に基づいており、それほどクラスに進出していません。 1つはネイティブ型を補強し、もう1つは補強しません。異なる戦略ですが、それはそれです。

  • ダニエル

Mootoolsには非常に満足しています。最近ではjQueryを使用する人が増えているため、jQueryを試してみようと何度も誘惑されてきましたが、Mootoolsのような優れたOO機能はまだ得られません。 jQueryであまり気に入らないもう1つの点は、hashkey(#)を追加して、ドル関数でidを取得することです。フレームワークを使用してhtml idを作成する場合、これは問題になる可能性があります。私があなただったら、Mootoolsの最新バージョンにアップグレードしてください。 Mootoolsは決して悪いライブラリではありません。

質問で、「Ajax、ドラッグアンドドロップ、およびいくつかの小さな効果」のためにMooToolsを使用していると述べました。 Mootoolsはそれを上手く行うことができますが(私はこれを言うことで非難されるかもしれません)私の意見では、正しい理由でMootoolsを実際に使用しているわけではありません。アプリケーションでMootoolsを使用していますが、実際にはJQueryを代用することは考えられません。組織内の他のアプリケーションが活用できるオブジェクト指向の長期保守可能コードを作成することが目的の場合、Mootoolsが勝ち抜きます。

そして、セレクターの速度だけで判断するのは間違った基準です(ただし、Mootoolsは今そこにあると思います)。コードのほとんどの場所には、変更する要素への参照が既にあります。要素を取得したら、実際にDOMを操作するのにほとんどの時間がかかります。また、内部テスト(公開を試行します)では、Mootoolsは通常の種類の操作でJQueryよりもはるかに高速です。私たちのアプリケーションは、Webサービスから入ってくるデータを使用してアプリケーション画面を作成するために、以前に構築されたMootoolsコントロール(当社または他者によって構築された)に依存する種類です。

オーバーホールを行うプログラマー時間があるかどうかを評価します。
    そうすることは、コードを最初から書き直すことを意味します。これは、機能、レビュー、テスト、バグの修正などのサイクルを繰り返さなければならないことを意味します。JavaScriptにあまり適していないプログラマーの最も重要な問題の1つは、DOM要素にアクセスするコードのほとんどがメモリリークが発生する傾向があります(ほとんどのWeb開発者にとって高速道路の場合です)。本来、jQueryはこれを軽減するために多くのことを行います。または、jQueryはJavaScriptからJavaScriptを削除します。
    2番目。 jqueryに移行するより魅力的な理由の1つは、JavaScriptコードの重みが劇的に減少することです。これは、クライアント側のコード集中型ページにとって理にかなっています。 jqueryの簡潔な性質により、コードも簡単に確認できます。
    私が働いている会社(support.com)にはたくさんのMootoolsコードがありました。 2008年の初め(議論の白熱した時間の後-私はjQueryに移行することに反対していました)に、段階的にjQueryに移行し始めました。日付まで後悔していません。

この議論は退屈で、MootoolsはO-Oであるため、適切なO-Oバックグラウンドを形成する人々は、PHP4またはHTMLバックグラウンドの人々よりもその知性を高く評価しています。

このような移行を行うことができる唯一の説得力のある理由は、切り替えを行うことで、維持する必要のあるコードの量が減る場合、および/または物事が簡単になる場合です。通常、このような切り替えには多くの作業が含まれるので、すべての作業が完了した後に戻って、「はい、それは価値がありました」と言ってください。

アプリケーションの目的に基づいて、この選択を行う必要があります。

jQueryはアニメーションでは驚くほどクールですが、Mootoolsの方が洗練されていると感じているので、重要なのはアプリであり、アニメーションがMootoolsに固執するのではない場合

速度もこれに関する問題です。今日の時点で、Mootoolsのパフォーマンスはわずかに低下しますが、Mootools 1.3がリリースされるまでは注意を払っていません。

http://slicktest.perrohunter.com

で最新のフレームワークのパフォーマンスをチェックアウトします。

JQueryは、幅広いサポートを備えた小規模なコードベースです。それがあなたのニーズを満たすなら、それは良いスイッチかもしれません。判断する必要があるトレードオフは、移行の労力と学習曲線が、より広い機能セット、より小さいコードサイズ、人気、JQueryのサポートに対して努力する価値があるかどうかです。

MooToolsのバージョン間の変更が非常に急な場合は、移行が正当化される可能性があります。

jqueryvsmootoolsのWebサイトで参照されている記事は、非常にうまく書かれています。

  

jQueryがDOMを遊び場にする場合、MooToolsはJavaScriptを遊び場にすることを目指しています

したがって、ここでの答えと「それが壊れていないなら、それを修正しないでください」と、私はあなたのニーズに対処し、世論ではないことを言うでしょう。

サイトがすでにMootoolsにあることを考えると、MooToolsが提供していないjQueryが必要なものを提供しているかどうかを評価する必要があります。変換の手間が拡張機能を書く手間よりも小さいかどうか。

jQueryには、DOMをすぐに操作できる機能があるようですが、余分な凝ったものやその他の作業領域(Datesなど)にはプラグインが必要です。

これは私自身の質問にも答えるのに役立ちました!

重複しない領域がいくつかありますが、これは残念です。 GUIは、素敵なウィジェットとアニメーションでjQueryに簡単に組み込むことができます。 MooToolsは、機能が少なすぎるセットを持っているか、一般的なWeb使用には重すぎます。

ライセンス: CC-BY-SA帰属
所属していません StackOverflow
scroll top