Кто похоронит современный веб?
По словам многих фронтенд-разработчиков веб становится все лучше и лучше с каждым годом. И это хорошо. Плохо то, что до хорошего состояния, при таких темпах улучшения, мы можем просто не дожить. Что дно с которого мы поднимаемся, находится так глубоко, что и не выплыть вовсе. Впрочем, о том, как все плохо в связке HTML-CSS-JS, за последние время написано было немало. Так что сегодня обойдемся без горестных стенаний и помечтаем о том что можно сделать и почему это будет сделано.
Правильное начало
Когда вы создаете веб-страницу, компонент, или пишете API, вы так или иначе сталкиваетесь с решениями заложенными 25 лет назад. То, что казалось логичным и правильным в дни создания первых графических броузеров, до сих пор аукается нам каждый день. Врядли у создателя Javascript была в голове концепция создания чего-то похожего на современные веб-приложения. Мобильных устройств, создающих сегодня большую часть интернет трафика, тогда не было и в помине. CSS рассматривался как способ стилизации документа, а как тьюринг-полный язык для создания презентаций. И т.п.
И, год за годом, по мере того как менялся окружающий мир, веб пытался адаптироваться. Изменения наслаивались одно на другое, но при этом старые фичи никуда не исчезали. И они же определяли то, каким образом будут добавляться новые фичи, заранее определяя радиус кривизны последних. Это привело к огромным спецификациям, к фактическому монополизму одного движка на рынке броузеров, к достаточно ухищренным приемам программирования и сборки. А для программистов это все выливается в бесконечное заучивание новых костылей, потому что веб сейчас целиком и полностью определяется наслоением спецификаций, а не здравым смыслом или продуманной архитектурой.
Причем эти спецификации пишутся в надежде угодить всем и в итоге полностью не подходят никому. Хуже того, они вводят достаточно высокоуровневое API, которое не всегда можно обойти снизу, чтобы решить задачу. Так мы на уровне концепций ограничены DOM, имеющимся подходом к безопасности, используемыми протоколами передачи данных.
Больше чем один веб
С самого начала надо признать, что веба как единой платформы сегодня не существует. Существуют разные классы приложений, сайтов, называйте это как хотите, например:
- текстовые сайты типа блогов и википедии
- CRM/ERP приложения
- мультимедийные приложения
- игры
- коммуникационные приложения
- шЫкарные продающие лэндинги
- социальные сети
Каждая из упомянутых категорий приложений требует от веб-платформы свой набор API. Но каждый такой набор упирается в ограничения другой категории. У лэндингов огромные требования к CSS, которые почти нигде больше не нужны. Для текстовых сайтов 90% спецификации веба излишни. API для мультимедийных приложений недостаточен для игр и коммуникационных программ. CRM/ERP и социальные сети требуют более мощных языков программирования, способов организации кода, которые не по карману, да и не нужны текстовым сайтам и лэндингам. И т.д.
Проблемы бы не было, если бы мы имели достаточно низкоуровневое API, которое позволяло пилить нужный вашему сайту функционал без оглядки на остальные отрасли. Но мы имеем лишь набор компромиссов. Если бы было что-то низкоуровневое, типа той же Java, да еще и спроектированной с нуля под нужды современного веба, это решило бы кучу проблем. Мы бы получили нормальный язык без детских болезней, в которым были бы учтены все ошибки последних десятилетий. В том числе главная ошибка — делать стандартным язык, а не условный байткод.
Имея низкоуровневое API можно будет значительную часть платформы засунуть в библиотеки. Да, это трафик. Но мы и так уже пришли к CDN с кэшированием (Press Ctrl+f5 to fix). Набор распространенных и нечасто обновляющих библиотек (там ведь должны быть базовые вещи) принципиально не ухудшит ситуацию. Более того, на фронтенде и так уже привыкли, что много где можно писать только с полифиллами. И те же минорные версии библиотек можно будет накатывать в виде полифиллов, не заставляя пользователя качать все, если только у него не совсем древняя версия.
Нужно спросить себя, а нужен ли в принципе DOM, как центральная структура документа? Может быть достаточно применять его только для некоторых виджетов на странице? А нужна ли сама концепция документа, как центра всего? Нужны ли все трансформации CSS в том виде в каком они есть? Нам точно нужен евент-луп в том виде в каком он есть?
И самое главное — нужна ли нам одна платформа для сайтов и веб приложений? Или нужно смириться, что с современными требованиями мы все равно придем к среде выполнения приложений типа JVM? Но только в одном случае получим ее с тоннами legacy и костылей, а в другом — с чистого листа.
По ту сторону иконки «Интернет»
Для многих пользователей до сих пор существует иконка на рабочем столе, которая олицетворяет черный ящик под названием «интернет». К сожаления для многих фронтенд-программистов броузер также является черным ящиком. И даже те из них кто хорошо (читай широко) знают спецификацию своей платформы, часто не осознают всей сложности реализации этих спецификаций в броузере. То что мы на сегодняшний день имеем сколько-то нормальную поддержку новых стандартов во всех броузерах не означает, что эпоха броузерных войн окончена. Это значит что движок хрома победил. Потому что реализовать движок сравнимой сложности с нуля никому не под силу. То, что работает в хроме, далеко не всегда работает в лисе. Короче мы получили IE6, но на качественно новом уровне.
Справедливо будет возразить, что раз хромовский движок открытый, то нужды писать новый нет, достаточно форкнуть. Тут есть несколько возражений. Во-первых чевертьвековой набор костылей так и останется с нами. Во-вторых поддерживать такую махину без огромных финансовых вливаний невозможно. Именно что финансовых, потому что опенсорс сообщество не показало особой эффективности в создании броузерных движков. На это много причин, и главная из них то что броузер это не про программирование, это про реализацию спецификаций, написание тестов, проверки чтобы ничего не сломалось, многочасовые компиляции. И все для того чтобы получить то же самое что делает оригинальный хромовский движок, только чуть хуже. Потому что новый движок не будет совместим с хромовским, а пользователям в массе нужно только это.
Производительность является еще одной важной для пользователей характеристикой. Но сделать новый движок кардинально быстрее вряд ли получится. Мы будем ограничены моделью DOM, из V8 уже выжали все возможные теоретические оптимизации (, а из-за него JS и так уже самый быстрый скриптовой язык в мире).
Монополия
Но давайте и о хорошем. Фактический монополизм Google на веб-платформу, ее огромные ресурсы и авторитет, все это может стать ключом к созданию нового веба. Весь мир подсажен на сервисы гугла, а, например, фейсбук и нетфликс генерируют значительную долю мирового трафика. Это уже создает предпосылки для того чтобы решения от союза таких монополистов было донесены до огромного числа людей. И этим людям в принципе все равно как это будет выглядеть, главное чтобы работало.
Если появится условный App Browser, который будет навязчиво предлагаться на всех страницах гугла и фейсбука, то у него уже как минимум будет шанс на успех. А если в версиях «сайтов» для него от оных компаний будет больше функционала, чем в традиционных веб-приложениях, то переход будет гарантирован. Не говоря о том, что какие-то сервисы могут быть в принципе доступны только в новом виде. Сложившаяся монополия дает шанс на такой эффективный переход, ну или как минимум на отвоевание новой платформой значимой доли рынка. А там как-нибудь запинаем.
Ведь даже самому гуглу может оказаться в перспективе дешевле поддерживать броузер нового типа. Часть платформы можно будет спихнуть на сообщество, которое будет пилить библиотеки. А сама работа станет проще, потому что движок будет не таким монструозным by design.
Будет ли такое решение от монополистов обязательно лучше? Думаю да. Почти в каждой дискуссии посвященной проблемам веба можно найти людей, которые раньше писали приложения на Delphi/QT/WPF/WinForms и т.п. При этом они были глубоко несчастны, и только переход на веб-стэк открыл им способ безболезненного создания GUI приложений. Возможно это и так. Но есть и мнение, что написание приложений для современного веба — это удаление гланд через задницу, причем операция затянулась минимум на 10 лет.
Поэтому вопрос не в том, кто прав, а какой подход доминирует на рынке. Не важны даже причины доминирования — при должных ресурсах и пиаре на рынок можно пропихнуть любую дрянь. Потом на нее кто-то подсядет и процесс станет самоподдерживающимся. Поэтому у гугла есть все шансы выкатить что-то свое, каким бы плохим оно не было.
А сделать хуже чем сейчас надо постараться, потому что как минимум современная платформа будет делаться не за 15 дней и под сегодняшние требования. И к тому же компания, сделавшая ставку на такую рискованную технологию, будет стараться всеми способами компенсировать эти риски, не делая совсем уж откровенной фигни. Тем более что другие крупные компании могут воспринять такой шаг как отмашку для разработки собственных конкурирующих решений.
Возраст дожития
Конечно, неприятно хоронить свой опыт по работе с имеющейся платформой. Но количество легаси хватит минимум лет на 10, даже если прямо завтра гугл разродится новым решением, а послезавтра App Browser будет стоять на 100% компьютеров в мире. Тем более, что будучи спроектированной с нуля, платформа (возможно) не заставит вас учить несколько форматов модулей или способов отцентрировать элемент по вертикали. И вы сможете применить свой прошлый опыт программирования, а не вызубривать исторически сложившиеся костыли. Хотя бы первые несколько лет.
Ну, а со стороны броузеров разработчики смогут наконец сосредоточиться только на багах и проблемах безопасности. А их много, в такой кодовой базе их просто не может быть немного.
Экономия на чем?
Когда говорят про современный веб как панацею для быстрого изготовления дешевых веб-приложений и сайтов, имеет место некоторое лукавство. Во-первых веб просто оброс типовыми решениями типа движков CMS, веб-магазинов, веб-компонентов и прочего, в которые уже вложены миллионы человеко-часов. Это эффект наработанной базы. Более того сейчас есть куча программистов специализирующихся на одних и тех же типажах сайтов, которые вносят минимальные правки в фактически готовый продукт и продают его следующему клиенту. Опять же, тут нет никакой магии или эффективности веба, просто стал более-менее понятен рынок готовых решений. И сегодня веб по количеству готовых решений активно теснится персональными мобильными приложениями, которые может позволить себе даже семейная пиццерия. И не всегда там обертка для веб-приложения. Это к тому, что вокруг популярной технологии всегда будет образовываться экосистема готовых решений, которая будет сильно снижать стоимость типовых решений на базе этой технологии.
Если попытаться с нуля сделать нормальный движок того же веб-магазина, то выяснится, что это ни разу не просто. Да, я знаю, что многие тут сидящие делали это. Но насколько вы оцениваете безопасность своего решения? Вы точно можете по памяти перечислить все типы атак, которым может быть подвержено веб-приложение? Проверяли ли как ваш магазин будет выглядеть на разных экранах, начиная от 4-дюймового смартфона-заглушки и кончая здоровыми десткопными мониторами? Рассчитывали на работу в устаревших броузерах и без JS? Хотя бы за пределелами Firefox и Chromium-based броузеров.
Скорее всего вы всего этого не делали. Вы просто осознанно выкинули расходы на реализацию этого. Потому что вы знаете на чем можно сэкономить и с вас за это не спросят. Но так можно поступить на любой программной платформе. Просто на веб опытным путем все поняли на чем можно сэкономить, и поэтому та же accessability не реализована практически нигде. Но это не заслуга веба, это результат устоявшегося рынка, когда заказчики просто пришли к подмножеству фич за которые они готовы платить. И перенести старые требования на новую платформу не составит никакого труда. Тем более что под боком есть замечательный пример мобильных приложений, которые с каждым годом отъедают все большую долю у традиционных веб-сайтов.
Заключение
Современный веб это чистейшее легаси живущее по принципу «так исторически сложилось». Технология умирающая под своей тяжестью, для работы с которой только одна компания в мире может поддерживать 100% работающий инструмент. И тем не менее критика веба воспринимается многими как святотатство. Мы привыкли к DOM настолько, что уже просто не мыслим другими категориями. Хотя тут же берем и строим интерфейс опираясь на веб-компоненты. И не думая при том, что коль мы все равно оперируем абстракциями, то почему бы не поменять их реализацию на более эффективную? Тем более, что сейчас, в связи с наличием на рынке интернет сервисов крупных монополистов, создание новой платформы более чем реально.
