Эволюция интерфейсов: как изменилась веб-разработка за 20 лет 

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

О том, как менялся инструментарий веб-разработчика, а вместе с ним пользовательские интерфейсы, через призму собственного опыта и воспоминаний рассказывает Сергей Бережной, директор по взаимодействию с разработчиками в Яндексе и руководитель Школы разработки интерфейсов Академии Яндекса.

Сергей Бережной

Директор по взаимодействию с разработчиками в Яндексе и руководитель Школы разработки интерфейсов Академии Яндекса

Интерфейсы нулевых: низкая скорость и статичные страницы

В конце 1990-х — начале 2000-х сайты состояли из статичных веб-страниц с кросс-ссылками. Идеальный пример из наших дней — Википедия. Слова «hyper text» в акрониме HTML означают именно это — текст со ссылками на другой текст. Картинки на таких сайтах встречались редко. В качестве интерактивных элементов взаимодействия с юзерами использовались простые форматы, например, формы обратной связи. И переходы по ссылкам, и отправка форм вызывали полную перезагрузку страниц. Интернет был медленным, да и понятие «безлимит» было доступно лишь небольшому числу счастливчиков, поэтому каждый графический элемент интерфейса и обновление страницы жадно съедали ограниченный трафик пользователя.

Делать такие сайты было и легко, и сложно одновременно. Технологически они были сильно проще, чем сейчас, а пользователи — менее искушенными, поэтому обычного текстового редактора и FTP-доступа на сервер хватало, чтобы справляться с задачами того времени. С другой стороны, делать это могли только специалисты («веб-мастера»), хотя бы минимально погруженные в тему. К слову, первые в мире CMS формально появились еще 1995 году, однако, широкое распространение получили позже — примерно в 2003-2006-м, когда на рынке появилась WordPress — система, на базе которой написано более 40% всех современных сайтов. Такие инструменты позволили владельцам веб-ресурсов (например, руководителям торговых компаний) даже без навыков программирования самостоятельно вносить нужную информацию: добавлять и удалять товары, менять адреса офисов, а также загружать полезные материалы.

Помню, в это время я работал в небольшой провинциальной веб-студии, где мы создавали собственную систему управления контентом для сайтов, которые продавали клиентам. Стоимость ресурсов с CMS была заметно выше, но зато их владельцы могли экономить на последующих обращениях в нашу компанию для обновления информации.

JavaScript: асинхронные запросы, всплывающие окна, чаты

Язык JavaScript, который был специально создан для разработки интерактивных сайтов, появился в далеком 1995 году, но, по моим ощущениям, массово использовать его стали только ближе к 2005-му. К слову, многие решения в вебе можно было воплотить в жизнь еще в середине 90-х, но большинство разработчиков и не задумывалось о том, чтобы делать сайты, которые бы активнее взаимодействовали с пользователем в ответ на клики, нажатия клавиш или наведение курсора на элементы интерфейса.

Когда веб-мастера, наконец, осознали, что с помощью JavaScript можно «оживлять» малоподвижные веб-страницы, на лету вставлять в HTML-код любые теги и проектировать интерфейс так, чтобы сайт «реагировал» на действия пользователей, начался расцвет анимированных меню, всплывающих окон и эффектов вроде падающих снежинок на Новый Год.

Немногим позже, в 2006-2007 годах, начали активно использовать AJAX. По сути, это набор разных практик и технических способов получать данные с сервера асинхронно и вместо всей страницы перезагружать только её часть. Как следствие, это значительно экономило трафик и помогало сайтам работать быстрее. Например, если раньше, чтобы создать чат, приходилось делать периодическую перезагрузку всей истории сообщений раз в несколько секунд (и тогда, с одной стороны, тратился трафик, а с другой — замедлялось общение на те самые несколько секунд), то теперь пользователи могли получать только новые сообщения, причем практически в тот же момент, когда они были отправлены.

Помню, интерактивные веб-страницы были настолько непривычными и заметными, что даже приемы, которые не основывались на асинхронной дозагрузке данных с сервера, а предполагали динамический показ кусков контента, загруженных заранее, тоже называли «АЯКСом».

Блоги и зарождение соцсетей

