Дайджест за 2024-06-25 - 2024-06-28

Conditionals on Custom Properties
Оказывается, в CSS скоро может появиться возможность делать условные стили через if. Данная статья разбирает предлагаемый синтаксис и рассуждает о нюансах применения этого синтаксиса для вложенных условий

Изначально я сильно удивился, что в css добавляют что-то подобное. Но, оказывается какое-то подобие условий уже можно было реализовать через calc и custom-properties calc(var(--test) var(--if-true) + (1 - var(--test)) var(--if-false)). Теперь же рабочая группа развития CSS обсуждает введение условий в язык.

⭐️Blazing Fast Websites with Speculation Rules
Огромная статья про новую фичу в вебе - speculation rules. В статье подробно описывается, что это за фича, какие у нее сценарии использования, какие есть плюсы и минусы.

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

How React 19 (Almost) Made the Internet Slower
React 19 замедляет интернет!!!!! Достаточно громкий заголовок у статьи, но она посвящена конкретному кейсу - изменена логика обработки асинхронных компонентов в Suspense.

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

⭐️React Internals Explorer - easily see how React works
React Internals Explorer - новый тул, который визуализирует работу рендера React. В нем одновременно есть окно с кодом, который можно редактировать, превью верстки, и интерактивная диаграмма, показывающая, как React рендерит этот код

В инструменте есть пресеты для изучения разных механик React, а также возможность запускать код в React18 и React19. В том числе там можно посмотреть разницу в рендере Suspense с несколькими асинхронными компонентами, про которую я писал в прошлом посте.

——————————————

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

Why Google Sheets ported its calculation worker from JavaScript to WasmGC

Движок гугл таблиц переехал на WasmGC.

Изначально движок был написан на Java в 2006 году. В 2013 году движок переехал в браузер и заработал на JavaScript (через компиляцию Java в JavaScript, как я понял). Это, очевидно, позволило убрать нагрузку с серверов на клиентские устройства. Движок запускается в веб-воркере и общается с главным тредом через MessageChannel.

Однако переезд на JS создал риск расхождения расчетов. Чтобы его нивелировать, команда создала кучу кейсов вида "вход => выход" и проверяла, что обе реализации движка работают одинаково. Во время проверки корректности работы также замерялся перформанс и выяснилось, что код на JS работал в 3 раза медленнее кода на Java.

Поэтому было принято решение скопилировать код в WasmGC - расширение Wasm для языков со сборщиком мусора (которым и является Java). Ребятам из гугла пришлось писать свой компилятор из Java в WasmGC. Первоначальная реализация оказалась в 2 раза медленнее реализации на JS. Но для первого прототипа - это хороший результат.

Дальше команда занялась оптимизацией созданного решения:
- Завезли оптимизации, которые есть в других тулчейнах. Например, оптимизация вызова виртуальных методов, которая реализована в V8 и JVM, но ничего похожего нет в WasmGC. Реализовав 2 самые распространенные оптимизации (спекулятивный инлайн кода и девиртуализация) вычисления ускорились на 40%
- Были кейсы, когда лучше было взять нативную реализацию. Например, вместо использования библиотеки re2j для регулярок, которая компилировалась в WasmGC, лучше взять нативный RegExp, предоставляемый браузером
- Часть кода была написана для JS. Например, в JS специфичные нюансы работы с массивами и объектами - они хорошо реализованы в JS движках, но as is плохи в других движках. Поэтому потребовалось переписать идиоматичный JS-код на что-то более подходящее для WasmGC.

Итоговая версия реализации на WasmGC оказалась в 2 раза быстрее реализации на JS.




https://web.dev/case-studies/google-sheets-wasmgc

#development #javascript #wasm #google #googleSheets

From Markdown to Video

Вы когда нибудь задавались вопросом, как превратить markdown в видео? Вот и я нет, а оказывается это можно сделать.

В статье очень коротко рассказывается как с помощью Code Hike (так до конца и не понял что это, но кажется это штука, которая позволяет превращать контент в markdown во что-то красивое) и remotion превратить markdown в видео.

Алгоритм примерно следующий:
- Вы пишете маркдаун контент
- Импортируете её в CodeHike, где контент будет преобразован в React компоненты и можно использовать всю мощь React
- Т.к. есть React, то для красивых анимаций можно использовать remotion

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

https://v1.codehike.org/blog/remotion

#development #javascript #react #remotion #codeHike #video #animations #markdown

