frontend (r)Evolution with data-star.dev
Далі буде трохи провокаційний пост, бо, на мій погляд відбувається (чи майже відбулася) революція в взаємодії між frontend та бекенд, але більшість поки що не здогадується про це.
Сподіваюся, багато хто вже за останні роки спробував альтернативні підходи для написання фронтенду — наприклад, широко розрекламований HTMX.
Я користуюся HTMX вже років п’ять точно, майже із самого початку. Сам я переважно бекенд-розробник, для мене розробка фронтенду в «новому стилі» (SPA) постійно була пов’язана з якимись незрозумілими для мене проблемами, і вчити кожного року новий JS-framework та переписувати весь код на ньому це дивно. Але таке відбувається кожні
І хоча я працюю бекендером, я постійно шукаю можливості, а як зробити своє життя легше, і чи можна обійтися без додаткової комунікаціі та робити невеликі сайти без залучення SPA frameworks (React, VueJS, Angular, etc).
Для того, щоб розібратися з цим, я спочатку вивчив ClojureScript (бо синтаксис як у Clojure, тільки бібліотеки інші), який дозволяє робити те ж саме, що й React, але з меншою кількістю коду, надійніше, без проблем у підтримці. Хоча я вважаю, що на ClojureScript писати набагато легше, аніж на самому React, але це знаю тільки я: переважна більшість людей ніколи не чули ні про Clojure, ні про ClojureScript. Тому довелося мені вивчити ще й Vue.js, щоб мати змогу робити невеликі зміни у фронтенд-коді.
Тепер, маючи досвід full-stack розробника, якби мене запитали рік тому, як я бачу розвиток проєкту та архітектуру
взаємодії, я б з упевненістю сказав:
- Комплексні сторінки, там де багато логіки UI чи бізнес: frontend — VueJS, React, чи мій улюблений Clojurescript з UIx^2 чи будь який інший JS framework
- Прості сторінки: HTMX, AlpineJS у комбінаціях
Бо станом на рік тому я вже мав кілька прикладів, коли починав щось на HTMX, а потім сам плутався в out-of-band swaps, і взагалі виявлялося досить важко підв’язувати логіку UI на фронтенді до реактивності бекенду. Тобто прості форми, валідації, заміни тощо — це ок. Але якщо на формі багато елементів, підрахунків =totals= і так далі, це вже виходить зовсім незручно. І можливо, в такому разі й не варто було починати, бо виходить так, що почав на HTMX, а потім все одно доводиться переписувати все на повноцінному SPA-фреймворку — це подвійна робота, а саме цього я й хотів би уникнути.
Але раптово виявилося, що наприкінці 2023 року вже існував альтернативний підхід, який дає можливість бекендеру писати всю програму на бекенді, майже без JS (ну, можливо,
потребують менше ресурсів у користувача (RAM, CPU, мережа), також можна робити апдейти з бекенду, тобто WebSocket стають непотрібними.
І цей фреймворк — Datastar. Він об’єднав у собі фронтенд- та бекенд-реактивність в одне елегантне та високопродуктивне рішення, яким легко користуватися.
Далі — відео, де я показую коротеньку презентацію цього фреймворку, та посилання на мій pet-проєкт, а також додаткові матеріали.
References:
- https://data-star.dev/
- github.com/avkoval/hola-tact-meet (мій Pet Project)
- andersmurphy.com/...ithout-clojurescript.html (Why not WebSockets)
- Real REST, how it supposed to be [1] [2]
- моя презентація
2 коментарі
Додати коментар Підписатись на коментаріВідписатись від коментарівБачу статтю про HTMX — ставлю лайк
Дякую за статтю! Пішов дивитись відео. Пишіть ще 🙂