Ситуация банальная, но болезненная.
У тебя есть открытая вакансия, бюджет — один человек.
И ты выбираешь: взять уже готового мидла или вырастить джуна?
На первый взгляд — ответ очевиден...
Привет! Я — Александр Дудукало, автор базового курса по JavaScript. Если вы читаете эту статью, значит, вероятно, уже знакомы с одной из основных логических конструкций в JavaScript — if-else. Если нет, рекомендую сначала прочитать предыдущий материал, где я подробно разобрал эту тему.
В этой же статье мы поговорим о других способах управления логикой в коде — тернарном операторе и конструкции switch. Да, звучит сложно и, возможно, пугающе. Но я уверяю, все очень просто. В итоге вы узнаете, когда их стоит использовать и чем они могут быть полезнее привычного if-else. Поехали?
На просторах сети немало сайтов, и у значительной их части на главной странице находится ОН — Самый Главный Слайдер.
Как правило, у него есть некоторый набор отличительных черт: он большой, у него красивые картинки, он содержит очень важную информацию!
А самое главное — зачастую, часть его слайдов... нечитаема. И это очень коварная проблема, ведь поначалу ничто не предвещает беды. Дизайнер делает красивый дизайн, верстальщик - качественную вёрстку. Всё идёт отлично!
А спустя время заказчик начинает вводить текст, загружает картинку, иии... Оказывается, что картинка подходит совсем не любая. На самом деле, даже не любая картинка зачастую тоже не подходит!
А ещё есть разные... кхм... разрешения... кхм... экрана... Простите, слеза в горле застряла.
В рамках одной из внутренних задач коллега занимался исследованием того, как Bitrix измеряет общую производительность системы. Пользователи часто ссылаются на эти цифры как на аргумент в пользу «медленных серверов». Мы решили разобраться, что стоит за этой метрикой на самом деле. Эта небольшая статья — адаптированный вариант проведённого исследования.
Оверинжиниринг — это когда простую задачу решают так, словно строят космический корабль: с абстракциями, фабриками и паттернами «на будущее». Разбираем живые примеры, почему так происходит и как находить баланс между гибкостью и простотой.
Одним из ключевых преимуществ этого пользовательского хука является его простота и возможность повторного использования. Всего с помощью нескольких строк кода вы можете без особых усилий реализовать адаптивное поведение во всем вашем приложении. Независимо от того, требуется ли вам условный рендеринг компонентов, применение определенных стилей или запуск различных функций в зависимости от размера экрана, useMediaQuery поможет вам в этом.
Микросервисы звучат заманчиво, но для стартапов это может оказаться роковой ошибкой. Неужели это идеальный кандидат на неудачу?
Почему они не потопили меня и всех моих коллег. Много объективной статистики и немного субъективщины.
Одним из ключевых преимуществ useGeolocation является его простота. Благодаря инкапсуляции сложной логики, необходимой для доступа к геолокации и ее обработки, этот хук обеспечивает чистое и многократно используемое решение. Хук автоматически обрабатывает состояние загрузки, обновляя его при загрузке данных геолокации, и устанавливает состояние ошибки, если в процессе возникают какие-либо проблемы.
Интернационализация (i18n) и локализация (l10n) часто кажутся проблемами “на потом” — пока внезапно не становятся срочными.
Как разработчики, мы все делали что-то вроде:
<button>Order now</button>
Или в шаблоне:
<p>Welcome back, {{ user.name }}!</p>
Всё работает — пока команда не говорит:
«Мы выходим на рынок Узбекистана, Казахстана и Ближнего Востока в следующем квартале.»
И тут внезапно каждая хардкодная строка превращается в технический долг. Разработчики в панике вытаскивают строки, дизайнеры чинят поломанные макеты, тестировщики ловят недостающие переводы, и релиз откладывается.
Вот тогда и наступает момент задаться вопросом: что такое i18n и l10n — и почему это важно?
Салют, Хабр! Меня зовут Всеволод, и я занимаюсь анализом защищенности веб-приложений в Positive Technologies.
С API веб-приложений я успел познакомиться со всех сторон: как разработчик, инженер в AppSec и пентестер. В большой корпорации мне пришлось столкнуться с колоссальными объемами API. Я быстро осознал, что в таких количествах их просто невозможно проверить вручную, и начал искать способы автоматизации. В результате уже больше двух лет я занимаюсь динамическим тестированием (DAST), в частности фаззингом.
В этой статье я расскажу, почему считаю DAST не менее важным, чем статический анализ кода (SAST), как новичку начать фаззить, а опытному специалисту научиться находить еще больше уязвимостей.
Привет, Хабр!
Мне всегда было интересно наблюдать, как развивается CSS. Держу себя в форме, чтобы не пропустить что-то важное. А недавно подумал: «Почему бы не поделиться ими с подписчиками?». И я тут.
Составил список новинок, которые мне кажутся важными и интересными. Есть несколько новых возможностей, которые очень сильно изменят CSS. Думаю, лучше готовиться к ним заранее.
Также скажу, что на сегодняшний день они реализованы минимальным количеством браузеров. Не получится использовать их прямо сейчас. Хотя некоторые можно, если вы поддерживаете только браузер Google Chrome. В любом случае про браузерную поддержку я тоже расскажу.
Давайте посмотрим, что я вам подготовил.
Наверняка вы неоднократно сталкивались с ситуацией, когда начинали разработку фронтенд‑приложения на React и вроде всё было очевидно, но через некоторое время чувствовали, что уже запутались, где какой компонент. И в такой ситуации приходится вновь и вновь смотреть код, чтобы вспомнить, где в иерархии находится определенный компонент. Или, например, начинаете создавать компонент и задумываетесь на время: — «А с чего начать и какой должна быть реализация?», а реализовав компонент понимаете, что можно было бы сделать это по‑другому.
Книга «Разработка фронтенд‑приложений» предлагает решения, для подобных ситуаций, а также даст руководство по‑другому подойти к разработке. Совершенно по‑новому!
Привет, Хабр! Хочу поделиться опытом создания сайта с помощью ИИ. Сразу скажу — я не профессиональный разработчик. Программировал несколько лет назад, потом переключился на другие задачи. Когда понадобилось сделать новый сайт, оказалось, что многое изменилось — новые инструменты, подходы. Пришлось учиться заново, но теперь уже с ИИ в качестве помощника.
Так что не судите строго — делюсь тем, что получилось, возможно, многое можно было сделать лучше или правильнее. Буду рад вашим советам!
У меня был сайт интернет‑магазина лабораторного оборудования, который постоянно ломался. Любое изменение — и что‑то отваливалось в другом месте. В итоге я решил: хватит мучиться, надо что‑то с этим делать. И попробовал создать новый сайт через нейросеть — через Claude.
Представьте себе машину, которую ремонтировали разные мастера в течение многих лет: заводишь двигатель — отваливается колесо, прикручиваешь колесо — открывается багажник. Именно так выглядел мой старый сайт. Сайт делали разные люди в разное время, в коде невозможно было разобраться, любое изменение ломало что‑то в другом месте. SEO практически не работало, трафик постоянно падал.
Нужно было создать новый каталог для 400+ позиций лабораторного оборудования. Но это не классический интернет‑магазин с корзиной и оплатой, а каталог с формой «запросить цену» — в сфере B2B так часто работают.
Синдром бесконечного релиза — это такая опасная болезнь современного стартапа, которая возникает, когда команда зациклена на доработке и улучшении продукта, но при этом так и не решается его выпустить.
Кажется, что всё ещё можно сделать чуть-чуть лучше, чуть-чуть полнее, чуть-чуть красивее… И всё.
Уже 10 лет в JS-экосистеме воюют два формата модулей: CommonJS и ES Modules. Чтобы и получить плюшки ESM, и не распугать пользователей, npm-пакеты часто используют dual packaging: собирают код в оба формата. Это решает одну проблему, но создает несколько новых.
Сегодня расскажу
Какие проблемы пришли к dual packaging, и не пора ли от него отказаться.
В какой формат паковать npm-библиотеки в 2025 году.
Статься будет полезна и для опенсорса, и для внутренних библиотек, и для простых разработчиков (хотя бы чтобы понимать, откуда у вас в node_modules 2 Гб).
Что если создать систему, которая работает как Trello, но специально заточенная под совместную работу с моделями искусственного интеллекта?
Это как Tesla с автопилотом — вроде бы всё автоматически, но иногда хочется взять управление в свои руки. А что если добавить к этому автопилоту "ручную коробку передач"?
Результат более предсказуем, чем при работе с большими автономными запросами к ИИ.
После пяти лет работы JavaScript-разработчиком, занимаясь как фронтендом, так и бэкендом, я провел последний год, осваивая Go для серверной разработки. За это время мне пришлось переосмыслить многие вещи. Различия в синтаксисе, базовых принципах, подходах к организации кода и, конечно, в средах выполнения — все это довольно сильно влияет не только на производительность приложения, но и на эффективность разработчика.
Интерес к Go в JavaScript-сообществе тоже заметно вырос. Особенно после новости от Microsoft о том, что они переписывают официальный компилятор TypeScript на Go — и обещают ускорение до 10 раз по сравнению с текущей реализацией.
Эта статья — своего рода путеводитель для JavaScript-разработчиков, которые задумываются о переходе на Go или просто хотят с ним познакомиться. Я постарался структурировать материал вокруг ключевых особенностей языка, сравнивая их с привычными концепциями из JavaScript/TypeScript. И, конечно, расскажу о "подводных камнях", с которыми столкнулся лично — с багажом мышления JS-разработчика.
Интернет‑свободы сжимаются как шагреневая кожа. То, что еще недавно было естественным правом — свободно общаться, — превращается в привилегию. А мессенджеры? Они давно перестали быть мессенджерами. Это социальные сети, замаскированные под простое общение.
Сижу, листаю новости, читаю очередное «заблокировали», «ограничили», «запретили». И думаю: блин, а только меня это раздражает?
Сегодня размышляю об искусственном интеллекте и вдруг понимаю: технологии уже готовы.
Представьте: вы и коллега в разных уголках планеты, но курсоры ваши встречаются в документа онлайн редактора. Вы одновременно вставляете слова в одну и ту же позицию или удаляете фрагмент текста, который ваш коллега в этот момент редактирует. Казалось бы, результат должен превратиться в хаос, но всё складывается в единую, логичную версию текста — несмотря на расстояния, задержки и одновременные правки. При этом вы даже не ждете, пока ваши изменения согласуются с общим состоянием на сервере. Просто редактируете документ и можете быть уверены в том, что ваши изменения применятся.
На деле за этим волшебством часто скрываются CRDT — структуры данных, делающие возможной децентрализованную синхронизацию. Я сам столкнулся с этим, когда работал над онлайн-совместным редактором: CRDT и библиотека Yjs буквально спасли мой проект от хаоса и сделали синхронизацию прозрачной.
Меня зовут Никита Лыкосов, я занимаюсь фронтенд-разработкой в Doubletapp и предлагаю шаг за шагом разобраться, как устроена эта инженерная магия. Спойлер: это гораздо проще, чем кажется.
Читайте в статье:
• G-Counter — самый простой CRDT
• Какие правила CRDT выполняются на примере G-Counter и зачем это нужно?
• Массивы
• Yjs: как устроено совместное редактирование на практике
