Интервью подкасту RadioDotNet об истории создания проекта JavaScript Engine Switcher

Кадр из 5-й серии 2-го сезона сериала «Молодой Скала»

Иногда авторы популярных open source-проектов долгое время остаются в тени своих творений. Проекты могут иметь миллионы скачиваний, сотни звезд на GitHub и о них могут быть написаны десятки статей, но имена их авторов остаются неизвестными широкой публике. Все это относится и к моему проекту JavaScript Engine Switcher.

Проект WebMarkupMin участвует в конкурсе «Open Source-трибуна»

Мой проект WebMarkupMin участвует в конкурсе «Open Source-трибуна», который проходит в рамках конференции HighLoad++ Foundation 2022. Вы можете проголосовать за него на сайте конференции, используя свой аккаунт Онтико, Facebook или ВКонтакте. Принимается только один голос.

UPD1: 26 февраля 2022 года конкурс был завершен.

Что нужно знать о JavaScript Engine Switcher 3.0

JavaScript Engine Switcher изначально создавался как вспомогательная библиотека и его развитие во многом определялось потребностями библиотек, которые его использовали. Фактически каждая его мажорная версия решала одну или несколько крупных задач необходимых для дальнейшего развития других библиотек:

1. В первой версии такой задачей было добавление как можно большего количества модулей-адаптеров для популярных JS-движков, поддерживающих платформу .NET. И это дало пользователям Bundle Transformer определенную гибкость: на компьютерах разработчика они могли использовать модуль MSIE, поддерживающий отладку JS-кода с помощью Visual Studio, а на серверах, на которых не было современной версии Internet Explorer или он не был установлен вовсе, они могли использовать модуль V8. Некоторым даже удавалось запускать Bundle Transformer в среде Mono на Linux и Mac, используя модули Jurassic и Jint.
2. Основной задачей второй версии была реализация поддержки .NET Core, которая требовалась для новой версии библиотеки ReactJS.NET. Другой немаловажной задачей было создание кроссплатформенного модуля, способного быстро обрабатывать большие объемы JS-кода (модули Jurassic и Jint не подходили для этого), и таким модулем, после ряда доработок, стал модуль ChakraCore.
3. В третьей версии основной акцент был сделан на улучшение интеграции с библиотекой ReactJS.NET и повышение производительности.

В этой статье мы рассмотрим некоторые нововведения третьей версии, которые для многих оказались неочевидными даже после прочтения текста релиза и раздела документации «How to upgrade applications to version 3.X»: изменения в классе JsEngineSwitcher, реорганизация исключений, более информативные сообщения об ошибках, прерывание и предварительная компиляция скриптов, возможность изменения максимального размера стека в модулях ChakraCore и MSIE, а также новый модуль на основе NiL.JS.

Доклад «WebMarkupMin – HTML-минификатор для платформы .NET» на MskDotNet Meetup #25

15 августа в Технологическом Центре Дойче Банка прошла 25-я встреча московского сообщества .NET разработчиков MskDotNet Community. Я выступал на данном мероприятии с докладом об одном из своих open source-проектов – WebMarkupMin.

Заблуждения о JavaScript Engine Switcher 2.X (Перевод)

Английскую версию данного поста я написал еще в мае и опубликовал ее в багтрекере проекта ReactJS.NET. Изначально я не планировал переводить данный пост на русский язык, но в понедельник я увидел программу 13-й встречи MskDotNet Community, и решил, что такой перевод был бы полезен сообществу

Для лучшего понимания материала изложенного в посте, я немного расскажу о ReactJS.NET и JavaScript Engine Switcher. ReactJS.NET – это .NET-библиотека, которая производит компиляцию JSX-кода в JS-код. Данная библиотека не является .NET-портом библиотеки React (по аналогии c Less.js и dotless). При создании ReactJS.NET использован совершенно другой подход: JS-код библиотеки React запускается из .NET с помощью JS-движка. Роль этого JS-движка, как раз и выполняет библиотека JavaScript Engine Switcher. JavaScript Engine Switcher определяет унифицированный интерфейс доступа к базовым возможностям популярных JS-движков (MSIE JavaScript Engine for .Net, Microsoft ClearScript.V8, Jurassic, Jint и ChakraCore) и позволяет быстро переключить вашу библиотеку или приложение на использование другого JS-движка (при условии, что ваш JS-код совместим со стандартом ECMAScript 5).

Переходим на WebMarkupMin 2.X

Весной прошлого года, когда ASP.NET 5 был еще в стадии Beta 3, я начал получать от пользователей письма с просьбами сделать WebMarkupMin совместимым с DNX 4.5.1 и DNX Core 5.0. Основной проблемой было то, что новый .NET не поддерживал настройку с помощью конфигурационных файлов App.config и Web.config. Переписывание WebMarkupMin.Core, WebMarkupMin.MsAjax и WebMarkupMin.Yui не должно было представлять особой сложности, потому что нужно было просто удалить весь код, использующий библиотеку System.Configuration. Серьезные проблемы должны были возникнуть при переписывании ASP.NET-расширений, потому что для них нужно было разработать совершенно новую модель конфигурации, а это, в свою очередь, требовало очень серьезных изменений в архитектуре. Эти изменения затрагивали не только код, но и структуру решения и NuGet-пакеты, поэтому я решил начать с чистого листа и сделал репозиторий на GitHub. На тот момент, до релиза стабильной версии нового ASP.NET оставалось как минимум полгода, поэтому нужно было одновременно поддерживать 2 ветви WebMarkupMin: стабильную 1.X на CodePlex и предварительную 2.X на GitHub.

