Нужно ли было умереть веб-формам ASP.NET?

ТЕХНОЛОГИЧЕСКОЕ КЛАДБИЩЕ

Нужно ли было умереть веб-формам ASP.NET?

Когда-то революционная технология наконец-то подошла к концу

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

Так было не всегда. Когда Microsoft выпустила первую версию .NET Framework, ASP.NET не вызвала затруднений - это была краеугольная технология и безудержный хит. Таким образом, возникает вопрос: были ли мы все пойманы в ловушку массовой галлюцинации разработчиков? Является ли смерть веб-форм ASP.NET примером изменения практики разработки или просто изменения моды? И почему нельзя было спасти веб-формы?

Мир до веб-форм

Чтобы понять, почему разработчики использовали (и часто любили) веб-формы ASP.NET, вам необходимо понять состояние веб-разработки, когда ASP.NET был впервые выпущен почти два десятилетия назад.

Шел 2002 год. Термин «веб-разработчик» почти не существовал - большинство технически подкованных веб-технологий делилось на обычных разработчиков (людей, которые писали код) и веб-дизайнеров (графических дизайнеров, которые не могли программировать, но понимали HTML и CSS). Ruby on Rails не существовало. Не было ни WordPress, ни Node. Забудьте React, Angular и другие клиентские JavaScript-фреймворки - никто еще даже не изобрел jQuery.

В то время современная веб-разработка заключалась в использовании встроенных скриптов - фрагментов кода, внедряемых на страницу, которые веб-сервер мог перехватить и выполнить. Вот пример классической веб-страницы ASP 3.0 (не ASP.NET), которая не вызывала бы удивления:

В этом примере создается базовая таблица, заполненная записями, запрошенными из базы данных. Что выделяется, так это похожий на спагетти клубок жестко запрограммированных строк HTML и кода VB. Это похоже на то, как будто HTML захвачен - заперт в жесткой, часто непрозрачной структуре условий и циклов. На полусложной странице становится невозможным проверить, что каждый путь кода генерирует последовательный, безошибочный HTML-документ. И горе программисту, которому нужно внести изменения.

Удивительно, но основанная на сценариях природа большей части веб-разработки не была самой большой проблемой, с которой столкнулся средний разработчик в 2002 году. Если вы спросите дюжину разработчиков, что вызывает у них самые большие головные боли и мешает им создавать амбициозные веб-приложения, которые они хотят, ответ будет: почти единодушны: совместимость с браузером. Получение последовательной работы с фрагментами кода JavaScript и стилизацией CSS было постоянной проблемой. Единственное работоспособное решение заключалось в том, чтобы ваши веб-страницы оставались настолько примитивными, насколько это возможно.

Что предлагали веб-формы

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

Если вы хотите разместить текст на странице с помощью веб-форм, вам не нужны теги или команды рендеринга. Вы могли бы вести себя как цивилизованный программист ООП и просто установить свойство элемента управления Label (названного так, чтобы соответствовать его аналогу в Windows Forms). Вот как это выглядело естественно:

lbl.Text = "Hello browser!";

Точно так же, если вы хотели поместить информацию в таблицу, не было необходимости понимать элементы HTML, такие как <tr>, <th> и <td>. Вы можете иметь дело с подходящими объектами для строк и ячеек:

table.Columns.Add("ProductNumber", typeof(string));
table.Columns.Add("ProductName", typeof(string));
table.Columns.Add("OrderDate", typeof(string));
table.Columns.Add("Quantity", typeof(string));
row = table.NewRow();
row["ProductNumber"] = "12-101";
row["Product_Name"] = "Blank CD-R Media";
row["OrderDate"] = "12/06/2002";
row["Quantity"] = "50";
table.Rows.Add(row);

Веб-элементы управления даже зашли так далеко, что представили модель более высокого уровня, которая обернула CSS. Это означало, что вы могли настроить внешний вид любого элемента управления, используя кучу различных свойств:

lbl.ForeColor = Color.Crimson;
lbl.Font.Name = "Verdana";
lbl.Font.Bold = "True";
lbl.Font.Size = FontUnit.Point(14);

