12

私は、既存のライブラリや名前空間を侵害したり侵害されたりすることなく、主要なブラウザや多数の独立したサイトで安定して実行する必要があるカスタムの軽量 JavaScript ライブラリに取り組んでいます。おそらく最も重要なのは、ライブラリを軽量にする必要があることです (最大 15k まで)。

更新このような小さなライブラリの必要性を明確にするために: これは、サイトがページに組み込むサードパーティのサービスです。既存のライブラリ、速度、またはページの読み込みを制御できないため、すべてを可能な限り軽量、高速、自己完結型に保つ必要があります。15k は、サービスの動的コンテンツによってアクセスされるライブラリのみのターゲット数です。

この時点で、私の考えは、私が見つけることができる最も凝縮された jQuery のようなベースから始めて、カスタム モジュールで拡張することです。

望ましい機能:

  • チャンピオンのようにブラウザー間の不一致を処理します (IE 6 以降、Chrome、FF 2 以降、Safari 3 以降)。
  • イベント処理 (キューイング/バインディング/ブロードキャスト)
  • 効率的なセレクター エンジン
  • 連鎖
  • 基本的なアニメーションを使用した DOM 操作
  • モジュールから簡単にビルドおよびバージョン管理可能

私はEnderJSとMicroJSに出くわしましたが、どちらについても多くの議論を見つけることができないようです。7.5k の重さの "The Jeesh"を使用して、上記のすべての機能にほとんど箱から出して対処しているように見えるので、この時点で Ender に慣れ親しみ、興味を持っています。いくつかの追加パッケージを追加しても、私の場合は 10k にプッシュされるだけです。これは、カスタム モジュールを肉付けするのに数 k しか必要ないため、完璧です。また、ビルド時にメイン ライブラリに組み込んで圧縮できる個別のモジュールを記述およびバージョン管理できるようになり、一意の名前空間を定義してすべてをまとめて保持し、できれば保護することもできます。Ender ライブラリのもう 1 つの魅力的な要素は、NodeJSの使用です。とにかくもっと遊んでみたいです。しかし、そうは言っても、私はまだ他のアイデアを広く受け入れています。

だから私の質問は：

EnderJSまたはMicroJSの経験がある人、または私が達成しようとしていることに対する別のソリューション/アプローチを持っている人はいますか? ここが「おしゃべりで自由回答形式の質問」をする場所ではないことは理解していますし、それは私の意図ではありません。一からやり直さずに軽量のカスタム ライブラリを構築し、代わりに利用可能な最新のマイクロ ライブラリにプラグインする最善の方法についての提案を探しています。

4

3 に答える 3

16

私は Ender の共同作成者の 1 人で、Fazal の言葉を +1 します。

Jeesh に関するメモは、Ender の優れたスターター パックではありますが、真の力は、増え続けるモジュール セットで Ender を拡張する機能にあります。ここで確認できます: https://github.com/ender-js/Ender/wiki/Ender-package-list

どういうわけか、Ender は「マイクロ ライブラリ」開発の最前線になりましたが、実際に私たちが求めているのは、疎結合されたモジュール (モジュールの大小にかかわらず) にまとまりのあるインターフェイスを配置することです。jQuery は、そのセレクター エンジン (Sizzle) を抽象化する最初の大きな一歩を踏み出しましたが、残念ながら残りの部分 (dom、events、animation、ajax、utils、promise) は相互に依存しているため、必要なものを選択して取得することはできません。

余談ですが、Ender の優れた点の 1 つは、モジュールを NPM に公開し、それらをプロジェクトに移植by nameできることです。build only what you need, when you need it

http://enderjs.com/learnにある学習ビデオをチェックする価値はあります。これにより、パッケージがどのように作成、構築、および使用されるかをよりよく理解できます。Ender を環境にセットアップするのは非常に簡単で、実際に作業するのがとても楽しいことがわかります。

ご不明な点がございましたら、@ded または @fat までお知らせください。喜んでお手伝いさせていただきます。

于 2011-07-06T00:59:21.327 に答える
12

私は最近 Ender を使用しましたが、特に問題はありませんでした。最初から使用できない jQuery 関数がいくつかありますが、JavaScript にかなり慣れている人なら誰でもこれを回避できます。特に、Ender の構造と拡張方法は jQuery とほぼ同じであるという事実を考えると。

私は最近ライブ サイトで Ender を使用しましたが、おかしなことに、microjs.com のいくつかのスクリプトを自分の関数ファイルと一緒に使用しました。すべての JavaScript の重量は約 15k でした。サイト コード全体の重量をそれ以下にすることは難しくありません。

たとえば、Jeesh から始めて、Ender の軽量バージョンを構築するだけでなく、非同期読み込みを検討することもできます。例は、Dustin Diazによって提供されています。

<script src="ender.min.js"></script>

<script>
$.require('/js/core.min.js', 'core')

$.ready('core', function () {
  $(document).ready(function () {
    $('<p>hello world</p>').appendTo('body')
      .bind('click', function (e) {
        $.require('/js/ajax.min.js', function () {
          $(e.target).css('position', 'relative')
            .animate({
              left: 500
            })
        })
      })
  })
})
</script>

