Я только что запустил BobaVim — браузерную игру, которая помогает освоить и практиковать движения в Vim через увлекательные задания и соревнования.
Можно играть в одиночку для тренировки или соревноваться с другими игроками в режиме 1 на 1 в реальном времени. В игре есть:
Учебник и справочник
Таблица лидеров для отслеживания прогресса
Уровни, сфокусированные на реальных Vim-командах
Этот проект — моя небольшая дань уважения Браму Муленаару, создателю Vim. Его труд и философия вдохновили меня на создание этого инструмента для сообщества.
Я разработал игру на HTML, CSS, JavaScript и Go, и заодно многому научился — от клиентского предсказания до обработки конкуренции и многопользовательской синхронизации в реальном времени.
☕ 5 способов создания DOM-элементов из HTML-строк методами JavaScript
Создание DOM-элементов из строк обеспечивает:
Динамическое создание контента – можно добавлять новые элементы на страницу без перезагрузки.
Гибкость – можно легко генерировать HTML на основе данных, полученных от пользователя или с сервера.
Шаблонизацию – поскольку упрощает создание повторяющихся структур HTML.
Управление интерфейсом – помогает создавать интерактивные элементы, которые реагируют на действия пользователя.
Почти все современные JavaScript-фреймворки и библиотеки предоставляют удобные инструменты для создания DOM-элементов из HTML-строк – это одна из основных задач, которую они решают. Если же нужно обойтись возможностями ванильного JavaScript, то это можно сделать несколькими разными способами.
innerHTML
Это самый известный метод: он позволяет вставить строку HTML внутрь атрибута innerHTML контейнера и затем получить доступ к созданному узлу DOM. Однако он может обрабатывать только допустимые узлы HTML – к примеру, попытка вставить элемент <tr> в <div> приведет к тому, что узел не будет создан. Кроме того, этот метод не выполняет скрипты в HTML-строках, что делает его безопасным при работе с непроверенным содержимым.
innerHTML + template
Использование тега <template> снимает ограничения на содержимое – он может содержать любую HTML-структуру, включая элементы, связанные с таблицами – <tr> и <td>.
insertAdjacentHTML
Как и innerHTML, этот метод обрабатывает только допустимые HTML-узлы и не выполняет скрипты.
DOMParser
Этот метод работает медленнее остальных, поскольку он разбирает строку, создавая полный HTML-документ, и только потом извлекает узел из документа. Он также может обрабатывать только допустимые узлы HTML и не выполняет скрипты.
Range.createContextualFragment
Самый простой, но не безопасный метод – выполняет скрипты. Поэтому при его использовании необходимо очищать данные для защиты от XSS – например, с помощью DOMPurify.
SVG-графика предоставляет нам стандартизированный способ создания изображений и иконок, которые можно отображать в любом размере без потери качества изображения. Но разобраться в методах SVG не так-то просто. На помощь придет интерактивный справочник SSSVG.
SSSVG поможет быстро понять принцип работы всех основных атрибутов
К слову, возможности SVG простираются за пределы создания векторных картинок и лого: энтузиасты умудрились сделать «Тетрис» в виде одного SVG-файла.
Этот «Тетрис» сделан полностью на SVG
Гайд по :has() в CSS
Псевдокласс :has() открывает новые возможности для творческих экспериментов в CSS, позволяя создавать сложные и интерактивные дизайны без использования JavaScript. Это первый родительский селектор, позволяющий стилизовать элемент в зависимости от его содержимого. Все невероятные возможности :has() продемонстрированы в интерактивном гайде CSS :has() Interactive Guide.
В гайде подробно разобраны десятки примеров использования :has()
🐘🧩 Интересные задачи по PHP для практики можно найти на нашем телеграм-канале «Библиотека задач по PHP»
🪚 Инструменты
Plasmic – опенсорсный визуальный конструктор для создания сайтов и веб-приложений на React со множеством функций:
Можно интегрировать с существующими React-проектами.
Можно использовать как CMS.
Позволяет подключать разные источники данных и бэкенд-сервисы.
Совместим с Next.js и Gatsby.
Поддерживает оптимизацию производительности, включая статическую генерацию сайтов и оптимизацию изображений.
article-extractor – эта библиотека Node.js извлекает текст статей, метаданные и ссылки на изображения по URL.
Протестировать article-extractor можно на демо-сайте
Turndown – Node.js-библиотека для конвертирования HTML в Markdown. Отлично работает в связке с предыдущим инструментом.
article-extractor + turndown подготовят контент для LLM
15 полезных расширений VS Code для фронтендера
Auto Rename Tag – при переименовании HTML-тега автоматически обновляет парный тег.
Code Spell Checker – находит опечатки в именах переменных и других идентификаторах.
DotEnv – добавляет цветовое оформление и улучшает читаемость файлов с переменными окружения.
Docker – добавляет вкладку для удобной работы с контейнерами, если вы используете Docker.
ESLint – выявляет проблемы в коде (нарушения форматирования или потенциальные ошибки) на лету.
Figma – позволяет встраивать и просматривать файлы дизайна Figma прямо в VS Code.
GitHub Copilot – предлагает AI-генерируемые подсказки во время набора кода.
Copilot Chat – предоставляет окно чата в стиле ChatGPT прямо в редакторе.
GraphQL – набор расширений, упрощающих работу с GraphQL.
Import Cost – показывает размер импортируемых пакетов, помогая выявить потенциальное раздувание кода.
Live Server – запускает локальный сервер с автоматической перезагрузкой, что удобно для предварительного просмотра изменений.
Live Share – позволяет программировать в команде с другими разработчиками, работая в одном редакторе в реальном времени.
Markdown Preview Enhanced – предоставляет живой предпросмотр Markdown-файлов во время редактирования.
Notes – удобный блокнот для хранения заметок по проекту, инструкций по настройке и т. д.
Hinty – предоставляет динамические подсказки в реальном времени. Помогает избегать повторения распространенных ошибок и соблюдать стандарты написания кода в команде.
Рендеринг – это процесс превращения кода в контент. За годы развития интернета эта технология прошла долгий путь – от формирования простейших HTML-страниц на стороне сервера до динамического обновления интерактивных приложений без перезагрузки. Сейчас в ходу несколько методов рендеринга:
Генерация статических сайтов (предварительно генерирует HTML-страницы во время сборки приложения).
Генерация на стороне сервера (генерирует полный HTML для страницы при каждом запросе).
Генерация на стороне клиента (использует JavaScript для рендеринга контента в браузере пользователя).
Инкрементальная статическая регенерация (позволяет обновлять отдельные страницы после сборки сайта).
Частичный пререндеринг (экспериментальный подход, который стремится автоматически оптимизировать стратегии рендеринга).
Эти методы по-разному подходят к оптимизации работы приложения, SEO и пользовательского опыта. Их можно комбинировать – это позволяет по максимуму использовать сильные стороны, нивелировать недостатки и обеспечить оптимальный баланс производительности, свежести данных и интерактивности. Разработчики Vercel (эта компания создала Next.js) написали подробную статью о преимуществах и недостатках каждого подхода и о том, как их лучше комбинировать.
Генератор статических сайтов (SSG)
Идеально подходит для страниц с редко меняющимся контентом, макетов сайтов, документации и лендингов, для которых важна максимальная скорость загрузки.
Преимущества:
Самая быстрая загрузка страниц.
Отличные показатели SEO.
Самая низкая нагрузка на сервер.
Низкие затраты на инфраструктуру.
Недостатки:
Увеличенное время сборки для сайтов с большим количеством страниц.
Обновление контента требует новой сборки и развертывания.
Рендеринг на стороне сервера (SSR)
Идеально подходит для персонализированных дашбордов, лент соцсетей и визуализации данных в реальном времени.
Преимущества:
Всегда отдает свежий, актуальный контент.
Показатели SEO и времени загрузки данных лучше, чем при рендеринге на стороне клиента.
Недостатки:
Загрузка происходит медленнее, чем при использовании SSG или ISR.
Подходит для случаев, когда сборка с SSG занимает слишком много времени. Используется для страниц продуктов в e-commerce, новостных порталов и крупных контентных сайтов.
Преимущества:
Сохраняет быструю загрузку страниц, как у SSG.
Позволяет обновлять контент по требованию без полной пересборки.
Эффективно масштабируется на большое количество страниц.
Может быть экономичнее, чем SSR, в некоторых случаях.
Недостаток:
Требует тщательного управления стратегиями инвалидации кэша.
Рендеринг на стороне клиента (CSR)
Подходит для интерактивных элементов страницы, требующих немедленной обратной связи, админ-панелей с данными в реальном времени и приложений типа Notion, которые непрерывно синхронизируют вводимые пользователем данные с сервером.
Преимущества:
Самый интерактивный пользовательский опыт.
Плавные переходы между состояниями приложения.
Взаимодействие с внешними данными в реальном времени.
Недостатки:
Начальная загрузка может быть медленнее из-за необходимости загрузки JavaScript-бандла.
Улучшенная производительность с меньшими затратами на разработку.
Недостатки:
Все еще находится в стадии исследований и разработки.
Может потребовать рефакторинга кода для включения в существующий проект.
Выбор стратегии рендеринга
При выборе стратегии рендеринга нужно учитывать следующие факторы.
Как часто обновляется контент?
Статический контент лучше всего обрабатывать генератором статических сайтов.
Для вывода периодически обновляемого контента отлично подходит инкрементальная статическая регенерация.
Обновление контента в реальном времени требует серверного или клиентского рендеринга.
Для повышения производительности нужно стремиться к максимальному использованию SSG и ISR, прибегая к SSR только в случае необходимости получения абсолютно свежих данных.
Насколько важно продвижение страницы в поисковых системах?
Хотя Google может рендерить JavaScript на стороне клиента, ключевые показатели Core Web Vitals все еще сильно влияют на ранжирование.
Высоких показателей CWV легче добиться на статических и серверных страницах, чем на страницах с клиентской загрузкой внешних данных.
Насколько активно пользователь будет взаимодействовать со страницей?
Если страница в основном статическая с минимальным взаимодействием, используйте SSG или ISR с небольшим количеством клиентского JavaScript.
В противном случае может потребоваться SSR (с гидратацией на стороне клиента).
Каковы требования к скорости загрузки?
Для максимально быстрой начальной загрузки используйте SSG или ISR с редкой инвалидацией.
Чтобы сбалансировать свежесть данных и скорость, используйте ISR или SSR (для актуальных данных).
CSR может обеспечить данные в реальном времени, но часто за счет начальной загрузки.
Нужно ли персонализировать контент?
Если вам нужен персонализированный контент, скорее всего, потребуется SSR или CSR.
ISR может работать в случаях, когда можно кэшировать персонализированный контент, например, настройки веб-приложения.
SSG не позволяет персонализировать контент.
🔤 Больше полезных материалов вы найдете на нашем телеграм-канале «Азбука айтишника»
Это статья для начинающих фронтенд разработчиков, которые с яркими глазами и минимальной зп готовы к первому коммерческому опыту.
Стэк: vue3, nuxt3
P.S. АХТУНГ! Много букаф, смысла null, потому я есть Shaltier Nullfallen! Статья написана ВЕЛИКИМ в "кавычках" грамотеем, если вы любите высококачественный контент, скорее всего вам не стоит читать эту статью. Все названия и имена были заменены, любое совпадение является чистой случайностью.
Добро пожаловать, заблудшие огоньки, сегодня я хочу поговорить о самых обычных моментах работы frontend разработчиком в маленькой фирме. Этот текст наполнен унынием и разочарованием, надеюсь он передаст толику моих эмоций.
Хромые клячи
Конец месяца, собеседование в компанию "Стрекозлы в АйТи" прошло весьма неплохо, я напортачил в предыдущей компании, создав образ посредственного падавана. Фронтендер из предыдущей фирмы "BODUNOV" видимо недавно открыл для себя vue и nuxt. Структура проекта была специфичной (это пример):
Я покажу тебе, как глубока кроличья нора
Примечание: Мне нравится структура из angular и это не мешает использовать похожий стиль в компонентах. Используйте основную структуру из доков nuxt. Старайтесь не допускать больше трех уровней.
Папка partials с огромной вложенностью передавала привет от мистера webpack, а точнее плагина по импорту html.
Разработчик сделал 40% проекта и метался от одного UI kit к другому, а я слушал и крутил барабан револьвера. Сделав одну страницу, меня попросили удалиться, попытка разбить вёрстку на компоненты и избавился от ненужных дубликатов html кода смутила разраба фирмы BODUNOV. И тут меня ждала новая не менее амбициозная компания, с 10-ти летним стажем на рынке.
На собеседование в "Стрекозлы в АйТи" я убедился у интервьюера, в отсутствие глуповатого маркетингового приёма, сверстать статический сайт и показать клиенту, сказав: 'Всё готово шеф, дело осталось за малым'. Люди серьёзные, работают с продукцией 1с и считаются в ней экспертами.
Битрикс есть, а отчеты пиши в excell. И не забывай щелкать таймер и писать отчёт в конце дня. Джира? Какая Джира? Продукты 1С топ! Мы пробовали только Яндекс и это был отстой.
Ну хоть хорошо что excell не используется как база данных для бэка. А вместо word не используют markdown. Вот тупые, кто `markdown` придумал.
После ознакомительного диалога ПМ-а по работе со Шмитрикс, я не понял как они ведут разработку. На канбан доске вместо привычных столбцов было несколько столбиков связанных со временем:
// Без срока // Запланированные // Сделаю сегодня // Сделаю на недели //
Хмм... наверное для перевода на тест нужно делегировать тестировщику, а потом...
А нееее... кроме менеджера, разработчиков и дизайнера больше никого нету. То есть нет тестировщиков, контент-менеджеров, seo, devops и т.д.
Менеджер сказал (не дословно, почти): "Всех кого-ты перечислил сомнительные личности и результат их работы не ясен. У нас было много SEO специалистов, целых 3, ой, 2 человека. Ну руководство не поняло их трудов и уволило."
Окей... Нам не в первой работать по старинке. Пока нам платят, мы будем радостно визжать как свиньи. Ну что погнали за работу!
Three Days Later...
Прошло 3 дня, а я ничего не сделал. Нет, вина не в моём титуле Капитан Улитка, просто задач нет! Как объяснил менеджер, он болеет, неделя очень тяжелая, задачу выдать не могу. (На самом деле было ещё 2 менеджера которые могли его подменить, но заставлять работать больного сотрудника веселее)
Обычно первым делом в любой компании заставляют читать документацию на 6 часов, ставить vpn, но в документах Шмитрикса было почти пусто, компания не хотела покупать продвинутую подписку, поэтому каждый создавал файлы в облаке, кто в гугл, кто в яндексе. Каждый держал файл у себя, а не в общей папке, поэтому узреть могли только избранные.
Первое задание. Разместить статический сайт выполненный начинающим верстальщиком Рыжий. Видимо только вчера прошел курс ХалалАкадемии и решил проверить новоиспеченный скил. Где-то пагинация была сделана картинкой, где-то отсутствовали блоки, где-то хромал адаптив.
Пишите а вам попадались сайты где не было верстки, только backgroundImage?
Мне дали доступ по ssh и попросили поставить сайт с сертификатом на nginx. В принципе окей, но в вакансии про эти скилы не слова.
One Day Later...
Разговор с дизом и ПМ. Дизайн находится под слоём черновик, каждый макет не имеет статуса готового к разработке.
Примечание: кнопка фигмы Ready For Dev, некоторые дизайнеры делают свой компонент для статусов макета или используют цветовые зоны, т.к. макет может иметь много статусов (прототип / в процессе доработки / на утверждение / готов)
Даже без матёрого глаза можно приметить множество огрехов в дизайне. Отсутствие модалок, элементы не интерактивные, нет статусов элементов форм. В некоторых местах много воздуха, неравномерные отступы... В общем полный комплект ошибок ждуна. Дизайнер пытается скрыть смущение, намекая на сроки, мол времени на UX и полировку UI не было. Удивительный факт, разработчикам всегда представляют диза так: "А это наш UI/UX дизайнер". Вот только времени на UX исследования у него нет.
И теперь работа? Нет. Доступа к гитлабу нет, задач в шмитриксе нет.
На следущий день получил доступ к гитлабу, сразу начал создавать проект, хотя задачи не было, есть интуиция и особая минтайная связь. ПМ захлебывался соплями и издавал предсмертный хрип, получить инфу по проекту было нельзя.
А инфы по проекту не было / LOL / Редизайн предполагалось делать на основе нового диза и поглядывая на старый сайт. Только новый дизайн сильно отличался. Не было к примеру локализации (был выбор региона) и ПМ сказал твёрдо её НЕ БУДЕТ! Вот тут и была первая подстава.
ПМ тоже не одобряет дизайн, но продолжает сюсюкаться (чей-то родственник или мидихлориан в избытке). Дизайн сделан посредственно и как оказывается не является техническим документом.
Спойлер: По мнению руководства я должен был делать не по дизайну, а по старому сайту, дизайн лишь красивый фантик для клиента и задача разработчика самому продумать адаптивность и функционал сайта.
Благо старый сайт не имел минификации и обфускации.
Примечание: После компиляции кода, файл со скриптом крайне тяжело прочитать. Начинающие разработчики умеют кидать скрипты в конец документа, чтобы не мешать прорисовке странице, на этом их знания исчерпываются. Раньше мы прописывали чанки в webpack ручками, теперь с vite многие разрабы не знают про это.
Ладно с дизайном всё ясно, ну мне нужно делать динамический сайт похожий по типу на интернет магазин, где взять бэкенд? Старый сайт был выполнен в php шаблонизаторе и имел мобильное приложение (отличается по функционалу от сайта), теперь предстояло сделать его на nuxt, а значит старое api не подходило.
Угадайте кто должен был придумать дизайн API? Бэкенд! Не угадали. Конечно же фронтенд (по факту vue SSR это уже fullstack)
Примечание: Бэкенд разработчики могут разработать API самостоятельно, а значит они могут приступить к работе сразу без верстки. После одобрения прототипа, уже можно предположить какие данные будут выводится. Прототип дазайна уже определяет базовое расположение блоков и медиаконтента
Мне позвонил специалист по отделу кадров, спрашивает как дела и мол я буду звонить тебе каждый месяц (это был последний звонок). А я такой: "not bad, но знаешь, тут ..."
- А покажи что ты сделал.
Я отправляю ему ссылку на сайт.
- Скажи, то что сделал Рыжий, тебе как-то помогло?
- Как я говорил на собесе, всю эту вёрстку все равно нужно переделывать, к тому же там было много косяков, вёрстка была абсолютная не валидна по w3c. Я начал с начала.
- Ну ты же понимаешь я не могу показать это?
На тот момент навигация еще не приходила с бэка, перемещаться по сайту было нельзя, а также были видны некоторые косяки. Я и не хотел демонстрировать сайт.
- Ну да, вы показали клиенту фантик без конфеты. Без серверной части нельзя оставлять заявки или отправлять формы, сайт и делается ради интерактивности, иначе мы могли бы продавать фотографию сайта.
Менеджер посмотрел на меня как на шарлатана. Почему кадровик ведет переговоры по проекту с клиентом? А может он, вовсе и не кадровик?
Если это была свежая компания из 5 человек, я бы понял. Но персонала было не менее 20 чел. А компании уже 10 лет. Наверное за это время можно было собрать базовую комплектацию.
Два месяца спустя или 44 раб дня
Бэкендер выходит из долгожданного отпуска...
4-5 остальных видимо были очень заняты. Я лично работал с двумя, но официально в штате их должно быть больше. Да и как-то на созвоне созвали толпу, которой объяснили как сделать 1 эндпойнт с получением данных из firebase. Результат: я поднял nuxt и сделал сам. Ну что сказать команда профессионалов, умеют убеждать.
Ах, да... Бэкенд выходит из отпуска и заходит в шмитрикс. Бэкендер плачет ПМ: "Там слишком много! Апи уже почти готово, там всё есть"
Конечно же там много чего не было, апи первой версии сделано не по REST, которому далеко до стандартов JSON:API.
Swagger-а нету, есть postman, апи которое написано ручками (тока шайтаны пишут доки в аннотациях и используют модуль автодокументации)
Примечание: Незнаю как в Yii, но в Symfony генерировать коллекции с готовыми Rest Api эндпоинтами милое дело. По идее мы один раз заморачиваемся пишем ядро, а далее используем от проекта к проекту. Документацию легко можно импортировать в postman. Если у вас будет фронтенд SPA/SSR в виде отдельного приложения, задумайтесь, а нужно ли его писать на php? Бэкенд на nodejs может сэкономить время. Низкой порог вхождения !== выгода. Nodejs может быть serverless, а php это танцы с бубном в плане деплоя. А там типизация от бэка почти готовая
Меня попросили переделать для бэка документ с api запросами и как вы думаете он приступил к правкам сразу? Конечно же нет. Рабочий день начинался в 9 часов, точнее так было у удалёнщиков, офисные планктоны почти всегда приезжали на работу после обеда. Оказывается часть сотрудников работают во вторую смену, а бэкендер на протяжения дня занимается бумажками от шефа, сам шеф со спокойной душой уезжал в командировку. По более сложному проекту с картами, мне приходилось ждать фидбека от шефа компании каждый вечер, а днём по указаниям из аудиосообщения я пилил приложение.
Конечно для написания ТЗ необходимо время, а наболтать по телефону сообщение это дело не сложное. Ну и тупые эти разработчики, носятся со своими ТЗ.
Хороший мальчик Бобби
Не курит, не пьёт. Деньги в копилку кладёт. Большая часть рынка разработки это ждуняшки ожидающие маны небесной. В один прекрасный день армию ждунов без тимлида, мидлов или сеньоров, только ждуны, только харкор. Банда маркетологов оказывается чаще всего во главе малого бизнеса (будем честны в крупных компаниях, тоже не всегда руководители инженеры), это приводит к печальным последствиям для IT рынка. Сначала нанимают партию разработчиков, через год или два, шеф проходит специальные курсы по бизнесу и открывает новые слова: "B2B" и "B2C". Он смотрит в собственное отражение и видит гениального человека, способного открыть свой телеграм канал и продовать свои собственные курсы. Увольняем 90% разрабов, получаем чистый профит с курсов. \ STONKS /
Судная ночь
Сайт в итоге сделали, правда за несколько часов до презентации (они решили все вместе приехать в офис клиента и открыть бутылку шампанского), а тут оказывается на сайте должно быть так, а ни сяк.
-- Эту кнопку убрать! Батюшки, я ведь всё ни так! Клиент? Какой клиент! Я так вижу! Сделать по моему! Клиент потом посмотрит и скажет. В смысле, конечно макет утвержден! Видишь дизайнер тока что стрелочки в дизайне дорисовал, а у тебя их нет! А ну быстро отсеките голову этому халопу! Стража! Стража!
Титры
Нет повести печальней, чем история о Shaltier и потерянном времени. Почему никто не плачет? Не забываем купить мои курсы "Как открыть IT стартап для ...". Продолжение пишем в комменты.
Спасибо за ваше потраченное время, надеюсь в следующий раз, контент будет лучше. Обычно мы начинаем работать в компании для поднятие скила, но этот опыт равносилен фрилансу, да еще платят меньше и мозг съедают чайной ложкой.
В этом ролике я провел эксперимент сменил свой стэк технологий. Поменял акцент с бэка на фронт,пересел с html`а на react,и научился базовым анимациям,также я перешел с бутстрапа на tailwindcss.