Дайджест за 2024-07-01 - 2024-07-05

Why Google Sheets ported its calculation worker from JavaScript to WasmGC
Движок гугл таблиц переехал на WasmGC.

Изначально движок был написан на Java в 2006 году. В 2013 году движок переехал в браузер и заработал на JavaScript (через компиляцию Java в JavaScript, как я понял). Это, очевидно, позволило убрать нагрузку с серверов на клиентские устройства. Движок запускается в веб-воркере и общается с главным тредом через MessageChannel.

From Markdown to Video
Вы когда нибудь задавались вопросом, как превратить markdown в видео? Вот и я нет, а оказывается это можно сделать.

В статье очень коротко рассказывается как с помощью Code Hike (так до конца и не понял что это, но кажется это штука, которая позволяет превращать контент в markdown во что-то красивое) и remotion превратить markdown в видео.

——————————————

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

The 4 keys to creating team accountability

Небольшая менеджерская статья про то, как передавать ответственность в команды (возможно неправильно перевожу, в оригинале "team accountability"). Статья содержит 4 ключевые практики для менеджера, которая помогут сделать команды accountability.

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

Явные ожидания > быстрые указания

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

Любознательность > Страх (в оригинале Curiosity > Fear)

Фразы "Мы все рассчитываем на вас" и "Каждая ваша ошибка может стоит дорого для компании" заставляет участников команды лишь нервничать и бояться ошибиться. Исследования показывают, что чем менее безопасно чувствуют себя люди, тем менее они производительны.

Мотивация должна строиться на желании сделать хорошее решение, а не на страхе ошибки. Почему это называется "Curiosity" я из стать не понял, но тут важна мысль, что мотивация не должна строиться на страхе, в любом понимании этого слова

Контекст > дедлайн

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

Самодостаточность > Зависимость

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

https://newsletter.canopy.is/p/the-4-keys-to-creating-team-accountability

#managment

Component, colocation, composition: A note on the state of React

Еще 1 разбор драмы в React вокруг изменения алгоритма рендера сиблингов в Suspense. Если коротко, то в бетке 19го React, команда React сделала так, что если в Suspense несколько компонентов кидают промисы, то они будут исполнены последовательно, а не параллельно. После фидбека от комьюнити все вернули назад.

В данном посте поднимается вопрос, как далеко мы отошли от бога команда React готова отойти от сообщества и экосистемы.

С одной стороны, компоненты должны быть самодостаточными - скрывать за собой UI, ui-логику, бизнес-логику, сетевые запросы, стейт. С другой стороны - React противится такому подходу: стейт и сайд-эффекты должны быть где-то в другом месте, но не в React. Тем не менее сообщество сделало много крутых решений, которые с помощью API React позволяют сделать что-то похожее на самодостаточные компоненты. Но чем более компоненты самодостаточные, тем менее они композируемы.

Теперь же команда React форсит использование React Server Components и, вполне вероятно, готова пойти против всего сообщества в пользу новых "правильных" паттернов.

https://bobaekang.com/blog/component-colocation-composition/

#development #javascript #react

New JavaScript Set methods

На MDN появилась статья про новые методы Set. Ссылка про новые методы уже была в канале, но текущая ведет на MDN и там хорошая визуализация работы этих методов.

Если коротко, то удобные методы у Set давно были у Safari и относительно недавно заехали в chrome и firefox. Скоро можно будет начинать использовать в продакшне без полифилов.

