Аксель Раушмайер у себя в блоге два дня назад опубликовал статью про то, как работают декларации в JavaScript — "Unpacking hoisting".

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

Традиционные функции и var'ы всплывают и работа с ними не вызывает особых проблем. Особенности есть при работе с const, let и class. Если обратиться к сущности в объявлении функции, то всё будет ок, но если попытаться выполнить эту функцию, когда сущность ещё не объявлена, то возникнет исключение ReferenceError. Промежуток времени между входом в область видимости сущности и исполнением инструкции с её объявлением называется Temporal Dead Zone (TDZ). Если в это время обратиться к объявляемым переменной/классу/функции, то возникнет исключение. Именно поэтому первый вызов функции из примера ниже выкинет исключение, а второй выполнится без ошибок:

function a() {
  return b;
}

a(); // throws ReferenceError
const b = 1;
a(); // 1

Статья небольшая, но очень хорошая. Очень рекомендую почитать и поразбираться с примерами, если вы не знакомы с TDZ.

#js #es2015

http://2ality.com/2019/05/unpacking-hoisting.html

Вей Гао опубликовала статью про то, как она добавила поддержку тёмной темы у себя в блоге — "Night Mode with Mix Blend Mode: Difference".

При подготовке своего доклада "This World Mixed and Blended" к Вей пришла идея сделать тёмную тему с помощью CSS-свойства mix-blend-mode: difference. Difference — режим смешивания, который доступен почти во всех современных браузерах кроме IE11. Этот режим можно выразить формулой: difference(A, B ) = |A - B|. То есть абсолютное значение разницы двух цветов.

Для реализации тёмной темы Вей сделала дополнительный div, который перекрывает контент. У этого элемента установлены background: white и mix-blend-mode: difference;. Благодаря этому светлый фон становится тёмным, а тёмный текст — светлым. Для исключения изображений из режима смешивания используется свойство isolation: isolate.

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

#css #colors

https://dev.wgao19.cc/2019-05-04__sun-moon-blending-mode/

Прочитал интересную статью Алексея Круглова "Continuous integration в Яндексе".

В статье рассказывается о том, как происходит работа над проектами в Яндексе. Есть единый монорепозиторий. В нём содержится очень много кода (25Гб), над которым работают более 2000 разработчиков. Использование монорепозитория позволяет снизить издержки на систему CI/CD, предотвращает вероятность появления библиотек с похожей функциональностью (так как всё на виду) и снижает порог для внесения исправлений в смежные проекты (используется общий стек для работы с кодом).

На каждый коммит запускается прогон тестов. Запускаются только те тесты, которые необходимы. Чтобы обнаружить нестабильно работающие тесты, они прогоняются два раза. Если какие-то тесты начинают "моргать", то владельцы этих тестов начинают получать уведомления с проблемой. Также используются diff-тесты, которые могут однозначно определить проблемный коммит, который вызвал поломку тестов.

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

#ci #testing #yandex

https://habr.com/ru/company/yandex/blog/428972/

Эдди Османи опубликовал в марте статью про работу с большими списками в React — "Rendering large lists with react-window".

Рендеринг десятков и сотен тысяч элементов в списке приводит к лагам в интерфейсе. Для решения этой проблемы используются виртуализированные списки, в которых рендерится не весь контент сразу, а только та его часть, которая видна в данный момент плюс некоторое смещение выше и ниже. Самая известная библиотека для создания таких списков react-virtualized Брайана Воуна (Brian Vaughn). Но существует более компактный аналог от того же автора — react-window. Про него и рассказывает в статье Эдди.

React-window — очень компактная и быстрая библиотека. В статье есть примеры того, как сделать с помощью неё виртуальный список и таблицу на гридах. У react-window есть несколько ограничений в отличие от react-virtualized, но для большинства случаев она подходит хорошо.

#performance #react #library

https://addyosmani.com/blog/react-window/

