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

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

Также советую канал @webnya
Download Telegram
Недавно инженеры Slack в статье "When a rewrite isn’t: rebuilding Slack on the desktop" поделились опытом обновления своего приложения.

Старая архитектура Slack содержала три основных проблемы: ручное управление DOM, жадную загрузку данных и отдельные процессы для каждого workspace. С первыми двумя проблемами можно было справиться постепенно: для работы с DOM был выбран React, для работы с данными — Redux. Но последняя проблема требовала фундаментального изменения дизайна приложения. Был выработан план: продолжать работать со старой кодовой базой, постепенно её обновляя и используя строгий интерфейс взаимодействия современной и старой части приложения. При этом весь новый код постепенно переносился в современное приложение из старого. Таким образом получилось добиться баланса между доставкой новых фич пользователям и переписыванием приложения. В результате обновлённое приложение стало работать быстрее и потреблять меньше памяти.

Статья очень интересная. Определённо, стоит почитать.

#electron #performance #architecture

https://slack.engineering/rebuilding-slack-on-the-desktop-308d6fe94ae4
Майк Ритмюллер несколько недель назад поделился своими мыслями про управление стилями в современных приложениях — "CSS Architecture for Modern JavaScript Applications".

Майк пишет про то, что использование современных подходов для управления стилями без планирования может вызвать проблемы в будущем. Например, переиспользование компонентов может стать невозможным, если не использовать принципы абсолютно независимых блоков. Недостаточно поделить макет на прямоугольники — нужно спланировать раскладку и то как с ней будут взаимодействовать презентационные компоненты. Для управления состоянием предлагает использовать переосмысленные типы состояний, позаимствованные из SMACSS. В статье есть пример этого подхода, но он мне показался сложным для восприятия. Имхо, для описания сложных состояний компонентов хорошо подходит старый-добрый БЭМ.

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

#css #musings #architecture

https://www.madebymike.com.au/writing/css-architecture-for-modern-web-applications/
Крис Льюис и Брендан Дин из UberEats рассказали, почему они пошли по пути переписывания основного сайта проекта и какие плоды это им принесло.

Проблема с предыдущей версией сайта имела накопительный эффект. Это было React-Redux приложение, которое плохо поддавалось разделению на бандлы и имело сложности с поддержкой из-за усложнённого подхода к работе с данными и смешиванию кода для разных платформ (desktop/mobile). В новой версии они перешли на фреймворк fusion.js, созданный Uber на базе React (аналог Next.js). Благодаря ему они получили server side rendering и хорошую поддержку code splitting. Для слоя данных оставили Redux, но только как хранилище данных, которое может быть использовано разными роутами приложения. Для всего остального состояния используется локальное состояние компонентов. Благодаря работающему code splitting решили проблему со смешиванием кода разных платформ.

Очень большая и толковая статья. Рекомендую почитать.

#react #performance #architecture

https://eng.uber.com/uber-eats-com-web-app-rewrite/
Флориан Раппл рассказал про текущее состояние микрофронтендов — "The State of Micro Frontends".

Микрофронтенды — это подход к организации приложения, когда команды в рамках одного продукта могут делать фичи, используя разные технологии, и релизить их независимо друг от друга. Микрофронтенды могут быть реализованы по-разному, поэтому существуют разные фреймворки для построения микрофронтендов, покрывающие специфические требования: qiankun, piral, mosaic, micromono и т.п.

Микрофронтенд — это не серебряная пуля, которая может решить все известные проблемы. Но в определённых случаях он может быть полезен. Такой подход для своих продуктов используют IKEA, Microsoft, SAP, Spotify и другие компании.

#architecture

https://blog.bitsrc.io/state-of-micro-frontends-9c0c604ed13a
Станислав Черенков написал статью про использование роутинга в современных SPA-приложениях — "Your SPA doesn’t need a router".

Станислав пишет про то, что использование готовых библиотек роутинга это не самое оптимальное решение, так как разработчики роутеров не могут предусмотреть всех возможных требований. Большинство роутеров не могут работать вне уровня представления, например, react-router использует jsx. В серьёзных приложениях с таким подходом могут проблемы, если при переходе на новый роут нужно выполнить какие-то проверки, загрузить данные или дополнительные скрипты.

В статье предлагается альтернативный подход с отделением представления от логики роутинга и использованием только самых необходимых библиотек, например, для сериализации url страницы в объект.

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

#musings #architecture

https://forweb.dev/en/blog/drop-the-router/
Андрей Мелихов опубликовал на хабре статью "Архитектура современных корпоративных Node.js-приложений".

Фронтенд-разработка в больших проектах давно вышла за границы работы с представлением. Фронтендеры должны поддерживать сервер-сайд рендеринг и жонглировать ответами от разных бэкендов. В статье рассказывается про подход с организацией логики уровня приложения с помощью BFF (Backend For Frontend). Разбираются плюсы и минусы нескольких подходов разделения приложения на слои. В качестве примера реализации используется фреймворк Nest, по ходу дела разбираются его ограничения.

