Старые версии IE были главным препятствием в использовании пикселей, поскольку те браузеры не позволяли пользователям нормально менять масштаб страницы. Современные браузеры отлично справляются с масштабированием страницы, свёрстанной в любых единицах размеров.
CSS — это высокоуровневый язык, где мы работаем с логическими пикселями, что гарантирует предсказуемость указываемых размеров на экранах с любой плотностью физических пикселей. Суть хорошо видна на иллюстрации:
Указание размеров интерфейсных элементов в относительных единицах отличается плавным изменением всей вёрстки при любом, даже самом небольшом изменении размеров окна браузера. Использование фиксированных размеров, конечно, вносит свои ограничения, но взамен мы получаем больший контроль над дизайном. Выбор единиц размеров зависит от дизайнерской задумки.
Упоминание эмулятора важно для читателей, которые могут не знать о доступном способе проверки вёрстки под произвольные размеры окна браузера.
Действительно, эмуляция существует уже давно и в статье приведён скриншот Яндекс.Браузера, но подразумевается, что аналогичный эмулятор есть во всех браузерах, реализация которых базируется на Chromium. Конечно, аналогичные эмуляторы есть и в других браузерах, например в Firefox.
Большинство задач адаптивной вёрстки решаются достаточно простыми легковесными техниками, овладение которыми будет ценным навыком для любого разработчика интерфейсов. Несмотря на это, существует большое количество инструментов, привносящих универсальные конструкции для облегчения рутины команды из нескольких разработчиков. Кажется, что упоминание таких инструментов полезно для полноты статьи.
Дело в том, что эти термины имеют достаточно размытое понятие.
Вы, вероятно, подразумеваете доступность интерфейса в зависимости от технических возможностей браузера. Здесь же речь идёт о наборе интерфейсных возможностей, которые могут быть доступны в зависимости от размеров экрана устройства.
Грубо говоря, на большом экране настольного компьютера может уместиться значительно больше кнопок, нежели в мобильном телефоне.
Это же абстрактный пример. К тому же использование browserify сводится к тому же самому.
Сборка указанного модуля приведёт к получению файла, содержащего все модули, необходимые для его работы. Если надо собрать несколько модулей, то можно make module1 module2 ... moduleN.
Думаю, что подавляющее большинство разработчиков не собирает библиотеки по частям, а просто скачивают собранный файл в один клик.
Но если хочется кастомно собрать проект из необходимых модулей, то с помощью definer можно сделать и это. А какую команду для сборки вы будете использовать, уже не так важно, хоть grunt, хоть make, или npm run-script и так далее.
Definer предназначается в первую очередь для разработки библиотек и инструментов для разработчиков.
Когда вы предоставляете другому разработчику библиотеку, важно, чтобы там не было ничего лишнего, а вырезать куски кода регулярными выражениями, как это делает jQuery мне кажется дикостью.
definer('a', function() { return 'a'; });
definer('b', function() { return 'b'; });
definer('c', function(a, b) { return a + b + 'c'; });
Собранный файл (206 символов):
(function(global, undefined) {
var a = (function () { return 'a'; }).call(global),
b = (function () { return 'b'; }).call(global),
c = (function (a, b) { return a + b + 'c'; }).call(global, a, b);
})(this);
Да, в результирующем файле собирается содержимое модулей в нужном порядке, но отсутствует вызов методов definer и их реализация.
Получается, что модулей в виде модулей нет и можно поставлять приложение из чистого кода.
1) Эта ошибка описана для ясности, в жизни же не предполагается такое использование системы, а зависимости нормально разрешаются при сборке.
2) В девелопменте с помощью грант-плагина можно автоматизировать сборку и добавить минификацию с помощью grunt-contrib-uglify, например.
Мне definer нужен в первую очередь для того, чтобы писать инструменты с разбивкой по модулям и автоматически собирать единый файл без модулей, который легко сможет использовать кто-то другой.
CSS — это высокоуровневый язык, где мы работаем с логическими пикселями, что гарантирует предсказуемость указываемых размеров на экранах с любой плотностью физических пикселей. Суть хорошо видна на иллюстрации:
Указание размеров интерфейсных элементов в относительных единицах отличается плавным изменением всей вёрстки при любом, даже самом небольшом изменении размеров окна браузера. Использование фиксированных размеров, конечно, вносит свои ограничения, но взамен мы получаем больший контроль над дизайном. Выбор единиц размеров зависит от дизайнерской задумки.
Действительно, эмуляция существует уже давно и в статье приведён скриншот Яндекс.Браузера, но подразумевается, что аналогичный эмулятор есть во всех браузерах, реализация которых базируется на Chromium. Конечно, аналогичные эмуляторы есть и в других браузерах, например в Firefox.
Вы, вероятно, подразумеваете доступность интерфейса в зависимости от технических возможностей браузера. Здесь же речь идёт о наборе интерфейсных возможностей, которые могут быть доступны в зависимости от размеров экрана устройства.
Грубо говоря, на большом экране настольного компьютера может уместиться значительно больше кнопок, нежели в мобильном телефоне.
Для этого действительно лучше использовать какую-то реализацию CommonJS.
Definer задуман для другого применения.
Сборка указанного модуля приведёт к получению файла, содержащего все модули, необходимые для его работы. Если надо собрать несколько модулей, то можно
make module1 module2 ... moduleN
.make modulename
?Спросите у разработчиков jQuery, зачем они вырезают из собранного файла всё про RequireJS.
Но если хочется кастомно собрать проект из необходимых модулей, то с помощью definer можно сделать и это. А какую команду для сборки вы будете использовать, уже не так важно, хоть grunt, хоть make, или npm run-script и так далее.
Когда вы предоставляете другому разработчику библиотеку, важно, чтобы там не было ничего лишнего, а вырезать куски кода регулярными выражениями, как это делает jQuery мне кажется дикостью.
Definer.
Модули:
Собранный файл (206 символов):
Browserify.
Модули:
Собранный файл (828 символов):
Очевидно, файл, собранный с помощью definer работает быстрее и его проще отлаживать.
Получается, что модулей в виде модулей нет и можно поставлять приложение из чистого кода.
Хорошая идея, но при этом надо обдумывать детали.
Он всегда конкатенирует модули в один файл и не работает с HTML.
2) В девелопменте с помощью грант-плагина можно автоматизировать сборку и добавить минификацию с помощью grunt-contrib-uglify, например.
Мне definer нужен в первую очередь для того, чтобы писать инструменты с разбивкой по модулям и автоматически собирать единый файл без модулей, который легко сможет использовать кто-то другой.
Если пришлёте пулреквест с документацией на английском — буду сильно благодарен :)