frontend (­r­)Evolution with data-star.dev

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

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

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

Я користуюся HTMX вже років п’ять точно, майже із самого початку. Сам я переважно бекенд-розробник, для мене розробка фронтенду в «новому стилі» (SPA) постійно була пов’язана з якимись незрозумілими для мене проблемами, і вчити кожного року новий JS-framework та переписувати весь код на ньому це дивно. Але таке відбувається кожні 2-3 роки, протягом останніх 15-ти... Якщо мова суто про бекенд, за останні 15 років не було майже не жодної backward-incomcompatible зміни в Django Templates Engine. Тобто всі мої HTML+CSS переїхали з Django 0.98 до Django 5.x без будь-яких суттєвих змін, тоді як ті частини, що були написані на JS переписувалися з нуля вже разів 5.

І хоча я працюю бекендером, я постійно шукаю можливості, а як зробити своє життя легше, і чи можна обійтися без додаткової комунікаціі та робити невеликі сайти без залучення 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 (ну, можливо, 4-12 КБ самого фреймворку), при цьому досягаючи набагато вищої швидкодії, використовуючи в десятки разів менше коду та сумарних зусиль. Сторінки рендеряться набагато швидше,
потребують менше ресурсів у користувача (RAM, CPU, мережа), також можна робити апдейти з бекенду, тобто WebSocket стають непотрібними.

І цей фреймворк — Datastar. Він об’єднав у собі фронтенд- та бекенд-реактивність в одне елегантне та високопродуктивне рішення, яким легко користуватися.

Далі — відео, де я показую коротеньку презентацію цього фреймворку, та посилання на мій pet-проєкт, а також додаткові матеріали.

References:

👍ПодобаєтьсяСподобалось6
До обраногоВ обраному1
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

Бачу статтю про HTMX — ставлю лайк

Дякую за статтю! Пішов дивитись відео. Пишіть ще 🙂

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