Что нужно знать о 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.

Переходим на 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. Теперь при настройке вместо декларативного подхода (использование конфигурационных файлов) используется императивный подход (использование программного кода).

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 в одночасье стали морально устаревшими.

Результаты опроса «Чем вы минифицируете внешние стили и скрипты в ASP.NET?»

В эту среду на Хабре стартовал опрос «Чем вы минифицируете внешние стили и скрипты в ASP.NET?», целью которого было определить наиболее популярные инструменты клиентской оптимизации для ASP.NET, с помощью которых можно «на лету» минимизировать код внешних стилей и скриптов. В список вошли следующие инструменты клиентской оптимизации:

• ASP.NET Web Optimization Framework (также известен как Bundling and Minification)
• ASP.NET Web Optimization Framework + Bundle Transformer
• Cassette.Aspnet
• Combres
• RequestReduce
• SquishIt

В опросе приняли участие 213 русскоязычных ASP.NET-разработчиков. Привожу результаты опроса:

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

Несколько дней назад я обнаружил, что мой Twitter-аккаунт @taritsyn был взломан и через него в течение двух недель рассылался спам на русском и украинском языке. Я был очень удивлен, что стал мишенью для спамеров, т.к. мой твиттер читает сравнительно небольшое количество подписчиков.

Я решил выяснить, почему мной заинтересовались спамеры, и после нескольких часов гугления, понял, что мой Open Source-проект Bundle Transformer стал пользоваться популярностью. Я обнаружил большое количество упоминаний о Bundle Transformer в блогах и твиттер-лентах зарубежных технических специалистов. Среди этих упоминаний есть и серьезные технические статьи:

WebMarkupMin HTML Minifier – современный HTML-минимизатор для платформы .NET

В начале 2012 года я работал над серией статей о клиентской оптимизации в ASP.NET MVC для журнала MSDeveloper.RU. Всего было опубликовано 2 статьи: «Сжатие JS- и CSS-файлов» и «Менеджеры ресурсов», но в моих планах было написать еще 2 статьи: одну про оптимизацию графики, а вторую про минимизацию HTML-разметки и GZIP/Deflate-сжатие (далее просто HTTP-сжатие). К сожалению, эти планы не удалось воплотить в жизнь из-за нехватки свободного времени (в тот момент, я запускал проект Bundle Transformer) и последовавшего закрытия журнала.

Но недавно я решил вернуться к теме оптимизации HTML-разметки. После небольшого исследования я понял, что под .NET практически не существует полноценных HTML-минимизаторов. Все существующие .NET-решения производят лишь 2 операции: удаление ненужных пробельных символов и удаление HTML-комментариев, из-за чего они очень сильно проигрывают решениям с других платформ. Поэтому я решил написать собственный HTML-минимизатор для .NET, о котором и пойдет речь в данной статье.

Эволюция HTML-минимизаторов

Прежде чем приступить к описанию своего проекта, я хотел бы немного рассказать о почти 15-летней истории HTML-минимизации и эволюции программный средств, автоматизирующих данный процесс.

Вопреки расхожему мнению, техники минимизации HTML-кода появились намного раньше, чем аналогичные техники для JavaScript. Уже в конце 1998 года Артемий Лебедев в 17-м параграфе ководства «Паранойя оптимизатора» описывал некоторые техники минимизации HTML-кода.

Вышел Bundle Transformer 1.6.10

Новая версия Bundle Transformer характеризуется следующими изменениями: большая часть сборок теперь подписана; в ядре, были исправлены ошибки, возникавшие при обработке путей; были обновлены некоторые модули (BundleTransformer.SassAndScss, BundleTransformer.CoffeeScript, BundleTransformer.TypeScript, BundleTransformer.MicrosoftAjax, BundleTransformer.Yui, BundleTransformer.UglifyJs, BundleTransformer.Csso и BundleTransformer.WG) и создана новая версия демонстрационного сайта ASP.NET Web Pages.

Рассмотрим основные нововведения данной версии:

Презентация «Bundle Transformer – инструмент для клиентской оптимизации в среде ASP.NET» с MoscowJS 8th

2 ноября в офисе компании «Яндекс» прошла 8-я встреча московского сообщества JavaScript-разработчиков MoscowJS. Мне посчастливилось выступить на этом мероприятии с докладом о своем продукте — Bundle Transformer.