Пару дней назад была представлена web-версия Apple Music. Web-версия также как и десктопная использует Ember, но с добавлением web-компонентов. Макс Линч — один из создателей Ionic — написал свои мысли по этому поводу в статье "Apple Just Shipped Web Components to Production and You Probably Missed It".

Макс пишет о том, что в сообществе очень много споров по поводу компонентных js-фреймворков и web-компонентов, так как они решают по сути одну и ту же задачу создания интерфейсов из переиспользуемых блоков. Тот факт, что Apple использует почти 50 компонентов у себя в приложении (нотификации, контролы для управления подкастами, видеоплейер и т.п.) говорит о том, что существует ниша для их применения. Например, их можно использовать для создания таких компонентов, которые могут быть использованы с разными фреймворками (скорее всего Apple решает именно эту задачу). Для создания web-компонентов в Apple music используется SencilJS, которая служит основой для Ionic.

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

#webcomponents #ember #jsframeworks

https://dev.to/ionic/apple-just-shipped-web-components-to-production-and-you-probably-missed-it-57pf

Тим Кадлек опубликовал пост с анализом производительности современных js-фреймворков — "The Cost of Javascript Frameworks".

Для анализа были использованы данные HTTP Archive: ~4,3 миллиона традиционных сайтов и ~5,5 миллионов мобильных. Оценивался объём js-файлов и время исполнения кода, использующего React, Angular, Vue.js и jQuery (добавлен for fun). По объёму кода на последнем месте для 90-го перцентиля оказались React (~2,2Mb) и Angular (~3,3Mb). По времени исполнении кода ситуация похоже, но для 90-го перцентиля на последнем месте оказался React (7,4 секунды), Angular (4,2 секунды). Для мобильных сайтов время выполнения кода для React вырастает более чем в три раза (~25 секунд), для Angular — примерно в полтора раза (~12 секунд).

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

#peformance #jsframeworks

https://timkadlec.com/remembers/2020-04-21-the-cost-of-javascript-frameworks/

Пару недель назад Брайан Ким представил сообществу новый фреймворк Crank.js — "Introducing Crank".

Crank.js был вдохновлён React. Он использует JSX для создания компонентов. Компоненты могут создаваться с помощью генераторов function * (), такой подход позволяет использовать нативные конструкции языка для работы с жизненным циклом компонента. Также благодаря тому, что компоненты могут быть асинхронными, из коробки становятся доступны возможности, которые даёт Suspense в React.

Потыкал его час. Работа с асинхронными запросами в компонентах выглядит органично. Для работы с событиями Crank использует интерфейс EventTarget, который используется в DOM. Работа с событиями императивна, в принципе нормально, но после React выглядит непривычно.

Брайан сделал очень большой упор на работу с нативными возможностями платформы. Один из пунктов его критики React, как раз заключается в том, что React старается переизобрести рантайм для UI, когда браузер уже им и является. Дэн Абрамов на Reddit написал пост с объяснением, почему React использует такой подход.

Пока рано говорить о судьбе Crank.js, но тем не менее это очень интересный эксперимент, отголоски которого мы, возможно, увидим в других фреймворках/библиотеках.

#jsframeworks #announcement

https://bit.ly/3deCWYj (пост Дэна)
https://crank.js.org/blog/introducing-crank

Increment — журнал про разработку — в этом месяце был полностью посвящён фронтенду. Там много постов от разработчиков из мира фронтенда. Среди них есть статья Эвана Ю "The process: Making Vue 3", где он рассказывает про разработку Vue 3 и особенности его работы.

К 2018 году в кодовой базе Vue 2 накопился технический долг и прояснились архитектурные проблемы. К этому моменту все браузеры стали поддерживать Proxy, благодаря чему можно было сделать новую систему реактивности с исправлением проблем старой. Также вторая версия не очень хорошо дружила со статической типизацией. Все эти факторы послужили причиной полного переписывания фреймворка и перехода на новую мажорную версию.

Из статьи узнал, что первые прототипы были написаны с использованием Flow, но команде приходилось поддерживать тайпинги для TS, которые были востребованы гораздо больше чем Flow-тайпинги. В итоге от Flow отказались в пользу TypeScript. Ещё в статье есть интересные технические детали работы Vue 3. В новой версии компилятор шаблонов был полностью переписан. В его основу лёг пайплайн на базе AST-трансформаций, который позволил компоновать оптимизации времени компиляции в виде плагинов трансформаций. Статический анализ шаблонов и новая архитектура позволили ускорить работу с Virtual DOM до 10 раз в бенчмарках рендеринга.

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

#vue #internals #history #jsframeworks

https://increment.com/frontend/making-vue-3/

Хуссеейн Джирде из команды Chromium недавно представил инструмент для анализа метрик производительности js-фреймворков — "Perf Track".

Perf Track — это дашборд, на котором агрегируются метрики по популярным фреймворкам: общий размер js, использование сжатия, First Contentful Paint, Largest Contentful Paint, Cumulative Layout Shift и т.п. Данные для анализа берутся из HTTP Archive и Chrome User Experience Report. Из интересного: статистика по First Input Delay хуже всего у React и Ember, статистика по First Contentful Paint — у Angular и Polymer. Лучше всего показатели у Svelte, но размер выборки Svelte-проектов на порядки меньше выборки других фреймворков, поэтому могут быть сильные перекосы.

Надо понимать, что Perf Track показывает среднюю температуру по больнице. Тем не менее он может быть полезен для анализа общего положения дел.

#performance #tool #jsframeworks

https://perf-track.web.app/

