Defront — про фронтенд-разработку и не только – Telegram
Defront — про фронтенд-разработку и не только
13.5K subscribers
21 photos
1.09K links
Ламповый канал про фронтенд и не только. Всё самое полезное для опытных web-разработчиков

Обсуждение постов @defrontchat

Также советую канал @webnya
Download Telegram
Никита Прокопов поделился своим опытом участия в ICFPC — международном соревновании команд программистов.

Соревнование шло три дня. Задание состояло в том, чтобы реализовать наиболее эффективный обход лабиринта с заданными ограничениями. Автор пишет, что Clojure не очень хорошо подходит для решения подобных задач, потому что итоговая оценка зависит от производительности написанного решения. Это подтверждается результатами соревнований. За несколько последних лет всё больше призовых мест берут команды, использующие C++, Java, JavaScript и т.п. Ирония в том, что соревнование приурочено к конференции по функциональному программированию.

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

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

#contest #algorithm

https://tonsky.livejournal.com/322258.html
Honeypot выложил на youtube новый документальный фильм, посвящённый GraphQL — "GraphQL: The Documentary".

Вот краткий пересказ. В 2011 году Facebook решил переписать своё мобильное приложение с HTML5 на нативные технологии — web на тот момент не позволял сделать качественное мобильное приложение. При переписывании самой сложной частью, которая не ложилась на традиционные API, была лента новостей (news feed). В феврале 2012 года Ник Шрок разработал прототип нового API, с помощью которого можно было получать произвольные наборы данных из бэкенда. Разработка прототипа заняла несколько дней. В начале он назывался SuperGraph. Ли Байрон и Дэн Шейфер вдохновились идеей и присоединились к Нику, чтобы довести прототип до production-решения.

Ребята с успехом справились с задачей. Лента была переписана на новом API за несколько месяцев. Спустя полтора года уже практически весь мобильный Facebook работал на GraphQL. Затем разработчики решили открыть исходный код своего решения. В ходе обсуждения Ли предложил переписать реализацию: "Если бы мы знали, что делаем, что мы бы сделали по-другому?". В 2015 году GraphQL был представлен публично и получил широкое распространение, его стали использовать в других компаниях: Github, Airbnb, Twitter и т.д.

Honeypot снял хороший фильм. Советую посмотреть, если интересуетесь историей развития технологий.

#graphql #history #facebook

https://www.youtube.com/watch?v=783ccP__No8
Это, наверное, уже не новость, но вдруг вы не знали. В блоге v8, есть специальный раздел с описанием новых фич JavaScript и WebAssembly, которые планируется добавить в будущие версии языка и платформы.

С начала года там появилось шесть новых статей:
- String.prototype.matchAll
- Numeric separators
- Array.prototype.flat and Array.prototype.flatMap
- Promise combinators
- Object.fromEntries
- Symbol.prototype.denoscription

Во всех статьях есть краткое объяснение работы новых фич и много примеров. По WebAssembly пока нет ни одной статьи, но это не снижает ценность ресурса.

#js #v8 #list

https://v8.dev/features
Реактивное программирование очень мощная штука. Томас Бурлесон (ex-Google) написал хорошую статью о том, как оно помогает в разработке приложений — "Push-based Architectures with RxJS" .

В статье рассматривается одно приложение, написанное с использованием двух подходов — pull-based и push-based. Pull-based — это традиционный подход, в котором view инициирует обращение к внешним API. В push-based подходе view реагирует на изменение данных в некотором источнике-стриме. Pull-based приложение без дополнительного тюнинга получилось очень топорным и не очень интуитивным. С push-based — приложение стало интуитивным и приятным в использовании. Код тоже стал более организован.

Томас ничего не написал про недостатки. По-моему опыту работа со стримами требует большего планирования, чем при обычном императивном программировании. Также rxjs требует время, чтобы в него погрузиться (но это того стоит).

Как бы то ни было очень советую посмотреть статью. Хотя примеры там и используют Angular, push-based подход можно применить в React, во Vue и в других фреймворках/библиотеках.

#angular #rxjs #architecture

