Автор статьи, перевод которой мы сегодня публикуем, работает программистом в компании Antler. Эта компания представляет собой глобальный генератор стартапов. В Antler несколько раз в году проходят демонстрационные дни, собирающие множество создателей стартапов и инвесторов со всего мира. Ситуация вокруг COVID-19 вынудила Antler перевести свои мероприятия в онлайн-формат.



Компании хотелось сделать так, чтобы посетители их виртуальных мероприятий, ни на что не отвлекаясь, и нигде не застревая, видели бы самое главное. А именно — идеи представляемых публике стартапов, выраженные в виде содержимого веб-страниц. Виртуальные демонстрационные дни могут быть интересны достаточно широкой аудитории. Некоторые представители этой аудитории, возможно, впервые принимают участие в чём-то подобном. Поэтому компании нужно было сделать всё самым лучшим образом и обеспечить высокую скорость загрузки страниц, представляющих стартапы. Они решили, что это — как раз тот случай, когда им может пригодиться высокопроизводительное прогрессивное веб-приложение (PWA, Progressive Web App). Главный вопрос заключался в подборе подходящей технологии для разработки PWA.

Звучит ли это знакомо: «Я начал заниматься веб разработкой после прохождения курсов»?

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

1. Стек (вызовов) (Stack)

Стек следует принципу LIFO (Last In First Out — последним вошел, первым вышел). Если вы сложили книги друг на друга, и захотели взять самую нижнюю книгу, то сначала возьмете верхнюю, затем следующую и т.д. Кнопка «Назад» в браузере позволяет перейти (вернуться) на предыдущую страницу.

Приготовьтесь написать клон сервиса по доставке еды deliveroo.co.uk используя современные технологии: Nuxt.js, GraphQL, Strapi и Stripe!

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

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



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

Материал, перевод которого мы сегодня публикуем, посвящён рассказу о 10 React-компонентах.

Какие-то приложения грузятся быстро, какие-то медленно, но за счет чего это происходит? Только ли скорость загрузки страницы является показателем производительности приложения?

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

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

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

Знакомо? Если да, то вы в непростой ситуации. Она закономерно возникает в большинстве проектов, которые за годы своего существования накопили достаточный объём legacy.

Перед вами — второй материал из серии, посвящённой особенностям работы JavaScript на примере движка V8. В первом шла речь о механизмах времени выполнения V8 и о стеке вызовов. Сегодня мы углубимся в особенности V8, благодаря которым исходный код на JS превращается в исполняемую программу, и поделимся советами по оптимизации кода.

В случае JavaScript-движка V8 — очень даже. В этой статье я привожу результаты своего маленького исследования эффективности одной из внутренних оптимизаций V8.

Доброго времени суток, друзья!

Устал от JS, переключись на CSS!

Задача

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

Возможное решение

Для слайдшоу возьмем странные «макрофото» Paweł Czerwiński (они прикольные).

Итак, поехали.

Привет, меня зовут Борис Шабанов, я — руководитель Frontend-разработки в департаменте разработки рекламных технологий Rambler Group. Сегодня я расскажу вам о том, как на нашем приложении возникли проблемы маршрутизации, и про то, как мы их решали.

Каков наилучший способ беспроблемного увеличения параллелизма в Node.js-сервисе, который используется в продакшне? Это — вопрос, на который моей команде понадобилось ответить пару месяцев назад.

У нас запущено 4000 контейнеров Node (или «воркеров»), обеспечивающих работу нашего сервиса интеграции с банками. Сервис изначально был спроектирован так, что каждый воркер был рассчитан на обработку только одного запроса за раз. Это снижало воздействие на систему тех операций, которые могли неожиданно заблокировать цикл событий и позволяло нам игнорировать различия в использовании ресурсов различными подобными операциями. Но, так как наши мощности были ограничены одновременным выполнением лишь 4000 запросов, система не могла достойно масштабироваться. Скорость выдачи ответов на большинство запросов зависела не от мощности оборудования, а от возможностей сети. Поэтому мы могли бы улучшить систему и снизить стоимость её поддержки в том случае, если бы нашли способ надёжной параллельной обработки запросов.



Занявшись исследованием этого вопроса, мы не смогли найти хорошего руководства, в котором речь шла бы о переходе от «отсутствия параллелизма» в сервисе Node.js к «высокому уровню параллелизма». В результате мы разработали собственную стратегию перехода, которая была основана на тщательном планировании, на хороших инструментах, на средствах мониторинга и на здоровой дозе отладки. В итоге нам удалось повысить уровень параллелизма нашей системы в 30 раз. Это эквивалентно снижению затрат на поддержку системы примерно на 300 тысяч долларов в год.

Данный материал посвящён рассказу о том, как мы увеличили производительность и эффективность наших Node.js-воркеров, и о том, что мы узнали, пройдя этот путь.

Привет, Хабр! Представляю вашему вниманию перевод статьи «10 Signs You Will Suck at Programming» автора Jonathan Bluks.



Очень часто на Reddit или Quora я вижу вопросы вида «Как понять, смогу ли я стать успешным программистом?» (На самом деле, эта статья является расширенным продолжением моего недавнего ответа на Quora.) Когда кто-то задумывается о смене карьеры или интересуется разработкой и хочет знать, что для этого требуется, неизбежно возникает этот самый вопрос.

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

