Dev News от Максима Соснова

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

Дайджест за 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 с несколькими асинхронными компонентами, про которую я писал в прошлом посте. —————————————— Спасибо что читаете, ставите реакции и отмечаетесь в комментариях. Если вы хотите помочь каналу - расскажите о нем своим коллегам или друзьям. Также оставляйте фидбек по формату, материалу и чему-угодно еще 🙂

React Internals Explorer - easily see how React works React Internals Explorer - новый тул, который визуализирует работу рендера React. В нем одновременно есть окно с кодом, который можно редактировать, превью верстки, и интерактивная диаграмма, показывающая, как React рендерит этот код В инструменте есть пресеты для изучения разных механик React, а также возможность запускать код в React18 и React19. В том числе там можно посмотреть разницу в рендере Suspense с несколькими асинхронными компонентами, про которую я писал в прошлом посте. https://jser.pro/ddir/rie #development #javascript #react #tool #recommended

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

function App() {
  return (
    <>
      <Suspense fallback={"Loading..."}>
        <ComponentThatFetchesData val={1} />
        <ComponentThatFetchesData val={2} />
        <ComponentThatFetchesData val={3} />
      </Suspense>
    </>
  );
}

const ComponentThatFetchesData = ({ val }) => {
  const result = fetchSomethingSuspense(val);

  return <div>{result}</div>;
};

В React18 все три компонента начнут загружать данные в один момент времени. В React19 сначала первый компонент загрузит свои данные, затем второй, затем третий. Видимо, команда React решила немножко оптимизировать рендер и React перестал рендерить сиблингов в Suspense, в случае отлавливания промиса. Однако, это изменение очень сильно воздействует на перформанс React-приложений. Команда React пообещала пофиксить эту проблему, поэтому в целом ничего страшного не произошло - сообщество нашло проблему, обсудило, разработчики обещали пофиксить. Историю со счастливым концом. https://blog.codeminer42.com/how-react-19-almost-made-the-internet-slower/ #development #javascript #react #react19 #suspense #performance

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

<script type="speculationrules">
  {
    "prerender": [
      {
        "urls": ["/shop", "/contact"]
      }
    ]
  }
</script>

Есть 2 вида спекуляций: prerendering и prefetching (т.е. пререндер и предзагрузка). Prerendering загружает ресурс и выполняет рендер в бекграунде. Когда пользователь кликает на ссылку и она уже была пререндерена - пользователь моментально видит новый контент Prefetching загружает ключевые ресурсы страницы, но не делает пререндер. Т.е когда пользователь кликает на ссылку на страницу, которая предзагружена, в браузере уже все загружено и нужно её только отрисовать. Какие преимущества у этой фичи: - Во первых, это нативная фича, для которой даже не нужен JS-код - Во вторых, в вебе уже есть похожие фичи (link rel=preload например), но ни одна из них не может загружить контент страницы и все связанные с ним ресурсы, а также сделать пререндер страницы. - Конфигурирование спекуляций очень гибкое, про это я опишу ниже Одна из крутых фичей нового API - можно делать предзагрузку или пререндер не описывая руками все урлы, а с помощью условий. Например, по матчингу урла ресурса

<script type="speculationrules">
  {
    "prerender": [
      {
        "where": {
          "and": [
            { "href_matches": "/*" },
            { "not": { "href_matches": "/logout" } }
          ]
        }
      }
    ]
  }
</script>

<!-- ✅ Prendered -->
<a href="/shop">Shop</a>

<!-- ✅ Prendered -->
<a href="/about">About</a>

<!-- ❌ Not prerendered -->
<a href="/logout">Logout</a>

Также можно указать, чтобы пререндер происходил, только если пользоватьель делает hover над элементом (и держит его более 200мс)

<script type="speculationrules">
  {
    "prerender": [
      {
        "where": {
          "href_matches": "/*"
        },
        "eagerness": "moderate"
      }
    ]
  }
</script>

А еще можно управлять пререндером на основе css-селекторов

<script type="speculationrules">
  {
    "prerender": [
      {
        "where": {
          "and": [
            { "href_matches": "/*" },
            {
              "not": {
                "selector_matches": ".no-prerender"
              }
            }
          ]
        }
      }
    ]
  }
</script>

Также спекуляции отображаются в девтулах: появляется отдельная вкладка в application, где можно посмотреть предзагруженные страницы и правила. Также предзагрузка страниц отображается в Network и Performance. Можно из JS понять, предзагружена страница или нет.

const isPagePrerendered =
  document.prerendering ||
  window.performance?.getEntriesByType?.("navigation").at(0)?.activationStart >
    0;

https://www.debugbear.com/blog/speculation-rules #development #performance #speculationRules #recommended

