JavaScript *

Автор статьи, перевод которой мы сегодня публикуем, говорит, что в компании commercetools приняли на вооружение хуки React в начале 2019 года — в момент их появления в React 16.8.0. С тех пор программисты компании постоянно перерабатывают свой код, переводя его на хуки. Хуки React позволяют, не используя классы, работать с состоянием компонентов и пользоваться другими возможностями React. Используя хуки, можно, работая с функциональными компонентами, «подключаться» к событиям жизненного цикла компонентов и реагировать на изменения их состояния.

Многие из нас уже несколько недель сидят дома и в голове все чаще звучит мысль — а нужно ли? Может быть власти и медиа сильно преувеличивают — если что и было, то уже закончилось, можно возвращаться в привычный ритм. В этой статье я дам вам возможность самим ответить на этот вопрос. Пользуясь случаем, я разработал приложение наподобие Plague Inc, только без игровой механики, но с возможностью точечной настройки параметров — Pandemic simulator. В статье я покажу, как отличается характер пандемии в зависимости от нас с вами — сидим ли мы дома и моем ли руки.

Вот так изменится население США в случае если у COVID-19 будет 90% летальность.

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

Немедленно вызываемая функция (Immediately Invoked Function Expression — IIFE) в JavaScript — это конструкция, позволяющая вызывать функцию непосредственно после ее определения.



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

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

Обзор

Intersection Observer API (IOA) позволяет приложению асинхронно наблюдать за пересечением элемента (target) с его родителем (root) или областью просмотра (viewport). Другими словами, этот API обеспечивает вызов определенной функции каждый раз при пересечении целевого элемента с root или viewport.

Примеры использования:

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

Falcon Heavy Demo Mission

Писать тесты скучно. А то, что скучно делать, постоянно откладывается. Меня зовут Назим Гафаров, я разработчик интерфейсов в Mail.ru Cloud Solutions, и в этой статье покажу вам другой, немного странный подход к автоматизированному тестированию.

Я — большой любитель TypeScript. По возможности я стараюсь использовать этот язык в своих проектах. TypeScript даёт разработчику отчёты об ошибках и проверку типов в JavaScript и TypeScript-коде. Кроме того, тот, кто пишет на TypeScript, может пользоваться удобными возможностями по автозавершению кода, может, быстро и надёжно, выполнять рефакторинг. TypeScript — это первая линия обороны от ошибок в коде. Ещё одна сильная сторона этого языка заключается в том, что он позволяет, при написании программ, пользоваться самыми свежими возможностями JavaScript. При этом то, что получается при преобразовании TypeScript-кода в JavaScript, будет поддерживаться всеми браузерами. Это очень приятно.



Правда, не все фронтенд-проекты предусматривают применение TypeScript. Что если можно было бы пользоваться возможностями TypeScript, но при этом не переводить на него весь проект (и всю команду), и не добавлять в конвейер сборки проекта новый инструмент? Это возможно благодаря VS Code и JSDoc.

Предлагаем вашему вниманию подборку с ссылками на новые материалы из области фронтенда и около него.

Бэкдор в собственном коде, который может незаметно взаимодействовать с операционной системой, это один из самых страшных кошмаров любого разработчика. В настоящий момент в npm имеется более 1.2 миллиона общедоступных пакетов. За последние три года зависимости проектов превратились в идеальную цель для киберпреступников. Экосистема npm может оказаться на удивление хрупкой в том случае, если сообщество разработчиков не обратит пристальное внимание на безопасность. В качестве доказательств этой мысли достаточно вспомнить о тайпсквоттинге и об инциденте с npm-пакетом event-stream.



Автор статьи, перевод которой мы сегодня публикуем, хочет, в образовательных целях, рассказать о том, как создавать бэкдоры для платформы Node.js.

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

Я подумал, что кому-то ещё это могло бы оказаться полезным и решил оформить в виде статьи на Хабр.

Сердце любого современного сайта или браузерного приложения (что SPA, что PWA, что любые другие три буквы) — это его State, или состояние.

Мы можем сколько угодно спорить о том, что лучше — React, Vue, Svelte, Angular, можем продолжать пользоваться jQuery, но в действительности это не так важно. Это та часть нашего приложения, которое мы видим — его “мышцы“ и “кожа”. Но то, как вы думаете — какими терминами оперируете, какие механики используете для даже визуализации в голове того, как в вашем приложении “текут” данные — все это идет из его скелета. Из state manager-а.