https://medium.com/@thomasburlesonIA/push-based-architectures-with-rxjs-81b327d7c32d
Proxy появился в ES2015, но до сих пор остаётся эзотерической фичей JavaScript. Про то чем он может быть полезен, рассказывает Томас Баррассо в статье "A practical guide to Javanoscript Proxy".

Proxy можно использовать для задания дефолтного значения, отличного от undefined, при обращении к несуществующему свойству объекта. С помощью него можно сделать python-like обращение к последнему элементу массива — arr[-1], скрытие свойств и инавалидирование свойств объекта, что может быть полезно при кешировании. Но больше всего мне понравился пример с перегрузкой оператора in, который позволяет реализовать проверку вхождения числа в заданный диапазон как в python 2 in range(1, 100) // true:
const range = (min, max) => new Proxy(Object.create(null), {
has: (_, prop) => (+prop >= min && +prop <= max)
})


Это, конечно, не всё, на что способен Proxy. В статье упоминается, что он лежит в основе новой системы реактивности Vue 3. Ещё там есть ссылки на другие способы использования. В общем, статья хорошая, почитать стоит.

#es2015 #js

https://blog.bitsrc.io/a-practical-guide-to-es6-proxy-229079c3c2f0
Эрик Кори — создатель библиотеки Irregexp, которая используется в Chrome, node.js и Firefox — написал статью про возможные оптимизации в движке регулярных выражений "Regexp backtracking in loops, and how we can optimize it away".

Эрик в начале статьи описывает то, как можно реализовать бэктрекинг (backtracking) с использованием стека. Он рассказывает, что это ведёт к большому потреблению памяти на длинных строках и что все движки регулярных выражений содержат обработчики специальных случаев, которые позволяют избавиться от этой проблемы. Эрик выдвигает предположение, что если бы движок мог распознавать naturally possessive квантификаторы, это бы позволило ещё больше сократить размер памяти необходимой для бэктрекинга.

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

#v8 #regexp #performance

https://medium.com/@erik_68861/regexp-backtracking-in-loops-and-how-we-can-optimize-it-away-ef3b2590f87e
Уже несколько недель лежала в закладках статья про то, как инженеры Google внедрили на страницу поиска сервис воркеры — "Bringing service workers to Google Search".

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

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

#serviceworker #performance #google

https://web.dev/google-search-sw/
Прочитал статью Мириам Сьюзан про изобретательные способы использования кастомных свойств — "CSS Custom Properties In The Cascade".

Мириам на очень показательных примерах показывает, как кастомные свойства позволяют сэмулировать функцию, миксин или компонент. "Функцию", например, можно представить с помощью кастомного свойства, которое в свою очередь использует другое кастомное свойство:
.stripes {
--stripes: linear-gradient(
var(--stripes-angle),
pink 50%,
powderblue 50%
);
}

.vertical {
--stripes-angle: 0deg;
background-image: var(--stripes);
}


Мириам в статье идёт дальше и рассказывает как можно задавать дефолтные значения, как использовать пресеты и как возможно было бы параметризировать "функцию", если бы браузеры поддерживали функцию attr() из стандарта CSS3.

Мне статья очень понравилась. Рекомендую прочитать всем, кто хочет разобраться в работе кастомных свойств.

#css #customproperties

https://www.smashingmagazine.com/2019/07/css-custom-properties-cascade/
Евгений Обрезков написал небольшую статью, в которой он разрушает самые популярные мифы, связанные с WebAssembly — "Three myths about WebAssembly". Вот небольшой пересказ, разбавленный моими мыслями.

Первый миф. "WebAssembly — это язык общего назначения". WebAssembly — это бинарный переносимый формат. Хотя у него и есть текстовое представление, он остаётся целью компиляции для других языков.

Второй миф. "WebAssembly — замена JavaScript". WebAssembly был разработан для того, чтобы работать в тандеме с JavaScript, а не заменить его. При этом WebAssembly поможет нативным языкам более эффективно работать с Web API, но это можно считать сайд-эффектом, а не целью создания WebAssembly. Как бы то ни было JavaScript сейчас слишком распространён, чтобы его можно было заменить в мгновение ока.

