Привет, меня зовут Вячеслав Колдовских, я 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, и особенно проблемно было создавать кросс-браузерную код.
РИА
Как дополнительное подтверждение того, что пара 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 и т.д. - это, по сути, отдельные независимые платформы, контролируемые коммерческими организациями, которые самостоятельно определяют правила игры.
Веб 2.0 / Веб.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-коде, и в идеале должен предоставить возможность машинам читать данные так, как это делают люди.
В браузере посетители сайта будут видеть обычный текст, а машины, например поисковые системы, смогут получить структурированную информацию.
Несмотря на то, что семантический веб получил определенное распространение, трудно утверждать, что это стало трендом будет им в ближайшем будущем. Причин можно назвать много, однако одна из них - это игнорирование веб-разработчиками семантической разметки, в свою очередь, лишает смысла дальнейшие усилия в направлении использования семантических данных в веб-страницах. Получается своеобразный замкнутый круг, и, несмотря на поразительную распространенность интернета и объем информации в нем, информация в значительной степени до сих пор не структурирована, - значит, пока вряд ли можно сказать, что мечта отцов-основателей о некоей всемирную библиотеку структурированных знаний осуществилась.
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-м AngularJS был лидером среди 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 - он находит силы обновиться и избавиться от них. Но интернет не делает это самостоятельно - это делают разработчики, своими руками сегодня предоставляют ему тех форм, которые он будет завтра. И чтобы разрабатывать под веб, надо понимать его, надо чувствовать его философию, идеи, которые заложили в него его создатели.
P.S. Перевод статьи с dou.ua