Пользовательские легкие библиотеки JavaScript: EnderJS и MicroJS

Ответ 1

Недавно я использовал Эндера, и у меня не было никаких проблем с ним. Есть несколько функций jQuery, которые недоступны с отключением, но любой, кто достаточно разбирается в JavaScript, может обойти это. Особенно учитывая тот факт, что Эндер имеет почти идентичную структуру и способ расширения как jQuery.

Недавно я использовал Ender на живом сайте и довольно забавно. Я использовал пару скриптов из microjs.com вместе со своим собственным файлом функций, а весь JavaScript весил около 15 тысяч. Это не сложно сделать весь код вашего сайта весом вокруг или меньше.

Помимо создания облегченной версии Ender, например, начиная с Jeesh, вы также можете рассмотреть загрузку async, например, Dustin Диас:

<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 более легкой и отложить часть загрузки, но, вообще говоря, если она загорается в первую очередь, вы должны быть в порядке.

Вы также можете воспользоваться компилятором Google закрытия, который дает вам доступ к Ender, чтобы скомпилировать код вашего сайта вместе с ender.

Наконец, как вам хорошо известно, вы также можете делать noConflict в Ender, на всякий случай, если у них уже есть другая библиотека.

По мере создания и настройки Ender вы, вероятно, захотите воспользоваться ender-wallet, который предоставит вам вид API, позволяющий вы можете удалить библиотеки, которые вам могут не понадобиться.

hotlinked screenshot:

Ответ 2

Я один из соавторов Эндера, и я добавлю слова Фейзала.

Заметка о Jeesh, хотя и хорошая стартовая пачка для Эндера, истинная сила заключается в возможности расширения Ender с его растущим набором модулей. Вы можете проверить их здесь: https://github.com/ender-js/Ender/wiki/Ender-package-list

Так или иначе, так или иначе, Эндер стал авангардом развития "микробиблиотеки", но на самом деле то, что нам нужно, это установить сплоченный интерфейс на слабосвязанные модули (как бы они ни были большими или малыми). jQuery сделал отличный первый шаг в абстрагировании своего движка селектора (Sizzle), но, к сожалению, остальная часть его взаимозависима (dom, события, анимация, ajax, utils, promises), что делает невозможным выбор и удаление того, что вы хотите.

С другой стороны, одна из опрятных вещей об Ender - это возможность публиковать модули в NPM и возможность переносить их в ваш проект by name, позволяя вам build only what you need, when you need it

Стоит проверить учебные видеоролики на http://enderjs.com/learn, который даст вам лучшее представление о том, как создавать, создавать и использовать пакеты, Вы обнаружите, что настройка Ender в вашу среду чрезвычайно проста и на самом деле довольно забавная для работы.

Давайте (@ded или @fat) узнаем, есть ли у вас какие-либо вопросы, и мы будем более чем готовы помочь разобраться в вещах

Ответ 3

Учитывая это:

Чтобы прояснить необходимость в такой небольшой библиотеке: это сторонняя служба, которую сайты будут вставлять на свою страницу. Нам нужно держать все как можно легким, быстрым и самодостаточным, поскольку мы не можем контролировать существующие библиотеки, скорость или загрузку страницы. 15k - это номер цели только для библиотеки, к которой обращается динамический контент службы.

Я бы рекомендовал использовать загруженный jQuery через один из CDN (Google или Microsoft, я думаю, Google используется больше, но вы хотите протестировать). Ваш код может определить, уже загружен ли jQuery и использовать его, если это так (~ 0k), и если не добавить элемент script динамически, который вытаскивает его из CDN. Если пользователь посетил какой-либо другой сайт, используя jQuery из этого CDN, то script может исходить из кеша (~ 0k). Если нет, то у вас есть ~ 31k, а не ~ 15k, но опять же, довольно часто у вас не будет никакого удара или просто хита "не измененного" ответа от CDN.

Вы хотите выпустить вызов noConflict, если вы его загрузили, если сайт использует $ для чего-то другого, кроме jQuery. Это легко сделать, наблюдая за событием load в элементе script (вы должны использовать readystatechange в IE и следить за статусом loaded или complete), а затем делать это, когда это произойдет.

В сегодняшнем мире телекоммуникаций разница между загрузкой 15 тыс. и загрузкой 31 тыс. тривиальна по сравнению с затратами на настройку 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();
        }
    }
}    

Обратите внимание на URL-адрес элемента script. Это так удобно для страниц http и https (details). Также обратите внимание, что я проверяю минимальную версию jQuery и использую более строгую форму noConflict, если мы ее загрузим. В любом случае, к моменту вызова обратного вызова символ ourjQuery относится к загруженной копии с минимальной версией.

Обновить. Адресация вашего комментария выше:

Это хорошая идея, но, к сожалению, для нас это не вариант. Я согласен с тем, что jQuery из Google CDN, скорее всего, будет кэшироваться - сэкономить нагрузку - и что мы можем проверять и расширять по мере необходимости, но он не кажется масштабируемым или стабильным, как его обслуживание. Сайт может решить перезаписать некоторый модуль jQuery в соответствии с их потребностями или хуже. Нам нужна легкая автономная библиотека, которую мы полностью контролируем и можем расширять и разветвлять по мере необходимости. Цель состоит в том, что эта библиотека будет кэшироваться и версироваться с нашего CDN.

Да, существует небольшой риск того, что сайт изменил базовую функциональность jQuery. Малый риск очень. Если вы ограничиваете себя основным API (а не плагинами и т.д.), Я откровенно не думаю, что это стоит беспокоиться.

Но если вы беспокоитесь об этом, то, честно говоря, я просто использовал слегка измененный jQuery, размещенный на вашем собственном CDN, используя другой символ, чем jQuery (и вообще не используя $). 31k против 15k в современном мире телекоммуникаций - не проблема; первичная стоимость будет заключаться в установлении соединения в первую очередь. Если бы вы захотели, вы могли бы немного поработать, удалив ненужные части, хотя, к сожалению, внутренняя часть jQuery немного борется и выборочно удаляет функциональность, возможно, не тривиальна (в зависимости от ее функциональности).