Третий миф. "WebAssembly быстрее JavaScript". Здесь нельзя однозначно заявить, правда это или нет, так как на скорость работы WebAssembly-кода будут влиять используемые оптимизации во время компиляции. В свою очередь JS-движки могут оптимизировать JavaScript-код настолько качественно, что в некоторых случаях он может быть производительнее, чем скомпилированный C++ код.

Статья небольшая, но в ней всё написано по делу. К слову, ссылку на неё я увидел в твите официального аккаунта WebAssembly.

#webassembly #list

https://blog.ghaiklor.com/2019/06/18/three-myths-about-webassembly/
Пару дней назад я писал про статью Эрика Кори об оптимизации регулярных выражений. Там есть ссылка, объясняющая почему JS обогнал C++ в бенчмарке regex-dna — "How did JavaScript beat C++ at the regex-dna benchmark?"

Regex-dna — это небольшая часть бенчмарка Sunspider, на который ориентируются разработчики JavaScript-движков на протяжении уже многих лет. В ходе соревнования друг с другом, реализации движков regex-выражений стали очень продвинуты. На данный момент Chrome и Firefox используют форк движка iiregexp. Его особенность состоит в том, что он компилирует регулярные выражения на лету в оптимизированный машинный код.

Хочу добавить, что сам по себе iiregexp написан на C++. В бенчмарке из вопроса сравнивали V8 и С++ код, использующий другой движок — re2. Интересно, какой бы был результат, если бы в C++ коде использовался iiregexp...

#regexp #performance #benchmark

https://www.quora.com/How-did-JavaScript-beat-C++-at-the-regex-dna-benchmark
Аксель Раушмайер написал первую статью из серии про Class Fields — "ES proposal: public class fields". Эта серия статей заменит его прошлую статью про поля классов, которую он написал в 2017 году.

Публичные поля классов предназначены для задания свойств экземпляра объекта и статических свойств изнутри тела класса. В статье есть пара ярких примеров, которые показывают насколько короче может получиться код при использовании публичных полей:
// classic instance property
class MyClass {
constructor() {
this.counter = 0;
}
}
// public field
class MyClass {
counter = 0;
}


Если в React-компонентах вы используете объявление метода через doSomething = () => {}, то на самом деле вы используете синтаксис пропозала class fields, который транспилируется babel'ем в стандартный синтаксис.

Пропозал "Class Fields" находится на третей стадии добавления в стандарт. На данный момент поддержка нового синтаксиса уже есть в Chrome (72+) и Node.js v12, в Firefox и Safari на стадии разработки.

#js #proposal

https://2ality.com/2019/07/public-class-fields.html
Forwarded from Вебня (Ҫѐҏӗѫӑ Ҹҋ 🤖)
⚡️ 26го июня Генеральная Ассаблея Ecma одобрила новые редакции спецификаций, разрабатываемых под эгидой Ecma International. Нас с вами интересуют две из них:
- ECMA-262 10th edition, ECMAScript® 2019, Language Specification
- ECMA-402 6th edition, ECMAScript 2019 Internationalization API Specification

Иначе говоря, официально вышла спека ES2019 и обновленная Intl API.

Среди фич, попавших в ES2019:
- Optional catch binding
- JSON superset
- Symbol.prototype.denoscription
- Function.prototype.toString revision
- Object.fromEntries
- Well-formed JSON.stringify
- String.prototype.{trimStart,trimEnd}
- Array.prototype.{flat,flatMap}
Наткнулся на статью Стейси Тей "How we made Carousell’s mobile web experience 3x faster". В статье Стейси делится опытом оптимизации web-приложения Carousell.

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

Они ввели бюджет на производительность: 120KB для ресурсов критического пути рендеринга, 2 секунды для First Contentful Paint и 5 секунд Time-to-Interactive. Частично реализовали паттерн PRPL, заинлайнили критический CSS, стали лениво грузить изображения, стали использовать сервис воркеры для кеширования запросов, включили сжатие изображений у своего CDN-провайдера. В итоге их сайт стал грузиться в 3 раза быстрее, в 3 раза увеличился CTR и на 63% увеличился органический траффик из Индонезии.