Интеграция CSS расширилась до функции Visual Studio, называемой макет сетки - по сути, это способ для разработчиков ASP.NET перетаскивать свой путь к фиксированному макету веб-страницы, так же, как они могут собрать окно в настольное приложение. Недостатки этой функции быстро стали очевидны. Фиксированные макеты нарушали доступность и масштабирование, а также обеспечивали невозможность перекомпоновки страниц для соответствия разному объему контента, разным размерам окон и разным устройствам. Microsoft незаметно спрятала эту функцию в следующей версии Visual Studio.

Веб-элементы управления не ограничивались HTML и CSS. В конце концов, если веб-элемент управления может отображать себя в HTML, почему бы не добавить еще и код JavaScript? Так стало возможным использовать многофункциональные веб-элементы управления, которые отображали все необходимые им поддерживающие скрипты, и гарантируя, что эти скрипты будут работать в каждой основной версии браузера. Это было почти как по волшебству. Конечно, такая конструкция усложняла модель рендеринга, поскольку элементы управления должны иметь возможность добавлять свои сценарии в нужное время, обрабатывать несколько своих экземпляров и избегать конфликтов с другими элементами управления. Но сложность казалась стоящей - по крайней мере, так было, пока разработчики ASP.NET все еще создавали относительно простые страницы.

Легко подумать, что Web Forms преуспели, потому что они покрывали сложности веб-разработки с помощью абстракции, которая имитировала разработку под Windows. И отчасти это правда. Но реальным преимуществом веб-форм было то, что они представили модель, которая могла решать веб-проблемы того времени, особенно совместимость с браузерами. Это даже дало разработчикам дорогу к тому, что, по их мнению, было бы будущим. Нажмите на переключатель, и веб-элементы управления ASP.NET переместятся с обычного HTML на совершенно корректный XHTML.

Стоимость абстракции веб-форм

Каждая абстракция приносит прибыль. Это упрощает детали, которые находятся перед разработчиком, и усложняет работу сантехники, которая работает за кулисами. Успех абстракции зависит от того, насколько хорошо работает эта сантехника, какой налог нужно платить за производительность и будут ли разработчики вынуждены покинуть абстракцию. Если разработчикам нужно заглянуть за занавес и начать возиться с сантехникой, чтобы получить то, что они хотят, абстракция не удалась. А у веб-форм было много неудач.

Основным элементом сантехники, который заставил веб-формы работать, был элемент HTML <form>, выходящий далеко за рамки его предполагаемого назначения. На странице веб-форм каждый веб-элемент управления находился внутри элемента <form>, и весь динамический контент отображался там. На практике это означало, что каждая веб-страница ASP.NET использовалась одной гигантской скрытой формой (отсюда и название - Web Forms).

Одна из самых важных задач формы - следить за тем, чтобы веб-элементы управления сохраняли свое состояние. Другими словами, веб-разработчикам нужно было иметь возможность установить значение в своем серверном коде в какой-то момент и сохранить его в силе позже, после обращения к клиентскому браузеру. В конце концов, именно так работали обычные настольные приложения, так что это было стандартом разработки примерно в 2002 году. Web Forms достигли этого трюка с помощью функции, называемой состояние просмотра, которая помещала информацию в скрытый элемент <input> в <form> (с хеш-значением для предотвращения взлома). Таким образом, данные могут быть отправлены на сервер, а затем обратно в браузер с каждым отдельным запросом, как дополнительный пакет, прикрепленный к спине мула.

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

Система обработки событий, которую веб-формы прикрепили к веб-страницам, называемая системой обратной передачи, была еще одной дорогой иллюзией. Чтобы страницы реагировали на действия пользователя и запускали серверный код, ASP.NET полагался на фрагмент кода JavaScript, который перехватывает события браузера и отправляет страницу обратно на веб-сервер. Там, на веб-сервере, развернулась череда событий.