Что это за методы:
intersection - позволяет найти пересечение множеств (set'ов)

const setA = new Set([1,2,3])
const setB = new Set([2,4])
setA.intersection(setB) // Set(1) {2}

union - позволяет объединить два множества

const setA = new Set([1,2,3])
const setB = new Set([2,4])
setA.union(setB) // Set(4) {1, 2, 3, 4}

difference - позволяет достать множество, которое получится если из множества А убрать все элементы множества Б

const setA = new Set([1,2,3])
const setB = new Set([2,4])
setA.difference(setB) // Set(2) {1, 3}
setB.difference(setA) // Set(1) {4}

symmetricDifference - позволяет достать множество, которое содержит элементы которые входят только в одно из множеств

const setA = new Set([1,2,3])
const setB = new Set([2,4])
setA.symmetricDifference(setB) // Set(3) {1, 3, 4}

isSubsetOf - возвращает true, если множество А является под-множеством Б

const setA = new Set([1,2,3])
const setB = new Set([2])
setA.isSubsetOf(setB) // false
setB.isSubsetOf(setA) // true

isSupersetOf - возвращает true, если множество А является над-множеством Б

const setA = new Set([1,2,3])
const setB = new Set([2])
setA.isSupersetOf(setB) // true
setB.isSupersetOf(setA) // false

isDisjointFrom - возвращает true, если у множеств нет пересечений

const setA = new Set([1,2,3])
const setB = new Set([2])
const setC = new Set([4])
setA.isDisjointFrom(setB) // false
setA.isDisjointFrom(setC) // true

https://developer.mozilla.org/en-US/blog/javascript-set-methods/

#development #javascript #set

Why do we underestimate how long it will take to complete a task?

Отличная статья про Ошибку Планирования (Planning Fallacy). В статье разбирается что это, какие когнитивные искажения приводят к этой ошибке и как избежать или уменьшить эффект этой ошибки.

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

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

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

Например, есть исследование, в котором студентов спросили, сколько своих сокурсников они смогут обогнать по итоговым результатам обучения. Средний студент верил, что сможет обойти 84% своих сокурсников. Что, конечно же, не бьется с реальностью - не может каждый второй быть в топ 16% по оценкам.

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

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

Другое когнитивное искажение, влияющее на ошибку планирования - это эффект якоря или эффект привязки (Anchoring effect). Это особенность восприятия, которая заставляет нас ориентироваться на первую высказанную мысль. Самый простой пример из мира разработки, это когда приходит менеджер и говорит "эй ребята, сможете взять в работу эту маленькую задачку". Задачка, конечно же, может быть не маленькой, но т.к. мы о ней впервые услышали как о маленькой, то наш мозг будет цепляться за эту мысль. Это и есть эффект якоря. С ошибкой планирования он связан следующим образом: на ранних этапах работы над задачей или проектом у нас есть какой-то контекст - бюджет, дедлайны, цели. И даже если в середине задачи мы начнем получать сигналы о том, что первоначальный контекст не совсем верен, мы будем мысленно цепляться за начальную установку.

Получается, что Anchoring Effect заставляет нас следовать плану, который был создан под эффектом Optimism Bias

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

Как избежать или уменьшить эффект от ошибки планирования.

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

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

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

Оказалось, что у второй группы результаты были стат. значимо лучше

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


https://thedecisionlab.com/biases/planning-fallacy

#managment #planning #planningFallacy #estimation #recommended

Дайджест за 2024-07-08 - 2024-07-12

The 4 keys to creating team accountability
Небольшая менеджерская статья про то, как передавать ответственность в команды (возможно неправильно перевожу, в оригинале "team accountability"). Статья содержит 4 ключевые практики для менеджера, которая помогут сделать команды accountability.

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

Component, colocation, composition: A note on the state of React
Еще 1 разбор драмы в React вокруг изменения алгоритма рендера сиблингов в Suspense. Если коротко, то в бетке 19го React, команда React сделала так, что если в Suspense несколько компонентов делают кидают промисы, то они будут исполнены последовательно, а не параллельно. После фидбека от комьюнити все вернули назад.

В данном посте поднимается вопрос, как далеко мы отошли от бога команда React готова отойти от сообщества и экосистемы.

New JavaScript Set methods
На MDN появилась статья про новые методы Set. Ссылка про новые методы уже была в канале, но текущая ведет на MDN и там хорошая визуализация работы этих методов.

Если коротко, то удобные методы у Set давно были у Safari и относительно недавно заехали в chrome и firefox. Скоро можно будет начинать использовать в продакшне без полифилов.

⭐️Why do we underestimate how long it will take to complete a task?
Отличная статья про Ошибку Планирования (Planning Fallacy). В статье разбирается что это, какие когнитивные искажения приводят к этой ошибке и как избежать или уменьшить эффект этой ошибки.

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

——————————————

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

Кратко про основные техники кеширования в браузере

Вводная и простая статья про кеширование. Статья рассказывает о нескольких заголовках - Cache-Control , E-tag, If-Modified-Since и, внезапно, про Local Storage.

Все объяснения сопровождены примерами реализации на Node.js



https://habr.com/ru/companies/otus/articles/825060/

#development #caching

Управление зависимостями в Javascript заходит на новый виток? Работа с ES модулями без сборщиков

Хорошая статья, которая в начале рассказывает о том, как развивалась идея модулей и их импортирования в JS-экосистеме - от ручного указания скриптов и появления bower, до последних нововведений в NPM.

Вторая часть статьи посвящена реализации идеи написания приложения без использования бандлеров и пакетных менеджеров. API web'а достаточно сильно развилось за последние годы - там появилось много разных крутых штук, которые позволяют нативно использовать то, что раньше было доступно только через инструментарий. Автор показывает, как можно писать react-приложение с использованием JSX-разметки без дополнительных инструментов в виде сборщика и пакетного менеджера. Это, в целом, реально, но все еще недостаточно удобно в плане DX.

https://habr.com/ru/articles/825424/

#development #javascript #esmodules #packageManagers #history

Vitest 2.0.0

Вышел Vitest 2! Если вы используете vitest - рекомендую подробно взглянуть на изменения. В целом там есть немного breaking-changes, немного фиксов багов и значительные работы по браузерному режиму работы vitest (как я понял - это режим работы, в которым тесты запускаются также в ноде, но в браузере появляется UI, позволяющий следить за прогоном тестов и как-то им управлять). Это режим, при котором тесты запускаются прямо в браузере, а не в nodejs

https://github.com/vitest-dev/vitest/releases/tag/v2.0.0

#development #javascript #vitest #release #releaseNotes

В node.js добавляют sqlite модуль

В Node.js добавили встроенный sqlite модуль - node:sqlite, пока что под флагом --experimental-sqlite. Давно пора было сделать что-то подобное т.к. sqlite есть буквально везде и рантаймам следует поддерживать его из коробки

Пример использования нового модуля

import { DatabaseSync } from 'node:sqlite';
const database = new DatabaseSync(':memory:');

// Execute SQL statements from strings.
database.exec(`
  CREATE TABLE data(
    key INTEGER PRIMARY KEY,
    value TEXT
  ) STRICT
`);
// Create a prepared statement to insert data into the database.
const insert = database.prepare('INSERT INTO data (key, value) VALUES (?, ?)');
// Execute the prepared statement with bound values.
insert.run(1, 'hello');
insert.run(2, 'world');
// Create a prepared statement to read data from the database.
const query = database.prepare('SELECT * FROM data ORDER BY key');
// Execute the prepared statement and log the result set.
console.log(query.all());
// Prints: [ { key: 1, value: 'hello' }, { key: 2, value: 'world' } ]

https://github.com/nodejs/node/pull/53752

#development #javascript #nodejs #sqlite

Дайджест за 2024-07-16 - 2024-07-19

Кратко про основные техники кеширования в браузере
Вводная и простая статья про кеширование. Статья рассказывает о нескольких заголовках - Cache-Control , E-tag, If-Modified-Since и, внезапно, про Local Storage.

Все объяснения сопровождены примерами реализации на Node.js

Управление зависимостями в Javascript заходит на новый виток? Работа с ES модулями без сборщиков
Хорошая статья, которая в начале рассказывает о том, как развивалась идея модулей и их импортирования в JS-экосистеме - от ручного указания скриптов и появления bower, до последних нововведений в NPM.

Вторая часть статьи посвящена реализации идеи написания приложения без использования бандлеров и пакетных менеджеров. API web'а достаточно сильно развилось за последние годы - там появилось много разных крутых штук, которые позволяют нативно использовать то, что раньше было доступно только через инструментарий. Автор показывает, как можно писать react-приложение с использованием JSX-разметки без дополнительных инструментов в виде сборщика и пакетного менеджера. Это, в целом, реально, но все еще недостаточно удобно в плане DX.

Vitest 2.0.0
Вышел Vitest 2! Если вы используете vitest - рекомендую подробно взглянуть на изменения. В целом там есть немного breaking-changes, немного фиксов багов и значительные работы по браузерному режиму работы vitest

В node.js добавляют sqlite модуль
В Node.js добавили встроенный sqlite модуль - node:sqlite, пока что под флагом --experimental-sqlite. Давно пора было сделать что-то подобное т.к. sqlite есть буквально везде и рантаймам следует поддерживать его из коробки

——————————————

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

Moving from express to fastify, pt 1

Статья от команды Val Town про то, зачем и как они мигрировали с express на fastify.

Express - это веб-фреймворк для Node.js, который был создан в 2009 году и позволял в 10 строчек поднять сервер, отдающий Hello World. В то время это было реально круто. Однако прошло 15 лет - экосистема JS сильно изменилась, а express почти не изменился - и в этом его главная проблема. Практически реальный пример, почему нужно быть agile :)