Помните, пару лет назад у нас была усталость от JavaScript-а? Сейчас я вижу у огромного количества людей усталость от state manger-ов. Redux? Да, да and да. RxJS? Тоже. MobX? Если он такой простой — блин, почему у него есть в документации страница западни.html?

Ответ “почему многим так тяжело” есть, но сначала надо точно сформулировать проблему.

Выбирая state manger — мы выбираем образ мышления. Вариантов сейчас много, но самые популярные подходы бьются на 3 группы:

TypeScript позволяет автоматизировать множество задач, которые, без использования этого языка, разработчикам приходится решать самостоятельно. Но, работая с TypeScript, нет необходимости постоянно использовать аннотации типов. Дело в том, что компилятор выполняет большую работу по выводу типов, основываясь на контексте выполнения кода. Статья, перевод которой мы сегодня публикуем, посвящена достаточно сложным случаям вывода типов, в которых используется ключевое слово infer и конструкция as const.

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

Можно бесконечно холиварить о том, является ли GitLab хорошим продуктом. Лучше посмотреть на цифры: по итогам раунда инвестирования оценка GitLab составила 2,7 млрд долларов, в то время как предыдущая оценка была $1,1 млрд. Это означает бурный рост и то, что компания будет нанимать все больше и больше фронтенд-разработчиков.

Так выглядит история появления фронтенда в GitLab.



Это график количества фронтендеров в GitLab, начиная с 2016 года, когда их не было вообще, и заканчивая 2019-м, когда их стало уже несколько десятков. Но сам GitLab существует 7 лет. Значит, до 2017 года основной код на фронтенде писали бэкенд-разработчики, хуже того, бэкенд-разработчики на Ruby on Rails (ни в коем случае никого не хотим обидеть и ниже поясним, о чем идет речь).

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

Web Audio API существует уже давно, и про него есть немало статей. Поэтому про сам API много говорить не будем. Расскажем, что Web Audio и Angular могут стать лучшими друзьями, если их правильно познакомить. Давайте сделаем это!

Предлагаем вашему вниманию подборку с ссылками на новые материалы из области фронтенда и около него.

Перевод статьи подготовлен в преддверии старта курса «Разработчик Node.js».

---

У современных разработчиков есть много альтернатив, когда речь заходит о создании веб-сервисов и других серверных приложений. Node стал крайне популярным выбором, однако многие программисты предпочитают более надежный язык, чем JavaScript, особенно те, кто пришел из современных объектно-ориентированных языков, например, таких как C#, C++ или Java. Если TypeScript просто хорошо подходит NodeJS , то фреймворк NestJS выводит его на совершенно новый уровень, предоставляя современные инструменты бэкенд-разработчику для создания долговечных и высокопроизводительных приложений с использованием компонентов, провайдеров, модулей и других полезных высокоуровневых абстракций.

В этой статье мы рассмотрим процесс создания простого API-сервера на NestJS для обработки базового сценария приложения: создание, хранение и получение списка продуктов универсама.

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



Код веб-страницы традиционно состоит из трех разделов, каждый из которых выполняет свои обязанности: HTML-код определяет структуру и семантику, CSS-код определяет внешний вид, а JavaScript-код определяет его поведение. В командах с участием дизайнеров, HTML / CSS разработчиков и JavaScript-разработчиков это разделение получается естественно: дизайнеры определяют визуальные элементы и пользовательский интерфейс, разработчики HTML и CSS размещают эти визуальные элементы на странице в браузере, а JavaScript-разработчики добавляют взаимодействие с пользователем, чтобы связать все вместе и «заставить это работать». Каждый может работать над своими задачами, не вмешиваясь в код остальных двух категорий разработчиков. Но все это справедливо для так называемого «старого стиля».

Всем привет! Сегодня я попробую поэкспериментировать с Dependency Injection на чистом JavaScript. Тех кто не в курсе, что это за дичь и как ее готовить, приглашаю ознакомиться. Ну а у тех кто в курсе будет повод написать важный и полезный комментарий. Итак, погнали…

Как давно вы платили на веб-сайте в один клик с помощью Google Pay, Apple Pay или заранее заданной в браузере картой?

У меня такое получается редко.

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

Это не очень удобно. Особенно когда знаешь об альтернативе: в последние пару лет стандарт Payment Request API позволяет легко решать эту проблему в современных браузерах.

Давайте разберемся, почему его не используют, и попробуем упростить работу с ним.