👆К чему я это все. Про оптимизацию фронтенда.

Я провела небольшой ручной тест в консоли браузера и была в шоке 🤯

Вы молодцы, что угадали. Обычный плюс - это самая быстрая склейка строк. Хоть и самая опасная. Зато примитивная 😋

Так что в случае острой необходимости оптимизаций вы теперь знаете, куда смотреть.

Всем шустрого веба 🔥

👀 Вы когда-нибудь задумывались, что ваши глаза могут вас обманывать?

А это может действительно искажать восприятие у пользователей. Но прежде, чем я расскажу, к чему это все, давайте проведём тест. Посмотрите внимательно на картинки выше ☝🏻

#meh

📐 Точность против UX

Оказывается, что объекты, математически точно выровненные по вертикали не являются таковыми для глаз пользователей. И чтобы это исправить, надо поднять объект немного выше геометрической середины. Не знаю, байка или нет, но мне квадрат на левой картинке сразу показался выровненным нормально 😂

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

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

Всем мир ✌️
С душой, с заботой, с 200 ОК 🎁

Пы.Сы. математически выровненным является квадрат на картинке 1

​​🎨 А где дизайн?

Когда работаете над своим проектом, чаще всего у вас нет навыков дизайна. Вы пришли кодить сайт, а не рисовать его прототип. У вас есть в голове идеи, и вы - окрыленные ими - сразу влетаете сразу в разработку. И… ничего не получается сделать! Бывало такое?

Всё потому, что лучше в начале пути задать себе (или команде) вопрос "а где дизайн?" и заняться его проработкой. Это не дороже ваших нервов 😉

Вот несколько простых вещей, на которые стоит обратить внимание при разработке своего первого дизайна:

⭐️ референсы (насмотренность помогает реализовать свои идеи в зародыше; обратитесь к Behance, Dribble или Pinterest)

⭐️ палитра (выбираем свои цвета, например с Adobe Color)

⭐️ цвет определяет действие (если пользователь должен нажать на кнопку, она должна бросаться в глаза, но если это не целевое действие - делаем ее менее заметной, неяркой)

⭐️ согласованность требований (рисуем только то, что будем реализовывать, без фанатизма)

⭐️ один цвет для активных контролов (он должен побудить к действию)

⭐️ ровные отступы (чтобы все 4 измерения были одинаковыми или похожими; исключениями могут быть кнопки)

⭐️ кратность отступов (лучше, если размер отступа делится на 4, реже на 5)

⭐️ читабельность (говорим "нет" - контрастным цветам для текста, особенно их комбинациям)

⭐️ единство композиции (шрифты одного размера, одинаковый форм-фактор у кнопок и т.п.)

⭐️ все состояния (например, active, hover, disabled для кнопок, выделенные табы, авторизованный/неавторизованный пользователь шапке, открытый/закрытый дропдаун, пустой экран, экран ошибки и т.п.)

⭐️ все размеры (десктоп, планшет, мобилка - минимум)

⭐️ качество картинок (если добавляем иконки/фото в макет - сохраняем их отдельно, чтобы можно было использовать на сайте в лучшем качестве)

⭐️ минимум шрифтов (не больше двух на проект)

⭐️ подложка под иконки на фоне (добавляем обводку/тень/подложку на иконки, которые используются, например, поверх картинок)

⭐️ иконки в размер шрифта (не вылезают за границы текста по высоте)

⭐️ ...

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

#NoJS #basics

❤️ Как веб помогает помнить

В этот день 10 лет назад мир потерял легендарного предпринимателя, одного из основателей огромной корпорации Apple - Стива Джобса. Этим сегодня говорит техническое сообщество, но я хотела затронуть другую его сторону. Сайт Apple - это витрина продуктов компании. Но не сегодня. Сегодня это ремайндер о великом человеке. И это сделано на сайте.

Вы задумывались, что создатели сайтов (как и любые другие создатели) - это создатели памяти? Мы делаем продукты, которыми (в лучшем случае) будут пользоваться и после нас.

Господа-веберы. Каждый раз, когда делаете задачу, когда перекрашиваете кнопку, помните о будущем. Это ваша ответственность.

📍Мы. Делаем. Историю. Спасибо.

#meh

🔥 Нет проблем, есть кросс-браузерность

Вы же помните, что фронтендер - это ниндзя в вебе? Почему? Да потому что ему то и дело надо успевать поддерживать новые браузеры и фичи в них.