Орта Терокс в блоге Svelte написал статью о поддержке TypeScript — "Svelte ❤️ TypeScript".

TypeScript в Svelte поддерживался и раньше с помощью набора независимых инструментов, работа с которыми была неудобна для рядовых разработчиков. Эти инструменты были перемещены в GitHub-организацию Svelte и в целом была улучшена эргономика работы с TS в Svelte.

Поддержку TS можно включить с помощью установки необходимых пакетов и добавления атрибута lang="ts" в script. Ручную проверку типов можно запустить с помощью svelte-check. В редакторах поддерживается автодополнение кода и проверка типов в том числе внутри разметки.

Очень хорошая новость. Полноценную поддержку TypeScript в Svelte ждали многие разработчики.

#svelte #typescript #jsframeworks

https://svelte.dev/blog/svelte-and-typescript

Джейсон Миллер — автор Preact — написал статью про то, почему делегирование событий не лучше обычного addEventListener — "Event Listeners: Delegation VS Direct Binding".

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

У всех подходов к обработке событий есть преимущества и недостатки. Не стоит противопоставлять их друг другу, а выбирать наиболее подходящее решение для текущей ситуации.

Интересная статья. Рекомендую почитать.

#jsframeworks #performance

https://jasonformat.com/event-delegation-vs-direct-binding/

Во фронтенде существует подход с добавлением динамики на страницу с помощью легковесных библиотек, которые расширяют синтаксис HTML и предоставляют средства для DOM-манипуляций и отправки запросов на сервер. В эту категорию попадают библиотеки htmx, unpoly, intercooler (предшественник htmx) и TwinSpark.

Александр Соловьёв написал статью про то, как он внедрил в свой проект TwinSpark, и что в итоге получилось — "A tale of webpage speed, or throwing away React".

TwinSpark разрабатывается Александром. Его библиотека развивает идеи intercooler и решает проблему с большим объёмом загружаемого js, наследованием и батчингом запросов. HTML с необходимым набором атрибутов для TwinSpark создаётся на стороне сервера из React-компонентов (для создания HTML может быть использован любой другой подход). TwinSpark добавляет нужную интерактивность уже поверх готовой разметки, то есть на клиенте React не используется. Внедрение нового подхода в проект Александра заняло четыре месяца. В результате JS уменьшился с 2.5Мб до 40Kб, HTML c 700Кб до 350Кб, и очень сильно улучшились метрики производительности.

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

#jsframeworks #performance

https://solovyov.net/blog/2020/a-tale-of-webpage-speed-or-throwing-away-react/

Эван Ю буквально пару часов назад на митапе Vue.js Amsterdam выступил с докладом "The Journey to Vue 3", где анонсировал официальный релиз Vue.js 3.

В начале доклада Эван рассказал про историю третьей версии, её разработка заняла два года. Первая идея о разработке Vue 3 появилась в феврале 2018 года. Затем в сентябре был представлен первый прототип. Потом последовал этап исследований. Были эксперименты с поддержкой классов, TypeScript, функциональных компонентов и time slicing. Какие-то идеи попали в релиз, например, функциональные компоненты в виде Composition API, от некоторых фич отказались, например, Class API.

Весь фреймворк был разбит на модули. Любую часть фреймворка при желании можно использовать в любом другом фреймоврке. Кодовая база была написана полностью на TypeScript. Появилась долгожданная поддержка TS в шаблонах. Система реактивности в третьей версии работает на базе Proxy, улучшая производительность. Реализована новая система рендеринга, использующая компиляцию шаблонов в оптимизированные функции рендеринга Virtual DOM. При необходимости система рендеринга откатывается в diff mode. Был ускорен Server Side Rendering. Фреймворк разрабатывался с учётом поддержки три-шейкинга. Добавлено новое Composition API для улучшения переиспользования и организации кода компонентов. На данный момент в процессе разработки инструменты для миграции со второй версии и поддержка IE11, работу над ними планируется закончить в четвёртом квартале 2020 года.

Также в докладе было обновление про статус второй версии. В первом квартале 2021 вторая версия получит последнее минорное обновление до версии 2.7. В неё попадут фичи из Vue 3, которые возможно портировать. Будут добавлены предупреждения для упрощения миграции на третью версию. Версия 2.7 будет последней минорной версией предыдущего мажорного релиза. Её поддержка закончится через 18 месяцев после даты релиза.

#vue #jsframeworks #release #talk

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

Узнал сегодня про фреймворк neo.mjs. Его основная фишка — разделение SPA на связанные части, с которыми можно работать из разных окон/вкладок. Тобиас Улих — автор фреймворка — написал статью про его особенности — "Expanding Single Page Apps into multiple Browser Windows".

Neo.mjs под капотом активно использует SharedWorker — специальный вид воркера, доступ к которому можно получить из разных контекстов браузера. Приложения, написанные с помощью этого фреймворка, используют минимум три воркера: VDOM Worker (работа с Virtual DOM), Shared App Worker (общее состояние приложения), Shared Data Worker (работа с данными). Каждое новое окно с приложением обращается к ним для выполнения своих задач. Благодаря такому подходу становятся возможны интересные пользовательские сценарии, например, перемещение компонента или дерева компонентов в другое окно/таб браузера с сохранением состояния инстанса компонента.

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

В общем, интересный подход. Но, как мне кажется, он не станет массовым, так как сложнее в реализации и поддержке по сравнению с традиционными SPA.

#jsframeworks

https://medium.com/swlh/expanding-single-page-apps-into-multiple-browser-windows-e6d9bd155d59