Статья очень ярко показывает, как оптимизация производительности может влиять на бизнес-метрики приложения.

#web #performance #pwa

https://medium.com/carousell-insider/how-we-made-carousells-mobile-web-experience-3x-faster-bbb3be93e006
Недавно был выпущен Firefox 68. По традиции на Mozilla Hacks разработчики опубликовали статью про новые фичи браузера — "Firefox 68: BigInts, Contrast Checks, and the QuantumBar".

В новой версии появилась поддержка пропозала BigInt, который позволяет работать с большими целыми числами в JavaScript, не теряя в точности. Была добавлена поддержка последнего синтаксиса для scroll snapping. В рамках работ над web-совместимостью были добавлены проприетарные методы из IE для работы с CSS-правилами: addRule() и removeRule(), и была добавлена поддержка -webkit-line-clamp (ура!). Доступ к медиаустройствам теперь разрешён только тем сайтам, которые работают по HTTPS. Теперь можно передавать опцию noreferrer в методе window.open().

В инструментах разработчика на панели доступности можно включить предупреждения для неконтрастного текста. Информацию по web-совместимости можно получить через about:compat. Новый многопоточный WebRender, написанный на Rust, теперь включён у пользователей на Windows 10 с видеокартами AMD. Продолжается работа над удалением легаси-кода, использующего XUL/XBL — адресная строка браузера была переписана с использованием стандартных web-технологий: HTML, CSS, JS.

#release #firefox

https://hacks.mozilla.org/2019/07/firefox-68-bigints-contrast-checks-and-the-quantumbar/
Хочу продолжить тему про Firefox. В посте выше было написано, что в новой версии браузера была добавлена поддержка последнего синтаксиса для scroll snapping. Рейчел Эндрю месяц назад написала пост про эту фичу — "CSS Scroll Snap Updated in Firefox 68".

Scroll Snap — это эффект прилипания контента при прокрутке содержимого контейнера. Он очень полезен при реализации каруселей, слайдеров и подобных элементов. Прилипание можно реализовать, используя JavaScript, но это может привести к плохому пользовательскому опыту, именно поэтому CSS Working Group разработала спецификацию "CSS Scroll Snap".

Работает Sroll Snap так: у контейнера задаётся свойство scroll-snap-type, а у вложенных элементов, которые должны прилипать, — scroll-snap-align. До Firefox 68 был реализован черновой стандарт Scroll Snap, в новой версии его поддержка была прекращена.

На данный момент поддержка актуальной спецификации Scroll Snap есть во всех основных браузерах: Firefox, Chrome, Safari.

#firefox #css

https://hacks.mozilla.org/2019/06/css-scroll-snap-updated-in-firefox-68/
Facebook открыл исходный код JavaScript-движка Hermes, который был разработан для оптимизации работы React Native приложений на Android.

Hermes в отличие от V8 использует ahead-of-time компиляцию (парсинг и компиляция JS-кода в байткод происходит не на устройстве пользователя, а на этапе сборки программы). Приложения, использующие Hermes, запускаются гораздо быстрее (примерно в 2 раза быстрее в демо с Mattermost) и потребляют меньше памяти. При сборке приложений с новым движком apk-пакеты занимают меньше места. Для режима разработки предусмотрена ленивая компиляция кода на устройстве, чтобы фидбек при разработке оставался быстрым.

Движок поддерживает большую часть синтаксиса ES2015. В процессе разработки добавление const, let, ES-модулей, классов, вычисляемых свойств объектов. Исключены из поддержки Proxy, Reflect, with и другие редко-используемые части языка.

Hermes уже используется в production-приложениях Facebook. На данный момент разработчики не планируют адаптировать Hermes для работы на сервере или в web'е.

https://www.youtube.com/watch?v=zEjqDWqeDdg

#talk #reactnative #engine #announcement #facebook
Эту неделю можно запомнить как неделю релизов JavaScript-движков. 9 июля Фабрис Беллар (автор QEMU, FFmpeg) представил свой новый проект — QuickJS.