Десятилетие с 1999 по 2009 также ознаменовало появление контентных досок и блоггинг-платформ. Это и Dirty.ru, который позже вырос в «Лепру», и известные сегодня всем LiveJournal и Tumblr. Механика работы блог-платформ позволила протестировать множество интерактивных функций, а лучшие наработки позже перекочевали в интерфейсы продуктовых сайтов и стали основой популярных социальных сетей.

Кстати, в 2007 году Яндекс тоже представил собственную блог-платформу «Я.ру» или, как её ласково называли, «Ярушку» (от доменов вида username.ya.ru). Сайт создавался отчасти по образу «Живого Журнала», но включал и множество наших собственных новаторских для того периода решений.

Для меня «Я.ру» стал первым большим проектом в Яндексе. Хорошо помню то время экспериментов с форматами и новой функциональностью, от написания постов и комментариев до ведения переписки, возможности делиться фото, ссылками и даже настроением. Однако большая часть аудитории проекта вскоре перетекла в популярные соцсети вроде Одноклассников и Вконтакте, поэтому в 2014 году руководство компании приняло решение закрыть платформу.

DevTools: «Браузерные войны», новые инструменты и изменение сайтов в браузере

DevTools или «инструменты разработчика», как встроенный в браузер способ посмотреть исходный код сайта, узнать детали сетевых запросов и внести «наживую» изменения в HTML, JavaScript и CSS, существовали не всегда.

В нулевые самым популярным браузером был Internet Explorer от Microsoft, он занимал почти 90% рынка благодаря тому, что входил в установочный пакет популярной операционки Windows. Однако о его недостатках уже тогда судачили на профессиональных форумах: медленная загрузка страниц, конфликты при установке плагинов, скудный угловатый интерфейс — все это не позволяло назвать его лучшим решением своего времени. Кроме того, Internet Explorer не до конца соблюдал веб-стандарты, установленные Консорциумом Всемирной паутины (W3C): не поддерживал SVG и инструменты для корректной обработки CSS, из-за чего элементы страницы могли отображаться на экранах непредсказуемо.

Но главный фактор, из-за которого IE проиграл вышедшему в 2004 году Firefox — в последнем было множество бесплатных встроенных расширений. Например, мощный девелоперский пакет FireBug (была версия и для Internet Explorer, но заметно медленнее и с усеченной функциональностью) позволял разработчикам править код прямо в браузере и просматривать HTTP-заголовки, в том числе и AJAX-запросов.

Сейчас это звучит дико, но до появления FireBug основным методом дебага JavaScript у меня был сниппет «a → alert(…);», который позволял вывести какое-либо значение в диалоговом окне (и заодно прерывал сложные действия в браузере, поскольку забирал фокус), а для дебага CSS — сниппет «b → border: 1px solid red;», который помогал понять, как браузер воспринимает те или иные HTML-элементы (и заодно мог критично изменить размеры элемента, из-за чего позже я стал использовать «b → background-color: pink;»).

К 2008 году «огненный лис» успел обрасти множеством новых функций, но из-за этого потерял в скорости, поэтому когда на арену вышел новый браузер от Google, значительная доля пользователей Firefox перешла к конкуренту. Chrome оказался шустрым и оперативно открывался даже на «слабых» устройствах. Этого удалось добиться, в том числе, благодаря полностью новому движку исполнения JavaScript, который позже лег в основу Node.js (среды исполнения, принесшей JavaScript на сервер).

БЭМ: смыслы первичны, технологии вторичны

Подход БЭМ — гордость Яндекса, потому что сегодня он помогает тысячам веб-разработчиков по всему миру. В 2006 году, работая над «Я.ру» и другими сервисами, мы выявили две проблемы: было сложно вносить изменения в код одной страницы, не затрагивая кода другой, и практически невозможно подбирать уникальные названия огромному числу созданных элементов интерфейса.

Так мы с Виталием Харисовым и другими коллегами пришли к новой методологии обозначения смысловых частей интерфейсов — БЭМ (сокр. от «Блок-Элемент-Модификатор»). В основе БЭМ — разделение интерфейса на независимые составляющие. Блок — компонент веб-страницы, который можно применить повторно.

