JavaScript *

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

Если спросить разработчиков, почему они выбрали веб-компоненты для своего проекта, довольно часто можно услышать такие аргументы

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

Аргументы выглядят логичными и справедливыми в обычной ситуации, но в случае веб-компонентов есть нюансы, которые я попробую раскрыть в этой статье.

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

Дорогие товарищи инженеры, сообщество Метархия представляет вашему вниманию современный курс по Node.js, который включает глубокий разбор всех возможностей и аспектов платформы. Основной упор делается на то, как создавать надежные высоконагруженные сервера приложений и API без привязки к конкретному фреймворку и даже протоколу, т.е. абстрагировать бизнес-логику в отдельный слой. К лекциям прикреплено множество примеров кода, демонстрирующих гибкую структуру приложений и архитектурные приемы, в том числе работу с СУБД через слой доступа к данным, создание интерактивных приложений на вебсокетах, обеспечение безопасности, Graceful shutdown, межпроцессовое взаимодействие, предотвращение утечек памяти, масштабирование и кластеризацию при помощи процессов и потоков. На текущий момент в курсе 38 лекций (около 35 и ½ часов видео), 37 репозиториев с примерами кода, 4 PDF со слайдами. Перед основной частью курса по Node.js нужно сначала освоить хоть частично курс по асинхронному программированию.

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



В Klarna используют платформу Node.js. Статья, перевод которой мы публикуем сегодня, посвящена тем урокам, которые специалистам компании удалось извлечь из опыта оптимизации производительности своего сервиса.

Был поздний вечер.

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

Код работал.

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

Ленивая загрузка компонентов в Angular? Может, речь идёт о ленивой загрузке модулей с помощью маршрутизатора Angular? Нет, мы говорим именно о компонентах. Текущая версия Angular поддерживает лишь ленивую загрузку модулей. Но Ivy даёт разработчику новые возможности в работе с компонентами.

Продолжаем лаконичную интерпретацию официальной документации Flutter в формате «вопрос-ответ». Вот уже 3-я часть, и она в большей степени будет полезна React Native-разработчикам. В данной интерпретации вы можете найти ответы на частые вопросы, а также определить для себя, сколько усилий нужно приложить, чтобы перейти с одного кроссплатформенного фреймворка на другой.

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

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



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

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

Многие слышали название GraalVM, но опробовать эту технологию в продакшене пока довелось не всем. Для Однокласснииков эта технология уже стала «священным Граалем», меняющим фронтенд.

В этой статье я хочу рассказать о том, как нам удалось подружить Java и JavaScript, и начать миграцию в огромной системе с большим количеством legacy-кода, а так же как на этом пути помогает GraalVM.

Во время написания статьи оказалось, что весь объём материала не влезает в традиционный для ХАБРа размер и если выложить публикацию целиком, то на её прочтение уйдет несколько часов. Поэтому мы решили разделить статью на 2 части.

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

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



Автор статьи, перевод которой мы сегодня публикуем, собирается исследовать три подхода к бандлингу JavaScript-проектов на примере простого Hello World-приложения, созданного с помощью React. Некоторые из приводимых им примеров подразумевают знание читателем основ сборщиков модулей, таких, как Webpack, который, похоже, является сегодня самым популярным среди подобных инструментов.

Сегодня мало кто помнит, что веб-приложения могут работать без единого XHR-запроса. AJAX (Asynchronous Javascript and XML) дает классную возможность — подгружать данные без перезагрузки страницы. Эта концепция лежит в основе большинства современных SPA.

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

Используете для создания приложений Vue, React, Angular или Svelte? Я использую, и если вы тоже, и уверен, что вам уже давно не приходилось писать приложение, которое выводит информацию без этих прекрасных инструментов.

Когда-то многие из нас писали веб-приложения только с помощью тех средств, что были встроены в браузер. И хотя современные инструменты помогают нам абстрагироваться от этого (и имеют много других преимуществ), всё ещё полезно знать, что происходит у них под капотом.

При выводе небольшого количества информации вам может потребоваться использовать HTML, JavaScript и DOM без каких-либо инструментов. Недавно я написал несколько базовых примеров, которые иллюстрируют основы веб-разработки и помогают в изучении DOM, HTML, JavaScript и принципов работы браузера. Этот опыт позволил мне понять, что другие разработчики — возможно, вы, — будут рады вспомнить, как выводить информацию без использования библиотек.

Кроме того, это забавно, полезно и помогает понять ценность современных библиотек и фреймворков, которые делают за нас так много работы.

Давайте рассмотрим разные способы вывода информации. И держите под рукой эту документацию!

Недавно опциональный доступ к аттрибутам (Optional Chaining) и значение по умолчанию для атрибутов (Nullish Coalescing) перешли на последний, четвёртый этап процесса TC39.

