JavaScript *

Ecma International, Technical Committee 39 или по-простому TC39 — это группа JavaScript-разработчиков, создателей реализаций технологий, академиков и других заинтересованных сторон, которые вместе с сообществом поддерживают и развивают JavaScript как платформу.

Участники TC39 обычно рассказывают что-то интересное, пользуясь своим глубоким пониманием JavaScript. Но кое-кому кажется, что они слишком далеко ушли от проблем простых разработчиков. Где разработчик языка, и где человек, который каждый день на практике пишет фронтенды?

Давайте познакомимся с докладом, который сочетает и глубину понимания, и высокую практическую применимость. Встречайте новый рассказ Romulo Cintra о проблемах интернационализации, которые будут решены новым API, которое вскоре появится в JavaScript.



Romulo Cintra — делегат TC39, работает в разработке и архитектуре уже более 10 лет, специализируется на вебе, мобильной разработке и облаках. В этом докладе из первых рук сопредседателя MessageFormat Working Group вы узнаете, какие варианты решения существующих проблем есть уже сейчас, и в каком виде их собираются решать посредством нового API в самом JavaScript.

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

Далее повествование от лица спикера.

Сегодня мы публикуем перевод статьи о математических вычислениях в JavaScript, которая представляет собой письменный вариант выступления её автора на WaffleJS. А само это выступление было чем-то вроде продолжения этой беседы в Twitter.

Математическое образование

Это перевод статьи об оптимизации и уменьшении размера бандла приложения. Она хороша тем, что тут описаны best practices, советы, которых стоит придерживаться, чтобы тришейкинг работал и выкидывал неиспользуемый код из сборки. Она будет полезной многим, потому что сейчас все используют системы сборки, в которых «из коробки» есть тришейкинг. Но чтобы он работал правильно, нужно придерживаться принципов, описанных ниже.

Кнопка — это один из тех элементов, которые чаще всего используются на веб-страницах. Тег <button></button> может быть применён для запуска некоего процесса вроде вывода данных, открытия модального окна, отправки формы и так далее. В материале, перевод которого мы публикуем, речь пойдёт о тонкостях стилизации элемента button и о том, как оформлять кнопки с учётом того, чтобы они хорошо работали бы в любых браузерах. Кроме того, тут будет рассмотрено большинство часто используемых стилей кнопок. Поговорим мы здесь и о некоторых сложностях, которые возникают при работе с кнопками.

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

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

• Андрей рассказал историю развития Playwright и Puppeteer;
• ответил на вопросы про протоколы, которые используют для работы с браузерами;
• рассказал про сложности браузерных движков и планируемые интеграции Playwright.

Андрей Лушников приедет на конференцию Heisenbug, где и у вас будет возможность задать ему вопросы.

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

Я полагаю, что для решения различных задач 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

Google Colab — это бесплатный облачный сервис на основе Jupyter Notebook. Google Colab предоставляет всё необходимое для машинного обучения прямо в браузере, даёт бесплатный доступ к невероятно быстрым GPU и TPU. Заранее предупрежу, что у него есть некоторые ограничения, поэтому вы не сможете использовать его для production.

С помощью Google Colab вы можете легко обучить свою модель за считанные секунды. Он поддерживает Python (2/3) из коробки, так что всё должно быть хорошо, верно?

Автор статьи, перевод которой мы сегодня публикуем, решил поделиться с читателями семью рекомендациями по JavaScript. Эти рекомендации, как хочется надеяться автору, помогут писать более надёжные программы.

Когда мне было семь, папа купил наш первый Ардуино и мы сделали игрушку для котов. Лазерная указка подвешивалась на два сервомотора и пускала луч — а животные носились за красной точкой по комнате. Я стал копатьcя в программе, что написал отец, пытаясь понять, как все работает… и так попробовал C++.

Быстро поняв, что “плюсы” для первоклассника как-то не очень, а вот программировать мне интересно, я засел за Scratch — учить его как раз посоветовал папа. Когда перерос его, отец показал пару приёмов на Python. Потом был классический путь: захотелось смастерить веб-страничку, засел за jQuery, JS-фреймворки и Node.js. И вот он я)

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

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

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

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

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



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

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

Надеюсь, эта статья будет полезна как начинающим разработчикам, так и опытным.

В вопросах, которые показались мне сложнее прочих, приведены ссылки на дополнительную литературу.

Буду признателен за развернутые комментарии. Все замечания будут учтены при редактировании статьи.

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

Я десять лет тестирую и пишу код, а последние четыре года — тестирую доклады в программном комитете конференции Heisenbug. Сегодня расскажу о сквозных тестах, кросс-браузерности и ощущениях от использования Playwright версии 0.10.0.

Из конца в конец

Зачем нужны сквозные (end-to-end) тесты? Они управляют браузером и имитируют действия пользователя. Например, я описал пользовательские сценарии и хочу, чтобы они были проверены с каждой версией продукта. Проверять все сценарии для всех версий вручную — дороже и дольше, чем автоматикой.

Есть разные инструменты: Selenium, Puppeteer, Protractor, Cypress и другие. Две недели назад вышел новый инструмент — Playwright, над которым работал Андрей Лушников, разработчик Puppeteer. Эта библиотека полностью решает проблему написания кросс-браузерных тестов.

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

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



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

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