これを行うことで、本質的に元のエンダー ビルドをさらに軽くし、ロードの一部を延期することができますが、一般的に言えば、そもそも軽い場合は問題ありません。

ender と一緒にサイト コードをコンパイルするために、Ender がアクセスできる Google クロージャ コンパイラを利用することもできます。

最後に、おそらくご存知のように、Ender で noConflict を実行することもできます。これは、既に別のライブラリが存在する場合に備えてです。

Ender をビルドして構成するときは、おそらく API ビューのようなものを提供するender-walletを利用したいと思うでしょう。これにより、まったく必要のないライブラリを削除できます。

ホットリンクされたスクリーンショット:
スクリーンショット

于 2011-07-04T15:39:54.220 に答える
4

これを考えると：

このような小さなライブラリの必要性を明確にする: これは、サイトがページに組み込むサードパーティのサービスです。既存のライブラリ、速度、またはページの読み込みを制御できないため、すべてを可能な限り軽量、高速、自己完結型に保つ必要があります。15k は、サービスの動的コンテンツによってアクセスされるライブラリのみのターゲット数です。

CDN の 1 つ (Google または Microsoft。Google のほうがよく使われていると思いますが、テストする必要があります) を介して、デマンド ロードされた jQuery を使用することをお勧めします。コードは、jQuery が既にロードされているかどうかを検出し、ロードされている場合 (~0k) を使用し、ロードされていない場合はscript要素を動的に追加して、CDN からプルします。ユーザーがその CDN から jQuery を使用して他のサイトにアクセスした場合、スクリプトはキャッシュ (~0k) から取得される可能性があります。そうでない場合は、最大 15,000 ヒットではなく、最大 31,000 のヒットがありますが、ヒットがないか、CDN からの「変更されていない」応答のヒットだけになることがよくあります。

サイトがjQuery以外のものnoConflictを使用している場合に備えて、ロードした場合は呼び出しを発行する必要があります。これは、要素のイベントを監視し ( IE で使用し、いずれかまたはステータスを監視する必要があります)、それが発生したときにそれを実行することで$簡単に実行できます。loadscriptreadystatechangeloadedcomplete

今日の電気通信の世界では、15k のダウンロードと 31k のダウンロードの違いは、最初に HTTP 接続をセットアップするコストに比べれば些細なことです。

そのデマンド ロードは、次の行に沿って、実際にはほんの少しのコードです。

function loadJQuery(cb) {
    var d, s, t;

    if (typeof jQuery === "function"
        && parseFloat(jQuery.fn.jquery) >= 1.5) { /* Or whatever */
        window.ourjQuery = jQuery;
        if (cb) {
            cb();
        }
        return;
    }

    d = document;
    s = d.createElement('script');
    t = d.body || d.getElementsByTagName('head')[0] || d.documentElement;

    s.onload = loaded;
    s.onreadystatechange = handleReadyStateChange;
    s.src = "//ajax.googleapis.com/ajax/libs/jquery/1/jquery.min.js";
    t.appendChild(s);

    function loaded() {
        if (s) {
            s = undefined;
            window.ourjQuery = jQuery.noConflict(true);
            if (cb) {
                cb();
            }
        }
    }

    function handleReadyStateChange() {
        if (s && (s.readyState === "loaded" || s.readyState === "complete")) {
            loaded();
        }
    }
}

script要素の URL に注意してください。httpこれは、とhttpsページ ( details )の両方に優しいためです。また、jQuery の最小バージョンを確認し、より厳密な形式のnoConflictif we load を使用していることにも注意してください。いずれにしても、コールバックが呼び出されるまでに、ourjQueryシンボルは読み込まれたコピーを最小バージョンで参照します。

更新：上記のコメントへの対処：

それは良い考えですが、残念ながら私たちにとって実際には選択肢ではありません。Google の CDN の jQuery がキャッシュされる可能性が高く、負荷を節約し、必要に応じてチェックおよび拡張できることに同意しますが、自分で提供するほどスケーラブルまたは安定していないようです。サイトは、ニーズに合わせて jQuery モジュールを上書きするか、さらに悪いことを決定する可能性があります。私たちが必要としているのは、完全に制御でき、必要に応じて拡張および分岐できる軽量の自己完結型ライブラリです。目標は、このライブラリがキャッシュされ、CDN からバージョン管理されることです。

はい、基本的な jQuery 機能が変更されたサイトのわずかなリスクがあります。非常に小さなリスクです。コア API (プラグインなどではない) に制限している場合、率直に言って、心配する価値はないと思います。

しかし、それについて心配している場合は、率直に言って、独自の CDN でホストされている、わずかに変更された jQuery を、別のシンボルを使用しjQueryて (まったく使用せず$に) 使用するだけです。今日の電気通信の世界では、31k 対 15k は問題ではありません。主なコストは、最初に接続を確立することです。必要に応じて、必要のない部分を削除することで、おそらくそれを少し減らすことができますが、悲しいことにjQueryの内部は少し厄介であり、機能を選択的に削除することは簡単ではない場合があります(機能によって異なります)。

于 2011-06-28T05:32:38.543 に答える