Метка «CommonJS»

Еще одна? Зачем? Есть же CommonJS и AMD? Страждующие могут пройти под кат.
Читать полностью »

Загрузка CommonJS модулей в браузер без изменения исходного кода

Однажды, сидя за компьютером и обдумывая свою очередную никчемную затею, я внезапно понял, что мне нужен способ использовать один и тот же код на стороне браузера и на стороне сервера. Я почти сразу же догадался, что наверняка я не первый такой умный, и все давно придумано за меня — и не ошибся.

Действительно, под мои требования замечательно подходил, например, RequireJS с его адаптером для Node.js, которые какое-то время с успехом удовлетворяли мои прихоти, пока меня опять не осенила гениальная мысль: «Почему я вынужден использовать кашу из двух совершенно различных форматов модулей в одном проекте? Нужно все унифицировать!».

И опять ответ не заставил себя долго ждать, нашелся миллион браузерных реализаций CommonJS модулей: и всевозможные склейщики скриптов, и серверные препроцессоры, и синхронные загрузчики, и асинхронные — все, что душе угодно. Но все они оказались с одним очень важным недостатком. Они так или иначе изменяли исходный код скриптов и делали очень неудобным процесс их отладки в браузерных инспекторах.Читать полностью »

Hello World,

Helios Kernel — это библиотека для управления зависимостями между javascript-модуями, реализующая «классический» подход, часто встречаемый в других языках и средах — с помощью функции include().

Такой способ отличается от других подходов своей простотой: зависимости перечисляются в начале модуля по точному пути к файлу, тело модуля содержит код, который выполняется после загрузки зависимостей модуля.

Helios Kernel придерживается принципа KISS, поэтому здесь отсутствуют некоторые возможности, которые сегодня принято ожидать от библиотеки по управлению зависимостями. При использовании Helios Kernel не нужно описывать конфиг с правилами поиска путей для разных модулей, или экспортировать библиотечные функци через специальный объект. Но эта библиотека была написана как раз потому, что хотелось просто подключать нужные модули и писать код, не натыкаясь на крутые возможности при указании каждой новой зависимости.

Helios Kernel поддерживает динамическую загрузку (и выгрузку) зависимостей в рантайме, а сама библиотека и формат модулей являются совместимыми между nodejs и броузерной средой — то есть модули можно использовать без изменений или трансляции.

В этой статье классический подход реализованный в Helios Kernel сравнивается с управлением зависимостями с помощью RequireJS и показывается, каким образом подход Helios Kernel позволяет избежать некоторых сложностей.

Читать полностью »

Hello World,

Helios Kernel — это библиотека позволяющая описывать зависимости между javascript-модулями «в стиле include»:

// объявление зависимостей
include("path/to/library1.js");
include("../path/to/another/library2.js");

init = function() {
    // использование зависимостей
    library1.doSomething();
    ...
}

Я уже писал про Helios Kernel раньше, с тех пор проект переехал на гитхаб, а поводом к новому релизу стал тот факт, что весь платформо-зависимый код был выделен, и после некоторого допиливания тесты наконец прошил и под nodejs:

Helios Kernel — include в джаваскрипте, теперь и для nodejs

Поэтому теперь я могу написать здесь про библиотеку громкое слово «кроссплатформенная»

Читать полностью »

В последнее время я стал много писать на JS, сейчас работаю над сложным приложением и довольно крупной библиотекой (~5K SLoC). Конечно же, я столкнулся с проблемой модульности.

Для приложения идеально подошел AMD — указываешь в зависимостях библиотеки, добавляешь связующий код, логику… и приложение готово. Но при разработке библиотеки я столкнулся с проблемой управления внутренними зависимостями при помощи AMD или CommonJS — получается слишком много обвязок (boilerplate), особенно когда части библиотеки взаимозависимы. Поэтому я выделил еще один подход к определению модулей в JS — YAMD.

Внимание! Это не замена AMD или CommonJS, для сборки приложения я по прежнему использую AMD, просто одна из библиотек, которую я подключаю, собрана с помощью YAMD. Таким образом, YAMD является подходом к декомпозиции сложной библиотеки без внешних зависимостей на части и отдельные файлы, и инструментом для сборки этих файлов воедино.

В статье я опишу подход. От вас хочется узнать в комментариях, что вы используете для тех же задач.Читать полностью »

Если вы пользуетесь stitch и вам его маловато, а browserify показался сложноват по настройкам — попробуйте clinch.

Что в коробке:

  • простой API
  • поддержка .js, .json, .coffee, .eco, .jade
  • develop-mode ready — легко встроить в express, умный кеш с инвалидацией
  • малый overhead на bundle ~ 40 SLOC
  • простой механизм подмены модулей и имитации глобальных объектов

Читать полностью »

Twitter объявил об очередной смене архитектуры: рендеринг страниц теперь будет осуществляться на стороне сервера, а не на стороне клиента.

После прошлой модернизации в сентябре 2010 года весь рендеринг UI и логику переложили на JavaScript на клиентской стороне. Браузеры напрямую обращались к Twitter REST API, как и мобильные клиенты. Хотя такой подход помог реализовать ряд преимуществ, но разработчики потеряли возможности оптимизации, которые доступны при серверно-ориентированном подходе. В результате, пользователи начали жаловаться на субъективное «подтормаживание» страниц twitter.com.

На этой неделе новую архитектуру выкатили для статичных ссылок (пермалинков). Как показали тесты, скорость загрузки страницы в браузер пользователя выросла в среднем в пять раз, а также значительно сократился разрыв между различными браузерами, которые по-разному справляются с JavaScript.
Читать полностью »


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js