JavaScript *

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

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

Я написал своё первое одностраничное веб-приложение на Javascript в 2005 году, сразу после того, как узнал о XMLHttpRequest и до появления серьёзных фреймворков. Я оставил профессиональную веб-разработку примерно в 2009 году (а начал её в 1997 году с WebObjects), а последний десяток лет своей карьеры занимался мобильными.

Сегодня я смотрю на мир веб-разработки, и меня поражает его безумие. Существует так много фреймворков для веба, и каждый день появляются новые. Для создания веб-приложения (в отличие от веб-сайта, например, моего сайта про искусство, который сгенерирован статически и содержит лишь немного Javascript), часто требуются кучи инструментов и технологий, часто меняющихся с большой частотой и содержащих бесконечные объёмы других технологий, о существовании которых мы и не подозреваем (о, смотрите-ка, в папке пакета две тысячи файлов).

Javascript — ужасный язык, никогда не задумывавшийся для чего-то подобного, но, как ни странно, ставший популярным, потому что он всегда был под рукой. Потрясающе, какой объём инноваций затрачен на построение современной вселенной веб-разработки, несмотря на достаточно шаткий фундамент, на котором она основана.

Привет, Habr! Я frontend-разработчик в Альфа-Банк. В статье я хотел бы поделиться опытом внедрения мобильной версии web приложения «Альфа-Бизнес» в нашу архитектуру. А точнее — как без массовых доработок 100 фронтовых сервисов мы заставили работать mobile web версию с новой навигацией.

Всем привет. Меня зовут Алексей. Сейчас я работаю frontend-разработчиком в компании Ozon. В свободное время мне нравится читать про новые технологии, фреймворки, а учитывая то, с какой скоростью развивается frontend, я никогда не скучаю. В этой статье пойдет речь о микрофронтах. В частности, мы посмотрим, как их реализовать на самом базовом уровне, разберемся, когда они нужны, а когда даже не стоит смотреть в их сторону. 

Зачем он нам вообще может понадобиться?

Добрый день. Меня зовут Тимофей, я фронт-тимлид в диджитал-продакшене ДАЛЕЕ. В данном цикле статей я поделюсь подходами и инструментами фронтенд-разработки на аутсорсе, которые помогут создать качественный продукт без кошмарного instant-legacy и значительно облегчат жизнь команде разработчиков и не только.

Расскажу, почему не стоит излишне усложнять архитектуру фронтенда, и дам примеры удобных и эффективных инструментов разработки с точки зрения DX (developer experience. Это важно) и дальнейшей поддержки.

На данный момент у нас используются три самых популярных менеджера пакетов (Npm, Yarn и Pnpm). И всё бы ничего, но разные команды начали периодически обращаться с проблемой несоответствия типов Typescript из наших транзитивных зависимостей. Выяснилось что это проблема Npm и Yarn, но как же её решать?

На ум сразу приходит самое очевидное решение: следить за версиями всех зависимостей в своих проектах и вовремя обновлять. К этому, естественно, необходимо стремиться всегда, но мы понимаем, на практике что это крайне сложно, а в legacy-проектах или в проектах, у которых нет постоянной поддержки и вовсе нереально. Следующим вариантом созрел Pnpm, тем более что в наших монорепах он себя уже продолжительное время отлично показывал. Я решил испытать его на действующих клиентских приложениях.

Всем привет, в этой статье я расскажу о основах Api, под игру Pixel Combats 2. Тут будет написано исключительно о моддинге, то есть написание кода. Подробностей как зарегистрироваться, и тд тут не будет. Эта статья написана для тех, кто уже умеет публиковать свой режим в игре.

Если вы следите за новинками экосистемы JavaScript, то должны были слышать об интересной библиотеке пользовательского интерфейса (user interface, UI) под названием shadcn/ui. Вместо того, чтобы распространяться в виде пакета npm, компоненты shadcn/ui добавляются с помощью интерфейса командной строки (command line interface, CLI), который помещает исходный код компонентов непосредственно в ваш проект. Разработчик библиотеки указывает причину такого решения на официальном сайте shadcn/ui.

"Почему код для копирования/вставки, а не библиотека?

Идея заключается в том, что вы полностью владеете и контролируете код. Это позволяет вам решать, как именно будут построены и оформлены ваши компоненты.

Начните с настроек по умолчанию, а затем кастомизируйте компоненты под свои нужды.

Используя пакет npm, можно наткнуться на один недостаток — стиль всегда связан с реализацией. Дизайн компонентов должен быть отделен от их реализации".

На самом деле, shadcn/ui — это не просто очередная библиотека компонентов, а технология, позволяющая представить дизайн-систему в виде кода.

Цель этой статьи — изучить архитектуру и реализацию shadcn/ui.

Если вы еще не использовали shadcn/ui, я советую просмотреть ее документацию и немного поэкспериментировать с ней, чтобы извлечь из статьи максимальную пользу.

Валидация форм является важной частью фронтенд-разработки, которая помогает улучшить пользовательский опыт и предотвратить ошибки при отправке данных на сервер. В этой статье мы рассмотрим, как использовать библиотеку AJV совместно с Vue.js и TypeScript для создания мощной системы валидации формы.

В прошлый раз мы рассматривали внедрение Sentry со стороны эксплуатации: устанавливали на сервер self-hosted, делали его высокодоступным при помощи сети доставки td-agent, настраивали мониторинг.

Теперь рассмотрим процесс внедрения Sentry со стороны команды разработки.

Недавно компания Facebook* (aka Meta**) выпустила в опенсорс собственную CSS-in-JS библиотеку под названием StyleX. По заявлениям разработчиков, она отлично подходит для больших проектов и ключевым ее преимуществом является перфоманс.

В этой статье мы рассмотрим пример использования, основные функции и особенности данного решения.

Каждый из нас, хотя бы раз, слышал о сборке мусора. Мы знаем, что где-то там работает сборщик мусора, убирая за нами ненужные объекты и массивы. Но сколько из нас знают, как он устроен под капотом?

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

Погнали собирать мусор!

Верней оформил 5 декабря 2023 года оформил для всех то, чем его разработчики пользуются уже давно. Позиционируется данный помощник для js-подобных фреймворков типа React, Preact, Solid, lit-html и Angular, однако оперирующие html шаблонами Vue и Svelte тоже могут задействовать StyleX, но после предварительной специальной её кастомизации.

Код в React в итоге выглядит примерно так:

Привет! Меня зовут Фёдор, я фронтенд-тимлид в KTS и преподаватель школы Metaclass.

Эта статья — цельный план развития во фронтенде. Расскажем, что из себя представляет современный фронтенд и какие знания нужны для востребованности на рынке труда.

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

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

Чтобы быстро продвигаться в рабочих задачах, необходимо иметь уверенность в том, что можно вносить изменения. А уверенность в изменениях зависит от тестового покрытия.

С тех пор как мы это поняли, автоматические тесты стали просто необходимы. Это привело к массовому внедрению шаблонов для старта работы. Однако просто начать работу недостаточно.

На Reddit прошла интересная дискуссия с 25К+ просмотрами по вопросу предпочтений разработчиков при необходимости управлять глобальным состоянием во Vue 3. Ниже её итоги.

Всем привет! Сегодня я хочу рассказать о Mock Service Worker — технологии, которая позволяет эмулировать поведение бэкенда в ситуациях, когда по каким-то причинам невозможно использовать реальный бэкенд для полноценной разработки фронтенда, а также когда необходимо изолированно протестировать различные пользовательские сценарии. Тем более, что совсем недавно вышла новая мажорная версия библиотеки msw, и в ней достаточно много важных обновлений.

Начинающие разработчики часто встречают на ревью пулл-реквестов очень дотошных ревьюеров, дающих кучу комментариев по теме чистоте кода. Меня зовут Мария Кондаурова, я фронтенд-разработчик в департаменте вычислительной биологии в BIOCAD. И у меня есть свои мысли на тему чистого кода и рефакторинга.

Со временем у разработчика опытным путем или с чтением хорошей технической литературы нарабатывается чувство чистого кода, но что делать новичкам? В этой статье я не буду долго мучать теорией про чистый код и паттерны —  про это уже было в Симпсонах в учебниках, конференциях и на Хабре в том числе. Но приведу примеры плохого (на мой взгляд) кода в приложениях на React и JavaScript — и также покажу, как его улучшить.

Надеюсь, что начинающим моя статья будет полезна — и после прочтения они смогут применить всё на практике.

Всем привет. Меня зовут Евгений Чернышев, и я возглавляю фронтенд-разработку в одном из направлений деятельности Домклик. Хочу поделиться своими мыслями о том, как управлять сложными конфигурациями Webpack. Сразу «проведу черту», чтобы предотвратить возможные холивары: сравнение Webpack с другими бандлерами (Rollup, Vite и прочими) выходит за рамки статьи.

Де-факто, Webpack является основным сборщиком фронтенд-проектов. Это зрелый продукт, который до сих пор развивается и повсеместно используется. Но, как и любой инструмент, он имеет свои слабые стороны. Я считаю что основной недостаток Webpack — это сложность его конфигурации. На крупных долгоживущих проектах конфигурационные файлы становятся слишком большими и нечитаемыми, превращаясь в мешанину вложенных объектов и spread-операторов. Чтобы показать, что я имею в виду, рассмотрим стадии развития проекта.