Первая большая боль - экосистема переехала на Typescript, а express - нет и в нем до сих пор неудобно писать типизированный код.

Вторая большая боль - команда Val Town захотела следовать современным лучшим практикам и решила сгенерировать из кода OPEN-API спеку для потребителей API. Для express есть несколько библиотек, реализующих генерацию OPEN API спеки, но их возможности весьма ограничены и у них не очень хороший DX. Эта боль неразрывно связана с предыдущей.

Третья проблема - это отсутствие адекватной поддержки аsync функций. Express появился задолго до появления аsync и до сих пор не поддерживает их из коробки. Хотя определенные подвижки наблюдаются в готовящейся 5-ой версии, но она уже долго не может зарелизится

Изо всех этих проблем Команда Val Town решила переехать на Fastity.
Чем обусловлен выбор fastify:
- Крутая экосистема с качественным плагинами
- Отличная документация
- Поддержка валидаций
- Поддержка аsync
- Интеграции инструментами мониторинга
- А главное, возможность плавной миграции благодаря пакету fastify/fastify-express

Val Town мигрировали своё приложение по роутам, пока наконец не перевели все роуты и теперь они предоставляют SDK скомпилированный из OPEN API (если я правильно все понял)

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

https://blog.val.town/blog/fastify/

#development #javascript #express #fastify #migration

