💡 Идеальный программистНавыки, которые присущи идеальному разработчику! 😍Спустя долгое время в разработке я для себя вывела набор качеств, которые реально делают программиста крутым. И вот какие навыки я считаю самыми важными:1️⃣ Умение не просто выполнять то, что написано в задаче, а понимать — нужно ли это вообще?Продуктивность не измеряется количеством написанных строк кода.2️⃣ Умение понятно излагать свои мысли(в переписке, на созвонах, на ревью — где угодно)3️⃣ Иметь свою точку зрения и уметь аргументировать её4️⃣ Быть командным игроком и понимать, что у всех разный уровеньи это нормально 🙌5️⃣ Постоянно развивать свои навыки и не терять энтузиазм к работе 🔥А вы что думаете по этому поводу?
Frontend Developer
@frontenddevelopernews
Пост-знакомство — https://t.me/frontenddevelopernews/3 По всем вопросам — @mobiledeveloper_bot
190подписчиков
🇬🇧
Похожие каналы
Все →
LIVE — Telegram, AI и технологии
2.1M подп.
GPT | ChatGPT | Midjourney — GPTMain News
2.0M подп.
![ChatGPT 4.0 & [🅼🅹] | Bot News](/avatars/chatgpt_botnews.webp)
ChatGPT 4.0 & [🅼🅹] | Bot News
312.5K подп.
GitHub Community
145.8K подп.
Bogdan & Xena: WEB3 stories
127.2K подп.
ChatGPT 5.2 | Нейросети | Gemini
121.9K подп.
ChatGPT | Midjourney Bot
118.8K подп.
Web3
97.6K подп.
Web3 на доступном
80.4K подп.
![[PYTHON:TODAY]](/avatars/python2day.webp)
[PYTHON:TODAY]
64.2K подп.
→
Все каналы
«Программирование и IT»
Последние посты
Всем привет!Наткнулась в интернете на статью, где автор делится вопросами, которые ему задавали на интервью в AmazonВопросы, которые задавали:1. Что такое aria-label, aria-labelledby, aria-live — и для чего они нужны?2. В чём разница между тегом <header> и заголовками <h1>…<h6>?3. Что такое семантические классы и семантическое именование классов?4. Каков будет вывод этого JavaScript-кода? (код про event loop)5. Как «расплющить» (flatten) массив без array.flat()?6. Реализация компонента Star Rating на ReactГлавные инсайты:🔹 Никогда не недооценивайте базу. Даже если вы отлично работаете с React — важно помнить основы языка.🔹 Коммуникация — это навык. Умение объяснить, *почему* вы делаете так, а не иначе, не менее важно, чем написать рабочий код.🔹 Провал — это не приговор. Одно неудачное собеседование не определяет вашу ценность.Если вам интересно — можете почитать оригинал: https://ujjwal3009.medium.com/frontend-developer-interview-amazon-f61e780add81
Начинаем открывать адвент календари.Ежегодный адвент-календарь о web performance: новые статьи, практики оптимизации, case-studies от инженеров крупных компаний. https://calendar.perfplanet.com/2025/Адвент-календарь с анти-паттернами HTML, забавными (и полезными) примерами того, как *не* стоит верстать. Каждый день — новая статья. https://htmhell.dev/adventcalendar/Самый популярный адвент-календарь по алгоритмам и программированию: ежедневно выходят интересные задачки разных уровней сложности. https://adventofcode.com/Ежедневные снипеты о современной CSS-разработке.https://cssadventcalendar.devАдвент-календарь, посвящённый accessibility: практики, паттерны и методы создания доступных интерфейсов. https://manuelsanchezdev.com/advent-2025
Как браузер обрабатывает <script> при построении DOM-дерева? 🧐Когда браузер разбирает HTML, встречающиеся теги <script> могут блокировать дальнейшее построение DOM, что влияет на производительность страницы. И вот как это работает:1️⃣ Синхронные скрипты (<script>, без async или defer) — блокируют построение DOM до своей загрузки и выполнения. Это замедляет рендеринг страницы.2️⃣ Асинхронные скрипты (async) агружаются параллельно с HTML, но выполняются сразу, как только файл загружен. Порядок их выполнения непредсказуем и может прервать рендеринг страницы.3️⃣ Скрипты с defer загружаются параллельно, но выполняются после полного парсинга HTML, в том же порядке, в котором они встречаются в документе.4️⃣ Модульные скрипты (type="module") загружаются как defer, но имеют строгий режим и поддерживают import/export. Они выполняются после загрузки HTML и поддерживают top-level await.5️⃣ Динамические скрипты (через document.createElement('script')) ведут себя как async по умолчанию.👩🎓 Немного рекомендаций: ✔️ Используй defer для большинства скриптов, чтобы они не блокировали рендеринг;✔️ Для независимых скриптов (например, аналитики) используй async;✔️ Минимизируй количество синхронных скриптов в <head> — это замедляет загрузку страницы.И помним, скрипты могут блокировать не только DOM, но и рендеринг страницы, влияя на скорость загрузки и пользовательский опыт, поэтому правильное использование async и defer ускоряет загрузку и рендеринг. 👍
Привет! ✨Собрала полезные материалы для фронтендеров:1. https://bespoyasov.ru/front-not-pain/«Фронтенд — это не больно!» — статьи о том, как фронтендеру работать без стресса: взаимодействовать с дизайнерами, бэкендерами и тестировщиками, бороться с рутиной и выгоранием, организовывать рабочий процесс.2. https://solidbook.vercel.app/Подробная книга о принципах SOLID. Помогает разобраться, как строить гибкую, предсказуемую и поддерживаемую архитектуру.3. https://www.patterns.dev/vanilla/module-pattern/Большая коллекция популярных паттернов разработки в JavaScript, объяснённых просто и визуально. В том числе модульный паттерн и многие другие.4. https://refactor-like-a-superhero.vercel.app/ruПрактическое руководство по рефакторингу. Чёткие советы, примеры и техники, которые помогают улучшать код без боли и риска всё сломать.5. https://www.youtube.com/playlist?list=PLaIuVNKRYUyEoKnY0UwapHPk8fEaREHPAПодробный видеокурс по Figma. По мне часто фронтендеру не хватает этого навыка даже в базовом виде.
Это не было бы так смешно, если бы не было правдой 😄К сожалению, многие фронты порой настолько зациклены на том, чтобы просто сделать «работающий код», что забывают о «хороших манерах» — например, о том, что не только 200 считается успешным результатом. Есть ещё 201, 204 и другие кейсы ✅И вообще, помимо привычных 200, 400, 404 и 500, существует множество других статус-кодов, которые могут значительно упростить логику на фронте и сделать API более понятным.Я уже как-то писала пост с HTTP Code Cheatsheet — можете обратить внимание 👇https://t.me/frontenddevelopernews/60
Всем привет! 👋Работая почти 10 лет в разработке, всё чаще замечаю, что многие фронтендеры приходят в профессию без формального IT-образования. Недавно наткнулась на статью, где автор — тоже без классического CS-бэкграунда — делится принципами, которые помогают ему принимать правильные решения «здесь и сейчас».Мне, человеку с бакалавриатом и магистратурой, было особенно интересно почитать, что же он там написал 🙂---🧩 Про «умные» принципы, которые иногда только мешаютАвтор пишет, что популярные советы вродеYAGNI (You Aren’t Gonna Need It),DRY (Don’t Repeat Yourself)и «преждевременная оптимизация — корень всех зол»звучат умно, но в реальной жизни часто создают больше путаницы.И вот принцип, который действительно помогает ему в работе — правило трёх.---📌 Правило трёхРефакторить или оптимизировать код стоит только после того, как вы написали его три раза:1️⃣ Первый раз — просто пишете код, который делает только то, что нужно.2️⃣ Второй раз — появляется та же логика, и вы буквально копируете её, немного адаптируя.3️⃣ Третий раз — у вас уже три подобные реализации, и теперь ясно, что обобщать, как упрощать и какой уровень абстракции действительно нужен.Зачем так делать?Потому что после трёх повторений вы уже точно знаете:* что в логике действительно общее,* что можно упростить,* какой абстракции хватает,* и не уйдёте в ненужный оверинжиниринг.---⚙️ Принцип «Make it work → Make it right → Make it fast»Очень хочется оптимизировать всё сразу — но быстрый код часто менее читаемый.Кент Бек предлагает простой порядок:🔹 Работает? Если нет — сначала добейтесь этого.🔹 Делает правильно? Если нет — исправьте логику, входы, поведение.🔹 Достаточно быстро? Если нет — вот теперь можно оптимизировать.Смысл простой: нет смысла улучшать код, который пока даже не работает или работает неправильно.---✔️ Как итогХорошие принципы помогают писать код, который:* легко читать,* легко понимать,* легко изменять,* легко тестировать.А плохой код «плох по-разному»: слишком много ответственности,
Вообще, как по мне, разработчики — самые ленивые люди на свете 😄 Не зря же мы через свои приложения пытаемся упростить жизнь людям.Когда я наткнулась на статью «Ultimate Prompts for Every Developer», сразу стало интересно: "какие там такие промпты, которые действительно полезны в работе?"Собрала для вас короткую подборку самых практичных — их можно просто копировать и использовать при необходимости 👇---1️⃣ Фреймворк для рефакторинга и оптимизацииI have a [language] function in a [framework] project that needs refactoring.Current code:[paste code]Issues I'd like to address:[specific issue, e.g., low readability][specific issue, e.g., non-optimal O(n^2) time complexity]What I've considered:[ideas you've already tried]Constraints:[must remain backward compatible, no new dependencies]Please suggest refactored code with explanations,including trade-offs and potential edge cases.2️⃣ Code Review от трёх «персон»Please review this code from three different perspectives:1. Security specialist: - Identify vulnerabilities / injection risks - Mention any OWASP Top 10 concerns2. Performance engineer: - Highlight inefficiencies or bottlenecks - Suggest better data structures or algorithms3. Maintainability expert: - Point out unclear naming / complex logic - Suggest improvements for testability and structureCONTEXT:- Tech stack: [React/Node/TS]- Constraints: [e.g., no new dependencies]CODE:[YOUR CODE]3️⃣ Постепенное проектирование APII'm designing a RESTful API for a [SPECIFIC DOMAIN] system.Let's develop this progressively:STAGE 1: Core resources- Define resources + relationships- Primary attributes- Basic CRUDSTAGE 2: Interaction patterns- Non-CRUD endpoints- Filtering, sorting, paginationSTAGE 3: Advanced- Auth & permissions- Rate limiting- Versioning- Caching (ETag, directives)- Error format standardizationSTAGE 4: Documentation- Generate OpenAPI spec- Provide request/response examples4️⃣ Документация по компоненту/модулюGenerate comprehensive developer document
Жиза 😂😂😂Жиза 😂😂😂
💡 Недавно наткнулась на очень полезную статью про 10 недооценённых фич JavaScriptи вот что я там обнаружила 👇1️⃣ Использование Set для удаления дубликатов и быстрых проверок.2️⃣ Методы Object.entries() и Object.fromEntries() для преобразования объектов.3️⃣ Операторы ?? (nullish coalescing) и ??= — более безопасные дефолты по сравнению с ||.4️⃣ Интернационализация через Intl — форматирование чисел, валют, дат.5️⃣ IntersectionObserver для ленивой загрузки изображений и бесконечной прокрутки.6️⃣ Promise.allSettled() для обработки набора промисов, когда нужно дождаться всех, даже если некоторые завершились с ошибкой.7️⃣ Метод Element.closest() для надёжного поиска в DOM вверх по дереву.8️⃣ Классы URL и URLSearchParams — работа с URL без регулярных выражений.9️⃣ Цикл for…of — итерации с поддержкой итераторов и возможностью прерывания.🔟 Топ-уровневый await (top-level await) — позволяет работать с асинхронным кодом в модулях без обёрток.📖 Подробнее читай в статье:👉 https://jsdev.space/underrated-js-features/
🌟 Site of the Day — Nov 10, 2025https://www.awwwards.com/sites/messenger💬 Представляю вам сайт дня — Messenger от студии Abeto.🔗 Ссылка на сам сайт:https://messenger.abeto.co/
🚀 Вышел Storybook 10!Крупный релиз популярного инструмента для разработки и документирования UI-компонентов.Главное изменение — переход Storybook на формат ECMAScript Modules (ESM-only).Это делает проект современнее, ускоряет установку и уменьшает вес зависимостей,но требует внимания при обновлении — это breaking change.🧭 Гайд по миграции: https://storybook.js.org/docs/releases/migration-guide-from-older-version📘 Подробнее о релизе и всех нововведениях:https://storybook.js.org/releases/10.0P.S. я уже как-то писала о том В чём же разница между CommonJS и ES Modules? - https://t.me/frontenddevelopernews/4Как вообще уживаются вместе .cjs, .mjs и .js файлы в одном проекте? - https://t.me/frontenddevelopernews/5
😭😭😭🤣🤣🤣
💡 Давайте решим лёгкую задачку:https://bigfrontend.dev/typescript/implement-Pick-T-KПо моим наблюдениям, многие фронтендеры не всегда до конца знают TypeScript.Базовые вещи — да 😊, а вот если копнуть чуть глубже, то многие теряются!---📘 Условие задачи:Реализуйте тип MyPick<T, K> самостоятельно.type Foo = { a: string b: number c: boolean}type A = MyPick<Foo, 'a' | 'b'> // { a: string, b: number }type B = MyPick<Foo, 'c'> // { c: boolean }type C = MyPick<Foo, 'd'> // ОшибкаИспользовать встроенный Pick<T, K> — нельзя 🚫---🧠 Чтобы решить задачу, нужно вспомнить две вещи:1. оператор keyof - https://www.typescriptlang.org/docs/handbook/2/keyof-types.html2. наследование с помощью extendsТип MyPick принимает:* первый аргумент — исходный тип T* второй — K, который может быть только ключом из T---✅ Решение:type MyPick<T, K extends keyof T> = { [P in K]: T[P]}Так мы получаем новый тип, содержащий только нужные ключи и их типы 👌
🔗 Your URL Is Your StateНедавно наткнулась на статью:https://alfy.blog/2025/10/31/your-url-is-your-state.htmlВ ней — простая, но почти забытая философия:в погоне за фреймворками и глобальными сторами мы перестали ценить то, что веб умел с самого начала — хранить состояние прямо в URL-е.Хорошо спроектированный URL — это контракт между приложением и пользователем.Он описывает смысл, сохраняет контекст и делает взаимодействие предсказуемым.🧭 Когда стоит хранить состояние в URL:✅ поисковые запросы, фильтры, сортировки, даты, активные вкладки, режимы просмотра❌ пароли, личные данные, временные состояния, слишком большие объекты💡 Лучшие практики:• Делайте параметры читаемыми и последовательными (?theme=dark&page=2)• Используйте pushState для навигации, replaceState — для мелких обновлений• Не храните чувствительные данные• Избегайте чрезмерно длинных или зашифрованных ссылок📖 В общем, очень советую прочитать статью —и вспомнить, насколько элегантным может быть веб, если не усложнять то, что уже давно работает идеально.