Архив

Архив автора

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

Логотип MskDotNet Community

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

Тег «Далее»

Реклама

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

Три сосны: MSIE, V8 и ChakraCore

Английскую версию данного поста я написал еще в мае и опубликовал ее в багтрекере проекта 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

Логотипы WebMarkupMin, .NET Core и NUglify

Весной прошлого года, когда 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

Логотипы 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: Что изменилось за год?

Логотипы Web Essentials и WebMarkupMin

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

Тег «Далее»

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

Логотип Bundle Transformer на сельскохозяйственном поле

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

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

Тег «Далее»

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

Упоминания о Bundle Transformer в Интернете

Я немного отойду от формата предыдущей статьи и прежде чем привести подборку интересных упоминаний о 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 в одночасье стали морально устаревшими.

Тег «Далее»