Conditionals on Custom Properties Оказывается, в CSS скоро может появиться возмождность делать условные стили через if. Данная статья разбирает предлагаемый синтаксис и рассуждает о нюансах применения этого синтаксиса для вложенных условий Изначально я сильно удивился, что в css добавляют что-то подобное. Но, оказывается какое-то подобие условий уже можно было реализовать через calc и custom-properties calc(var(--test) * var(--if-true) + (1 - var(--test)) * var(--if-false)). Теперь же рабочая группа развития CSS обсуждает введение условий в язык. Данная статья концентрируется на одном аспекте нового синтаксиса, а именно описывает нюансы применения вложенных условий. https://geoffgraham.me/conditionals-on-custom-properties/ #development #css #customProperties

Дайджест за 2024-06-17 - 2024-06-20 ⭐️Why, after 6 years, I’m over GraphQL Отличная статья про проблемы GraphQL. Особенно интересна она тем, что автор буквально залетел в GraphQL 6 лет назад, когда еще был hype train, но теперь он не может советовать использовать GraphQL в большинстве проектов. В целом минусы GraphQL касаются безопасности, производительности и удобства. То что легко сделать в обычном REST API, становится сложно делать в GraphQL Test-Driving HTML Templates В последнее время был очень популярен подход с чистым SPA при котором нам не нужен сервер и весь рендеринг происходит на стороне браузера. Однако сейчас все чаще становится популярным рендеринг на сервере. В блоге Мартина Фаулера опубликована статья, рассказывающая, как применять TDD при рендере HTML-шаблонов на "серверных" языках. Data Fetching Patterns in Single-Page Applications Статья в блоге Мартина Фаулера про паттерны загрузки данных в SPA-приложениях. Загрузка данных в SPA-приложениях - не самая простая задача, т.к. необходимо учитывать все нюансы асинхронно природы этого действа - например, необходимо обрабатывать ошибки и долгую загрузку. В статье по-шагам реализуются основные паттерны для загрузки данных. Если вы уже "собаку съели" на загрузке данных, то вы вряд ли увидите в этой статье что-то новое. Однако, сама статья весьма неплоха для начинающих разработчиков. Сначала автор описывать, как работать с состоянием загрузки. У нас есть 3 основных состояния: данные грузятся, данные не удалось загрузить, данные загружены. Первый паттерн - Asynchronous State Handler - необходимо написать генерализированный код, инкапсулирующий в себя управление загрузкой и отдающий в UI только знания о текущем состоянии. Самое ценное в этом паттерне - это разделение кода UI от кода загрузки данных. В рамках статьи автор реализует паттерн, создавая генерализированный хук для загрузки данных по урлу. Мощь AST в действии, или как переписать код 10 летней давности на ES6-модули и ничего не сломать Статья о проведении автоматического рефакторинга с помощью JS CodeShift. Есть проект на Google Closure Library и команда решила перевести код на ECMAScript 6. Поскольку проект большой (900 000 строк кода), было решено сделать это автоматизированно. —————————————— Спасибо что читаете, ставите реакции и отмечаетесь в комментариях. Если вы хотите помочь каналу - расскажите о нем своим коллегамдрузьям. Также оставляйте фидбек по формату, материалу и чему-угодно еще 🙂

https://habr.com/ru/companies/ispring/articles/822975/ Статья о проведении автоматического рефакторинга с помощью JS CodeShift. Есть проект на Google Closure Library и команда решила перевести код на ECMAScript 6. Поскольку проект большой (900 000 строк кода), было решено сделать это автоматизированно. Почему решили отказаться от Google Closure Library: • Длинные пространства имён • С Google-модулями плохо работают подсказки IDE • Появление скрытых зависимостей • Актуальность технологий Делать рефакторинг в таком большом проекте руками сложно: долго, нудно и, скорее всего, такой рефакторинг приведет к ошибкам в проде. Поэтому логично его автоматизировать. Сделать такой рефакторинг с помощью регулярных выражений невозможно, но его легко сделать с помощью работы с AST (Abstract Syntax Tree). Для этого был выбран JS CodeShift. Описать изменение таких файлов с помощью регулярных выражений в общем случае невозможно. Для проверки гипотезы были отрефачены 3 небольших (500 файлов) проекта. Весь рефакторинг занял 1 час, включая ручные правки сложных моментов. Автор даёт два совета: • Начинать с небольших и простых модулей или проектов. • Не следует пытаться автоматизировать всё. Автоматический рефакторинг хорошо покрывает часто встречающиеся паттерны. Остальное легче поправить вручную. Т.е. утрируя, можно следовать правилу 80/20 - 80% кейсов рефакторинга можно покрыть автоматикой, остальные 20% лучше сделать руками, чтобы рефакторинг не превратился в первые 80% работы и вторые 80% работы Мощь AST в действии, или как переписать код 10 летней давности на ES6-модули и ничего не сломать #development #javascript #ast #refactoring #jscodeshift