Минутка историй. Сегодня с командой осознали всю боль новых фичей чудо-машины под названием Safari. iOS 15 предоставил пользователям возможность перенести адресную строку вниз браузера. И… сделал это поведение по-умолчанию! Эта адресная строка (внимание) находится поверх основного контента! Представляете, как классно быть разработчиком чата, в котором поле ввода всегда находится внизу? 🤩

Боюсь представить, что будет в Safari на новых маках, представленных сегодня. Челка явно даст о себе знать. Неужели придётся раздвигать топлайн… 🤔😱

#meh

🥇 Mobile First

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

Последнее время слышу много разговоров про концепцию Mobile First. Но так никогда не могла до конца понять, что это, кроме «ну мобилку надо сверстать». Погнали разбираться вместе 🙃

Mobile First в разработке = начинаем верстать сайт с версии для мобилки. Затем «растягиваем» верстку до размера планшета и десктопа.

Этот концепт можно осмысленно объяснить так. Мы привыкли, что мы читаем слева направо. Для нас точка отсчета всех стилей начинается с левого верхнего угла. Верстаем сайт с этой точки и постепенно растягиваем его вправо и вниз.

Какие профиты:
✅ сайт сразу адаптирован под все разрешения, не требуется чинить скролл для «убегающего» контента
✅ более осмысленные отступы между элементами. Не нужен margin-top в общем случае, т.к. мы соблюдаем направление верстки вниз и вправо. Это позволяет убрать любой элемент из верстки без случайных "прилипаний" других элементов
✅ четкие брейкпоинты в media queries. Если сказали, 1024px, значит и берем min-width: 1024px. Это означает, что с 1024px верстка будет перестраивается в то, что ожидает дизайнер. Всё четко, без всяких условностей и декрементов.

Проблемы:
💔 нужен дизайн мобилки, а он не всегда есть для MVP. Однако всегда можно покреативить и самому придумать мобильную версию 😜
💔 потенциально дольше верстать (хотя это спорно, когда знаешь сам принцип + в будущем экономия времени на адаптив)

Выглядит, как минимум, интересно…

#advanced

🎁 Бонус. Новичкам в копилку.

Дефолтные брейкпоинты для адаптивной верстки

- 320px (меньше мобилку сложно найти)
- 768px (iPad)
- 1024px (iPad landscape)

*дополнительно для широкоэкранных мониторов и особых случаев*
- 1200px
- 1440px

Всем красивого адаптива 🎨

#advanced

​​🛑 Strapi как замена бекенду

Ребяты, привет 👋

Если я скажу, что бекенд нам больше не нужен, как вы отреагируете? А если скажу, что нам не нужен фронтенд? Нет, нас не собираются заменять роботами (я надеюсь), но ситуация всё равно интересная. #щачёрасскажу

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

Strapi - это Handless CMS, open-source решение для таких горе-разработчиков, как я - не умеющих в разработку полноценного API. И он написан на JavaScript 😏

В чем смысл: вы поднимаете небольшой сервачок, который предоставляет вам админку. В этой админке вы можете создавать нужные сущности (как если бы вы это делали на настоящем бекенде), связи между ними, а также наполнять вашу БД данными. Да, БД сразу будет подключена без лишних танцев с бубнами (вы можете выбрать ту, которая вам больше нравится, по умолчанию подключается SQLite). Strapi на основе созданных сущностей САМ генерирует для вас "хвостики" API, за которые можно спокойно "дёргать" из фронта. Причем, дёргать можно как какие-то простые GET-запросы за списком, так и любые сложные фильтрации или патчи.

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

С меня однозначно лайк! А еще у ребят очень красивый сайт и куча подробных гайдов для новичков 😍 Линки прикрепляю. Всем быстрой разработки ✌🏻

#advanced #noJS

ку 🙃 я вернулась) и у меня есть немного много фронтендерского контента 🤓
сегодня поговорим про основу основ фронтенд-проекта - package.json!

пы.сы. в канале включены реакции, не держите в себе 😁

package.json - по сути конфиг фронтенд-проекта. Когда мы хотим создать новый проект, который будет использовать внутри себя npm-пакеты, мы должны задать конфигурацию проекта.

Этот файл создается автоматически при запуске команды npm init.

💔 не забывайте, что это JSON-файл. Он должен быть валидным.

Разберём базовое содержимое:

- scripts. Это npm-команды, которые мы можем запускать в рамках проекта. Минимально здесь описаны команды запуска dev-сервера, сборки проекта, прогона тестов и линтера.
- dependencies. Список внешних npm-пакетов, которые используются в проекте. Это те зависимости, которые обязательно должны быть в production-сборке. Т.е. без них проект просто не будет работать.
- devDependencies. Список внешних npm-пакетов, которые используются именно в develop-режиме. Например, это могут быть пакеты для тестования.
- peerDependencies. Это зависимости, которые требует проект, если он должен быть интегрирован в какой-то хост-проект. Если наш проект - это библиотека или виджет, и он должен быть встроен в какой-то сайт, то лучше зависимости нашего проекта выносить именно сюда, а не в deps. Иначе на сайте проекта может возникнуть дубль пакетов или конфликт версий.

В дальнейших частях мы разберем особенности установок зависимостей (особенно в текущих реалиях), посмотрим основные скрипты, а также затронем некоторые ошибки, которые могут возникнуть из-за неправильной настройки. Stay tuned 💫

Подробная дока по ссылке

#basics

​​💛 Фронтенд-митап

Хотя современные митапы уже не назовёшь полноценно фронтендерскими, этот мит обещается именно для любителей джиэса 😅

Коллеги из Яндекса проводят регулярную конференцию «Я 💛 фронтенд», в этом году наконец-то оффлайн! Правда, места в зале разобрали в первый день анонса, как пирожочки (оцените уровень!). Но на онлайн ещё можно попасть.

Почему стоит подключиться:
🔥 узнать, как грамотно разрабатывать фронт параллельно с API (наконец-то!)
🔥 подыскать современную замену Bootstrap (и убедиться, что чистый CSS one love)
🔥 оценить доступность своего сайта с клавиатуры (уже пора бы это поддерживать)
🔥 окунуться в атмосферу написания своей стейт-машины (Тьюринг, Тьюринг и ещё один Тьюринг)
🔥познакомиться с заменами Express (оказывается, он не единственный!)
🔥 полюбить идею создания своей UI-библиотеки на примере (каждый фронтендер хоть раз хотел это сделать у себя в проекте, no?)
🔥 узнать полезности про метрики перфоманса веб-приложения (и новые вкладки DevTools!)
😁 достойный повод прогулять рабочую пятницу

🗓 Пятница, 12 августа
⏰ 10:30
🔗 Регистрация

Бегом регаться 🤓

​​​​💯 Переменные в JS в 2к22

Must-have тема для всех фронтендеров. Она часто вызывает трудности в начале пути, поэтому разбираемся (или вспоминаем) 😉

Если коротко, вся разница в идентификаторах (var, const, let) заключается в области видимости, в которой они работают.
Область видимости (лексическое окружение) - блок кода (функция или глобальный объект), в рамках которой переменная “видна”. Внутри этой области к ней можно обратиться. За пределами она не существует (будет ошибка ReferenceError: variable is not defined).

1️⃣ const. Используется для обозначения неизменяемых переменных. Такая переменная доступна только в блоке, где она была объявлена. Нельзя обратиться до инициализации. Если попытаться изменить присвоение - будет ошибка.

2️⃣ let. Пишем, когда переменная изменяемая. Аналогично const: переменная доступна только в блоке, где она была объявлена + к ней нельзя обратиться до инициализации. Часто используется в итераторах или аккумуляторах.

3️⃣ var. Dangerous - устарело!!! Встречается в старом коде (до ES6), а также в билд-сборках после сжатия вашего кода бандлером. Использовалась как let, но с исключениями. Переменная не ограничена блоком, только глобальным скриптом или функцией (т.е. можно считать вне блока). Можно обратиться до инициализации, ошибки не будет, будет “undefined”/”uninitialized”. Можно повторно объявить переменную.

🧨 Важно 1. Для объектов и массивов используем const. Они хранятся ссылками, поэтому изменяем содержимое ссылки, а не её саму.

🧨 Важно 2. Для итераторов циклов используем let. Семантически мы меняем одну и ту же переменную, поэтому const не уместно. Также let работает в рамках одной итерации цикла, что позволяет избежать случайных замыканий и переопределений. А еще раньше была тема, что если итератор объявлен через let, то он занимает одну ячейку памяти, а если через const - на каждую итерацию своя ячейка (если кто-то найдет этому прувы, буду сильно благодарна!).

🔗 Почитать ещё: раз, два и три

⚛️ Примеры: ниже #ачтопокоду

🤡 Практика: скоро будет, не переключайтесь 💃🏻

#basics