Название блока должно отражать его смысл, например, Contacts, Menu, Promo и так далее.

Элемент — часть блока, вроде Contacts__address, Promo__item.

Модификатор — внешний вид, состояние или поведение блока или элемента, например, Logo_type_big, Promo__item_theme_dark.

При этом блоки, элементы и модификаторы существуют во всех технологиях, которые используются для создания интерфейсов. И вместо отдельных папок `css/` и `js/`, где находился один или несколько больших файлов для всего проекта или разных его страниц, у нас появилось множество папок с разными блоками, элементами и модификаторами, в каждой из которых лежал маленький кусочек CSS и JavaScript. А чтобы пользователь увидел в итоге полноценную страницу, мы реализовали процесс сборки нужных больших файлов из этих кусочков.

Так понятие сборки и «компиляции» веб-технологий полноценно вошло в нашу работу в Яндексе. Хотя, помню, коллеги из бэкенд-разработки еще долго спрашивали «Что вы там компилируете в своих JS/CSS? Это же интерпретируемые языки!»

Кроссбраузерность или мечта перфекциониста

В начале 2010-х подход к верстке интерфейсов стал меняться стремительней — появлялись все новые части стандартов веб-технологий, которые внедрялись в браузерах. Например, CSS-модуль Flexbox позволил располагать элементы на странице и горизонтально, и вертикально, процесс стал более гибким в сравнении с использующимися до этого таблицами или плавающими блоками.

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

Чтобы решить эти проблемы, разработчики браузеров придумали префиксы для новых CSS-свойств (например, «-webkit-» для Safari и Chrome, а «-о-» для Opera), они должны были дать возможность создателям сайтов писать разный код, понятный конкретному браузеру.

Но и здесь все оказалось непросто — при таком подходе кода, который писался вручную, становилось больше, поэтому вскоре появились дополнительные инструменты, которые добавляли нужные префиксы уже на этапе компиляции и сборки CSS (например, Autoprefixer). К слову, эти же инструменты познакомили широкие массы веб-мастеров с самой идеей того, что CSS, который мы отдаём браузеру, не обязательно создавать «руками».

Интерфейсные фреймворки: быстрее, легче, красивее

«Писать меньше, делать больше» — этот девиз провозгласили веб-разработчики в 2006 году, когда возникла JavaScript-библиотека jQuery. У создателей интерфейсов появилась возможность настраивать взаимодействие между HTML и JavaScript и проще получать доступ ко всем элементам DOM. Кроме того, jQuery дал удобное API при работе с AJAX. Это была «обертка», которая позволила не оглядываться на особенности браузеров. Сегодня jQuery до сих пор «в ходу», но с появлением «большой тройки» интерфейсных фреймворков (React, Vue и Angular) он отошел на второй план при создании новых сайтов.

Самый популярный фреймворк на сегодняшний день —  React, он позволил сделать взаимодействие с DOM более декларативным, а подход к разделению кода на части (который мы так полюбили после изобретения БЭМ-методологии) более естественным.

Да, у React это получилось не сразу. Я помню и фундаментальные проблемы с производительностью больших приложений из-за блокировки браузера на время  перерендеринга фрагментов интерфейса, и мелкие неприятности, например, невозможность отрендерить один компонент в два новых. Из-за них мы долго не могли решиться на повсеместное использование React во всех проектах Яндекса. Но, так же как это было с jQuery, сообщество вовлеченных разработчиков помогло со временем исправить большую часть этих проблем. Даже в рамках Осенних Школ по веб-разработке ставку в последнее время мы делаем на React.

Технологии меняют наш мир и реальность очень быстро. Еще 15 лет назад мало кто верил, что смартфоны захватят рынок, мобильный интернет будет самым популярным способом связи, а чтобы заказать на дом еду, будет достаточно сделать пару «тапов» по экрану.  Поэтому современным специалистам и тем, кто мечтает связать свою жизнь с IT, важно постоянно учиться новому и пристально следить за развитием технологий. Помните слова Красной Королевы у Льюиса Кэрролла? «Здесь приходится бежать, что есть мочи только для того, чтобы оставаться на месте, ну а если хочешь куда-нибудь передвинуться, придется бежать, по меньшей мере, вдвое быстрее».