Sneaky React Memory Leaks: How the React compiler won't save you

Sneaky React Memory Leaks: How the React compiler won't save you

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

import { useState, useCallback } from "react";

class BigObject {
  public readonly data = new Uint8Array(1024 * 1024 * 10);
}

export const App = () => {
  const [countA, setCountA] = useState(0);
  const [countB, setCountB] = useState(0);
  const bigData = new BigObject(); // 10MB of data

  const handleClickA = useCallback(() => {
    setCountA(countA + 1);
  }, [countA]);

  const handleClickB = useCallback(() => {
    setCountB(countB + 1);
  }, [countB]);

  // This only exists to demonstrate the problem
  const handleClickBoth = () => {
    handleClickA();
    handleClickB();
    console.log(bigData.data.length);
  };

  return (
    <div>
      <button onClick={handleClickA}>Increment A</button>
      <button onClick={handleClickB}>Increment B</button>
      <button onClick={handleClickBoth}>Increment Both</button>
      <p>
        A: {countA}, B: {countB}
      </p>
    </div>
  );
};

Один из разработчиков React compiler сказал, что эта проблема решена в компиляторе. Автор проверил это и пришел к выводу, что проблема находится в квантовой суперпозиции - она и решена и не решена одновременно. Как такое может быть?

Конкретно этот кейс с большой переменной решился тем, что компилятор видит, что объект ни от кого не зависит и его можно агрессивно закешировать. Что он и делает

const bigData = useMemo(() => new BigObject(), [])

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

const bigData = new BigObject(`${countA}/${countB}`);

Вот так вот, проблема и решена (конкретный кейс) и не решена (в общем виде).

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

Поэтому важно следовать простым правилам:
- Пишите маленькие компоненты
- Пишите чистые компоненты
- Используйте кастомные функции и хуки
- Профилируйте память


https://schiener.io/2024-07-07/react-closures-compiler

#development #javascript #react #performance #memoryLeak #reactCompiler

What's coming next for ESLint

В апреле зарелизился ESlint 9.0.0. Это первый крупный релиз ESlint за почти 3 года и в этом релизе видно, что команда ESlint собирается активно развивать свой инструмент. Эта статья показывает, куда пойдет ESlint в ближайшем будущем.

2 года назад было принято решение, что ESLint должен поддерживать не только JS, но и другие языки. Чтобы достичь этого, требуется переделать ядро проекта. Сейчас эта переделка уже в работе и должны появится пакеты:
- eslint/js - все что связано с JS
- eslint/json - первый плагин, который позволяет подключить язык, отличный от JS
- eslint/markdown - переименовали eslint-plugin-markdown чтобы следовать общей схеме именования

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

Также в текущем ESLint есть архитектурные проблемы. Архитектура почти не менялась со времен первого релиза ESLint - 11 лет назад.
Текущие архитектурные проблемы:
- Синхронная логика в ядре. У сообщества большой запрос на добавления асинхронной логики.
- Ограниченное API. Публичное API очень ограничено, потому что оно не было создано с целью его активного использования. Вообще-то оно делалось для браузерной демки
- Отстуствие типизации
- Использование CommonJS