Как известно всем, выход стабильных версий .NET и ASP.NET Core 1.0 задержался еще на несколько месяцев и состоялся только в конце июня этого года. Вслед за релизом этих фреймворков, состоялся и релиз WebMarkupMin 2.0. В этой статье я расскажу вам о том, как обновить существующие приложения под WebMarkupMin 2.X, а также как добавить его в веб-приложения, написанные на ASP.NET Core.

Критические изменения и нововведения

Для того чтобы установить пакеты WebMarkupMin 2.X вам необходимо обновить NuGet Package Manager до версии 2.8.6 или выше.

Основным критическим изменением версии 2.X стал отказ от использования файлов Web.config и App.config для настройки WebMarkupMin. Теперь при настройке вместо декларативного подхода (использование конфигурационных файлов) используется императивный подход (использование программного кода).

WebMarkupMin: Минимизация представлений KnockoutJS и AngularJS

Начиная с версия 0.9.0 в WebMarkupMin поддерживается минимизация представлений KnockoutJS (далее просто Knockout) и AngularJS (далее просто Angular). Многие из вас могут задать вопрос: «Почему Knockout и Angular, а не Mustache или Underscore?». Этот выбор был сделан по следующим причинам:

1. Шаблоны на основе DOM. Шаблонизаторы, встроенные в Knockout и Angular, базируются на DOM-шаблонах (DOM-based templates), а не на строковых шаблонах (string-based templates) как Mustache и Underscore. Код таких шаблонов не содержит программных вставок (например, {{…}} или <%…%>) за пределами текстового содержимого элементов (тегов) и значений атрибутов, что позволяет минимизировать его как обычный HTML.
2. Популярность среди .NET-разработчиков. Knockout изначально создавался для .NET-разработчиков, чтобы позволить им перенести свой опыт разработки MVVM-приложений из WPF и Silverlight в обычный веб. Что же касается Angular, то он вообще не нуждается в представлении и его популярность среди веб-разработчиков в целом бьет все возможные рекорды. Помимо этого популярности этих библиотек среди .NET-разработчиков способствовало огромное количество статей евангелиста Microsoft Джона Папы.
3. Высокая эффективность сжатия выражений привязки. Выражения привязки в Knockout и Angular фактически являются простым JavaScript-кодом или объектами в формате JSON, которые можно сжать JS-минимизатором.

HTML-минимизация в Web Essentials 2013: Что изменилось за год?

С момента публикации предыдущей статьи прошел почти год и приведенный в ней пример минимизации HTML-фрагмента уже неактуален (команда Web Essentials ► Minify selection больше недоступна в контекстном меню при редактировании HTML-файлов). Серьезные изменения в данном функционале произошли еще в декабре прошлого года, когда вышла версия 1.5, но в тот момент у меня не было времени, чтобы написать об этом статью. Поскольку за это время никто не описывал данный функционал на русском языке (на английском языке есть статья Дэвида Пакетта «Minifying your HTML»), то я постараюсь наверстать упущенное.

Bundle Transformer: Летние обновления

Начиная с сентября прошлого года, когда библиотека MSIE JavaScript Engine for .NET была заменена библиотекой JavaScript Engine Switcher и был создан модуль BundleTransformer.CleanCss, в Bundle Transformer практически не было каких-либо революционных изменений. Изменения были в основном эволюционными: добавлялась поддержка новых версий минимизаторов и трансляторов (самая рутинная и сложная часть работы над проектом), исправлялись мелкие ошибки и шла работа над увеличением производительности.

Но этим летом все изменилось: с конца мая по июль от пользователей Bundle Transformer было получено огромное количество рекомендаций по улучшению проекта. Большая часть из них была реализована в версии 1.9.0 и последующих летних обновлениях. В данной статье мы рассмотрим наиболее значимые из них:

Бандл… Пара-пара-па хэй! или Bundle Transformer шагает по планете 2

Я немного отойду от формата предыдущей статьи и прежде чем привести подборку интересных упоминаний о Bundle Transformer, я расскажу об изменениях, которые произошли в проекте за последние полгода.

До августа прошлого года библиотека dotless была основным средством для работы с LESS в сообществе .NET-разработчиком, и входила в состав практически всех инструментов клиентской оптимизации для ASP.NET: Cassette, SquishIt, Combres и RequestReduce. Bundle Transformer также не являлся исключением: библиотеки dotless и DotlessClientOnly (облегченная версия) использовались в модулях BundleTransformer.Less и BundleTransformer.LessLite.

Ситуация в корне изменилась, когда вышел Twitter Bootstrap 3.0. Исходники таблиц стилей Bootstrap 3.0 были написаны на LESS 1.4.X, а библиотека dotless на тот момент поддерживала более старую версию LESS (поддержка LESS 1.4.X появилась в dotless только в декабре 2013 года). Фактически все перечисленные инструменты для работы с LESS в одночасье стали морально устаревшими.