Data Fetching Patterns in Single-Page Applications Статья в блоге Мартина Фаулера про паттерны загрузки данных в SPA-приложениях. Загрузка данных в SPA-приложениях - не самая простая задача, т.к. необходимо учитывать все нюансы асинхронно природы этого действа - например, необходимо обрабатывать ошибки и долгую загрузку. В статье по-шагам реализуются основные паттерны для загрузки данных. Если вы уже "собаку съели" на загрузке данных, то вы вряд ли увидите в этой статье что-то новое. Однако, сама статья весьма неплоха для начинающих разработчиков. Сначала автор описывать, как работать с состоянием загрузки. У нас есть 3 основных состояния: данные грузятся, данные не удалось загрузить, данные загружены. Первый паттерн - Asynchronous State Handler - необходимо написать генерализированный код, инкапсулирующий в себя управление загрузкой и отдающий в UI только знания о текущем состоянии. Самое ценное в этом паттерне - это разделение кода UI от кода загрузки данных. В рамках статьи автор реализует паттерн, создавая генерализированный хук для загрузки данных по урлу. Если у нас в рамках компонента есть под-компонент, которому также необходимы данные, то мы можем поймать проблему водопада запросов. Например, есть компонент профиля, внутри него есть компонент друзей. Сначала мы показываем скелетон для загрузки профиля, загружаем данные профиля, узнаем что надо грузить друзей - снова ждем. Здесь нам на помощь приходит Parallel Data Fetching - нужно уметь грузить данные параллельно, чтобы не заставлять ждать пользователя дольше необходимого Для того чтобы не нагружать UI-код обработкой долгой загрузки или ошибки загрузки, выделяется паттерн Fallback Markup - когда мы выделяем обработку этих состояний в отдельные под-компоненты, а их использование описывается декларативно. В React, например, это легко делать с помощью Suspense. Если же мы заранее знаем, какие данные пользователю понадобятся, то мы можем загружать их заранее и тем самым реализовывать паттерн Prefetching. Например, используя <link rel="preload">. Но это подходит только для данных, о загрузке которых мы уверены еще на уровне первоначального рендера страницы. Но иногда мы получаем эту уверенность по другому тригеру. Например, наше приложение предоставляет большой список и при клике на какую-то кнопку нужно загрузить и отобразить дополнительную информацию о конкретном элементе списка. Вместо того, чтобы загружать данные только по клику, мы можем их предзагружать если пользователь водит мышкой по компоненту больше скольки-то милисекунд. Это может привести к излишней загрузке в некоторых кейсах, но если мы, например, знаем на основе нашей аналитики, что 90% пользователей, которые держат мышку на элементе дольше 300мс кликают на кнопку загрузки - то можно облегчить жизнь 90% пользователей. Последний рассмотренный паттерн - Code Splitting. Не весь код приложения нужен пользователю прямо сейчас. Вместо этого можно загружать верстку или логику только тогда, когда она реально понадобилась. https://martinfowler.com/articles/data-fetch-spa.html#ChoosingTheRightPattern #development #martinFowler #SPA #javascript

Test-Driving HTML Templates В последнее время был очень популярен подход с чистым SPA при котором нам не нужен сервер и весь рендеринг происходит на стороне браузера. Однако сейчас все чаще становится популярным рендеринг на сервере. В блоге Мартина Фаулера опубликована статья, рассказывающая, как применять TDD при рендере HTML-шаблонов на "серверных" языках. В целом статья разделяется на 3 этапа 1. Проверка корректности HTML. Первоначально было бы неплох отбрасывать невалидную вёрстку. Для этого на целевом языке берется библиотека, умеющая проверять валидность HTML 2. Проверка бизнес-логики. В HTML-шаблонах содержится логика и её нужно проверять. Цель таких тестов - отбросить все лишнее и проверять только то, что важно. В примере из статьи проверяется, что выставлены корректные статусы и задач в ToDoList 3. Тестирование поведения. Для того чтобы протестировать реальное поведение UI, нужно уметь проверять, что приложение делает на условный клик и как оно обрабатывает ответ сервера (например, при отправке формы). Для этого нам нужен браузер, поэтому автор предлагает использовать Playwright для тестирования. В этих тестах предлагается мокировать вообще все сетевые запросы, что немного странно, но возможно применимо в каких-то примерах. Чем интересна данная статья: она показывает как применять TDD к разработке UI. В чистом виде вам эта статья может не понадобится (т.к. в целом проще разрабатывать через storybook и скриншот-тесты), но идея использовать TDD может быть полезна https://martinfowler.com/articles/tdd-html-templates.html #development #martinFowler #TDD #html