Если вы пытаетесь разобраться, какой из этих двух замечательных фреймворков выбрать, читайте мнение сторонника Vue по этому вопросу, которое я перевел и дополнил.
Переведено при поддержке облачной платформы Mail.ru Cloud Solutions.
Читать полностью »
Вносить однотипные изменения в три-четыре разных места в JS-коде — искусство, требующее концентрации внимания. Если элементов больше, поддержка кода превращается в муку. Поэтому для долгосрочных или крупных проектов следует писать код так, чтобы его можно было вынести в отдельные компоненты.
Я занимаюсь фронтенд-разработкой уже 10 лет и расскажу о применении компонентов для создания элементов фронтенда — это значительно упрощает жизнь фронтенд-разработчика.
Написано при поддержке Mail.ru Cloud Solutions.
Читать полностью »
Доброго времени суток.
Разбор полетов провожу на Reactjs (сторона клиента) и Nodejs (сторона сервера).
Недавно в моем маленьком проекте встал вопрос, как легко и просто можно обмениваться изображениями по типу клиент — сервер.
Сегодня мы научимся отправлять бинарные данные (конкретно изображения ) со стороны клиента и обрабатывать их на сервере. Добро пожаловать в под кат.
Читать полностью »
Этот пост является вторым в серии статей об авто-трекинге — новой системе реактивности в Ember.js. Я также обсуждаю концепцию реактивности в целом, и как она проявляется в JavaScript.
От переводчика: Крис Гарретт — работает в компании LinkedIn и является одним из core-контрибьюторов js-фреймворка Ember. Он принимал активное участие в создании нового издания фреймворка — Ember Octane. Одним из краеугольных камней этой редакции является новая система реактивности на основе автоматического отслеживания (autotracking). Несмотря на то, что его серия написана для Ember-разработчиков в ней затрагиваются концепции, которые полезно знать всем веб-программистам.
Читать полностью »
Я полагаю, что для решения различных задач React-разработки лучше использовать маленькие узкоспециализированные инструменты, а не универсальные решения, предлагаемые библиотеками компонентов. Мне нравится выбирать компоненты самостоятельно, я не люблю читать длинную документацию, и мне хочется избежать бессмысленных обновлений библиотек, после которых в проекте нередко что-то ломается.
Некая фронтенд-библиотека способна дать разработчику единообразное оформление компонентов, что крайне важно. Но может оказаться так, что в проекте, в котором планируется использовать такую библиотеку, уже есть собственная дизайн-система, или собственная UI-библиотека. В такой ситуации разработчик ищет не новую библиотеку, а лишь настраиваемые компоненты, подходящие для многократного использования и ускоряющие работу. В подобном случае больше смысла я вижу в поиске отдельного компонента, а не целой библиотеки, которая содержит, вместе с тем, что очень нужно разработчику, много такого, что ему совершенно ни к чему.
Материал, перевод которого мы сегодня публикуем, посвящён рассказу о 10 React-компонентах.
Читать полностью »
Каждый год выходит исследование State of JavaScript, которое обобщает результаты опроса, изучающего текущее состояние экосистемы JavaScript. Это исследование затрагивает фронтенд-фреймворки, серверную и мобильную разработку, тестирование, популярные ресурсы для разработчиков и многое другое.
В нём всё, конечно, крутится вокруг JavaScript. Поэтому если вы используете для веб-разработки JS — я очень рекомендую взглянуть на State of JavaScript в том случае, если вы ещё этого не сделали.
Для меня одним из самых интересных результатов State of JavaScript стало неожиданное внимание тех, кто участвовал в опросе, к фронтенд-фреймворку Svelte.
В общем рейтинге ведущих фронтенд-инструментов (основанном на показателях осведомлённости о фреймворке, интереса к нему и удовлетворённости им) Svelte появился на второй позиции. Он идёт там сразу после React, опережая такие хорошо известные инструменты, как Vue.js, Preact, Angular и Ember.
Меня это слегка шокировало, так как Svelte — это сравнительно новый инструмент — как в плане возраста, так и в плане парадигмы разработки программного обеспечения.
Рейтинг фронтенд-фреймворков по результатам исследования State of JavaScript
Читать полностью »
Мы продолжаем рассказ о том, как внутри Одноклассников с помощью GraalVM нам удалось подружить Java и JavaScript и начать миграцию в огромной системе с большим количеством legacy-кода.
Во второй части статьи мы подробно расскажем о запуске, сборке и интеграции приложений на новом стеке, погрузимся в специфику их работы как на клиенте, так и на сервере, а так же обсудим, возникшие на нашем пути, трудности и опишем решения, помогающие их преодолеть.
Если вы не читали первую часть, то очень рекомендую это сделать. Из неё вы узнаете об истории фронтенда в Одноклассниках и познакомитесь с его историческими особенностями, пройдете путь поиска решения проблем, которые накопились у нас за 11 лет существования проекта, а в самом конце окунетесь в технические особенности серверной реализации принятого нами решения.
Читать полностью »
Когда я заглядываю в файл {domain}/selectors.js в больших проектах на React/Redux, с которыми работаю, я часто встречаю огромный список redux-селекторов подобного вида:
getUsers(state)
getUser(id)(state)
getUserId(id)(state)
getUserFirstName(id)(state)
getUserLastName(id)(state)
getUserEmailSelector(id)(state)
getUserFullName(id)(state)
…На первый взгляд использование селекторов не выглядит чем-то необычным, но с опытом мы начинаем понимать — селекторов может накопиться слишком много. И кажется, мы дожили до этого момента.
Инверсия Управления это довольно простой для понимания принцип программирования, который, при этом, может заметно улучшить ваш код. В данной статье будет показано как применять Инверсию Управления в JavaScript и в Reactjs.
Если вы уже писали код который используется больше чем в одном месте, то вам знакома такая ситуация:
Что именно делает код кошмаром для использования и поддержки? Есть несколько аспектов, которые могут сделать ваш код проблемным:
Если попытаться в двух словах описать, в чем заключается функция роутинга на фронтэнде веб-приложений, то можно придти к выводу, что каждый популярный фреймоворк совершенно по-разному представляет это себе. Даже, сравнивая версии одного и того же фреймоворка, можно придти к выводу, что функции и API роутинга наиболее подвержены изменениям (часто без обратной совместимости). Например 4-я версия роутинга в React была переработана настолько радикально, что некоторые популярные проекты на githab.com так и не перешли на эту версию.
За всем этим просматривается общая тенденция, которая, по моему мнению, заключается в том, что функционал роутинга в многих популярных фронтэнд фрейморках перегружен. В связи с этим, он становится жестко связанным с другими компонентами, которые могли быть выделены из роутинга (например с навигацией, историей, ссылками и т.п.). Поэтому, наверное, многим знакомо то чувство, когда использование роутинга становится неудобным, а его расширение просто невозможным. По сравнению с гибкими и расширяемыми компонентами, роутинг в популярных фронтэнд фрейморках выглядит на порядок менее удобным и совсем не расширяемым. Особенно это относится первым версиям (до 4-й) роутинга в React.
В этом сообщении я рассмотрю некоторые исторические моменты, которые привели к такому положению дел с роутингом, а также использование библиотеки universal-router, совместно с React.
