От переводчика: Давид Хейнемейер Ханссон написал небольшой текст о том, почему он и его команда Ruby on Rails разработала свой собственный Javascript фреймворк. Оригинал текста размещен в репозитории нового проекта

обновлено 4 февраля: оригинал статьи был официально опубликован в блоге Basecamp. Обновил ссылку на оригинал и название

Мы пишем много Javascript в Basecamp, но мы не используем его для создания "JavaScript-приложений" в современном смысле. Все наши приложения рендерят HTML на стороне сервера, затем мы добавляем вкрапления Javascript, чтобы оживить их.

Это путь величественного монолита. Basecamp работает на множестве платформ, включая нативные мобильные приложения, с единым набором контроллеров, представлений и моделей, созданных под Ruby on Rails. Иметь общий интерфейс, который обновляется из единого места, — это ключ к тому, чтобы маленькая команда работала хорошо, несмотря на множество поддерживаемых платформ.

Это позволяет нам быть продуктивными, как и в старые добрые времена. Возвращение к тем дням, когда единственный программист мог обеспечить немалый прогресс, не застревая в слоях абстракций распределенных систем. Время до того, как каждый стал думать, что святым граалем является ограничение серверной стороны до только лишь производства JSON для Javascript-приложений на клиенте.

В течение нескольких последних месяцев мы тихо работали надо новым проектом. Сегодня я готова анонсировать Dart Sass всему миру. Это абсолютно новая реализация Sass, созданная, чтобы быть быстрой и легкой в установке и разработке. Она еще не завершена — я веду работу по приведению её в соответствие со спецификацией Sass — так что сегодня я просто публикую версию 1.0.0-alpha.1. Но она достаточно надежна, чтобы можно было скачать, поиграться с ней и начать сообщать баги.

Довольно часто приходится слышать, что React и особенно JSX-шаблоны – это плохо, и хороший разработчик так не делает. Однако нечасто объясняется, чем именно вредит смешивание верстки и шаблонов в одном файле. И с этим мы попробуем сегодня разобраться.

Подход "каждой технологии свой файл" использовался с начала существования веба, поэтому неудивительно, что слом этого шаблона вызывает отторжение некоторых разработчиков. Но перед тем, как заявлять "нет, мы так делать не будем никогда", будет полезно разобраться истории и понять, почему JSX пользоваться можно, а смешивать скрипты и html – нет.

Во всех современных системах сборки фронтенда есть режим watch, при котором запускается специальный демон для автоматической пересборки файлов сразу после их сохранения. Также он есть и gulp.js, но с некоторыми особенностями, делающими работу с ним немного сложней. Работа gulp.js основана на обработке файлов как потоков данных (streams). И ошибки в потоках не всегда можно перехватить, а когда ошибка случается, то будет выброшено неперехваченное исключение и процесс завершится.

Чтобы этого не происходило, и watcher мог игнорировать отдельные ошибки и запускаться снова и снова при сохранении файлов, в gulp нужно сделать несколько дополнительных настроек, о которых и расскажется в этой статье.

В прошлой части мы написали небольшую библиотеку, пожожую на require.js и позволяющую загружать AMD-модули. Настало время расширить ее возможности и сделать из нее полноценную замену оригинального require.js. Поэтому сегодня мы реализуем возможность настройки, аналогичную функции require.config() и поддержку плагинов, чтобы все дополнения к обычному require.js работали и здесь.

Чтобы не иметь проблем с зависимостями и модулями при большом количестве браузерного javascript, обычно используют require.js. Также многие знают, что это всего лишь один из многих загрузчиков стандарта AMD, и у него есть альтернативы. Но мало кто знает, как они устроены внутри. На самом деле, написать подобный инструмент не сложно, и в этой статье мы шаг за шагом напишем свою версию загрузчика AMD. Заодно разберемся с Promise, который недавно появился в браузерах и поможет нам справиться с асинхронными операциями.

Основой require.js, является функция require(dependencies, callback). Первым аргументом передаем список модулей для загрузки, а вторым – функцию, которую вызовут по окончании загрузки, с модулями в аргументах. Используя Promise написать её совсем несложно:

function require(deps, factory) {
  return Promise.all(deps.map(function(dependency) {
    if(!modules[dependency]) {
      modules[dependency] = loadScript(dependency);
    }
    return modules[dependency];
  }).then(function(modules) {
    return factory.apply(null, modules);
  });
}

Конечно, это еще не всё, но основа есть. Поэтому продолжим.

Привет, меня зовут Борис. Я работаю в Яндексе в отделе тестирования и создаю инструменты, которые позволяют сделать жизнь наших тестировщиков проще и счастливее. Наша команда отчасти исследовательская, поэтому мы можем позволить себе использовать довольно необычные инструменты и эксперименты. Недавно я рассказал своим коллегам об одном из таких экспериментов: Gulp.js. Сегодня я хотел бы поделиться этим опытом с вами.



Для начала немного предыстории, о том, как развивались веб-технологии. В начале не было фронтенда как отдельного понятия, большая часть логики выполнялась на сервере. Поэтому разнообразные задачи по сборке скриптов и стилей, а также подготовка картинок, шрифтов и других ресурсов выполнялись бэкэндом, и их сборщиками, например, Apache Ant или Maven. Фронтенд оказывался в невыгодном положении, инструменты, предоставляемые этими сборщиками не очень подходили для него. Эту проблему начали решать только недавно, когда появился Grunt. Это первый сборщик, написанный на JS. Каждый фронтендер знает JavaScript, поэтому может без проблем писать задачи под Grunt и разбираться в уже написанных. Это и обусловило успех этого сборщика. У Grunt есть куча преимуществ, но есть и недостатки.

Используя ExtJS в своих проектах, приходится постоянно видеть один и тот же сине-голубой интерфейс, что не всегда хорошо. В 4й версии этого фреймворка появился удобный компонент для изменения внешнего вида вашего веб-приложения без ручной правки CSS, основанный на использовании метаязыка SASS. С его помощью можно получить интерфейс, внешне не похожий на стандартный, заменив всего пару строк в конфигурационном файле.