Привет! Меня зовут Влад, я frontend-разработчик в компании SimbirSoft. Мне приходилось создавать приложения как на старых версиях Vue, так и на новых. Причем многие из моих коллег вполне успешно разрабатывают на Vue 2 и не спешат переходить на Vue3, даже спустя два года после релиза.

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

В этой статье попытался раскрыть новшества, которые могут стать «триггером» для миграции на новую технологию для обеих заинтересованных групп. Поговорим об экосистеме Vue 3, о новинках и пользе для разработчиков и бизнеса. И, разумеется, сравним Vue 2 и Vue 3 с технической точки зрения. Также рассмотрим одно из главных нововведений фреймворка – Composition API, раскроем технические нюансы и определим лучшие кейсы использования нового API.

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

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

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

Когда мы имеем дело с большим проектом, в репозитории которого накопились десятки тысяч строк кода, иногда единственным здравым решением кажется все переписать с нуля, а не оптимизировать. С точки зрения бизнеса может возникнуть вопрос: а почему вообще нужно оптимизировать или даже переписывать приложение, если оно работает? Дело в том, что по мере роста кодовой базы есть вероятность увеличения дублирующихся компонентов/фрагментов кода, появления устаревших участков, которые тормозят сборку, но полезной нагрузки уже не несут. Это негативно влияет на скорость работы приложения и увеличивает срок разработки.

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

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

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

Мы часто слышим в новостях фразы «Хакеры атаковали», «Хакеры взломали», «Хакеры украли» и подобные. Как сообщают legaljobs, хакеры проводят 1 атаку в вебе каждые 32 секунды. По прогнозам cybercrime magazine, ущерб от киберпреступлений к 2025 году составит $10,5 трлн против $3 трлн в 2015 году. Но почему у них получается произвести атаку, как это происходит и кто же они такие, “эти хацкеры”?

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

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

О хуках в фронтенд-разработке на Хабре писали уже не раз, и в этой статье мы не сделаем великого открытия. Наша цель другая – рассказать про React Hooks настолько подробно и просто без трудной терминологии, насколько это возможно. Чтобы после прочтения статьи каждый понял про хуки всё. Эта статья будет полезна как начинающим React-разработчикам, так и тем, кто хочет, не уходя в глубины документации, получить практическую информацию в сжатом виде. 

Для удобства отражения сайта на мобильных устройствах зачастую нужно внедрить в проект страницу Accelerated Mobile Pages (AMP). Делимся примером, как можно выполнить эту задачу, если вы работаете с приложением на React.

Начнем с того, что AMP — технология ускоренных мобильных страниц от Google с открытым исходным кодом. Этот способ позволяет оперативно загрузить веб-страницу при низкой скорости подключения к сети.

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

Именно такая задача появилась в одном из наших проектов, где стек технологий включал в себя Next.js, React, Styled components и Effector, при этом не было доступа к стору на стороне клиента. Большинство инструкций и гайдов по внедрению AMP, в свою очередь, были ориентированы на обычные html-страницы.

Бывает так, что ваше приложение обрабатывает графику и нуждается в высокой производительности – например, если это сервис для бронирования мест в зале, который мы показали в одной из прошлых статей. При этом зачастую нужны плавный зум или скроллинг элементов, а также поддержка различных библиотек. Рассмотрим, как сохранить производительность и скорость, на примере работы с библиотекой react-three-fiber.

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

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

У каждого из вас может возникнуть потребность поработать с графикой при создании React-приложения. Или вам нужно будет отрендерить большое количество элементов, причем сделать это качественно и добиться высокой производительности при перерисовке элементов. Это может быть анимация либо какой-то интерактивный компонент. Естественно, первое, что приходит в голову – это Canvas. Но тут возникает вопрос: «Какой контекст использовать?». У нас есть выбор – 2d-контекст либо WebGl. А как на счёт 2d-графики? Тут уже не всё так очевидно.

Когда нужно сделать код в проекте гибким и удобным, на помощь приходит разделение архитектуры на несколько слоев. Рассмотрим подробнее этот подход и альтернативы, а также поделимся рекомендациями, которые могут быть полезны как начинающим, так и опытным разработчикам Vue.js, React.js, Angular. 

В старые времена, когда JQuery только появился, а о фреймворках для серверных языков лишь читали в редких новостях, веб-приложения реализовывали целиком на серверных языках. Зачастую для этого использовали модель MVC (Model-View-Controller): контроллер (controller) принимал запросы, отвечал за бизнес-логику и модели (model) и передавал данные в представление (view), которое рисовало HTML. 

Объектно-ориентированное программирование (ООП) на тот момент только начинало формироваться, поэтому разработчики зачастую интуитивно решали, где и какой код надо писать. Таким образом, в мире разработки зародилось такое понятие, как «Божественные объекты», которые первоначально отвечали практически за всю работу отдельных частей системы. Например, если в системе была сущность «Пользователь», то разработчику следовало создать класс User и в нем писать всю логику, так или иначе связанную с пользователями. Без разбиения на какие-то ещё файлы. И если приложение было большим, то такой класс мог содержать тысячи строк кода.