Front-end Digest № 7: розуміння React Server Components, випадковість в CSS та нова пропозиція Google

Усі статті, обговорення, новини про Front-end — в одному місці. Підписуйтеся на телеграм-канал!

Привіт, колеги. Мене звати Олександр і я займаюся фронтендом в компанії Zfort Group. Маю для вас черговий дайджест з цікавими матеріалами зі світу фронтенда за останній тиждень.

Веброзробка

Оновлення за першу половину 2023 року: у центрі уваги функції браузерів, оновлення JavaScript і CSS
Нова пропозиція Google щодо Web Environment Integrity відхилена компаніями Brave, Mozilla та Vivaldi
API віртуальної клавіатури (VirtualKeyboard API)
Вступ до WebGPT
Моя подорож подалі від JAMstack
Цифри чи дужки для числових запитань?

CSS

Порядок застосування трансформацій в CSS
Найкращі інструменти для очищення вашого CSS
Огляд розмірних одиниць в CSS
Як використовувати функцію CSS Grid repeat()
Випадковість в CSS за допомогою тригонометрії
Відновлення та призупинення анімації в CSS

JavaScript

Посібник з 4 нових методів Array.prototype в JavaScript
Тип vs інтерфейс: Що використовувати у 2023 році?
Як ухилитися від методів антидебагінгу JavaScript
Відкриваємо для себе Svelte: Що я дізнався, користуючись Svelte

👍ПодобаєтьсяСподобалось11
До обраногоВ обраному2
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Мені здається, шо RSC це крок не туди.

Реакт це класна фронтова ліба і лізти нею в бекенд — як мінімум відходити від її основної направленості. Фронт це фронт, бек це бек. А умовний Network Waterfall можна пофіксати або структурою коду, або еджастанням дизайну, або тим самим одним ріквестом в бутьківському компоненті.

Тому реакт подобається все менше і менше. Починалось все з «це просто ліба малювати UI», а зараз вже дішло до того react-specific знань стільки, що очі розбігаються. А щоб що? Щоб просто продовжувати малювати UI. Ну то нафіг треба, чесно кажучи. Хочеться писати логіку та працювати над accesibility, а не переписувати 50к строк коду на RSC щоб було. За 5 років досвіду залізобетонно вивів для себе, що React це завжди бійка з оптимізацією рендерингу, коли ж на Vue/Svelte я взагалі за це не думаю і маю чудовий перфоманс.

Реакт і на фонті не дуже... сьогодні зайшов на фейсбук маркетплейс — декілька хвилин норм працює... потім все настільки повільно... що зовсім неможливо користуватися

І це на новітньому MacBook Pro M2 Max.... навіть не знаю як компанія котра досі не змогла зробити веб додаток щоб веб застосунок працював с адекватним перформансом вчить як робити веб ...

Ну звісно ні до чого тут реакт, тільки його зробив фейсбук. І за стільки років вони не можуть довести це до нормального перформанса причому на стороні кліента — я не кажу про перформанс бека, застосунок у браузері (написаний на реакті) не працює нормально.

так просто збіг обставин...

Звісно багато хто використовує реакт та має норм перформанс, але задля цього дуже багато зусиль треба докласти, чи розробника застосунка чи розробників бібліотек.

І звісно дуже гарна ідея використовувати щось що не працює нормально у тому середовищі для якого воно від самого початку було створено.

задля цього дуже багато зусиль треба докласти

Майже нема зусиль\страждать. Реакт+мобх. Плюс, розкидання великих частин апп-ки на різні піддомени (так, зі справжнім класичним перезавантаженням сторінок..))

Речі, які ви забули (або ніколи не знали) через React

React-розробники починають щось розуміти...

На жаль, далеко не всі, поки що..

Ну основне на що ссилаються, це zero bundle size серверних компонент, і загалом простіша робота з ними(не треба той самий useEffect щоб дані сфетчити і useState щоб їх сторити).

Сенс ось у чому. Далеко не кожній апці потрібен супер-дінамічний UI, в якому постійно оновлюються більша частина екрану. Зазвичай, є статичні блоки (меню, хедер, футер), а буває й так, що постійно оновлюється лише певна частина екрану.

У «до-реактні» часи усі ці статичні блоки рендерили на сервері, а там, де дані треба було оновлювати динамічно, використовували AJAX.

Але потім прийшла ера Single Page Application, де було прийнято рендерити весь UI на клієнті у припущенні, що цей UI буде динамічний, як у desktop додатків (хоча, по правді кажучи, не у всіх desktop додатків такий вже й динамічний UI). Ну і як воно зазвичай буває в IT, SPA стало черговим карго-культом, і в стилі SPA стали робити навіть лендінги (лендінги, Карл!), де з інтерактиву взагалі хіба що анімація зображень в каруселі. Так, SSR також існував, але використовувався переважно лише там, де без SEO зовсім ніяк.

З того, що спостерігаю, зараз епоха беззаперечного захоплення SPA змінюється на більш прагматичний підхід, у якому уся статика знов рендериться на сервері, але при цьому залишається семантика React компонентів, щоб спростити перехід на RSC для фронт-енд розробників.

Якщо брати світ поза межами реакту, то подібний до AJAX підхід впроваджувався, наприклад, у Phoenix Framework, але то Elixir, який не те, щоб дуже популярний в mainstream Web розробці.

Все одно якось воно виглядає багатошаровим костилем, де спочатку роблять проблему, а на наступному кроці героїчно її латають і роблять нову проблему. Краще б оптимізували рендерінг дерева статичних компонентів з боку клієнта, бо щось не зрозуміло які там непереборні перепони, що довелося так все ускладнювати і редерити на сервері статику, замість оптимізації статики на етапі збірки бандером. Та і за 10 років вже могли реалізувати в стандарті DOM якість API для вузьких місць Реакту нативно в браузері. По суті ми ж просто патчимо DOM з перевикористанням існуючих елементів, що здається має бути набагато ефективніше, якщо б це виконувалося всередині браузера через який додатковій DOM api.

Воно погано індексується то спа нафіг не треба не кажучі про те що треба тягнути на клієнт бандл під 2мб

Підписатись на коментарі