Нет, истории будут не про то, как я заказывал лавандовый раф, а мне принесли с сиропом топинамбура.
*в этом абзаце вы узнаете, какой я крутой и почему вы должны это читать*
В начале карьерного пути я был юнцом с битриксом под ногтями и с JQuery в сердце. Тогда для меня было нормальным передавать настройки фронтенда через data-атрибуты и посылать ajax запросы не за модным JSON, а за готовым HTML-кодом. Тем временем в соседнем отделе матёрые фронтендеры писали на хайповом React, который умел много чего удивительного, в том числе и переход по страницам без перезагрузки. Я захотел так же и пошел советоваться с опытными фронтендерами: «А я могу просто перехватывать клик по ссылке, сделать ajax запрос на новую страницу за всем, что лежит между header и footer и вставлять на место текущего контента, подменяя историю?» Ребята посмеялись, на меня стали косо посматривать… Теперь же хайпует htmx, который по сути делает то же самое. Он будто создан для битрикса.
Мораль басни? Она в том, что простые решения самые лучшие — не надо тянуть какую-то технологию, просто потому что «ну, это ж все сейчас так делают». Например, те же микросервисы или микрофронты приносят кучу боли, и писать монолит не зазорно. Все сложности должны быть обоснованными. Я, кстати, на другом проекте сделал как задумывал — работает хорошо до сих пор.
Как-то раз я проводил аудит веб-сайта (с умным видом прокликивал вкладки dev tools) и решил поискать утечки памяти. Сделал пару снэпшотов — и что я обнаружил? Течет. Через пару минут я нашел виновный объект в глобальном стейте.
— Говнокод на Redux, — подумал я.
— Спам логов в консоль, — ответила жизнь.
Вывод тут сами делайте. Кстати, джунам рекомендую выделить один день и прощёлкать все dev tools, начинающий разработчик найдет там много нового.
В начале работы кайф договориться с дизайнером о сетке, чтобы верстка была консистентна, а дизайнеру не приходилось работать pixel perfect. Например, сетка может быть кратна 8-ми пикселям — тогда, если вы видите отступ на макетах 30 пкс, то вы понимаете, что это 32 пкс, ширина 203 пкс превращается в 200 пкс. Размер шрифтов может не соответствовать сетке, но всегда соответствует UI kit, который должен быть у проекта. Он весьма сильно связан с компонентами на фронте и помогает установить «общий язык» между членами команды. Обычно дизайнеры сами всё это знают, но несколько раз я работал с менее опытными коллегами, и эти «фишки» (база) облегчили нашу работу.
Лично у меня подгорает, когда я на сайте кликаю по ссылке колёсиком мыши, а ничего не происходит, когда tab не работает, когда картинку можно скачать только через dev tools. Всем разработчикам таких «продуктов» свойственно одно — DIVиантое поведение (Фить. ХА!). Базовая семантическая верстка не требует лишнего времени и легка в понимании. Хотя бы ради инвалидов, ребята, пожалуйста, напрягитесь.
Мысленно благодарю всех разработчиков, которые оставляют source maps в продакшене. Исходный код такого сайта можно скачать в один клик. Однажды благодаря подобному альтруизму я за три дня сделал кор фронтенд браузерной игры, на разработку которого ушло бы не меньше месяца. Вообще я и сам оставляю открытым исходный код на своих личных проектах, мне не жалко. Если вы хотите защитить свой уникальный функционал от совсем простого скачивания, то лучше будет не выкладывать sourc’ы, подключить Sentry для отлова ошибок на проде и прокидывать карты источников туда. Шифрование, обфускация и прочие методы усложнения кода, в том числе, WAsm, могут отбить желание скачивать вашу интеллектуальную собственность, но всё же полноценного способа защиты фронтенд кода не существует (или я не знаю). Видел как-то сайт, у которого в нетворке не отображался js, а на самой странице была странная пара строк кода, хотя на ней был весьма сложный калькулятор. Как раз эта пара строк скачивала зашифрованный js, расшифровывала его и применяла. Понятно, что и такой код можно выкачать, несмотря на минификацию и обфускацию. Один раз удалось даже зареверсить код на бэкенде путем множества запросов и поиска взаимосвязей между запросами и ответами. Чего уж про фронт говорить.
На собесах иногда разговариваю с кандидатами о том, как понять, что сайт работает плохо. «На глаз», — часто отвечают они. Конечно, визуальный осмотр никто не отменял, но если твой глаз смотрит на 4K, 144 гц, RTX 4080, i9 последнего поколения, а мой — на твою богатую рожу, то мы придём к разным выводам. Дополнительно возникает вопрос о том, что такое “плохо”. Он обычно остается без ответа. Благо умные дяди уже всё померили за нас и создали стандарты, которых стоит придерживаться: Rail model, Web Vitals, Mozilla recommendations. А проверить подходит ли ваш сайт под эти требования можно в dev tools на вкладках Performance, Performance monitor, Lighthouse.
Есть известный способ проверить, будет ли поддерживаться какая-либо технология на какой-либо платформе — https://caniuse.com/. Правда, разработчики браузеров тоже люди и допускают баги, поэтому caniuse не всегда верен. Особое внимание стоит обратить на iPhone.
В прошлом мне доводилось создавать мобильные приложения из сайтов. Как всегда, сначала я предпочитаю рассматривать самый дешевый и простой подход. В данном случае это web view. Честно, не могу понять, почему некоторые компании предпочитают потратить деньги и время на разработку одного функционала под три платформы, когда у их приложения 0 нативных функций. Превратить сайт в приложение на Android можно за 1 день с помощью PWA + TWA. Но iPhone всё равно заставит страдать… и платить…
При перечислении плюсов такого решения упоминают возможность не обновлять приложение в сторах, так как оно качает свой код из сети. Но я добавлю к этому то, что Google может забанить такой аккаунт за неактивность, удалив приложения без возврата средств :)
Если вдруг сломался docker, то сначала просто перезапусти его (как роутер).
Не так давно стало популярным видео о том, как "чистый" код снижает производительность. Я не поленился и решил поперфтестить данные примеры на JS. В итоге оказалось, что применение принципов "чистого" кода, в том числе SOLID, не только не снижает производительность, но и даже повышает её. Так я понял, что JS — это язык, на котором разговаривают боги.
Вообще SOLID часто относят именно к принципам ООП. На самом деле, эти правила хорошо ложатся на прочие парадигмы и на компонентный подход. Например, компонент должен иметь одну зону ответственности, UI-компоненты не должны зависеть от бизнесовых и т. п.
Иногда провожу рефакторинг во время обычных задач, если замечаю проблему, которая быстро решается — поправляю. Рады ли этому тестировщики? Не думаю. Поэтому главное не забыть их предупредить.
В течение карьеры мне повезло получить коммерческий опыт на Vue, React, Svelte, в том числе на всех их SSR производных. Angular, Qwik и Solid я изучал и тестил локально. Поэтому позволю себе наглость порекомендовать вам для новых проектов использовать именно Vue 3/Nuxt, если на вас не влияют имеющиеся компетенции команды. Svelte не пригоден для больших проектов, так как финальный код сильно разбухает, при этом он целиком и намертво ложится из-за какой-то ошибки в одном компоненте. React жирнее и медленнее Vue, сложнее для новичков, при этом нарушает принципы программирования и заставляет разработчиков нарушать их (не закидывайте камнями). Angular неплох, но гораздо сложнее и дороже Vue. Остальные недостаточно популярны и вряд ли предоставляют действительно полезный функционал, ради которого стоит их использовать. Так и получается, что не лишенный минусов Vue остается финальным вариантом.
Конечно, это не все истории и боли. Если увижу, что вам понравилось, сделаю вторую часть про собесы. Надеюсь, Хабр откроет комменты под этим постом, чтобы мы могли обсудить ваши вопросы и утверждения.
Автор: alexey_ym