Очень хорошая статья. Рекомендую почитать всем, кто хочет узнать больше про разработку серьёзных web-приложений на Node.js.

#architecture #nodejs

https://habr.com/ru/company/yandex/blog/514550/
В Китае очень популярны суперприложения — приложения, с помощью которых можно получить доступ к разным сервисам (заказ такси, бронирование столиков в ресторане и т.п.) Они состоят из нативной оболочки и миниприложений конкретных сервисов, которые создаются с помощью web-технологий. Томас Штайнер из Google разобрался с разными видами миниприложений и подготовил доклад для TPAC 2020 — "Learning From Mini Apps".

Из интересного. Все суперприложения используют разные диалекты HTML и CSS для описания представлений миниприложений — Wxml/WXSS (WeChat), AXML/ACSS (Alipay), Swan Element/CSS (Baidu), TTML/TTSS (ByteDance). Для описания логики используется подмножество JavaScript — WXS (WeChat), SJS (Alipay, ByteDance), Baidu (JS). Для доступа к функциям операционной системы используется специальный мост (bridge). Для связи представления и состояния используется паттерн model-view-viewmodel (MVVM). Все суперприложения предоставляют специальные среды разработки.

Томас предлагает использовать идеи миниприложений для создания многостраничных приложений (multi-page single-page apps — MPSPA) на базе легковесных компонентных фрейморков или custom elements.

#architecture

https://docs.google.com/presentation/d/e/2PACX-1vREwN7H71zfjPP8lwYgyc-iXam7_PMFCxiZy2dQNZ-XpbiKk1aRSj67vxfcegkHogcO0q3BFHxPf6S5/pub
Райан Карниато — автор библиотеки Solid.js — написал статью о общих принципах работы точечной реактивности — "A Hands-on Introduction to Fine-Grained Reactivity".

Точечная реактивность (fine-grained reactivity) используется в MobX, Vue, Svelte, Knockout и Solid. Если объяснять совсем просто, то её суть сводится к выполнению реакций при изменении наблюдаемых значений. Точно также как меняется результат выполнения формулы в Excel при изменении ячеек, которые используются формулой. Если продолжать аналогию, то эти "ячейки" в разных библиотеках называются по-разному: Signals, Observables, Atoms, Subjects, Refs, — а "формулы": Reactions, Effects, Autoruns, Watches, Computeds.

В статье нет каких-либо деталей реализации, но её можно рекомендовать как хорошее введение в тему точечной реактивности.

#jsframeworks #reactivity #architecture

https://dev.to/ryansolid/a-hands-on-introduction-to-fine-grained-reactivity-3ndf
Гал Шлёзингер поделился подходом для создания лёгкого встраиваемого виджета — "HTML over the wire with Preact".

Галу надо было сделать интерактивный виджет, который можно встроить на любой сайт. Он хотел как можно сильнее уменьшить размер js-бандла виджета, поэтому вместо React выбрал Preact. Для работы с GrahpQL на стороне клиента была выбрана библиотека urlq, но её размер тоже был очень большим. В итоге вместо отправки JSON стал отправлять на клиент уже готовую разметку HTML (проект это позволял). Так как dangerouslySetInnerHTML ломал доступность (пропадал фокус и DOM-состояние при замене разметки), он воспользовался библиотекой preact-markup для преобразования полученной HTML-размеки в Preact-элементы, чтобы работал diff виртуального DOM при замене элементов.

В общем, довольно интересный подход, его также можно использовать в React.

#preact #architecture

https://gal.hagever.com/posts/hotwire-in-preact-apps/
Вчера в блоге Google появилась новость о том, что Google Docs переходит на движок рендеринга, работающий поверх canvas, — "Google Docs will now use canvas based rendering: this may impact some Chrome extensions".

После публикации в сети появились обсуждения насколько это оправдано. Своими мыслями поделился один из авторов оригинального Google Docs. Он говорит о том, что HTML-движки хороши для рендеринга обычных сайтов, но им не хватает фич для реализации полноценных WISWYG-редакторов. И о том, что кастомный движок рендеринга выигрывает по скорости у HTML-движков благодаря ограниченному набору функций.

У многих возникли вопросы по поводу доступности. Я немного потестил тестовый документ из статьи, и с доступностью там более менее всё ок. Озвучивание текста включается с помощью хоткея cmd+option+z — появится div с aria-live вне области просмотра с текстом документа текущей страницы. При перемещении по документу озвучивается текущая строка.

Обновление Google Docs будет раскатываться постепенно в течение двух ближайших месяцев. После обновления браузерные расширения, работающие с HTML-разметкой приложения, перестанут работать.

#architecture #announcement #google #a11y

https://workspaceupdates.googleblog.com/2021/05/Google-Docs-Canvas-Based-Rendering-Update.html
https://news.ycombinator.com/item?id=27129858 (обсуждение на Hacker News)