Пару месяцев назад в канале был обзор статьи "Код ревью" Дмитрия Мананникова. Тогда я написал, что к ней добавить особо нечего. Но недавно нашёл пост бывшего инженера Facebook — "On Code Reviews", который отлично дополняет предыдущую статью.

Ник Шрок рассказал про психологию работы с код ревью. Самое ценное для меня, что можно почерпнуть из статьи, это то, что цель код ревью не сделать код таким, как бы вы его написали, а валидация того, что код адекватно решает поставленную задачу. Если есть минорные замечания, обязательно отметьте их в комментариях к пулл реквесту, но не блокируйте ими попадание кода в основную ветку. Доверяйте своим коллегам в том, что они прислушаются к вашим рекомендациям и внесут изменения. Таким образом вы повысите скорость доставки фич. Если изменения не будут сделаны, то скорее всего на это были веские причины.

Если вы работаете в команде с ревью кода (и даже если нет), очень рекомендую прочитать статью.

#musings #codereview #programming

https://medium.com/@schrockn/on-code-reviews-b1c7c94d868c

Дас Сурма недавно написал ещё один пост про работу с WebAssembly — "Compiling C to WebAssembly without Emnoscripten".

В этой статье он показывает как работать с WebAssembly без Emnoscripten. Есть пример того, как скомпилировать простой C-код в wasm с помощью llvm. Немного разбирается архитектура llvm (бэкенд/фронтенд-компиляторы). Показывается, как работать с динамической памятью, на примере суммирования массива целых чисел. Для выделения памяти в Emnoscripten используется malloc, но так как в статье рассказывается про более низкий уровень, там используется простой самописный bump-аллокатор памяти.

Статья довольно техническая и очень подробная. Если интересуетесь темой WebAssembly, рекомендую почитать.

#webassembly #llvm #internals

https://dassur.ma/things/c-to-webassembly/

Хочу порекомендовать хороший небольшой телеграм-канал Олега Ковалёва, в котором он собирает cheat-sheets для самых разных технологий. У него можно найти подборки по алгоритмам, машинному обчению, базам данных, go, rust, инструментам разработки, гиту и т.п. Активно собирает подборки от подписчиков. В общем, рекомендую.

P.S. Это не реклама, Олег даже не в курсе, что я решил немного попиарить его канал.

#telegram #tools

https://news.1rj.ru/str/techchsh

Макс Бок написал статью "The CSS Mindset" про свой опыт изучения CSS.

В статье мне понравилось объяснение того, почему работа с CSS может быть мучением. Многие разработчики, которым приходится что-то иногда делать со стилями, привыкли к иной парадигме программирования. При написании обычных программ один и тот же набор инструкций даёт вполне определённый результат. При работе со стилями это уже не работает. Надо иметь в виду, что написанный код, это не набор конкретных инструкций, а описание того, как должна выглядеть страница. Браузер использует это декларативное описание, чтобы максимально адекватно отобразить желаемое намерение разработчика с учётом всех ограничений и факторов, которые заранее узнать чаще всего невозможно (например, размер браузера, количество отображаемых элементов, количество текста, пользовательские стили).

Также Макс в статье делится и другими инсайтами, которые помогли ему с изучением CSS. Статья хорошая. Советую почитать.

#css #musings

https://mxb.dev/blog/the-css-mindset/

Посмотрел выпуск видео-подкаста HTTP 203, в котором Джек Арчибальд и Сурма Дас рассказывают про особенности цикла for в JavaScript "JavaScript for-loops are… complicated".

Обычные циклы for (с var в инициализаторе) работают следующим образом: инициализируется счётчик, проверяется условие выхода, выполняется тело цикла, производится инкремент счётчика, проверяется условие, выполняется тело цикла и т.д. Если в инициализаторе используется let, то логика работы цикла немного меняется. Это объясняется тем, что переменная счётчика должна копироваться в создаваемую лексическую область тела цикла. Такое поведение закреплено в стандарте языка. C let, код ниже выведет цифры 0, 1, в отличие от цикла с var, который бы вывел цифры 2, 2.

