Современные фронтенды
Вам будет полезно прочесть статью если:
вы заказчик разработки или разработчик, который хочет запустить продукт
у вас стартап, в особенности на ранних стадиях
ваш продукт имеет веб-интерфейс
вы хотите сделать как можно больший результат за как можно меньшее время
Цель статьи: дать несколько иной от общепринятого взгляд на фронтенд часть, который возможно поможет сэкономить вам много времени и денег.
Мы будем делать по-своему, не так как все. Профессионалы могут себе это позволить, потому что могут отличить когда применимо одно, а когда другое, и где можно отойти от норм. Можно нарушать правила когда их знаешь, принимать решения осознанно и взвешенно.
Я поставлю под сомнение то, как сейчас принято по умолчанию делать web. И в моём случае этот не-дефолтный подход не будет костылём или велосипедом (как на меме ниже на участке IQ 70), а будет правильным управленческим и техническим решением. Которое в итоге приведёт к преимуществу над всеми, кто делает одинаково.
Преимущество это будет заключаться в том что мы решим нашу задачу в 3 раза быстрее чем они. И дальнейшее развитие будет идти быстрее, меньшей командой и меньшим бюджетом. У нас будут меньше расходы, и следовательно больше прибыль (или меньше минус). Мы будем двигаться быстро, подстраиваясь под рынок.
Именно это является важными факторами для стартапов, тех кто находится на ранней стадии и делает MVP. Если у вас горы денег и сотрудников, то для вас все дальнейшие рассуждения не релевантны.
Каждая технология и подход имеет область применимости. Чтобы понять, сможем ли сэкономить на «современном фронтенде», давайте определимся с тем какую задачу мы решаем. Тут я предлагаю выбрать одно из двух, ответив на вопрос: ваш проект выглядит скорее как приложение или как web странички? Не с точки зрения реализации (реализовать можно что угодно и как угодно, вопрос эффективности), а с точки зрения смысла. И под этот смысл мы и будем подбирать реализацию. Чтобы ответить на вопрос, вспомните как было лет 15 назад. Были десктопные приложения, приложения в браузере тоже были, но редко, например игры на flash’е. И были сайты, интернет магазины, площадки. Всё второе — это всё web странички, и неважно какой сложности там бизнес-логика. Мы сейчас говорим про интерфейс. Он либо скорее приложение, либо скорее web-странички. Если вы сомневаетесь, то ваш случай скорее всего относится ко второму. Если вы считаете что приложение, то контрольный вопрос: если из этого сделать десктоп приложение, оно будет иметь смысл, будет ли это удобнее с точки зрения использования? Примеры когда будет: игры, figma, miro, telegram. В приложениях есть много органов управления, большая динамика, горячие клавиши и прочее. В приложении сидишь и работаешь, там происходит какой-то длительный процесс. А не зашёл, сделал заказ и вышел.
95% сайтов которые есть в интернете — это как раз web странички, а не приложения. Но если вы попадаете в оставшиеся 5%, то дальнейшие рассуждения для вас тоже не релевантны. Сэкономить на фронтенде не получится, потому что фронтенд в этом случае является одной из ключевых частей, ведь конечный продукт и результат делается вокруг интерфейса.
Итак, мы расставили break’и в этой статье и теперь находимся в точке где уже понятно что:
мы делаем web проект
при этом не приложение
мы хотим экономить на разработке
Вернёмся снова немного назад в историю. Термин frontend это относительно молодое понятие. Раньше не было фронтендеров, были верстальщики. И они не называли себя разработчиками, кстати. Им на вход давался макет в фотошопе, а на выходе они отдавали архив с вёрсткой в формате html + css + js. Дальше программисты «натягивали» эту вёрстку на «движок». Верстальщики думали про совместимость с разными браузерами, про поддержку Internet Explorer старых версий, про адаптивность и мобильную вёрстку. Потом это дело начало развиваться, появился sass, less. Потом angular со своим знаменитым to-do листом в качестве демо. Потом верстальщики с мотивацией о том что нужно что-то упростить, решили усложнить всё остальное. Придумали vue и react. Переименовались во «фронтенд разработчиков». Кто не хочет быть разработчиком? Разработка — это что-то сложное, вот они решили что у них теперь сложное, значит можно называться разработчиками.
Сами фронтендеры не считают что «современные фреймворки» сложные. Они меня постоянно убеждают в том что react облегчает им что-то. Но большинство из них молодые (после курсов о том как вкатиться в IT) и не застали тех времён. Ответ я нарисовала на схеме:
Фронтендеры находятся в мире где существует только SPA (single page application), поэтому сравнивают react с тем чтобы делать то же самое не на react, а изобретать самим. Но кто сказал что нужно делать то же самое! Для большинства задач можно откатиться назад и выбрать SSR (server side rendering) вместо SPA.
SPA и SSR это два разных подхода. SPA — это приложение в браузере, оно исполняется на клиенте, то есть в браузере. Бывало такое что заходите на какой-то сайт и начинает вентилятор крутиться? Это оно. SSR исполняется на сервере, вентилятор крутится у них там, а не у вас. Сервер выдаёт готовую HTML страницу, которая просто отображается в браузере. Но это не значит что с таким подходом мы не можем в браузере чего-то реализовать. 99% любого функционала можно сделать на технологиях классической вёрстки. Там где нужна динамика и частичное обновление страницы, можно сделать на ajax или websockets. И обмазывать этим можно точечно те места, где это требуется. Количество этих мест обычно оооочень далеко от 100%, чтобы ради них страдать с SPA по всем пунктам, перечисленным выше.
Именно так делали web проекты раньше. И делали, кстати, вполне себе сложную бизнес логику. Не сказать что мы сильно продвинулись по части интерфейсов за эти 10 лет. Если конечно смотреть на конечный результат с точки зрения пользователей, а не зарплаты версальщико-фронтендеров. Facebook, вконтакте, инстаграм, avito, cian, ozon, yandex, всё это существует давно и не то чтобы что-то в их интерфейсах сильно улучшилось за 10 лет (если не ухудшилось).
Что имеем в итоге. React стал модным и теперь это дефолт-технология для того чтобы делать веб-интерфейсы. Кстати, поскольку теперь всё стало сложно, то можно не заморачиваться с тем чтобы поддерживать «старые» браузеры (это те которым больше 3х месяцев с обновления), про Internet Explorer все и думать забыли. Теперь если браузер не очень, то вполне нормально повесить плашку на весь экран с предложением поменять браузер. И неважно что на самой странице — рокет сайнс интерфейс или простой текстовый сайтик. Адаптироваться? Нет. Не ронять конверсию с рекламных заходов? Нет, это не наши проблемы. SEO? Пффф.
Вы может обращали когда-нибудь внимание на такие вещи как:
неработающая браузерная кнопка «Назад»
меняется содержимое страницы — не меняется url, сложно отправлять ссылку
несогласованность данных на странице, в одном месте обновили элемент, в другом забыли, например счётчик
что-то не работает? «почистите кеш»
Это происходит из-за того что инструмент используется не по назначению. Мы получаем в довесок к сомнительным плюсам (они не особо актуальны для веб страниц) ещё ряд минусов (не актуальны для приложений, но для веб страниц важны). Раньше, когда делали по-простому, таких проблем не было по определению, из коробки. Теперь про эти вещи нужно заранее подумать и закрыть костылями. Возникает дополнительная работа, и эти детали не сразу заметны, не все внимательны на 100%, про что-то забывают или забивают. В итоге возникают баги в неочевидных местах. А иногда фронтендеры ещё и говорят «ну вы не просили URL поддерживать, мы и не делали». А ничего что это само собой разумеющееся? Про гигиенический минимум для SEO я даже молчу.
Ну хорошо. Допустим уговорила, фронтенд делать сложнее и дольше. Зато! Реализуется принцип «разделяй и властвуй». Бекендеры могут улучшать свои бекенды, фронтендеры могут якобы независимо улучшать свои фронтенды, эти единицы могут масштабироваться независимо друг от друга. Красота. Но в чём подвох?
А подвох в том что делить нужно то что делится, а не то что не делится. Представьте, вы — водитель. У вас 3 основных органа управления машиной: педали, руль и коробка передач. Реализация подхода «разделяй и властвуй» здесь была бы нанять отдельного человека на педали, отдельного человека на КПП и отдельного на руль, а вы, как менеджер, будете им тикеты ставить «нажми сцепление», срок 30 секунд. «Переключи скорость с первой на вторую», срок 40 секунд, но после того как первый выжмет сцепление. Если же произошёл рассинхрон, то придётся откатывать операцию и начинать заново. А ещё надо общаться не в директивном тоне, а говорить «пожалуйста» и «спасибо», иначе исполняющий обязанности кручения руля может выгореть и придётся искать нового. А потом, когда окажется что мы не справляемся, не успеваем доехать из точки А в точку Б, какое решение примет менеджер? Что нужно больше исполнителей, например взять на педали 2 человека, один пусть нажимает на сцепление, а второй — на газ и тормоз. Вы меня поняли.
А что нужно сделать вместо этого если оно не работает? Правильно. Вернуться к истокам. И я тоже предлагаю вернуться к истокам. И не смотреть что так сделано в гугле или яндексе. Это совершенно не значит что вам для вашей задачи, в ваших условиях, с вашими ресурсами и целями нужно делать как они. Большие крупные корпорации могут позволить себе многое, то что стартап себе позволить не может. Не надо делать как все, иногда стоит пойти в обратную сторону. И этот уникальный путь станет преимуществом.
Так вот, вернуться к истокам. А именно — к SSR. Не обращать внимание на этот путь в 10 лет, он был сделан для другого класса задач. А мы делаем по-старому, это работало, работает, и будет работать. Гнаться за модой не обязательно, это касается и других современных тенденций, но об этом в следующий раз. Если мы говорим про web интерфейс со своим дизайном, то схема создания продукта такая:
Дизайнер делает дизайн всех страниц
Верстальщик его верстает в формате проектной работы, т.к. «вход» и «выход» определены, конкретны и приёмка результата проходит просто
Бекендер берёт готовую верстку и натягивает её на свой «движок»
В некоторых случаях можно обойтись без дизайна и вёрстки, купив готовый шаблон. Собирать из кирпичиков проще чем с нуля вёрстку делать, этому намного легче обучиться и бекендер, приложив немного усилий, может стать фуллстеком, способным затаскивать проекты в одно лицо. Получаем одного водителя, а не целую команду, которая переводит друг на друга стрелки. Не нужно нанимать бекендера и фронтендера и менеджера им впридачу.
Подводя итоги, у вас, как у человека, который заинтересован в конечном результате и ограничен в ресурсах, есть выбор. Страдать вместе со всеми или делать просто. Искать бекендера, фронтендера и менеджерить их, бесконечно допиливать то одно, то другое, чинить баги которые вылезают в неожиданных местах. Либо выбрать короткий путь к цели. И я говорю не только про первичное создание, но и про развитие и поддержку.
Я специализируюсь на создании MVP. Его можно сделать и за день, и за неделю, если уметь срезать все углы, в том числе и фронтенд.