Команда ESLint выбирала между плавным рефакторингом и переписыванием ядра с нуля. И решил переписывать с нуля. Поэтому в скором времени мы можем ожидать:
- Новый репозиторий
- Современные пакеты
- Ядро, не привязанное к определенному рантайму
- Удобное и композируемое API
- Новая CLI

При этом поддержка старого ядра и создание нового будут идти параллельно и команда обещает, что сообщество не пострадает от такого решения.

Штош, задача выглядит решаемой, пожелаем ребятам удачи.


https://eslint.org/blog/2024/07/whats-coming-next-for-eslint/

#development #javascript #eslint

es-toolkit

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

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

Что же он предлагает:
- es-toolkit предлагает современное исполнение широкоиспользуемых функций, таких как debounce, delay, chunk, sum, pick.
- В 2-3 раза быстрее лодаша
- Три-шейкается из коробки и на 97% меньше чем lodash es
- Отличная поддержка TS. Также предоставляются гварды, например isNotNil
- 100% тестовое покрытие


https://www.npmjs.com/package/es-toolkit

#development #javascript #library

Расширяем возможности мобильного приложения на WebView. Опыт Ozon Банк

Интересная статья от ребят из Ozon, где они коротко рассказывают, почему используют webview в приложении Ozon Банк и какие плюсы и минусы есть у такого подхода.

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

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

Минусы:
- WebView требует загрузки ассетов. А значит, первое открытие экрана может быть долгим. Это конечно можно попробовать решать разными способами, но факт остается фактом - вы либо смиряетесь с тем, что первый раз экран долго грузится, либо делаете какую-то обвязку для менеджмента ассетов
- Низкая автономность. Если интернета нет - не будет работать и WebView. Это также решаемая проблема, но не совсем из коробки.
- Есть сложности с навигацией. Часть экрана построена как нативный UI (шапка и футер), часть - как WebView. При этом поверх WebView может открываться нативный модал. В таком гибридном приложении есть сложности с навигацией между экранами
- Из-за особенностей WebView на мобильных платформах, может случится такое, что приложение еще живет, а WebView была "остановлена" операционной системой

Из интересного в статье также рассказывается реализация коммуникации между JS и нативным кодом. Обычное взаимодействие асинхронное и делается так: нативный код инжектит в WebView JS, с которым может общаться код WebView и ожидать резолва промисов от этого API. Но иногда требуется синхронное взаимодействие, т.е. необходимо "подвесить" поток WebView. Для этого ребята сделали следующую штуку: они переиспользовали возможности prompt. По умолчанию это команда открывает модальное окно в браузере, в которое необходимо что-то ввести. Но ребята написали свой обработчик prompt и используют эту механику, когда нужно сделать какую-то синхронную коммуникацию



https://habr.com/ru/companies/ozontech/articles/828186/

#development #javascript #webview #ozon

Дайджест за 2024-07-22 - 2024-07-26

—————

Сегодня у меня начался трёх недельный отпуск 🌴. Поэтому возможны перебои в постинге ссылок.

—————


Moving from express to fastify, pt 1
Статья от команды Val Town про то, зачем и как они мигрировали с express на fastify.

Express - это веб-фреймворк для Node.js, который был создан в 2009 году и позволял в 10 строчек поднять сервер, отдающий Hello World. В то время это было реально круто. Однако прошло 15 лет - экосистема JS сильно изменилась, а express почти не изменился - и в этом его главная проблема. Практически реальный пример, почему нужно быть agile :)

Sneaky React Memory Leaks: How the React compiler won't save you

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

What's coming next for ESLint
В апреле зарелизился ESlint 9.0.0. Это первый крупный релиз ESlint за почти 3 года и в этом релизе видно, что команда ESlint собирается активно развивать свой инструмент. Эта статья показывает, куда пойдет ESlint в ближайшем будущем.

2 года назад было принято решение, что ESLint должен поддерживать не только JS, но и другие языки. Чтобы достичь этого, требуется переделать ядро проекта. Сейчас эта переделка уже в работе и должны появится пакеты:

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

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

Расширяем возможности мобильного приложения на WebView. Опыт Ozon Банк
Интересная статья от ребят из Ozon, где они коротко рассказывают, почему используют webview в приложении Ozon Банк и какие плюсы и минусы есть у такого подхода.

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

——————————————

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