for (let i = 0; i < 2; i++) {
  setTimeout(() => console.log(i));
}

В итоге инкремент счётчика в случае с let происходит перед выполнением тела цикла, но не для первой (!) итерации. Эту особенность можно использовать для каких-нибудь странных вещей, но Джек и Сурма не рекомендуют так делать. Они подытожили подкаст советом использовать итераторы и инструкцию for...of вместо обычного цикла for, когда это имеет смысл. И я тоже считаю, что это хороший подход.

#js #quirks

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

Недавно в Firefox Nightly появилась поддержка subgrid. Рейчел Эндрю в статье "CSS Grid Level 2 – subgrid is coming to Firefox" рассказала про причину его появления.

Subgrid — это небольшое расширение гридов, которое добавляет новое ключевое слово subgrid в свойства grid-template-columns и grid-template-rows. Subgrid может быть полезен там, где необходимо наследование свойств полос родительского грида. В статье есть два примера его использования: в наборе элементов, у которых должны быть одинакового размера заголовок, контент и подвал, и в раскладке с неизвестным числом элементов с растягивающимся первым элементом на всю высоту контейнера.

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

#css #grids

https://hacks.mozilla.org/2019/06/css-grid-level-2-subgrid-is-coming-to-firefox/

Гарри Робертс на csswizardy написал статью про оптимизацию загрузки статических ресурсов "Self-Host Your Static Assets".

Он пишет про то, что использование ресурсов сторонних сайтов (например, популярных CDN) оказывает негативное влияние на скорость загрузки сайта в целом. Например, в документации Bootstrap есть ссылки, которые предлагается вставить на страницу, для того чтобы начать использовать CSS-фреймворк. Они содержат обращение к трём разным доменам code.jquery.com, cdnjs.cloudflare.com и stackpath.bootstrapcdn.com. На соединении с высокими задержками, загрузка этих ресурсов на 1.765 секунды медленнее загрузки тех же самых ресурсов с домена, на котором находится основная страница сайта. По поводу аргумента того, что может использоваться кросс-доменное кеширование, Генри приводит контр-аргумент с Safari, в котором кеширование между доменами не работает.

Статья хорошая. В ней есть ещё много информации. Очень рекомендую почитать и задуматься о переносе ресурсов с внешних доменов на свой.

#performance #web #cache

https://csswizardry.com/2019/05/self-host-your-static-assets/

Автор CSS-фреймворка Codyhouse Себастьяно Гирейро опубликовал пост о том, почему они используют CSS-переменные вместо переменных SASS — "Why we prefer CSS Custom Properties to SASS variables".

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

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

#css #customproperties

https://codyhouse.co/blog/post/css-custom-properties-vs-sass-variables

Брэд Ву написал на CSS Tricks статью про блокирование прокрутки основного контента при открытии модального окна — "Prevent Page Scrolling When a Modal is Open".

Прокрутка контента при открытом модальном окне ведёт к плохому пользовательскому опыту, так как после закрытия окна пользователь может оказаться в другом месте страницы. Бред рассматривает несколько вариантов решения этой проблемы. Пример с overflow-y: hidden очень простой, но не работает с мобильной версией iOS. Для блокирования скролла в iOS в статье описывается другой подход с использованием position: fixed и смещением, которое задаётся с помощью JavaScript.

В комментариях к статье пишут, что overflow: hidden для блокирования прокрутки документа работает в iOS 13. Мне стало интересно — нашёл тикет в трекере WebKit. Действительно, баг починили месяц назад. Остаётся подождать, когда большинство пользователей перейдёт на новую версию iOS, и о хаке с fixed можно будет забыть.

#ios #scrolling #ux

https://css-tricks.com/prevent-page-scrolling-when-a-modal-is-open/

Мартин Турнойж написал небольшую статью про то, почему он до сих пор использует jQuery — "Why I'm still using jQuery in 2019".

