Кратко: после браузерных войн организация W3C и группы разработчиков, такие как Web Standards Project, долго и упорно работали, чтобы восстановить единый нефрагментированный Веб. Но в последние несколько лет мы, разработчики, взяли, и заново всё зафрагментировали… Наверное, нам надо понять, что мы теряем, прежде чем потеряем этот Веб навсегда.
Ровно год назад патриарх веб-индустрии Anil Dash написал: "Мы потеряли Веб", скорбя по ранней, «досоциальной» блогосфере, до всех этих наших постингов фото, видео и мыслей, находящих последний приют в катакомбах Фейсбука, Твиттера, Инстаграма и Ютуба. Это вызвало отклик у многих, кто застал те дни; многих, кто по иронии судьбы затем ушёл работать в эти катакомбы.
Особенно, если тот самый период, примерно до середины 2000-х, был ранее вашего полноценного присутствия в Сети, вы должны найти время, чтобы не спеша, основательно прочитать его статью. Веб, действительно, изменился за последнее десятилетие, и не всегда к лучшему. Анил пишет:
«Мы потеряли основные идеи, лежавшие в основе, и хуже того, отказались от основополагающих ценностей, которые были в истоках мира Сети.»
… и отмечает, что одна из целей, для которых он написал заметку — чтобы люди, создающие новые социальные приложения, прикоснулись к истории, узнали её истоки.
Наверное, какие-то из этих идей, действительно, витают в воздухе, поскольку в последние пару недель Faruk Ateş и Jeremy Keith тоже размышляли на эту тему.
И я в том числе, большую часть прошедшего года думал о подобном, чувствуя, что мы потеряли кое-что из раннего веба, хотя думал о гораздо более ограниченной составляющей Интернета. О том, что обычно не попадает в поле зрения большинства пользователей Сети — о его коде. Думаю, что к нему тоже относится "… отказались от основополагающих ценностей, которые были в истоках мира Сети".
Браузерные войны
Анил говорит о Веб примерно с 2000 года, но я хочу сказать о сроке примерно с середины 1990-х годов. Сейчас почти все из нас слышали о браузерных войнах. Если спросить, что же тогда произошло, то большинство скажет, что это было время, когда Netscape и Microsoft боролись за контроль над Интернетом, стремясь сделать свой браузер доминирующим.
Но каким способом они пытались добиться доминирования? В некотором смысле, войны браузеров (первоначально воевали между собой Netscape и его предшественник Mosaic) могут называться «HTML-войнами», потому что полем сражения, образно говоря, для многочисленных браузеров, в том числе появившихся до IE, был язык HTML.
Не было никакой «стандартной версии HTML». Вместо этого, новые языковые возможности появлялись с новыми версиями браузеров — такие, как img, списки, таблицы, фреймы, теги font, embed и так далее. Появлялись целые языки (Javascript) и сложные архитектуры, такие как DOM. В основном, это было хорошо. Веб увеличивался в сложности и быстро получал жизненно важные функции.
Но ни одна из функций не была изначально стандартизована, никто не разрабатывал стандартов, каждая из них изначально появлялась в одном из браузеров, а другие поспешно реиженерили удачные решения и затем реализовывали самостоятельно, как правило, в виде несколько несовместимой версии.
Из этого периода мы узнали, что выигрывает тот, кто «ходит первым» (к примеру, теги «img», предложенные Марком Андрессеном, несмотря на противодействие Тима Бернерса-Ли, выступавшего за более гибкий механизм, победили и продолжают являться нам по сей день). Решения, принимаемые на уровне архитектуры, может иметь очень длительный период полураспада, поэтому должны делаться особенно тщательно.
Это — обычный пунктик сегодняшних сетований веб-разработчиков; проще говоря, несоответствие браузеров — причина головной боли в веб-разработке. Представьте, каково разрабатывать сайты на самых последних, едва сделанных и плохо документированных функциях, меняющихся с каждым релизом браузеров?
Именно этот хаос видела группа W3C, роль которой, по-прежнему часто не понимают. Цель этого комитета была и остаётся — наладить диалог заинтересованных сторон, чтобы стандартизировать новшества. Чуть позже веб-разработчики почувствовали необходимость отстаивать принятие новых стандартов, и так родился проект Web Standards (который, как ни смешно, в начале этого года заявил, что «Наша работа здесь закончена». Почему это смешно, рассмотрим чуть ниже).
Но похоже, что мы упустили из виду то, что следствием браузерных войн и последующей основой W3C и проекта Web Standards было избегание «балканизации» в Интернете. Мы знали, что для Интернета важна универсальность и совместимость. И мы знали, что Галактика он был в опасности из-за браузерной фрагментированности.
И совершенно восхтительно, особенно, если вы знакомы с событиями Интернета конца 1990-х, с противостоянием JSSS (JavaScript StyleSheets) компании Netscape и CSS, несовместимыми недокументированными DOM, JavaScript и JScript, жестокой битвой между Netscape Communications и Microsoft — на этом фоне мы создали Веб, который не был раздробленным, стандартизируя HTML, CSS, JavaScript и DOM, давая изнурённым разработчикам преимущества такого Веба. Это было замечательное достижение; усилиями многих людей из Microsoft, Apple, Mozilla и Google была сделана большая неблагодарная работа по стандартизации технологий, теми, кто выступал за обучение разработчиков технологиям, основанных на стандартах. Некоторые стали хорошо известны, большинство упорно трудились за скромные награды, но каждый чувствовал, что именно таким должен быть Веб.
А потом, шаг за шагом, подобно той лягушке, которая не замечает своей смерти в медленно закипающей воде, мы выбросили этот Веб.
- Мы позволили, поощряли и приняли фрагментацию DOM библиотеками и фреймворками, в каждом из которых — свой способ доступа к атрибутам, изменению элементов и управлению DOM.
- Мы фрагментировали JavaScript языками, компилируемыми в него.
- Мы фрагментировали HTML тоннами шаблонизаторов.
- Мы фрагментировали CSS препроцессорами наподобие Sass и Less.
Что же мы наделали?
Это не означает, что всё кругом совершенно плохо. Это далеко не так. Каждая из этих технологий и инноваций доставляет разработчикам новые заботы. Многие — намечают пути для будущих стандартов. Но в совокупности, мы взяли относительно простой набор самостоятельных технологий — HTML, CSS, JavaScript, DOM; каждую — со своими четко определенными ролями, каждую — относительно законченную, чтобы освоить и начать работать с ней, и создали хаотичный зоопарк конкурирующих технологий, многие из которых делают ровно то же самое, но несколько иначе и несовместимо.
И на этом пути добавились зависимости от других языков и сред, потому что появилась стадия сборки в рабочем процессе, чего в Вебе ранее не было.
Что же мы получили?
Возможно, разработчики сейчас — более продуктивны. Возможно, мы сделали жизнь проще во время начальной фазы развития проектов. Но есть основания сомневаться, что есть больше, чем отдельные успехи во имя поддержания веры. Поверьте — это общий аргумент любой новой технологии — что она сделает разработку более продуктивной. Вы ведь читали что-то из вашей литературы? (вспомните, как чуть выше убеждали помнить наше наследие.) И разработчики ПО давно поняли, что лишь малый процент стоимости системы относится к начальной стадии её развития. Техническое обслуживание за годы и десятилетия — очень значительная доля затрат на систему (да, есть много литературы и на эту тему).
Но что же мы потеряли?
Когда-то веб-разработки стали отличаться от большинства других технологий тем, что мы говорили на одном языке, некотором Койне, lingua franca, наподобие разработок для Windows, крупнейшей платформы в течение многих лет, где несметное число языков, основ и сред разработки основывалось на Windows API. Эта общность языка принесла с собой ряд преимуществ, в том числе, облегчённое обучение веб-технологиям и упрощение поддержки проектов. Это увеличило жизнеспособность ваших знаний и опыта веб-разработчика.
Обучаемость
Наличие общего набора технологий для фронтенда упростило обучение. Поиск учебников, экспертов и рабочих встреч по этим технологиям было относительно простым делом. Освоение навыков и знаний было относительно просто. Вы можете написать некоторый HTML- и CSS-код и построить что-то полезное. Со временем вы сможете увеличить свои знания о них и добавить понимание JavaScript и DOM, чтобы расширить свои возможности. Был эффект сети из-за существования большой группы разработчиков, имеющих общие языки и концепции.
Действительно ли мы хотим уменьшить этот сетевой эффект путём фрагментации технологий в Интернете, рытьём катакомб институтов экспертизы, с незначительной долей общего языка? Мы должны хотя бы быть в курсе потенциальных последствий нашего выбора. Осознавая не только индивидуальные плюсы от выбора, но и то, что все вместе мы можем потерять.
Ремонтопригодность
Наличие общего набора технологий упрощает поддержание существующей базы кода. Лежащие в основе технологии HTML, CSS, JavaScript и DOM длительное время стабильны в отличие от большинства фреймворков, библиотек, языков и препроцессоров (не говоря уже об инструментах и языках, на которые они частично опираются). Будет ли база вашего сервиса поддерживаться 5 лет? И, основываясь на менее распространенных технологиях, количество разработчиков, способных поддерживать базу кодов, значительно уменьшается.
Традиционно, более половины стоимости сложной системы пришла во время фазы эксплуатации, так что при большой перестройке проще всё выбросить и начать строить заново, чем вести эволюционное развитие программных проектов; то, что мы строим для Интернета, становится все сложнее, и для критически важных проектов фаза обслуживания будет становиться все более длительной и дорогостоящей. И опять же, хорошо понятно, что ремонтопригодность сильно зависит от возможностей разрозненных разработчиков, чтобы понять и иметь причины (мотивацию) поддерживать кодовую базу длительное время, чем просто использовать для правок copy-paste [в языках разметки страниц — прим.перев.].
Взаимодействие
Одним из основных принципов Web является «совместимость». Хотя это непосредственно касается обеспокоенности тем, что «компьютерные языки и протоколы… призваны избежать рыночной фрагментации в прошлом», я бы утверждал, что фрагментация должна не только беспокоить, когда речь заходит о системах с нашим работающим кодом. Мы также должны быть обеспокоены фрагментацией сообщества веб-разработчиков. Чем меньше разработчиков с рабочим знанием технологии, тем меньше возможностей им взаимодействовать по вопросам технологии.
Из этого же круга — вопрос о том, как будут взаимодействовать технологии друг с другом. Скажем, у вас нравится, как Sass реализует переменные, но хочется использовать и @ debug в LESS. Вам нужны и LESS, и Sass, и, вероятно, вокруг разразится чертов беспорядок. Монолитный подход многих «инноваций» значительно влияет на то, как будут взаимодействовать они друг с другом.
Долговечность
Если вы провели годы, развивая знания и опыт в Flash или Silverlight/WPF, это знание становится всё более бесполезным. То же самое произойдет с jQuery, как это было с другими, казалось бы, доминировавшими библиотеками JavaScript и фреймворками, такими как Prototype. Это произойдет со всеми библиотеками и фреймворками, которые мы изучаем сегодня так усердно: AngularJS, Bootstrap, <… подставьте ваше название...>. Очень немногие технологии прожили последние годы, не говоря уже про десятилетия. Как человек, тратящий разумное количество времени в изучение технологий, я был бы озабочен тем, чтобы усилия были оправданы.
Что же делать?
jQuery, Backbone, AngularJS, CoffeeScript, Bootstrap, Sass, LESS (просто назовём некоторые из самых популярных фреймворков, библиотек, языков и препроцессоров, которые мы разработали за последние несколько лет для решения проблем, чтобы делать все более сложные вещи, не выделяя ничего конкретно) являются сложными, мощными технологиями, хорошо проверенные в очень многих рабочих процессах, используемых тысячами, десятками тысяч разрабочиков или более. Они не уходят. И вслед за ними придут другие. Возможно, понадобится медленное погружение из высоких технологий в HTML, CSS, DOM, JavaScript. В конце концов, программисты мало, если вообще, пишут на ассемблере, не говоря уже о машинном коде. Но, как Anil Dash писал о другом Вебе, "мы отказались от основополагающих ценностей, которые были в истоках мира Сети", и я думаю, что это верно и по отношению к создаваемому коду.
Что может быть этими основными ценностями? Нетрудно видеть, что они ясно описаны консорциумом W3C (еще раз, слова Анил: "узнать немного истории, чтобы знать свои истоки").
«W3C стремится к техническому совершенству, но прекрасно понимает, что известное сегодня может быть недостаточно, чтобы решить проблемы завтра. Поэтому мы стремимся построить Web, который может легко превратиться в еще лучший Web, не нарушая того, что уже работает. Принципы простоты, модульности, совместимости и расширяемости лежат в основе всех наших конструкций.»
Цели W3C, принципы работы и их направленность
Руководствуются ли разработчики этими принципами простоты, модульности, совместимости и расширяемости, когда они разрабатывают новые языки? Фреймворки? Препроцессоры? Конечно, во многих случаях — да. Это особенно верно в отношении polyfills и "prollyfills". У них нет цели «вскипятить океан» организацией огромного массива функциональности, а скорее, следуют модели „свободного присоединения небольших кусочков“, которые делают одно действие, но делают это хорошо.
Но во многих случаях наши решения не модульные, не простые или не совместимые (особенно, в произвольных комбинациях). На самом деле я бы сказал, что в этом — суть вопроса. Вместо решения конкретной задачи через простоту, модульность и совместимость, наши решения часто становятся все более сложными нагромождениями решений всех видов проблем. Вот к примеру то, что архитекторы CSS пре-процессора сообщают о принципах конструирования Sass:
»Не существует формального процесса, по которому мы добавляем новые функции в Sass. Подходящие идеи могут исходить от кого угодно и отовсюду, и мы рады рассмотреть их из списка рассылки, IRC, Twitter, сообщения в блоге, из других компиляторов CSS, или любого другого источника".
… которые, скорее, напоминают Гомера:
Свободное присоединение небольших кусочков
В 2002 году один из пионеров веба Дэвид Вайнбергер (между прочим, соавтор из Cluetrain Manifesto) описал " небольшие слабо связанные кусочки " — способ , который делает интернет особым. Я давно думал, что это относится также к технологиям Интернета, и эти принципы должны определять, как мы создаём проекты для Интернета, будь то наши собственные сайты, для наших клиентов, работодателей, или самих технологий, которые развиваются в Интернете.
Если бы каждый раз, когда мы брались решение задачи, мы думали, «как я могу решить эту маленькую проблему?», или даже "в самом ли деле здесь проблема?", и затем решить её на принципах модульности, совместимости, и расширяемости, насколько возможно, то мы выберем долгий путь к укрощению взрыва сложности, который мы видели в течение последнего пятилетия или около того, и возвратимся, по меньшей мере, частично на тот Web, который мы потеряли.
Возможно, этому вебу тоже пришлось бы повзрослеть, чтобы отвечать на вызовы все более усложняющихся моделей, которые мы строим. Когда веб состоял из документов и сайтов, возможно, мы сохранили бы простоту, но в эпоху приложений простота — это роскошь, которую не можем себе позволить. Возможно, с течением времени будут необходимы фундаментальные доработки всех необходимых фрагментов платформ.
Но, прежде чем мы потеряем навсегда этот веб, думаю, что мы должны по-настоящему понять тот веб и то, что обеспечивает его чёткую работу. И когда мы делаем технические, архитектурные решения о том, каким будет веб, мы не должны думать только о собственных выгодах, но также о том, что утратит с ними нынешний интернет.
Автор: spmbt
