Хабрахабр

Почему веб такой сложный?

Добавлю свое мнение, и буду рад услышать мнение других. Обсуждение итогов года во фронтэнде внезапно стало предметом дискуссии.

Да и "внутри" имеет несколько уровней. Как мне кажется, имеет смысл поговорить о том, что то, что творится в современном вебе, воспринимается снаружи и внутри совершенно иначе. Взгляд "они опять усложняют верстку" с одной стороны абсолютно корректен, а с другой — ошибочен и порочен, но и взгляд "не мешайте нам строить абстракции" тоже неэффективен.

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

image
источник картинки

Это и классические веб-сайты и SPA, и приложения на электроне, и мобильные приложения на cordova, NativeScript, React Native, и даже на Flutter. Под современным фронтэндом и его друзьями сейчас понимают куда больше, чем кажется со стороны. Это сложная инфраструктура с CDN-ами, геодецентрализованными службами, это чат-боты на JS, и даже инструменты машинного обучения для оптимизации сборки и даже генерации верстки.

Я сам успел пару лет назад прикоснуться к разработке полноценного браузера генома в браузере — я занимался обеспечением перформанса и 60FPS, что было достаточно большой, но решаемой проблемой. А в самом вебе появляются чудовищно сложные решения, которые раньше могли работать исключительно в десктопном режиме. Еще лет 5 назад никто и подумать не мог, что браузер генома мог бы быть не чем-то устанавливаемым на мощный компьютер, а это решение позволило врачам и исследователям работать с геномом даже с планшета или легковесного ноутбука.

Почему?

По КПД в часах разработки на потенциальную аудиторию и доступность — веб-технологии опережают и мобильные, и десктопные решения. На данный момент связка HTML+CSS+JS является одной из самых мощных в вопросах построения интерфейсов — не только за счет своих возможностей, но и количества решений, построенных на ней — css-фреймворки, библиотеки визуальных компонент, интерфейсы к огромному количеству сервисов и SAAS. И сейчас она распалась на целых три направления:

  • Разработка полностью статических и около-статических сайтов с частично динамическим контентом (галереи, попапы и так далее)
  • Разработка "классических" веб-приложений на серверных фреймворках (django, rails)
  • Разработка клиентских веб-приложений

И каждое из них обладает абсолютно отличающейся от других спецификой.

Разработка на JS действительно была болезненной, поэтому начали появляться решения, которые решали эту боль.

Но они быстро угасли, и на их место пришли инструменты, позволяющие максимально эффективно повторно использовать код, статически обнаруживать ошибки, и строить эффективные абстракции, "пряча" отдельные уровни сложности за простыми и хорошо описанными интерфейсами. Если посмотреть на них, можно увидеть кое-что очень интересное: сначала начали появляться решения вроде jQuery и CoffeeScript, уменьшающие избыточность и многословность языка.

Появились TypeScript и Flow, которые решали проблемы нехватки типизации. Появился GraphQL, решающий проблемы со сложностью описания, документирования и поддержания REST. Появился WebAssembly, позволяющий переиспользовать код из других языков, и делать это быстро. Появились новые сущности языка, позволяющие эффективно работать с асинхронными операциями, классами, потоками данных.

Они решают проблему с тем, чтобы взять чужой код и начать использовать. Все эти решения направлены на одно и то же: переиспользование кода и потенциал построения "плоских" команд.

Это явное свидетельство того, что веб развивается в сторону работы в больших командах, он стал платформой для "взрослых" решений.

Это очень важный момент: за отсутствием возможности использовать в вебе другие языки, компании начали подстраивать свои процессы в поисках "серебрянной пули", которая им позволит сократить далеко не маленькие затраты на разработку и время на доставку нового функционала до всех клиентов. Еще более явным свидетельством стал ряд событий, произошедший дальше: появились React Native, NativeScript, Dart + Flutter и другие решения для переиспользования кода на нативных платформах. Любому проекту важно быть быстрым, и специалисты высокого уровня начали объединяться в поисках возможности эффективно работать на JS.

Невозможность расширить, необходимость знакомить разработчиков с новым языком, риск отмирания платформы, децентрализованность привели к тому, что начали предпочитать шаблонизаторы фреймворков, которые старались быть как можно ближе к платформам HTML/DOM. Кстати, по этой же причине начали частично отмирать шаблонизаторы: использование еще одной семантики показало себя менее эффективным, нежели использование знакомого всем HTML с небольшими расширениями на JS (Angular, Vue) или использование просто языка для описания верстки (React, Flutter).

Если язык позволяет работать сверх-быстро, но при этом синхронизация отдельного функционала между двумя разработчиками создает чудовищную боль, он скорее всего остается нишевым. Однако, помимо эффективного написания кода, есть еще и "коэффициент" для синхронизации команды. Они уменьшают этот "коэффициент", говорящий о том, сколько джуниоров может одновременно контролировать миддл, и сколько миддлов может контролировать ведущий разработчик. Поэтому многие возможности языка и решения направлены именно на уменьшение проблем с синхронизацией и отсутствием проблем. Он не должен быть красивым, он должен хорошо синхронизироваться. Из последних примеров таких возможностей — es6 imports частично решают в том числе проблему циклических зависимостей, а prettier позволяет получить ожидаемый, хорошо поддающийся merge-ам в git-е код вне зависимости от того, как пишет сам разработчик.