На практике это означает, что эти и другие нововведения станут частью стандарта JavaScript уже в этом, 2020 году. Их мы и рассмотрим в этой статье.

Отслеживать поддержку браузерами можно здесь («2020 features») — прим. перев.

Те телефоны, о которых идёт речь в заголовке, по-английски называют «feature phone». Они отличаются крайне скромными возможностями. Кроме того, они весьма доступны, так как стоят в районе $20-25. Их можно сравнить с облегчёнными версиями современных смартфонов. Такие телефоны позволяют сотням миллионов человек из развивающихся стран пользоваться веб-ресурсами.


Телефон Jio

Если в основе сайта лежат технологии, ориентированные на обеспечение высокой скорости его работы, то от этого выиграют все — и владельцы простых дешёвых телефонов, и те, кто смотрит веб-страницы со свежих мощных смартфонов.

Примечание переводчика: в текущий момент я подготавливаю материалы для обещанной статьи по монадам. К сожалению, это занимает довольно много времени, не говоря о том, что я всё же должен заниматься основной работой и уделять время семье, но процесс идёт. А пока представляю вам перевод небольшой свежей заметки от замечательного товарища Mark Seemann'а, которая мне показалась любопытной.

Я часто становлюсь участником длительных и жарких дебатов на тему статической типизации против динамической. Сам я определенно отношу себя к сторонникам статической типизации, но эта статья не о достоинствах статической типизации. Цель статьи — устранить распространённое заблуждение насчет статически типизированных языков.

Церемонность

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

Церемония — это то, что вы делаете до того, как начнете делать то, что вы действительно собирались сделать.

Venkat Subramaniam

Динамически типизированные языки производят такое впечатление, что им не требуются особые церемонии, но отсюда нельзя сделать вывод что статически типизированные языки их требуют. К сожалению, все мейнстримные статически типизированные языки относятся к одной и той же семье, и они требуют церемонности. Я думаю, что люди экстраполируют то, что они о них знают, ложно заключая что все статически типизированные языки обязательно идут в комплекте с оверхедом церемонности.

Это привело меня к мысли о том, что существует злосчастная Зона Церемонности:

Конечно же, эта диаграмма всего лишь упрощение, но я надеюсь, что она демонстрирует суть. C++, Java и C♯ — языки, которые требуют церемонности. Справа от них находятся языки, которые мы могли бы назвать транс-церемониальными, включая F♯ и Haskell.

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



За многие годы я сформировал ментальную модель JavaScript, которая дала мне ощущение уверенности. Здесь я собираюсь поделиться с вами весьма сжатым вариантом этой модели. Её структура напоминает словарь. Каждое понятие описано в нескольких предложениях.

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

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



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

---

С чем можно столкнуться при синхронизации Web Audio и геймплейных часов внутри javascript-приложения; сколько вообще разных «часов» есть в javasctipt (три!) и зачем все они нужны, а также готовое приложение для node.js – под катом.

Badoo регулярно участвует со стендом в выставках IT-конференций. Поэтому каждый год мы с коллегами — инженерами и деврелами — придумываем, что бы такого айтишного сделать, чтобы не скучать в перерывах между докладами.

Меня зовут Иван, я frontend-разработчик. В этой статье вместе с коллегой и DIY-энтузиастом lilek Юрой Лилековым мы расскажем, как при помощи двух красных кнопок, одного микроконтроллера, кода на React и 250 слов на айти-тематику мы сделали игру «IT-угадайка» и собрали уютную тусовочку на Highload++ и Heisenbug.

Помните те времена, когда стеки веб-технологий были простыми? Когда уровни этих стеков можно было обозначить в виде четырёхбуквенного сокращения вроде LAMP, LEMP или LEPP? Когда всё, что было нужно для создания и поддержки сайтов, сводилось к вполне обычному железу, к какому-нибудь опенсорсному софту, да к упорству в достижении цели?

Мой первый успешный сайт, теперь уже старинный проект 1999 года, был создан с использованием технологий, которые можно пересчитать по пальцам одной руки: HTML4, CSS2, JavaScript3 и Apache 1.1. Всё это крутилось на сервере с Linux 2.0. Сайт включал в себя 38000 страниц. И сегодня, через 20 лет, он всё ещё их выдаёт.



С тех пор всё изменилось. Это касается и стеков веб-технологий. Теперь они совсем не те, что прежде.

Автор статьи, перевод которой мы сегодня публикуем, хочет рассказать о том, как он перешёл от «фуллстека» к «стеку 2020 года». Некоторые технологии в ходе этого путешествия неожиданно стали фаворитами, а некоторые потеряли былую привлекательность.