В статье основной аргумент такой: зачем изобретать колесо, делая свои хелперы, которые не реализованы в браузере, когда уже есть готовая библиотека с удобным API. Ещё в защиту jQuery приводится факт, что минимальная сборка весит всего 17kb. Ещё приводится пример с Bootstrap, когда разработчики решили выпилить jQuery. Им пришлось заново реализовывать некоторые функции. Мартин пишет про то, что была проделана пустая работа в течение полутора лет. Я с ним не согласен, так как выпиливание библиотеки (насколько мне известно) шла в фоновом режиме, и от сокращения объёма загружаемого трафика выиграли все пользователи Bootstrap.

C некоторыми моментами из статьи я не согласен, но всё-таки она заставляет немного задуматься. С чем я согласен, это то, что методы для работы с DOM API иногда очень нелогичны. Но с этим уже ничего нельзя сделать... Вот так вот и живём.

#jquery #musings

https://arp242.net/jquery.html

Пару дней назад Матиас Байненс из команды v8 твитнул о том, что новые методы массивов flat и flatMap доступны во всех стабильных версиях браузеров и Node.js. Этот твит напомнил мне старую трагедию, которая развернулась из-за проблемы с flatten (предыдущее название `flat`).

Если говорить кратко, то добавление реализации flatten сломало как минимум один популярный сайт в Firefox Nightly. Причиной поломки была библиотека MooTools, которая содержала свою реализацию этого метода. Один из участников комитета TC39 завёл тикет про переименование flatten в smoosh. Это вызвало сильные волнения в js-сообществе — очень много разработчиков негодовало из-за нелогичного названия. Оказалось, что это была внутренняя шутка TC39, которую плохо донесли до сообщества. Как результат Матиас написал пост "#SmooshGate FAQ", в котором постарался объяснить, почему бы это название не прошло в стандарт, даже если бы это была не шутка. Спустя некоторое время, участники комитета TC39 переименовали flatten во flat.

Если интересуетесь историей развития web'а или хотите узнать немного больше о том, как принимаются решения в TC39, обязательно почитайте статью.

#history #tc39

https://developers.google.com/web/updates/2018/03/smooshgate

Эли Штайнбок написал статью "How We Write Full Stack JavaScript Apps" про то, каким принципам следует его команда и какие вспомогательные инструменты использует.

Он пишет про то, что его команда придерживается простоты: лучше скопировать код, чем делать плохую абстракцию. При написании кода на React советует пересмотреть подход с размещением контейнеров и компонентов в разных файлах/директориях. Их разделение зачастую не несёт решения каких-либо проблем. Он советует хранить связанные вещи рядом. Тот же самый подход его команда использует и для серверной части. Они не разносят модели, сервисы и резолверы по разным местам, а хранят их в одном логически выделенном месте. Ещё в статье есть небольшая подборка инструментов, которые они используют для генерации типов и кода.

Давненько я не читал чего-то такого похожего. Лично мне всегда очень интересно узнать про подходы в работе других команд. Кстати, в статье есть неплохая подборка сниппетов кода. Можно забрать и творчески переработать.

#react #graphq #devexperience

https://medium.com/@eliezer/how-writing-simple-javanoscript-got-us-6200-github-stars-in-a-single-day-420b17b4cff4

Дайон Алмаэр опубликовал небольшой пост на тему противопоставления фреймворков и Web-компонентов — "The Truth about Web Components and Frameworks".

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

Недавно я где-то увидел шутку про Теорию Великого Объединения JavaScript-фреймворков. В общем, неизвестно, сколько ещё пройдёт времени, когда кто-то придумает инструмент, который решит все проблемы с web-приложениями.

#musings #webcomponents #jsframeworks

https://blog.almaer.com/the-truth-about-web-components-and-frameworks/

Андрэ Стальц поделился своими мыслями по поводу экономики открытого программного обеспечения — "Software Below the Poverty Line".

