Перевод статьи Вячеслава Колдовского «Веб-розробка: вчора, сьогодні, завтра», опубликованной на сайте DOU.UA.
Привет, меня зовут Вячеслав Колдовский, я Programming Mentor. В веб-разработке я с 1990-х, сейчас работаю в SoftServe над учебными проектами. Четверть века я наблюдал за эволюцией веба, видел появление и смерть технологий, делал ставки в конкурентных войнах. Меня всегда интересовало, куда оно все движется. Именно об этом хочу с вами поговорить, и разговор не будет коротким.
История часто цинично шутит с человеческими изобретениями: далеко не всегда задуманное становилось реальностью, очень часто реальностью становилось то, что задуманным не было. Похоже, вся история веба и соответственно веб-разработки — то, с чего оно все начиналось, как развивалось, куда направлялось и где оказалось теперь, — яркий пример этого утверждения.
Первый сайт увидел свет 6 августа 1991 года. Это был набор примитивных веб-страниц, которые, собственно, и презентовали всемирную паутину — World Wide Web. Интересно, что он до сих пор доступен по тому же адресу, что и почти три десятилетия назад.
Если вы перейдете на этот сайт и заглянете в его код, у вас может случиться когнитивный диссонанс: несмотря на то, что сайт открывается и отображается вполне нормально в современных браузерах, его код лишь отдаленно напоминает тот, который мы пишем сегодня. Именно в этом заключаются красота и боль веб-разработки — необходимость создавать решения, сохраняющие вид и стабильность работы в условиях среды и инструментов, стабильность которых лишь в постоянной изменчивости. Сегодня уже выросло не одно поколение разработчиков, не задумывающихся о том, что Интернет как сеть существовала задолго до презентации WWW, веб должен был стать всего-навсего одним из сервисов, которые она предоставляла. Вряд ли кто-то мог подумать при запуске, во что он превратится, — собственно, в этом и есть корень проблем, о которых мы поговорим далее.
HTML
Как сам отец интернета — физик-контрактор CERN Тим Бернерс-Ли — его представлял, можно увидеть на том же первом сайте: «The WorldWideWeb (W3) is a wide-area hypermedia information retrieval initiative aiming to give universal access to a large universe of documents». В вольном переводе звучит так: это такая себе библиотека документов, связанных между собой гиперссылками. То есть говорится о всего-навсего документах, представленных в формате гипертекста и соединенных между собой гиперссылками. Ключевые термины здесь «документы», «гипертекст» и «гиперссылки».
Интересно, что Тим Бернерс-Ли не был автором ни идеи, ни самого термина «гипертекст». Термин изобрел еще в 1963 году Тед Нельсон, работавший над проектом Xanadu — попыткой переосмыслить понятие документа и работы с информацией вообще. Xanadu — это проект всей жизни Теда Нельсона, а его идеи опередили время. Но как часто бывает в реальном мире, успешным становится не изначальный автор научно обоснованной рафинированной идеи, часто оторванной от реальности, а тот, кто увидел, как совместить идею с реальностью, даже пожертвовав какими-то важными ее принципами. Здесь можно вспомнить классический случай, когда автор ООП Алан Кей жестко раскритиковал C ++ как неудачную имплементацию его замыслов: «Когда я изобрел ООП, то не имел в виду C++». То же можно сказать и об изобретении Теда Нельсона — ему не слишком понравилось, как его идеи были реализованы в WWW. Вот интересное видео 2008 года, где автор демонстрирует рабочий прототип и объясняет ключевые концепции своего проекта. Там воочию можно убедиться: проект очень отличается от реализованного Тимом Бернерсом-Ли.
Кроме концепции гипертекста и гиперссылок, стоит обратить внимание и на имплементацию веб-страниц с помощью HTML. Все веб-разработчики знают о современной пятой версии HTML, но мало кому известно, что первой формальной версией этого языка является HTML 2.0, вышедшая в формате RFC только в ноябре 1995 года. К тому моменту стандарта языка как такового вообще не было. Тим Бернерс-Ли позаимствовал идею языка у SGML, но одновременно достаточно свободно интерпретировал ее, и поэтому веб-страницы не были корректными SGML-документами, хотя и использовали синтаксические конструкции языка, такие как теги и атрибуты. Впрочем, версии HTML со второй по четвертую строились как SGML-документы, однако уже в HTML5 от такой идеи отказались. Для желающих остается возможность реализовывать веб-страницы в формате XHTML, но смысла в том немного, потому что возникают некоторые побочные эффекты, например селекторы CSS становятся чувствительными к регистру и тому подобное. История показала, что идея привести HTML в соответствие с SGML с самого начала была нелогичной, — похоже, надо уметь вовремя отрубить концы прошлых идей и не тащить с собой в будущее ворох прошлого — веб в этом смысле хороший антипример.
Если говорить о веб-страницах в целом и HTML частности, то стоит отметить, что формат сам по себе является не чем иным, как формой представления информации в виде структурированного документа, который может содержать текст, информацию в виде списков и таблиц, изображения, аудио и видео, а также, конечно, гиперссылки. Все это предназначено только для того, чтобы показать информацию пользователю, еще и в достаточно статической форме, подобно странице книги, газеты или журнала. Интерактивность в HTML реализована с помощью элементов формы, задача которых — «взять» информацию у пользователя и отправить ее на сервер.
Если же говорить об использовании HTML как UI для программ, то он для этого мало приспособлен, и, например, любой привычный для UI элемент в форме вкладок и привязанных к ним блоков страницы просто отсутствует в HTML. То же касается «карусельки» из элементов или известного всем бургер-меню — конечно, их все можно реализовать, но не только средствами чистого HTML, что еще раз доказывает: язык для этого не был задуман. Особенно интересно, что таких элементов в чистом HTML нет до сих пор, хотя они встречаются чуть ли не на каждом современном сайте. Для дружественной к UI среды было бы логично иметь возможность программно «нарисовать» что-то на экране — достаточно дать координаты и все. Однако это не совсем легко, потому что нельзя просто так взять и нарисовать что-то поверх других тегов страницы. Мы ограничены DOM-деревом и не можем рисовать «просто на странице», необходимо использовать canvas, спозиционировать его и т.п.
CSS
Думаю, хватит о HTML, поговорим о CSS. Сколько боли приходилось видеть в глазах молодых людей, с энтузиазмом начинавших изучать веб-разработку и с легкостью осваивавших основы HTML, а затем обрывавших свой полет, столкнувшись с суровой реальностью работы с таким замечательным изобретением, как каскадные таблицы стилей.
Считается, что автором CSS является норвежец Хокон Ли (Håkon Wium Lie), который предложил идею Тиму Бернерсу-Ли в октябре 1994 года, а первая версия стандарта вышла два года спустя. До CSS разделения на представление и контент в HTML не существовало, и идею разделить обязанности можно было бы считать гениальной, если бы она не была одним из фундаментальных принципов разработки программных проектов. Но, как мы знаем, зло скрывается в деталях, и больше всего это касается CSS. Иронично, что сайт изобретателя CSS не очень хорошо выглядит ни на слишком широких, ни на узких экранах, и даже валидатор CSS имеет к нему претензии.
Возможно, и не стоило так уж придираться, но на то есть серьезная причина: несмотря на кучу различной функциональности в CSS, поддержки целостного и продуманного подхода к размещению элементов на странице долго не было. Это делалось комбинацией каких-то трюков и хаков, понять которые неподготовленному человеку было крайне сложно. Взять хотя бы использование свойства float, которое задумывалось для работы с изображениями, однако на длительное время стало опорой для адаптивной верстки. Впоследствии float уступило свое место Flexible Layout, который на самом деле, несмотря на всю свою гибкость, тоже не совсем предназначен для полноценной верстки сложных макетов, и только с Grid Layout, появившимся совсем недавно, все более-менее стало на свои места.
Написание кода на чистом CSS приносит мало удовольствия, особенно потому, что в нем практически отсутствуют механизмы реализации одного из важнейших принципов разработки — DRY (Do Not Repeat Yourself). До недавнего времени переменных не существовало, для вложенных элементов DOM приходится повторять цепочки селекторов, а возможности заново использовать код, модифицируя его поведение в зависимости от определенных условий, нет и сейчас.
Именно поэтому опытные разработчики редко изъявляют желание иметь дело с чистым CSS и вместо этого используют препроцессоры, то есть переходят на метаязык, что, в свою очередь, имеет определенные последствия — от потребности в компиляции до усложнения отладки, потому что реальный код, который выполняется браузером, часто существенно отличается от написанного в IDE.
Вообще CSS — настолько мощный и гибкий инструмент, что его часто применяют не по назначению, например, исправляя недостатки HTML. Например, в HTML есть тег, позволяющий сделать горизонтальную линию, и логично было бы иметь тег, делающий вертикальную. Но его нет, и чтобы нарисовать вертикальную линию, приходится креативить, многие делают это по-разному и используют при этом CSS. Особенно циничный случай такого применения — трансформировать элемент горизонтальной линии в линию вертикальную. «Циничный» потому, что если воспринимать код HTML семантически, тег hr, создающий горизонтальную линию, должен создавать именно горизонтальную линию. (Если говорить о семантически корректном подходе решению этой задачи, то лучше создать собственный элемент в HTML, стандарт это позволяет, вот пример).
JavaScript
Переходя к, вероятно, самой интересной составляющей фронтенда, стоит сделать отступление и спросить: а что делает язык программирования на фронтенде вообще? Здесь стоит отметить, что в 1990-х человека, который занимался сайтом, очень часто называли веб-мастер, и далеко не всегда это был человек с навыками программирования. Как-то на эту тему пошутил Крис Коэр, основатель css-tricks.com: «Два фронтенд-разработчика сидят рядом в баре. Им не о чем говорить». И это не тот случай, когда кто-то пишет на React, а другой на Angular. Это скорее о том, что один — типичный программист с алгоритмическим мышлением, которому удобнее сгенерировать весь контент динамично и императивно, достаточно лишь получить контейнер, а второй, наоборот, человек, которому ближе семантика элементов, структура контента, стили, анимации и т.д., то есть декларативный подход. Если говорить о философии, заложенной в HTML, то именно второй подход является корректным, насколько бы странно это ни было для некоторых сегодняшних разработчиков.
Собственно, сам Тим Бернерс-Ли никакого языка программирования внутри браузера не предполагал, поэтому неудивительно, что история его возникновения напоминает детектив. Компания Netscape, основанная в апреле 1994 года, выпустила первую публичную версию браузера Netscape Navigator с номером 0.9 в ноябре того же года. Браузер стремительно начал набирать популярность, и уже через четыре месяца занимал три четверти всего рынка.
Основатель компании Марк Андрессен решил, что HTML не хватает именно легковесного скриптового языка программирования, код которого можно было бы писать прямо в тексте веб-страниц. Поэтому в апреле 1995 года он нанял Брэндона Айка, который был тогда известным специалистом по языкам программирования, для того чтобы встроить язык программирования Scheme в браузер Netscape Navigator. Однако в языке Scheme довольно специфический синтаксис, а Sun тогда имела сильные рыночные позиции и активно продвигала Java, поэтому одним из требований, которые выдвинул Брэндон Айк к новому языку, была синтаксическое сходство с Java. Среди требований также была достаточная простота языка и отсутствие классов, поэтому для Брэндона это стало своеобразным челленджем — он решил реализовать в языке ООП, но без классов.
В Netscape принято было работать очень быстро, поэтому Брэндон Айк разработал прототип языка за 10 рабочих дней в мае 1995 года. Это действительно очень мало для того, чтобы создать собственный язык программирования с нуля, но, похоже, вполне достаточно, если базироваться на уже готовых решениях. Именно поэтому новый язык позаимствовал синтаксис у Java, основную функциональность у Scheme, а реализацию ООП у Self.
Также интересной особенностью языка была встроенная устойчивость к ошибкам — синтаксическим и ошибкам во время выполнения кода. Это давало бы возможность пользоваться языком непрофессиональным разработчикам. Поэтому, например, в JS точка с запятой для разделения утверждений является опциональной, а арифметические операции вообще не прерывают ход выполнения кода — можно смело делить на ноль или извлекать квадратный корень из отрицательного числа. Попытка прочитать значение из массива за его пределами просто вернет undefined, а если забыть задекларировать переменную и присвоить ранее незадекларированному идентификатору какое-то значение, то ошибки не возникнет, переменная создастся автоматически. Однако это вряд ли хорошо, потому что создана переменная будет не на уровне блока или функции, а в глобальном пространстве имен.
На тот момент такая гибкость и устойчивость к ошибкам в коде казалась важным достижением, она должна была привлечь к программированию людей, которые до того не имели к нему отношения. Но время показало, что профессиональным разработчикам, привыкшим к строгости и точности в программировании, JavaScript казался недостаточно серьезным языком. Тем более что некоторые решения были осуществлены под давлением ограниченного времени, и даже сам автор языка признал их неудачными. Например, однажды в 2013 году Брэндона Айка спросили (через твитер) о странном решении об отсутствии блочной области видимости в JavaScript. Он ответил, что 10 дней не хватило на блочную область видимости, и в то время для простого скриптового языка такой подход казался вполне приемлемым.
В 1995 году и представить было нельзя, что однажды JavaScript станет самым популярным языком программирования в мире. Собственно, тогда, в 1990-х, старт JS среди разработчиков вряд ли можно было считать удачным, потому что этот язык воспринимался как нечто недостаточно серьезное, чем следует пользоваться для замены изображения, поверх которого движется курсор мыши, или для каких-то других задач в том же духе.
Стоит вспомнить о тогдашнем тренде — в целом избегать написания кода на фронтенде и использовать инструменты, позволяющие конструировать страницы визуально, а код генерировать автоматически. Среди таких инструментов — Vermeer FrontPage, вышедший в 1995 году (позже — Microsoft FrontPage) и Macromedia Dreamweaver (позже — Adobe Dreamweaver), вышедший в 1997. Возможность сгенерировать код веб-страницы из визуального ее представления получил Adobe Photoshop. То есть очень часто фронтенд сайта воспринимался как часть проекта, с которой работают дизайнеры, а не программисты, потому что для последних есть бэкенд.
Кстати, программирование на бэкенд пришло значительно раньше, чем на фронтенд, там его место казалось логичным. Первой такой технологией, позволявшей динамически генерировать HTML, была технология CGI (Common Gateway Interface), созданная в 1993-м, всего через два года после запуска первого сайта. Реализована она была очень примитивно: HTTP-запрос от клиента направлялся на скрипт на сервере, который получал параметры запроса и генерировал ответ, направляя его на стандартный вывод, что, собственно, и получал браузер в ответ. CGI позволяла писать код на любом языке, достаточно было запустить его на сервере — хоть Perl, хоть C, однако в целом это делалось довольно трудоемко.
Настоящим прорывом в веб-разработке стало появление PHP 1995 года — этот язык был создан специально для интернета и позволял органически соединить HTML и синтаксически близкий к C язык программирования. Идея оказалась удивительно удачной и послужила прообразом для Active Server Pages от Microsoft (1996) и многих других технологий, которые заняли свою нишу рынка, однако не смогли приблизиться к популярности PHP даже четверть века спустя.
В определенной степени своим успехом PHP обязан тому, что браузер тогда не воспринимался как серьезная платформа для программирования. Возможности JavaScript в работе со страницей были очень ограничены, к тому же во второй половине 1990-х разгорелись браузерные войны: Microsoft выпустила свой браузер, в котором имплементировала собственную интерпретацию JavaScript под названием JScript, и особенно проблемно было создавать кросс-браузерный код.
Вот, например, фрагмент кода с реального сайта 1998 года. Можно только представить, какое «удовольствие» приносило писать что-то такое:
RIA
Как дополнительное подтверждение того, что пара HTML/JavaScript не воспринималась как платформа для разработки, следует назвать появление и расцвет разнообразных плагинов, которые должны быть встроенными в веб-страницы — или вообще заменять их — и предоставлять разработчикам «полноценный» опыт программирования. В частности, в 1996 году Sun в рамках платформы Java выпустила Java Applets, а Microsoft представила ActiveX, одновременно компания Macromedia приобрела FutureWave Software и выпустила свой плагин для браузера — Macromedia Flash, который сначала позиционировался как медиапроигрыватель, но впоследствии стал полноценной программной платформой.
Все эти плагины для веба были сторонними, требовали времени на загрузку и инсталляцию и не приносили особого удовольствия пользователям браузеров. В то же время возможности для программирования в браузерах именно с помощью JavaScript развивались достаточно медленно, хотя и были первые сдвиги. В частности, когда в Netscape почувствовали серьезную угрозу со стороны Microsoft, то решили отдать JavaScript на стандартизацию в организацию Ecma International. Организация достаточно оперативно взялась стандартизировать и развивать язык и на протяжении 1997-1999 годов выпустила три версии EcmaScript. Также в 1997 году мир увидел Microsoft Internet Explorer 4.0 — сокрушительный для Netscape продукт, благодаря которому MS победила в браузерных войнах. Среди его особенностей была задекларированная поддержка Dynamic HTML — набор технологий, включавший JavaScript и DOM, которые, наконец, позволяли полноценно манипулировать содержанием HTML-страницы на клиентской стороне и даже динамично применять стили.
Впрочем, разработчики браузеров и плагинов объединили усилия и в 2002 году предложили концепцию RIA — Rich Internet Applications, в которых идея пользоваться браузерами с плагинами подавалась как необходимость для получения качественного медиаконтента и опыта работы с сайтом в целом. Такой подход в значительной степени нивелировал идею веба как единой платформы обмена информацией, потому что Flash, Silverlight и т.д. — это, по сути, отдельные независимые платформы, контролируемые коммерческими организациями, самостоятельно определяющими правила игры.
Web 2.0 / Web.3.0
Уже в конце 1990-х стало понятно, что Интернет в целом и веб в частности захватили мир, потеснив все остальные сети и способы представления интерактивной информации. В январе 1999 года вышла статья авторства Дарси Динуччи, в которой впервые было сказано о концепции Web 2.0. Аавтор назвала веб того времени лишь эмбрионом того, что должно прийти в будущем. Основной чертой Web 2.0 была работа на устройствах с различными вычислительными возможностями, размерами экранов, способами ввода информации и в условиях кардинально разной скорости связи. В течение нескольких лет концепцию Web 2.0 дополнило понятие «контент», генерируемый пользователями, хотя тогда мало кто представлял, чем оно станет в недалеком будущем с его тотальным засильем социальных сетей. Тогда это казалось скорее набором независимых сайтов-блогов, на страницах которых посетители могли бы оставлять комментарии.
Как видим, концепция Web 2.0 оказалась пророческой, потому что теперь веб очень похож на тот образ, который создали два десятилетия назад.
Однако отец интернета Тим Бернерс-Ли хотел бы видеть его будущее несколько по-другому, поэтому сосредоточил свои усилия на так называемом семантическом вебе, назвав его Web 3.0.
Цель семантического веба — дать возможность машинам понимать данные, которые описывает HTML. Достичь ее можно, используя такие технологии, как RDF (Resource Description Framework) и OWL (Web Ontology Language).
Семантический веб позволяет описать схему данных, которые представлены в HTML-коде, и в идеале должен предоставить возможность машинам читать данные так, как это делают люди.
Например, обычный элемент div, содержащий информацию о человеке, дополненный RDF-атрибутами, может иметь следующий вид:
В браузере посетители сайта будут видеть обычный текст, а машины (например, поисковые системы) смогут получить структурированную информацию.
Несмотря на то, что семантический веб получил определенное распространение, трудно утверждать, что это стало трендом или станет им в ближайшем будущем. Причин можно назвать много, одна из них — игнорирование веб-разработчиками семантической разметки, что, в свою очередь, лишает смысла дальнейшие усилия в направлении использования семантических данных в веб-страницах. Получается своеобразный замкнутый круг, и, несмотря на поразительную распространенность веба и объем информации в нем, информация в значительной степени до сих пор не структурирована, а значит, пока вряд ли можно сказать, что мечта отцов-основателей о некой всемирной библиотеке структурированных знаний осуществилась.
AJAX
Несмотря на появление DHTML, во фронтенд-программировании длительное время была одна фундаментальная проблема. Классическая модель коммуникации браузер-сервер предусматривает отправку или получение данных с сервера вместе с запросом, направляемым браузером, только в момент перехода или обновления страницы (или фрейма, фактически являющегося независимой страницей). Это означает, что возможности получить или передать данные, не обновив одновременно страницу, с момента создания веба не существовало.
Однако, в 1999 году вместе с браузером MS IE версии 5.0 Microsoft выпустила обновленную версию ActiveX библиотеки MSXML, одной из особенностей которой была поддержка возможности без перезагрузки страницы и асинхронно, а не блокируя потока выполнения JavaScript-кода, отправить запрос на сервер, получить результат и с помощью DHTML встроить его в страницу.
Интересно, что несколько лет такую возможность не замечали: хотя ее и использовали на определенных сайтах, но в целом о массовом распространении речь не шла до тех пор, пока Google не запустила в 2004 году сервис Google Suggest, показавший возможности этой технологии всему миру. В феврале 2005 года Джеймс Ґаррет опубликовал статью «AJAX: новый подход к построению веб-приложений», в которой был предложен сам термин и подробно описана технология, что и обусловило активное ее применение.
AJAX фактически был последним фрагментом в пазле технологий, которые превращали родные компоненты веба — HTML, CSS и JavaScript — в полноценную платформу программирования.
jQuery
С появлением AJAX интерес к программированию с помощью JavaScript в браузере существенно вырос, однако писать кросс-браузерный код не стало проще даже в условиях монополии браузера от Microsoft, поскольку добавились проблемы совместимости различных версий IE.
В 2006 году появилась первая версия библиотеки jQuery, разработанная Джоном Резиґом, который вдохновился идеей выбора элементов HTML с помощью селекторов CSS в другой библиотеке cssQuery, но удачно соединил ее с удобными методами манипуляции DOM и встроил возможность делать AJAX-запросы.
Для многих разработчиков, которые испытывали свои силы в браузерном программировании, jQuery стала именно той спасительной соломинкой, которая позволяла выбраться из трясины кроссбраузерного программирования и сфокусироваться на самом задании, а не на способах решения. Интерес к «родному» программированию в браузере (а не к сторонних плагинам) начал существенно расти.
HTML5 / EcmaScript 2015
В январе 2008 года появился черновик новой, пятой версии HTML. Кроме собственно модификации самого языка разметки, он содержал также описание значительного количества API, превращавших браузер в полноценную платформу программирования. Если говорить собственно о языке разметки, то среди важных изменений следует назвать появление семантических тегов и отказ от некоторых тегов, отвечающих за представление. Выход HTML5 как стандарта затянулся на целых шесть лет. Впрочем, новый стандарт восприняли его очень положительно как разработчики самих браузеров, так и веб-разработчики, ведь он, наконец, превращал браузер в полноценную программную платформу, нивелируя потребность в таком постороннем для веба творении, как плагины для RIA.
Параллельно с работой над HTML5 велась работа и над очередной версией JavaScript. В 2009 году выходит EcmaScript 5, ровно через 10 лет после предыдущей версии. На удивление, изменений за десятилетие было предложено относительно немного, несмотря на то, что уже начали ощущаться недостатки языка, заложенные при ее создании. Только через шесть лет мир увидел по-настоящему обновленный стандарт языка под названием EcmaScript 2015, и вместе с ним язык, наконец, избавился от некоторых детских болезней, преследовавших его (например, уже упомянутая ранее блочная область видимости), а также получил обновленный синтаксис, сохраняя при этом обратную совместимость с ES5.
Именно парочку HTML5 / ES2015 следует считать переходом веб-платформы в период зрелости. Потребность в jQuery существенно уменьшилась, программировать на чистом JS стало значительно комфортнее.
Путь стандартизации HTML5 был непростым, длительное время существовало два отдельных стандарта: от W3C и WHATWG, и только в 2019 году двум организациям удалось договориться о едином стандарте — теперь это просто HTML Living Standard без номеров версий, над которым изначально работала WHATWG. В стандартизации EcmaScript также произошли важные изменения: новая версия стандарта языка теперь выходит ежегодно, язык развивается динамичнее, но вместе с тем изменения не нагружают разработчиков большими порциями.
SPA
Уже в конце первой декады 2000-х стало заметно, что объем кода на фронтенде очень вырос и приобретает большое значение модульность и поддерживаемость решений. jQuery в этом аспекте мало что могла предложить, поэтому на сцену начали выходить фреймворки Single Page Application, которые самой возможностью своего существования обязаны AJAX.
Knockout, Backbone, ExtJS, AngularJS — далеко не полный перечень SPA-фреймворков, которые начали тогда появляться. В основном они использовали паттерн MVC или его производные. Сам паттерн изобрели еще в конце 1970-х, но в веб-разработке его использование стало особенно распространенным. Считается, что впервые MVC в интернете применили в 1996 году в малоизвестном сегодня серверном фреймворке WebObjects. Затем он быстро распространился на другие серверные фреймворки и вообще очень комфортно чувствовал себя в интернете, накладываясь на традиционную модель коммуникаций, которая предусматривала перезагрузку страницы при каждом запросе клиента.
Но с появлением AJAX гармония MVC начала разрушаться, потому что, кроме традиционных запросов на контроллер, которые должны обновить представление, появились запросы, не совсем укладывающиеся в паттерн. И именно с помощью SPA эту гармонию удалось восстановить. Также пригодился созданный в начале двухтысячных Дугласом Крокфордом формат передачи данных JSON — значительно более удобный, чем XML. За десять лет SPA расцвели и закрепились на фронтенде, практически монополизировав его как подход к созданию веб-решений. Многие веб-разработчики даже не видели альтернатив и не задумывались о них, да и вообще вряд ли спрашивали себя, нужно ли что-то кроме SPA.
Действительно, с точки зрения классических разработчиков, для которых важны принципы распределения обязанностей, модульности и структурирования решений, паттернов и всего того, чему учит современная инженерия программного обеспечения, SPA — это очень хорошее решение для построения проектов. Но если взглянуть на это с точки зрения философии и духа веба и спросить, что со SPA не так, то ответ будет очень прост: все не так!
Сначала такой ответ может смутить, но если задуматься, сложно не согласиться с тем, что Single Page — это не очень хорошо, поскольку в самой природе веба заложено наличие многих страниц, объединенных гиперссылками. И эти страницы не должны быть просто имитацией в браузере. Они должны быть доступны любому клиенту, который делает HTTP-запрос к серверу по конкретному адресу, а не только тому, который получит минифицированный код на JavaScript, выполнит его и императивно построит страницу. В последнем случае мы теряем декларативную сущность веба, подменяя его аппликациями. Собственно, здесь и становится понятным, что Application тоже лишняя — разве мы не определились с тем, что HTML значительно ближе к книге или журналу, чем к графическому интерфейсу компьютерных аппликаций?
Следует признать, как бы это ни было обидно современным разработчикам, не представляющим фронтенд без SPA, эта концепция на самом деле чужда вебу, потому что пытается подменить идеи, заложенные в веб, подходами, пришедшими из разработки приложений с графическим интерфейсом пользователя. Кто-то, возможно, посчитает, что это не принципиально, и если оно работает, то какая разница, как оно сделано. Но практика показывает, что это не так. Все-таки SPA выполняются в браузере, и, как минимум, сохраняется потребность в возможности ссылок на отдельные страницы. Для этого начали реализовывать deep linking, перенаправляя любые запросы на бэкенд на одну страницу, которая является точкой входа в аппликацию, и выводя нужную страницу на фронтенде. Но потом стало понятно, что нельзя совсем отказаться от декларативного HTML на фронтенде и полностью подменить его динамичной аппликацией, лучше иметь HTML-контент на сервере. Как следствие — возникло понятие Server-Side Rendering. Но при реализации SSR возникает задача передать состояние от сервера к клиенту, а реализация этого тоже требует определенных усилий. Также очень посредственной оказывается поддержка доступности (accessibility) для SPA-приложений, декларативный HTML для этого лучше приспособлен. И так далее. Это напоминает непрерывный процесс, в котором решение одних проблем приводит к появлению других.
В общем сложность разработки и сопровождения SPA для веба начинает выходить за разумные пределы, все сложнее убеждать клиентов в том, что этот подход не имеет альтернатив. А их и правда нет?
А что у нас с фреймворками?
JavaScript-фреймворки это всегда горячая тема. Мы все прекрасно знаем: день проходит впустую, если мир не увидел новый фреймворк. Хотя это едва ли не самая любимая тема для новичков — любителей похоливарить, опытные разработчики редко поддаются на провокации и просто наблюдают за трендами и изучают то, на что есть спрос.
Примерно в 2014-м году ngularJS был лидером среди SPA-фреймворков, но с тех пор многое изменилось. Уже несколько лет подряд в абсолютных лидерах React, который формально является скорее библиотекой, чем фреймворком. Однако популярность — вещь обманчивая: во-первых, она переменчива, постоянно удерживать корону удается разве что jQuery, во-вторых, не всегда самая популярная технология является самой высокооплачиваемой — здесь стоит вспомнить о PHP.
Многие уже «похоронил» Angular, но здесь не все так просто: в Google переписали AngularJS с нуля, даже имя изменили, полностью поломав обратную совместимость, однако вряд ли кто-то скажет, что этим они сделали хуже. Как следствие — вышел некий мегаконструктор SPA, не очень подходящий для несложных проектов, но удачно нашедший свою нишу в корпоративных. Он и дальше активно развивается, Google обеспечивает серьезную поддержку — в общем, будущее представляется значительно оптимистичнее, чем может показаться на первый взгляд.
В течение нескольких последних лет достаточно уверенно чувствует себя VueJS. Легковесность и простота — это два основных фактора, которые обеспечивают его популярность. Он активно развивается и особенно популярным стал в Азии — именно это, вероятно, и следует отнести к немногочисленным недостаткам: часто значительно проще получить поддержку на китайском языке, чем на английском.
Но настоящее открытие 2019 года, которому еще предстоит показать себя в 2020-м, — это «исчезающий фреймворк» — Svelte. Пока React и Vue называют Virtual DOM своим преимуществом, Svelte, наоборот, среди преимуществ называет его отсутствие. Но ключевая его особенность заключается в том, что после сборки аппликации в ней не остается фреймворка как такового — аппликация компилируется в чистый JS, с помощью которого и происходят манипуляции с элементами страницы. Это весьма существенно отличает Svelte от других, хотя такой подход использовали разработчики Angular в последних версиях с новым двигателем рендеринга Ivy.
В конце 2019 года среди фронтенд-разработчиков всего мира проводился традиционный опрос «State of JS», в котором по уровню интереса Svelte занял первое место.
В общем, подход, использованный в Svelte, можно только приветствовать: вместо того чтобы в очередной раз строить в браузере мета-платформу, разработчики фреймворка использовали возможности браузера. Здесь уместно вспомнить, что развитие браузеров как платформы тоже не стоит на месте. Среди последних нововведений особенно стоит обратить внимание на поддержку WebComponents — механизм, позволяющий создавать собственные HTML-элементы с независимыми стилями и логикой, решая те же задачи, что и большинство фронтенд-фреймворков. Так что стоит ожидать распространения именно такого подхода, приближающего фреймворки к браузеру как платформе, а не отдаляющего от него.
Что с бэкендом?
Еще с 1990-х на бэкенде правит бал стек LAMP и производные, созданные по его образу и подобию. И вопрос даже не в конкретном наборе технологий, которые его формируют, а в общих принципах работы — запросы с фронтенда обслуживаются динамично, в процессе участвуют база данных и сервер приложений, которые относительно медленно работают и сложно масштабируются по горизонтали. В таком подходе принципиально ничего не изменилось даже с приходом SPA, которые позволили отказаться от передачи сгенерированных страниц с сервера, перегоняя только данные с помощью RESTful API.
Вместе с тем следует отметить, что разработчикам на бэкенде приходится решать типовые задачи даже в разных проектах — реализовывать аутентификацию и авторизацию, создавать типичные CRUD-операции для сущностей предметного участка, передавать DTO между различными уровнями аппликации, покрывать все это тестами и тому подобное. Чтобы не повторяться каждый раз и заново использовать сделанные ранее решения, еще с конца 1990-х стали набирать популярность CMS (Content Management Systems), а с распространением RESTful API — так называемые Headless CMS, вообще не имеющие фронтенда.
Несмотря на то, что CMS удается решить определенную часть проблем с повторным использованием кода, проблемы с развертыванием и поддержкой серверов остаются. Дальнейшая эволюция таких решений это миграция в облака и использование сервисов, которые полностью управляются облачными провайдерами. В этом смысле очень привлекательными представляются такие решения, как Google Firebase и подобные. Сочетание возможностей аутентификации, авторизации, API для работы со структурированными данными с возможностями хостинга с поддержкой CDN — серьезный аргумент против того, чтобы заниматься всеми этими вопросами самостоятельно. Разделение монолитов на микросервисы и использование платформ, берущих на себя масштабирование под нагрузкой, — такие архитектурные решения побуждают использовать облачные сервисы и не заниматься вопросами управления и поддержки инфраструктуры.
Одна из интересных инноваций на бэкенде, быстро приобретающая популярность и способная повлиять на принимаемые подходы к разработке решений, — GraphQL. Это разработанная в Facebook технология, позволяющая на фронтенде сформировать запрос в структуру данных, которые должен вернуть бэкенд. Такой подход лишает бэкенд-разработчиков необходимости создавать бесконечные CRUD-операции и в целом является хорошей альтернативой RESTful API.
Как следствие — все активнее наблюдается тенденция использовать возможности CDN, чтобы размещать статический контент веб-решений максимально близко к клиенту, а динамическую часть веб-решения строить так, чтобы она адаптировалась к уровню нагрузок, используя для этого возможности платформ облачных провайдеров, а не просто перенося в облака монолитные аппликации в неизменном виде.
JAMstack
В конце 2017 вышла интересная статья, в которой достаточно подробно был описан стек технологий под общим названием JAMstack (JavaScript + API + Markup). Сам термин изобрела и активно продвигает компания Netlify, которая очень удачно начала продвигать идею альтернативного SPA подхода, который на самом деле вовсе не новый, но гораздо ближе к оригинальным идеям веба, чем SPA.
JAMstack пропагандирует идею так называемых статических сайтов, хотя термин «статический» здесь совершенно неуместен, потому что в действительности статическими эти сайты не являются, просто, в отличие от SPA, их обычное состояние это заранее отрендеренный статический HTML-контент, размещенный на CDN, и динамические вставки только там, где надо. Бэкенд рассматривается в виде набора API, к которым можно обращаться с помощью JavaScript, и это далеко не всегда кастомный бэкенд, это могут быть уже готовы сервисы, реализующие аутентификацию, сервисы хранения данных и так далее. Текстовый контент не обязательно держать в виде HTML, для этого целесообразно применить какой-то из языков разметки, например Markdown. А сам сайт обновляется с помощью процессов CI/CD, которые стартуют по триггеру, например после обновления кода в системе контроля версий.
Поскольку статический контент может быть на CDN максимально близок к клиенту, а также не требует времени на динамический рендеринг, сайты, созданные с помощью JAMstack, — очень быстрые. Для индексации поисковыми системами и deep linking нет нужды в каких-то дополнительных действиях — это упрощает и в конечном итоге удешевляет разработку.
Вероятно, JAMstack не подойдет для всех возможных сайтов, однако он вполне пригоден для большого количества распространенных категорий, таких как блоги, новостные сайты и даже онлайн-магазины. В отличие от SPA, JAMstack идеологически гораздо ближе оригинальным идеям веба: контент не отображается императивно с помощью JavaScript, а представлен декларативно в страницах, размещенных на сервере, хотя возможность делать динамические ставки есть, в частности можно отказаться от перехода между страницами с помощью браузера и делать это в стиле SPA.
GatsbyJS — один из самых удачных фреймворков для JAMstack, на DOU даже есть цикл публикаций о нем, он сочетает в себе поддержку React, GraphQL, Markdown и он достаточно гибкий, чтобы адаптироваться к различным сценариям использования.
Интересно, что некоторые компоненты JAMstack не новинка, однако удачное их сочетание и учет специфики веба, похоже, и являются тем катализатором, который должен обеспечить успех нового стека.
WebAssembly
Одна из технологий, влияние на веб-разработку которой непросто предсказать, — это WebAssembly. Можно сказать, что это ящик Пандоры для языков программирования в браузере, альтернативных JavaScript. Если бы поддержка этой технологии появилась еще лет десять назад, то у JavaScript было бы гораздо меньше шансов в битве против других, «серьезных» языков программирования. Однако теперь я расцениваю шансы как равные, к тому же сам делаю ставку на JavaScript, поскольку этот язык существенно обновился на протяжении нескольких последних лет, а его применение для веба настолько естественное, насколько разработчику привычно писать идентификаторы на английском языке.
Поскольку среди основных аргументов в пользу WebAssembly называют скорость, то мы, вероятно, будем наблюдать процесс, когда где-то там «под капотом» в реестре npm обновятся библиотеки, которые будут оптимизироваться по скорости с использованием альтернативных по отношению к JavaScript языков, однако их интерфейсы так и останутся на JavaScript.
Конечно, WebAssembly постепенно начнет «откусывать» часть разработчиков у JavaScript. Этому будут способствовать такие проекты, как, например, Microsoft Blazor, предназначенные осуществить давнюю мечту бэкенд-разработчиков: лишить себя удовольствия изучать JS. Однако эти процессы вряд ли будут происходить быстро, и если говорить о перспективе нескольких ближайших лет, то монополии JavaScript для фронтенда это вряд ли существенно угрожает.
Вероятно, единственный язык, который в ближайшей перспективе хоть как-то заметно способен потеснить JavaScript в вебе, — это TypeScript, но его вряд ли можно назвать альтернативой JS, это скорее некий «JavaScript следующего уровня». Он используется опционально и становится нужен тогда, когда проект значительно разрастается. Поэтому важно иметь не только статическую типизацию, но и интерфейсы, декораторы и другие составляющие, которые есть в TS.
Вывод
Эта тема такая широкая, что о ней можно издать целую книгу, но рано или поздно разговор стоит завершать. История веба особенно интересна тем, что она не стояла на месте: здесь всегда все активно развивается, что-то бурлит и взрывается, несколько шумно приходит, а потом незаметно исчезает. Учитывая роль веба в мировом бизнесе, нет ничего удивительного в том, что он был, есть и, несомненно, будет в будущем полем битвы больших корпораций за свое влияние на обычных пользователей и разработчиков.
В этой борьбе всегда появляется кто-то, кто чувствует в себе силы и желание подмять под себя веб, установив монополию на браузер или определенные технологии, которые должны использовать разработчики. Сначала это была Netscape, затем ее вытеснила Microsoft, затем в интернете стала господствовать Google, которую, в свою очередь, вытесняет Facebook. Но удерживать корону еще сложнее, чем ее получить, ибо сила веба — в открытости стандартов, и каждый раз, когда его пытаются монополизировать или инфицировать сторонними компонентами, — как, например, было с RIA — он находит силы обновиться и избавиться от них. Но интернет не делает это самостоятельно — это делают разработчики, которые своими руками сегодня придают ему ту форму, которая будет у него завтра. И чтобы разрабатывать под веб, надо понимать его, надо чувствовать его философию, идеи, которые заложили в него его создатели. Именно поэтому я призываю разработчиков ответственно относиться к принимаемым решениям и применяемым подходам, стараться меньше использовать сторонние для веба вещи, а больше то, что он дает нам как платформа, ибо, как говорил гениальный Алан Кей, «Нет лучшего способа предсказать будущее, чем создать его».
[customscript]techrocks_custom_after_post_html[/customscript]
[customscript]techrocks_custom_script[/customscript]