QuickJS — это маленький встраиваемый JavaScript-движок, который поддерживает спецификацию ES2019. Его особенности: быстрая интерпретация, быстрое время старта, проходит 100% ECMAScript Test Suite, может компилировать исходники с JS-кодом в исполняемые файлы без зависимостей, содержит математические расширения BigInt, BigFloat, директивы 'use bigint'; и 'use math'; и т.п., содержит небольшую стандартную библиотеку, которая разбита на два модуля: std и os.

По результатам бенчмарка v8, QuickJS опережает другие встраиваемые движки — DukTape, XS, MuJS и JerryScript. Удивительно, что это творение рук одного человека. Очень рекомендую прочитать про него статью на хабре (https://habr.com/ru/post/119455/).

#js #engine #embedded

https://bellard.org/quickjs/
Анкита Масанд написала статью про использование API для интернационализации приложений в JS — "New Intl APIs in JavaScript".

API интернационализации живёт в глобальном объекте Intl. В статье рассматривается несколько кейсов, где оно может быть полезно. Например, можно использовать Intl.RelativeTimeFormat для форматирования относительных дат ("минуту назад", "день назад", "через 10 дней" и т.п.). Intl.ListFormat для форматирования списков (можно использовать списки с конъюнкцией, дизъюнкцией или с обычным перечислением через запятую). Intl.NumberFormat используется для форматирования больших целых чисел (между разрядами числа в русскоязычном формате добавляются пробелы, в англоязычном — запятые). Для форматирования времени и дат используется Intl.DateTimeFormat.

Intl доступен во всех актуальных браузерах, но полнота имплементации от браузера к браузеру отличается. Например, Intl.RelativeTimeFormat не поддерживается в IE11 и Edge.

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

#js #i18n

https://blog.bitsrc.io/new-intl-apis-in-javanoscript-c50dc89d2cf3
Евгений Бондаренко в статье "9 лет в монолите на Node.JS" поделился опытом перевода Node.js монолита OneTwoTrip на микросервисы.

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

Преимущества микросервисов: частые релизы, проще делать независимые тесты, использование разных технологий для наиболее оптимального решения задач. Минусы: необходимость в шине передачи данных и хорошем логировании, у разработчиков появляется слишком много свободы, необходима команда DevOps для управления всеми этими делами.

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

#nodejs #architecture

https://habr.com/ru/post/459206/
Недавно в блоге V8 появилась статья, посвящённая новому пропозалу WeakRef (Stage 3) — "Weak references and finalizers".

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

Именно здесь на помощь приходит WeakRef. С помощью WeakRef можно создать слабую ссылку на изображение и записывать её по ключу вместо самого изображения:
const wr = new WeakRef(image);
cache.set(name, wr);
// для получения изображения
const ref = cache.get(name);
const image = ref.deref();


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

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

#js #proposal #gc

https://v8.dev/features/weak-references
Пару дней назад Джейсон Миллер из Google написал статью про несколько стратегий загрузки js-бандлов с современным синтаксисом — "Modern Script Loading".

Отдача скриптов с современным синтаксисом для актуальных браузеров может очень положительно отразиться на производительности. При этом нельзя забывать о старых браузерах, которые могут не поддерживать новый синтаксис. Для условной загрузки скриптов в стандарте предусмотрен специальный аттрибут nomodule у тега noscript. Если вставить на страницу два тега скрипт один с современным синтаксисом, а другой со старым и с атрибутом nomodule, тогда последний не будет загружаться в современных браузерах. Но есть проблема — этот трюк будет вызывать лишний фетчинг файлов в Edge и Safari.

Джейсон предлагает четыре решения возникшей проблемы:
1. Определение поддержки браузером современных модулей и вставка на страницу нужного бандла в рантайме
2. При формировании страницы на сервере определять User-Agent и вставлять в код страницы нужный скрипт
3. Использовать описанный выше паттерн nomodule/module, понимая, что у какой-то части пользователей будет происходить лишняя загрузка кода
4. Использование полифиллов в теге с аттрибутом nomodule

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

#js #esm #modules #performance

https://jasonformat.com/modern-noscript-loading/