Он провёл анализ открытых данных по пожертвованиям, которые получают популярные проекты. В итоге, если бы разработчики работали фул-тайм над своими проектами и жили на пожертвования, за чертой бедности оказалось бы больше половины мейнтейнеров. Ещё в статье разбирается тема популярности и справедливости. Не удивительно, что больше всего пожертвований получают проекты, которые у всех на слуху. Например, Babel, который используется в 350000 проектах, получает в 5 раз больше Core.js, который используется более чем в 2 миллионах проектах. В статье есть несколько предложений, что надо делать, чтобы над открытыми проектами могло работать фул-тайм большее количество разработчиков: регулярно делать пожертвования, работать только в тех компаниях, которые вносят значимый вклад в open source, использовать альтернативные лицензии и т.п.

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

#opensource #musings

https://staltz.com/software-below-the-poverty-line.html

Как-то я пропустил это небольшое событие. В январе появилось предложение Матиаса Байненса о добавлении в стандарт JavaScript нового метода промисов any().

Promise.any() сигнализирует о том, что один из обрабатываемых промисов был успешно разрешён. Этот метод похож на метод Promise.race(), но отличается тем, что не завершает работу, если был отклонён один из промисов. Отклонение Promise.any() происходит только тогда, когда все обрабатываемые промисы были отклонены. Вот небольшой пример, как работает этот метод:

const promises = [
  fetch('/endpoint-a').then(() => 'a'),
  fetch('/endpoint-b').then(() => 'b'),
  fetch('/endpoint-c').then(() => 'c'),
];
try {
  const first = await Promise.any(promises);
  // Один из промисов был успешно разрешён, например 'b'
  // При этом и 'a', и 'c' могли быть отклонены
  console.log(first);
} catch (error) {
  // Все промисы были отклонены
  console.log(error);
}

Предложение находится на первом этапе рассмотрения в TC39. И я пока не вижу причин, почему его могут выкинуть из стандарта.

UPD: Только что обнаружил, что соавтор предложения Сергей Рубанов — ведущий канала @juliarderity (спецификации и другие горячие новости из мира web).

#js #proposal #async

https://github.com/tc39/proposal-promise-any

Рич Снапп написал статью с объяснением того, почему лучше отказаться от использования reduce вместе со spread объектов — "The reduce ({...spread}) anti-pattern".

В современном JavaScript код для создания объекта из массива объектов с одинаковыми свойствами можно написать так:

let result = items.reduce((acc, item) => ({
   ...acc, [item.name]: item.value
}), {})

Как оказывается в v8 такой код будет выполняться с квадратичной сложностью. Рич доказывает существование этой проблемы, разбирая байткод, который генерирует движок. В качестве альтернативы он предлагает использовать reduce с мутированием, или for...of, которые справляются с этой задачей за линейное время.

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

#v8 #performance #algorithm

https://www.richsnapp.com/blog/2019/06-09-reduce-spread-anti-pattern

Людмила Мжачих написала статью "Нужны ли препроцессоры в 2019 году" с объяснением, почему CSS-препроцессоры больше не актуальны.

Когда появились препроцессоры, это был прорыв — разработчикам для написания CSS стали доступны переменные, вложенность, математические функции и т.п. Но время не стояло на месте, и в стандарте CSS появилось очень много фич, которые стали причиной появления препроцессоров. На данный момент они пока ещё не поддерживаются во всех браузерах, а некоторые только совсем недавно были приняты в стандарт, например, вложенность, но если подключить плагин postcss-preset-env, то можно писать на CSS будущего уже сегодня. Преимущество этого подхода в том, что не надо изучать синтаксис препроцессоров, и по мере появления поддержки в браузерах можно просто отключать транспиляцию фич, не модифицируя исходный код.

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

#css #musings

https://medium.com/@lucyhackwrench/нужны-ли-препроцессоры-в-2019-году-727a856d1443