Думаю, что после прочтения статьи Никиты Прокопова «JavaScript Bloat in 2024» (рус. «Насколько потолстел JavaScript к 2024 году?») не я один стал с пессимизмом смотреть на будущее веб-разработки. Хотя тема раздутия JavaScript не нова (одним из первых на эту проблему обратил внимание Эдди Османи в своей статье-отчете «The Cost Of JavaScript» (рус. «Сколько стоит JavaScript?») в 2017 году), но здесь поражает масштаб проблемы, обозначенный автором статьи.

Нечто подобное было с HTML (и в какой-то степени с графикой) на ранних этапах развития Всемирной паутины (далее веб). Проблему раздутия HTML удалось практически полностью решить к середине 00-х за счет внедрения веб-стандартов и совершенствования WYSIWYG-редакторов HTML. Появление технологии AJAX и одностраничных приложений (SPA) сместило акцент на JavaScript, но это не привело к мгновенному утяжелению веб-приложений (например, первые версии Gmail прекрасно работали даже на самых медленных dial-up-соединениях).

Ситуация начала меняться в худшую сторону где-то на рубеже 00-х и 10-х, когда стали появляться первые смартфоны. Разработка ПО стала постепенно усложняться, дорожать и носить более конвеерный характер. Начался массовый найм разработчиков, повсеместное внедрение гибких методологий разработки и стала расти доля работы, отдаваемой на аутсорс. В веб-разработке наступила эпоха фреймворков и инструментов сборки для фронтенда. Со временем подходы, которые были призваны снизить порог входа в профессию, временные и финансовые издержки, стали давать обратный эффект.

В конце прошлого десятилетия авторитетные специалисты заговорили о неэффективности современной разработки ПО. Также они высказали мнение о том, что часть проблем разработки имеют причины организационного характера. В этой статье я сделал подборку из трех таких высказываний, сделанных известными людьми старшего поколения.

На прошлой неделе технологическая компания, занимающаяся автоматизацией сетей общественного питания, опубликовала в соцсетях фотографию одной из своих точек питания при входе в которую висело объявление о поиске .NET-разработчика. Объявление содержало текст «.NET разработчик найдись» и QR-код, содержащий ссылку на описание вакансии. Этот нестандартный метод хантинга разработчиков заставил меня вспомнить о событиях 14-летней давности, свидетелем которых мне довелось быть. История, о которой пойдет речь, является примером самого быстрого найма разработчиков из всех, что я видел за свою карьеру. Поскольку я собираюсь рассказать эту историю без прикрас, то я последую примеру Игоря Ашманова и напишу статью в жанре «зашифрованных мемуаров». Поэтому вы не увидите здесь ни имен людей, ни названий компаний.

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.

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

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

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-минимизатором.

Стоит отметить, что для ASP.NET Web Forms (файлы с расширениями .aspx, .ascx и .master) по-прежнему используется старый редактор.

1. Многие современные веб-технологии и библиотеки являются Open Source-проектами (например, компиляторы LESS и CoffeeScript, верификатор JSHint и т.д.), и некоторые из этих проектов имеют лицензии, которые не позволяют включать их в состав коммерческих продуктов.
2. Сейчас веб-технологии развиваются настолько быстро, что их поддержка средствами разработки может стать неактуальной в течение одной недели. Поэтому ни частые релизы Visual Studio (сейчас период между релизами сократился с двух лет до одного года), ни периодические обновления не позволяют поддерживать Visual Studio в полностью актуальном состоянии.

1. Поддержка Zen Coding (более подробную информацию об использовании Zen Coding в Web Essentials можно прочитать в статье Джона Папа «Zen Coding in Visual Studio 2012») и генератор текста-«рыбы» Lorem Ipsum (например, если ввести lorem10 и нажать клавишу TAB, то в код будут вставлены 10 слов из трактата Цицерона «О пределах добра и зла»).
2. Команда Go To Definition для тегов <a>, <style> и <script>.
3. HTML-минимизация выделенного фрагмента кода.
4. Поддержка HTML-регионов (например, <!--#region main--> Какой-то код… <!--#endregion-->).

1. В предыдущем обзоре в качестве исходных файлов использовались: bootstrap.css и bootstrap.js из Twitter Bootstrap 2.3.2, из-за чего достоверность результатов была низкой. В новом же обзоре размер выборки был увеличен: для сравнения были отобраны 7 JS-файлов и 5 CSS-файлов из 10 популярных Open Source-проектов.
2. Теперь в сравнении минимизаторов CSS-кода также участвуют встроенные средства минимизации препроцессоров LESS и Sass.
3. Как известно, Bundle Transformer минимизирует каждый файл по отдельности и затем производит объединение минимизированного кода в один файл. Данный механизм сделан для того, чтобы предотвратить повторную минимизацию предварительно минимизированных файлов. Другие аналогичные библиотеки сначала объединяют код файлов, а затем минимизируют этот объединенный файл. Поэтому для полноты картины мы произведем 2 сравнения: сначала сравним эффективность минимизаторов на файлах, полученных путем объединения минимизированного кода, а затем на файлах, полученных путем минимизации объединенного кода файлов.

В начале 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-кода.

1. Объявляем и регистрируем Bundle`ы;
2. Используем Bundle`ы в коде наших представлений.