На первый взгляд последовательность событий жизненного цикла страницы кажется достаточно логичной. Но даже опытные разработчики ASP.NET могут запутаться в порядке действий, которые страница должна выполнять: чтение разметки, регидратация веб-элементов управления из состояния просмотра, запуск кода инициализации, выполнение привязки данных, захват новых значений, которые были опубликованы в форме, загрузка пользовательских элементов управления и т. д. Если веб-элементу управления нужно было что-то сделать на одном из этих этапов, что он мог бы предположить о других элементах управления на странице? Проблемы было трудно выявить, и автоматические тесты не рассматривались. И снова абстракция веб-форм дорого обходилась, но теперь это была не производительность, а сложность.

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

Возвышение Аякса

Проблемы усугубились с появлением Ajax, поскольку веб-страницы начали использовать JavaScript и объект XMLHttpRequest, чтобы стать более отзывчивым.

Сначала ASP.NET справился с этой задачей. Он включал в себя особенно удобный UpdatePanel элемент управления, который позволял страницам веб-форм переключаться с устаревших обратных передач на обратные вызовы на основе XMLHttpRequest без вывода сообщений. Лучше всего то, что не требовалось кодирования JavaScript. Но UpdatePanel был комплексным решением для обновления страниц. Это не помогло вам создать более сложные и гибкие элементы управления, такие как календари, всплывающие меню, слайд-шоу и анимации. И разработчики не могли отказаться от чужих библиотек JavaScript, потому что они могли нарушить абстракцию веб-форм. (Например, если код JavaScript изменил часть элемента управления, он больше не выровнялся бы со своими данными состояния представления, вызывая проблемы при следующей отправке страницы обратно на сервер.)

Если вы были разработчиком ASP.NET и хотели иметь более богатый и современный пользовательский интерфейс, наполненный JavaScript, вам нужно было найти веб-элементы управления, которые могли бы делать все. И ASP.NET выпустила набор полезных элементов управления, в которых использовались методы Ajax. Но единый набор инструментов пользовательского интерфейса не может конкурировать со всем миром разработки на стороне клиента. Повсюду JavaScript наполнялся новыми идеями и методами. Тем временем разработчики ASP.NET застряли, глядя на новый ландшафт веб-разработки через крошечный иллюминатор.

Если бы мобильная разработка и Ajax были единственными проблемами, с которыми сталкивались веб-формы, Microsoft, возможно, смогла бы усовершенствовать технологию и сохранить ее актуальность. Но настоящая проблема заключалась в философском сдвиге в этих и других областях. Проще говоря, у веб-разработчиков было новое ожидание - иметь точный контроль над HTML, CSS и JavaScript, включенными в каждую страницу. Это было невозможно с абстракцией, которая создавала всю свою разметку на сервере.

Действительно ли веб-формы мертвы?

Все сложно.

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

Фактически, как часть окончательной версии .NET Framework (4.8), ASP.NET Web Forms считается официальным системным компонентом Windows, что означает, что срок его службы привязан к сроку службы Windows 10. Это гарантирует Microsoft поддержка веб-форм по крайней мере до 2025 года - и, вероятно, намного дальше этого.

Но политика поддержки Microsoft не раскрывает всей истории. Это потому, что, хотя ASP.NET остается частью .NET Framework, Microsoft в настоящее время заменяет .NET Framework на .NET Core, проект, который завершится выпуском .NET 5 в конце этого года. Эта современная замена .NET не включает веб-формы ASP.NET вообще. Больше не имеет значения, работают ли веб-формы. Разработка новых инструментов не поддержит этого. Новые программисты не будут его изучать. И новые функции, исправления и улучшения производительности не дойдут до него.

Итак, в итоге: веб-формы ASP.NET больше не подходят для новой разработки. Его избегают, но он не умер - поддерживается как устаревший продукт, но окончательно исключен из будущего .NET. Возможно, самым большим сюрпризом является не то, что веб-формы со временем перестали работать. Дело в том, что Microsoft удалось поддержать его, одновременно создавая замену, которая сохранит ASP.NET на долгие десятилетия.

Чтобы получать рассылку раз в месяц с нашими лучшими техническими историями, подпишитесь на Информационный бюллетень Young Coder.

Нужно ли было умереть веб-формам ASP.NET?

ТЕХНОЛОГИЧЕСКОЕ КЛАДБИЩЕ