Кстати, основная претензия к почти-монополии Google на веб в лице Chromium и заключается в том, что они проталкивают в возможности веб-платформы и JS то, что им нужно (хотя это обычно совпадает с тем, что нужно большинству компаний). И в итоге за буквально несколько лет веб как платформа была захвачена большими компаниями и серьезными командами, отчего у большинства случилась "усталость от javascript".

Но... В итоге мы получили с одной стороны совершенно восхитительную платформу для переиспользуемого везде кода, синтаксис, позволяющий работать большими плоскими командами.

Все стало сложно и все запутались

В чем, собственно, проблема? И никто не понимал, что делать. В тех самых трех отличающихся категориях.

  • Разработка полностью статических и около-статических сайтов с частично динамическим контентом: для этого типа приложений характерен HTML как точка входа, максимальная скорость загрузки и опциональный JS
  • Разработка "классических" веб-приложений на серверных фреймворках (django, rails): для этих решений на данный момент характерна загрузка c HTML как точкой входа, но вместо максимальной скорости загрузки они акцентированы на переиспользовании кода, DRY и интеграции с бэкэндом. JS-код частично сгенерирован фреймворком (нотификации, формы, турбо-ссылки и так далее), частично надо писать самим
  • Разработка клиентских веб-приложений. Вот тут происходит неожиданное: HTML вместо точки входа становится одновременно манифестом приложения и платформой рендеринга, а "точкой входа" становится JS.

Если пользователю нужно показать информацию, то нам нужен HTML+CSS, если запустить приложение — нужен JS, который запускается из HTML. Что я подразумеваю под точкой входа: это некая сущность, загрузка которой равна минимальной доставке до пользователя продукта.

И, чтобы запутать всех окончательно — появилась четвертая категория:

Изоморфные приложения

В таком режиме умеют работать приложения на react, angular, vue.js, есть готовые фреймворки — Next и Nuxt, например. Под "изоморфным" в веб-разработке обычно подразумевают нечто, что работает и на сервере, и на клиенте.

Иначе говоря, они должны доставить и HTML, и JS как две точки входа, одну для контента, другую для приложения. Для них актуальны обе задачи: веб-приложение должно и доставлять свое изначальное состояние до пользователя максимально быстро, и выступать в качестве приложения. Для JS это решается чанками вебпака, code splitting-ом и динамической загрузкой кода, шаблоны уехали в JS, но остается еще CSS. Это создает два противоречащих параграфа: с одной стороны, объем доставляемых данных должен быть минимальным, с другой — нужно переиспользование кода. А потом кому-то в голову все-таки дошла идея: у таких приложений действительно две точки входа. А самое главное — нам хочется не доставлять ни одного лишнего байта пользователю. Их можно обрабатывать как две автономных сущности.

Из этого и родилась концепция CSS-in-JS, сфокусированная на двух отдельных процессах: генерации CSS-файла для статического контента, и сохранения стилей рядом с компонентами.

Все уехало в JS.

Теперь в JS можно найти и стили, и верстку, и собственно код.

Теперь все в JS и это хорошо

Стоит сделать еще одно отступление — теперь в продуктовую сторону.

Это действует на любом из уровней: Любому продукту в разработке или развитии важно иметь возможность "перехода" в другую сторону.

  • Необходимость переписывания его с нуля — не круто. Возможность превратить визуальный компонент в компонент с минимальной логикой добавлением строчки кода — это очень круто.

  • Разумнее, если это не накладывает издержек, начинать с самого начала с такой платформы. Дешевое превращение в SPA или в приложение с серверным рендером — это действительно круто, но это очень редко возможно.

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

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

Они сложные в понимании. В случае с приложением на angular/react/vue это именно так. Но они дают возможность за несколько часов сделать то, что раньше делалось несколько недель, а за несколько дней — то, что раньше занимало несколько месяцев. Не так сложны, как Angular 1, конечно, но все равно — путь к их осознанию долог, и полугодичных онлайн-курсов не хватает для их понимания.

Впрочем, верно и обратное — многим они не нужны, но их используют, потому что "модно".

Сейчас это настолько разные направления, что пересечений по знаниям у них не будет, кроме JS. Когда разговаривают архитектор инфраструктуры группы веб- и мобильных приложений и верстальщик — им будет чертовски тяжело.

Когда вы в следующий раз захотите сказать "веб стал очень сложным и раздутым" — подумайте о том, насколько сложно проектировать и делать почтовый клиент уровня google inbox (с интеллектуальными сущностями, включающимися в зависимости от письма), Web IDE типа Cloud9 или интернет-банк.

Но если к вам придет верстальщик и начнет рассказывать про то, что ему нужен react, потому что ему нужна строгая типизация и декораторы для верстки лэндинга, не поддавайтесь на уговоры.

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть