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

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

Одним из новых инструментов в арсенале Vue 3 является Vite - быстрый и легковесный бандлер, который значительно упрощает процесс разработки и ускоряет сборку проекта. В этой статье мы рассмотрим, как перейти от стандартного подхода с использованием Vue-CLI и Webpack к более продвинутому и эффективному методу работы с помощью Vite.

Привет, Хабр! В этом посте делюсь опытом разработки на Svelte, демонстрируя это на моем пет-проекте.

Код проекта: GitHub
Лайв демо: ivan-sem.com

TLRD: zod не подходил в проекте и решили сделать свой builder с помощью ajv в zod-like API. Поскольку гугление не показало никаких вменяемых результатов - было решено сделать свои костыли решения.

Если стало интересно - прошу под кат!

Во многих разрабатываемых программах мы сталкиваемся с необходимостью организации работы с данными. Такие задачи могут быть самыми разными: хранение, актуализация, масштабирование и т. п. А ещё приходится реализовывать взаимодействие различных библиотек. Рассмотрим один из способов решения этих проблем при помощи React Lens.

Два года назад команда Next.js представила новый подход к роутингу, который должен был стать заменой так называемому Pages Router, вместе с тем добавив ряд принципиально нового функционала.

Практически в каждом релизе я находил множество полезного и нужного как для личных проектов, так и для коммерческих. Тем не менее, 13-ю версию я обошёл стороной для коммерческих проектов, так как функционал показывал себя крайне нестабильным и недостаточным. Однако, сейчас этот функционал перенесён в категорию стабильных, App Router считается основным, а Pages Router скорее поддерживаемым для обратной совместимости и постепенного перехода.

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

Мотивация разработчиков библиотек и фреймворков для фронтенда может быть разной. И если вы, являясь таким разработчиком, хотите работать не “в стол” а с расчетом на какое-то признание и пользу для индустрии, вы должны четко понимать, что именно и зачем вы делаете. Если вы хотите сэкономить пользователям пару килобайт трафика или пару миллисекунд отклика - вам будет очень тяжело доказать миру, что ради этого стоит выбрать именно ваше решение. Люди выберут размер комьюнити, богатую экосистему и крупного вендора. Ваш набор аргументов должен быть достаточно веским, чтобы обратить на себя внимание. Сейчас я попытаюсь доказать, что при наличии такого решения как LitElement от гиганта индустрии Google, имеет смысл посмотреть в сторону Symbiote.js.

Cache API - сравнительно старый API для управления хранилищем кэша, доступный уже во всех современных браузерах и являющийся частью ServiceWorker.

Разберемся, как мы можем его использовать, сравним с другими методами организации кэша на стороне клиента, а также реализуем новостную ленту с применением Cache API.

Как full-stack разработчик, я понимаю, что управление датами и временем в разных часовых поясах может быть сложной задачей. В JavaScript родной объект Date и популярные библиотеки, такие как Moment.js, обрабатывают часовые пояса по разному. Эта статья углубляется в эти различия и предлагает рассмотреть вопросы форматов даты и времени в API, чтобы достичь ожидаемых результатов в приложениях на JavaScript.

Детство самого известного сооснователя Vercel. Он родился в малом городе в Аргентине, не окончил школу, в 17 лет уехал работать в Швейцарию, а в 18 эмигрировал в США и начал воплощать свои идеи в роли бизнесмена.

Минули те времена, когда разработчики писали Frontend на «чистом» JavaScript (вплоть до ECMAScript 5). Все изменилось с выходом в свет версии ECMAScript 6 в 2015-м году. Это событие стало, по истине значимым в мировой Frontend разработке. Предыдущие 6 лет до этого, язык практически не менялся. Годом ранее, в 2014-м, компания Microsoft опубликовала TypeScript 1.0 и предоставила встроенную поддержку языка в своей IDE VisualStudio 2013. На самом деле, официально, TypeScript был выпущен еще в 2012 (версия 0.8), однако, популярностью он не пользовался в виду практически полного отсутствия поддержки со стороны существующих, на тот момент, IDE.

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

Типизацию TypeScript рассматривать в этой статье не будем, т.к. очевидно, что в ECMAScript её нет, и сравнивать тут нечего.

Для чистоты эксперимента код будем транспилировать в старый добрый ECMAScript 5. TypeScript, для удобства, возьмем версии 4.8.4 (этой версии, для целей статьи достаточно) и будем компилировать его родным tsc компилятором. Для ECMAScript воспользуемся инструментарием Babel.

Всем привет! Меня зовут Александр Григоренко, я фронтенд-разработчик, и в последнее время я много работаю над веб-интерфейсами с возможностью перетаскивания объектов методом Drag and Drop. В процессе изучения стандартов и сложившихся лучших практик работы с этим подходом, мне стало интересно разобраться в истории его появления. Копнув поглубже, я выяснил, что Drag and Drop — это один из самых первых способов взаимодействия человека с компьютерной программой. В этой статье хочу рассмотреть историю появления и развития этой технологии.

В 2024 году изучать frontend по-прежнему актуально. Вот несколько причин, почему это может быть полезным:

1. Развитие технологий: Веб-технологии постоянно развиваются, и в 2024 году можно ожидать еще большего прогресса. Изучения frontend поможет быть в курсе последних тенденций и использовать новые инструменты и фреймворки.

2. Рост спроса на разработчиков: Веб-разработка остается одной из самых востребованных отраслей IT. Спрос на frontend-разработчиков будет продолжать расти, так как все больше компаний стремятся создавать привлекательные и функциональные веб-приложения.

3. Возможность карьерного роста: Уверенное владение frontend-навыками может открыть двери к различным возможностям карьерного роста. Вы сможете работать над различными проектами, включая веб-сайты, веб-приложения, мобильные приложения и другие интерактивные решения.

4. Комбинированные навыки: Знание frontend-разработки может быть полезным дополнением к другим IT-навыкам. Например, если вы уже знаете backend-разработку, изучение frontend поможет вам создавать полноценные веб-приложения самостоятельно.

5. Творческий потенциал: Frontend-разработка предоставляет возможность реализовать свои творческие идеи и создавать уникальные пользовательские интерфейсы. Вы сможете воплотить свою визуальную концепцию и улучшить пользовательский опыт.

В целом, учить frontend в 2024 году будет полезно для тех, кто хочет развиваться в сфере веб-разработки, создавать современные и инновационные веб-приложения и иметь перспективы для карьерного роста.

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

Аннотация к циклу статей об одной из самых развитых и быстрорастущих платформ.

Должен признаться: на протяжении очень долгого времени я испытывал страх перед Unicode. Когда была необходимость в работе с Unicode, я предпочитал искать альтернативные пути решения, поскольку не совсем понимал, что делаю.

Я старался избегать работы с Unicode до тех пор, пока не столкнулся с проблемой, требующей глубокого понимания этого стандарта, а других вариантов решения просто не было.

Приложив определенные усилия, прочитав кучу статей — я постепенно начал понимать что к чему, и это оказалось не так уж трудно. Хотя, некоторые статьи приходилось перечитывать раза по 3.

Как оказалось, Unicode — это универсальный и удобный стандарт, но работать с ним может быть непросто из-за множества абстрактных терминов.

Если у вас есть пробелы в понимании Unicode, то сейчас самое подходящее время их заполнить! Заварите себе вкусный чай или кофе ☕. И давайте погрузимся в удивительный мир абстракций, символов, астралов (astrals) и суррогатов (surrogates).

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

Вы также узнаете, как JavaScript взаимодействует с Unicode и какие трудности могут возникнуть на этом пути.

А также, каким образом новые функции из ECMAScript 2015 могут помочь в решении этих проблем.

Готовы? Давайте начнем!

В наше время многочисленные сайты создают страницы, которыми пользователи хотели бы делиться в разных социальных сетях или мессенджерах. Благодаря тегам Open Graph ссылки могут иметь красочное превью изображение, которое привлекает еще больше внимания. В этой статья я хотел бы рассказать как с помощью Puppeteer и node.js мы упростили поддержку и сократили время разработки при создании таких изображений.

В мире веб-разработки JavaScript давно стал не просто инструментом, а основополагающей силой, без которой современный интернет трудно представить. Однако эта монополия языка несёт в себе не только преимущества, но и серьезные риски. Мы собрали ведущих экспертов по JavaScript, чтобы в рамках дискуссии на YouTube обсудить перспективы развития  языка и шансы его свержения с Олимпа веб-разработки.

Frontend-разработка очень богата различными инструментами. Новые фреймворки и библиотеки выходят чуть ли не каждый день и, к сожалению, не все из них одинаково полезны или могут сделать ваш продукт лучше. Кроме того, они различаются по степени удобства именно для разработчика. Есть такое понятие DX – Developer eXperience – по аналогии с UX. Это то, насколько разработчику удобно, интуитивно понятно пользоваться определенным сервисом.

Меня зовут Аня, я frontend-специалист в компании SimbirSoft с опытом в разработке более трех лет. Уже успела поработать со многими инструментами, участвовала в проекте, где переносили огромное приложение на новые библиотеки, в том числе заменяли Redux на Effector. В этой статье хочу поделиться своими мыслями об этих стейтменеджерах с точки зрения DX. 

Да, их сравнивали много раз, но мой акцент будет на том, как писать код на Effector для привычных кейсов в Redux. Подчеркну, DX — это не про рациональные аргументы, а про комфорт, фэншуй и тому подобные вещи (вы же понимаете, о чем я, правда?…).

Забегая вперед, хочу сказать, что Effector мне понравился. И прежде всего своей простотой — да-да, один из наших любимых принципов KISS). И может быть, что я по поводу Effector испытываю ещё какую-то национальную гордость, потому что это разработка ребят из России.

Всем привет! В этой статье я хотел бы рассказать про один из моих инструментов - GigaChat, ссылочка, который стал мне помощником на работе. Расскажу как его использую в повседневных рабочих задачах. Также подписывайтесь на мой канал про фронтенд, где делюсь интересной информацией, ссылочка здесь.

GigaChat - это мультимодальная модель (аналог ChatGPT от OpenAI), которую разрабатывает Сбер. В отличие от языковых моделей, мультимодальные работают не только с текстом. Они могут генерировать иллюстрации.

Анализ системы защиты сайта от ботов на примере letu.ru с использованием javascript reverse engineering.