Рубрика «CommonJS»

Эволюция модульного JavaScript - 1

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

Не будем лукавить: JavaScript никогда не был идеальным языком программирования. Одним из слабых мест в JS была модульность, а точнее её отсутствие. Действительно, зачем в скриптовом языке, который анимирует падающие на странице снежинки и валидирует форму, заботиться об изоляции кода и зависимостях? Ведь всё может прекрасно жить и общаться между собой в одной глобальной области — window.

С течением времени JavaScript трансформировался в язык общего назначения, так его начали использовать для построения сложных приложений в различных средах (браузер, сервер). При этом нельзя было положиться на старые подходы взаимодействия компонентов программы через глобальную область: с ростом объёма кода приложение становилось очень хрупким. Как результат для упрощения процесса разработки создавались различные реализации модульности.

Эта статья появилась в результате общения с участниками TC39 и разработчиками фреймворков, а также чтения исходных кодов, блогов и книг. Мы рассмотрим следующие подходы/форматы: Namespace, Module, Detached Dependency Definitions, Sandbox, Dependency Injection, CommonJS, AMD, UMD, Labeled Modules, YModules и ES2015 Modules. Кроме того, мы восстановим исторический контекст их появления и развития.
Читать полностью »

Привет,

Javascript и Front-end в целом становятся все сложнее и сложнее. На мой взгляд, стандартная поставка Rails не отвечает современным потребностям Front-end разработчика. К тому же использование Sprockets делает ваш код очень Rails-специфичным, что затрудняет он-бординг новых разработчиков, незнакомых с Rails.

В данном видео, на примере простого React.js приложения, я покажу, как можно мигрировать со Sprockets на Browserify.

Этот подход дает следующие бонусы:

  • Управление зависимостями Javascript пакетов через npm;
  • Лучший туллинг и интеграция с IDE;
  • Уменьшение связности фронтенда и бекенда;
  • Читать полностью »

Содержание

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

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

Мастер-программист знает, когда нужна структура, а когда нужно оставить вещи в простом виде. Его программы словно глина – твёрдые, но податливые.

Мастер Юан-Ма, Книга программирования

У каждой программы есть структура. В частностях она определяется тем, как программист делит код на функции и блоки внутри этих функций. Программисты вольны в создании структуры своей программы. Структура определяется больше вкусом программиста, нежели функциональностью программы.

В случае больших программ отдельные функции уже теряются в коде, и нам необходима единица организации кода больших масштабов. Модули группируют программный код по каким-то определённым признакам. В этой главе мы рассмотрим преимущества такого деления и техники создания модулей в JavaScript.
Читать полностью »

Еще одна? Зачем? Есть же 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