Будучи преподавателем на курсе «Full-stack Web-development», я работал со многими программистами-новичками. Хорошая новость в том, что мне редко встречались студенты, которые вообще не могли научиться программировать. Я считаю, что умение программировать — такой же базовый навык, как умение читать, писать и считать. Это под силу любому, так как это одна из способностей человека, но этому действительно надо учиться.

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

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

В 2019 году Node.js исполнилось 10 лет. Количество пакетов, доступных в реестре npm, пересекло отметку в 1 миллион. С каждым годом объём загрузок самой платформы Node.js увеличивается на 40%. Ещё одной важной вехой для Node.js стало то, что этот проект присоединился к OpenJS Foundation. Благодаря этому можно ожидать улучшения состояния и стабильности проекта, а также, в целом, положительных сдвигов в области взаимодействия членов JavaScript-сообщества.



Несложно заметить то, что за короткий отрезок времени, за год, в мире Node.js произошло много всего интересного. Каждый год Node.js набирает обороты. У нас нет причин рассчитывать на что-то другое в 2020.

В следующих релизах Node.js нас ждёт множество интересных возможностей. Этот материал посвящён наиболее значительным новшествам платформы, которые могут появиться в ней в 2020 году.

Вместо предисловия

Статья будет полезна тем, кто так-же как и Мы решил попробовать Svelte в живом проекте. В нашу небольшую компанию пришёл заказ на разработку веб-админки для сервиса с бекэндом на Mongodb Stitch. В последние пару лет frontend Мы пишем на React или Vue (в зависимости от размера проекта и нужен ли ReactNative), но наслышав о красотах Svelte мы решили попробовать его, чтобы понять для себя так ли он хорош. И может нам тоже стоит дальше использовать его вместо Vue или React?..

Кто такой Svelte?

Если в двух словах — это новый js фреймворк (но он таким себя не считает), который убийца React и Vue, и бла, бла, бла… В своей статье я хочу рассмотреть Svelte не какой он классный «под капотом», а с точки зрения удобства его использования в реальном проекте.
Мы не делаем машины, мы на них ездим и у нас есть злые заказчики с еще не менее злыми сроками.

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



Автор статьи, перевод которой мы сегодня публикуем, отобрал 9 таких инструментов.

В предыдущем сообщении Apollo graphql client применялся для разработки чисто клиентского приложения. В документации Apollo graphql client есть (очень лаконичный) раздел, посвященный серверному рендерингу и изоморфным приложениям.

Одна из сложностей серверного рендеринга в react.js является необходимость асинхронной загрузки данных, т.к. серверный рендеринг в reaсt.js — операция синхронная. Например, фреймверк next.js предлагает для этого использовать специальный компонент page в котором реализован дополнительный метод static async getInitialProps(), в котором предлагается проводить асинхронную загрузку данных. Такое решение не лишено недостатков. Например, этот метод статический, следовательно не имеет доступ к экземпляру компонента, метод реализован только для компонента самого верхнего уровня и отсутствует у вложенных компонентов. Решение с Apollo graphql client может быть использовано для компонента произвольного уровня вложенности.

Я работаю с Реактом на протяжении почти 3 лет, использовал как Redux так и MobX и у меня к текущему моменту возник вопрос. Почему абсолютное большинство front-end разработчиков продолжают свято верить в то, что Redux + Redux Saga + Reselect + 100500 других библиотек «облегчающих» жизнь — это лучшее решение на сегодняшний момент? Я приведу 4 аргумента в пользу того, чтобы в следующем проекте вы использовали MobX вместо Redux.

Прошло примерно 18 месяцев с внутреннего релиза Deno, вышел preview release, появилось несколько статей на Хабре, и Райан ездит по конференциям и рассказывает о нём. Однако я нигде так и не видел сколько-нибудь вдумчивого разбора этого проекта — почему-то все ограничиваются переводом документации...

Что же, давайте попробуем это сделать сейчас. Последние 5 лет я пишу на Node.JS, а компания OneTwoTrip, где я сейчас работаю, пишет проекты на ноде около 9 лет (да, это я писал историю про 9 лет в монолите на ноде). Так что анализ должен выйти неплохой. Тем более что я его уже рассказал на Moscow Node.JS Meetup 10, и было интересно. Кстати, если вам удобнее слушать, а не читать, то послушать и посмотреть можно вот тут. Моё выступление второе, я чувак в розовой рубашке.

Доброго времени суток, Хабровчане!

Хочу рассказать о том, как я недавно узнал о неких "хуках" в React. Появились они относительно недавно, в версии [16.8.0] от 6 февраля 2019 года (что по скоростям развития FrontEnd — уже очень давно)

Прочитав документацию я заострил свое внимание на хуке useReducer и сразу же задал себе вопрос: "Эта штука способна полностью заменить Redux!?" потратил несколько вечеров на эксперименты и теперь хочу поделиться результатами и своими выводами.

На написание этой статьи меня сподвигло отсутствие какого-либо более-менее полного мануала, как же сделать Server Side Rendering для React приложения.

Когда я столкнулся с этой проблемой, у меня было 2 варианта это сделать, либо Next.js фреймворк, либо используя Express.js.

На инвестигейт Next.js было потрачено около 100 часов, чтоб завести его для нашей готовой крупной OTT платформы, но проблем было настолько много, что мы от него отказались (по этому поводу напишу статью еще), остался выбор за малым, Express.js, про который я и хочу рассказать.

Полный код демо-примера, рассматриваемого в статье, тут.