JavaScript *

У меня очень странная проблема с браузером. Скрипты на некоторых страницах просто не работают, пока не пройдёт около 20 секунд.

Что бы вы ни собирались предложить — да, я уже думала об этом, и нет, не помогло. Я рассказываю об этом не в надежде, что кто-то подскажет с отладкой, а потому что этот случай заставил меня остро осознать некоторые, как бы сказать… причуды… разработки на фронте.

(В самом деле, даже не пытайтесь диагностировать проблему по одному предложению, не надо, я слышала и перепробовала почти всё, что вы можете себе представить).

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

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.

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

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

В данной статье мы возьмем функцию из спецификации и разберем ее объяснение. Поехали.

Предисловие

Даже если вы хорошо знаете JavaScript, чтение спецификации может быть затруднительным. Следующий код демонстрирует использование Object.prototype.hasOwnProperty:

const o = {
    foo: 1
}
o.hasOwnProperty('foo') // true
o.hasOwnProperty('bar') // false

В примере объект «o» не имеет метода «hasOwnProperty», поэтому мы обращаемся к его прототипу — «Object.prototype» (цепочка прототипов).

Для описания того, как работает Object.hasOwnProperty, в спецификации используется следующий псевдокод:

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

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

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

Как-то я увидел в проекте соседней команды код, который генерировал строку с URL-параметрами для последующей вставки в iframe src-атрибут.

Эта статья может показаться лишней, очевидной или слишком простой, но раз такое встречается в живой природе, об этом не стоит молчать, а наоборот, поделиться best-practices.

Итак, вот он, оригинальный код:

const createQueryString = (param1, param2, objectId, timestamp, name) => {
  const encodedTimestamp = encodeURIComponent(timestamp);
  const delimiter = '&';
  const queryString = `${param1}${delimiter}
        param2=${param2}${delimiter}
        objectId=${objectId}${delimiter}
        itemTimestamp=${encodedTimestamp}${delimiter}
        itemName=${name}`;
  return queryString.replace(/ /g, '%20');
};

Для справки, param1 и param2 в оригинальном коде имеют говорящие названия. А их значения могут быть любыми строками с множеством невалидных для URL символов

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

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

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

Привет, Хабр! Данная статья обязательна к прочтению всем, кто работает с Vue SSR, в частности с Nuxt. Речь пойдет об утечке памяти при использовании axios.

Предыстория

Пол года назад я попал на проект со стеком VueJS + Nuxt, его особенность была в том, что в проде постоянно умирали нодовские сервера(Nuxt) и на их места поднимались новые. По графикам и логам было видно, что оператива процесса ноды доходила до 100% и она падала с ошибкой out of memory. В это время на место убитого процесса поднимался новый, на что уходило порядка 30 сек., этого хватало, чтобы пользователи успели получить 502 ошибку. Очевидно, что где-то в коде была утечка памяти, которую нужно было найти.

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

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

Представляю вашему вниманию три задания по JS, предложенные участникам Microsoft’s Online Assessment 2019.

Microsoft’s Online Assessment — предварительный отбор кандидатов в разработчики. Тех, кто прошел предварительный отбор, приглашают на онлайн собеседование. Нашел в сети информацию, что на решение задач отводился ровно один час, но это не точно.

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

За решения огромное спасибо Matt Clark.

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

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

Если вдруг кому интересно то я веду телеграм канал по фронтенду где выкладываю интересные статьи на разные темы а так же сам периодически пишу шорт-риды которые могут быть вам полезны. А теперь поехали!

---

Привет, Хабр! Представляю вашему вниманию перевод статьи «7 Tricks with Resting and Spreading JavaScript Objects» автора Joel Thoms.

Всем привет, на днях коллега по работе скинул мне ссылку на статью на английском языке в которой перечисляются разные методы работы с rest и spread операторами. Она оказалась мне полезна и я решил её перевести. Итак, начнем.

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



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

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

Начав разрабатывать боты для Telegram несколько лет назад, я открыл для себя производительность, простоту и гибкость работы с ними как с частным случаем интерфейса командной строки. Эти характеристики, доступные сегодня многим — во многом заслуга популярного фреймворка telegraf.js и ему подобных, которые предоставляют упрощенные методы для работы с API Telegram.

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

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

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

Chrome Developer Tools — очень мощный набор инструментов для разработки веб приложений. С помощью этих инструментов мы можем перемещаться по DOM, осуществлять проверку запросов на сервер, настраивать производительность приложений и др.

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

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

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

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

В нём всё, конечно, крутится вокруг JavaScript. Поэтому если вы используете для веб-разработки JS — я очень рекомендую взглянуть на State of JavaScript в том случае, если вы ещё этого не сделали.

Для меня одним из самых интересных результатов State of JavaScript стало неожиданное внимание тех, кто участвовал в опросе, к фронтенд-фреймворку Svelte.

В общем рейтинге ведущих фронтенд-инструментов (основанном на показателях осведомлённости о фреймворке, интереса к нему и удовлетворённости им) Svelte появился на второй позиции. Он идёт там сразу после React, опережая такие хорошо известные инструменты, как Vue.js, Preact, Angular и Ember.
Меня это слегка шокировало, так как Svelte — это сравнительно новый инструмент — как в плане возраста, так и в плане парадигмы разработки программного обеспечения.

Рейтинг фронтенд-фреймворков по результатам исследования State of JavaScript