ITRampage

Якщо веб-розробка здається Вам занадто складною, Ви абсолютно праві. Справа у тому, що більша частина ІТ-індустрії рухається хибним шляхом, вирішує неправильні проблеми, копіює, нерозуміючи що, швидко перемикається на нові технології, вважаючи, що усе нове обов’язково краще за те, що вже було. Ми занадто схильні до переускладнення і більшість проблем, які ми вирішуємо були створені нами самими.

У цій публікації я поясню деякі моменти, через які веб-розробка стала такою складною та як їх можна уникнути.

Веб – це гіпертекст

HTTP (HyperText Transfer Protocol) – це протокол рівня додатку, що призначений для передачі гіпертекста через всесвітню мережу.

HTML (HyperText Markup Language) – це мова розмітки/структурування гіпертексту. Стандарт гіпертексту, який розуміють веб-браузери – це стандарт HTML.

Гіпертекст – це сукупність текстів (які можуть містити і не текстові вкладення, як то зображення, відео, аудіо, 3д-моделі, та інше) що посилаються один на інший за допомогою гіперпосилань. Гіпертекст – це мережа текстів.

Веб-додаток – це додаток, для якого GUI є гіпертекст.

HTML/гіпертекст – це першооснова

HTML – це першооснова до якої має адаптуватися усе інше. CSS та JavaScript вторинні, тому вони й виникли пізніше. HTML має впливати на CSS та JavaScript, а не JavaScript та CSS на HTML. CSS розширяє можливості відображення семантичного HTML, JavaScript розширяє поведінку семантичного HTML. CSS та JavaScript мають обслуговувати HTML, ми не маємо писати HTML під певний CSS чи JavaScript.

Якщо йти цим шляхом, то будемо мати мінімалістичний, зрозумілий код на HTML, мінімалістичний код на CSS та мінімалістичний код на JavaScript. Якщо ми йдемо проти цього підходу то коди HTML, CSS та JavaScript, хоча й розміщені у різних файлах, виявляються концептуально перемішаними та взаємозалежними, а внесення будь-яких змін суттево ускладнюється та значно збільшує вірогідність регресій.

Ви використовуєте HTML не правильно

HTML код не має відповідати за відображення, проте дуже часто можна побачити HTML код, який написаний під CSS, наприклад, коли використовується деякий сторонній  CSS-фреймворк.

HTML код має семантично розмічати текст відповіді на запит користувача. Все повинно мати сенс: те, які теги Ви використовуєте, те, як Ви вкладаєте одні теги в інші, те, як Ви використовуєте атрибути й таке інше. HTML має відповідати за семантику, структуру документа, що презентує відповідь.

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

Ми можемо генерувати CSS із HTML, але не можемо генерувати HTML із CSS – це ще один доказ того, що HTML первинний та не має залежати від CSS. Будь який наразі популярний CSS фреймворк порушує здорові відносини між HTML та CSS і тільки ускладнює розробку. CSS фреймворки мають виглядати якось інакше, аніж те, що в нас є на сьогодні.

Ви використовуєте CSS не правильно

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

Наразі дуже популярний підхід з атомарними/функціональними/утилітарними селекторами, як то реалізовано, наприклад, у фреймворці Tailwind.CSS. Протилежністю до цього підходу є використання семантичних селекторів, як то .User-Logo, aбо .CardItem-Qnt. Для зручної роботи з CSS нам необхідно примирити ці дві протилежності.

Ми маємо використовувати семантичні селектори, генерувати CSS із HTML та наповнювати правила заздалегідь визнеченими властивостями, що мають семантині імена. Іншими словами, атомарні селектори мають бути трансформовані у т.з. mixin’и, що підмішуються у семантачні селектори. Те, які mixin’и ми визначаємо та як їх організуємо – це і є CSS фреймворком.

Певно, важко зрозуміти, про що я тут пишу, тому надаю посилання на свої експериментальні/PoC репозиторії з простими HTML-шаблонізатором та генерацією семантичного CSS коду. Посилання ведуть на файли з тестами, в яких можна побачити як виглядають шаблони, генерація CSS та mixin’и, що в наданому коді мають назву Styling. Шаблонізатор gt. Шаблонізатор dt.

Ви використовуєте JavaScript не правильно

Та кількість JavaScript, яку ми використовуємо, не є адекватною, особливо коли мова йде про SPA. Браузерний JavaScript був створений для можливості розширення поведінки HTML коду, аби підвищити інтерактивность гіпертексту. JavaScript має обслуговувати HTML, а не бути центром веб-додатку.

HTML код – це і є дані, ті дані з якими має сенс працювати на тій чи іншій веб-сторінці (гіпертекстовому документі). Усі дані, що передаються з сервера до кліента (веб-браузера), мають бути у форматі HTML коду, придатного для вставки як є у відкриту веб-сторінку. В іншому випадку ми будемо змушені генерувати HTML на клієнті із, наприклад, JSON, або отримаємо проблеми, пов’язані з розбіжностями у двох реалізаціях однієї функціональності: на клієнті та на сервері.

JavaScript код, що відповідає за оновлення HTML сторінки, має бути приєднаний до елементів-контейнерів, в які безпосередньо буде відбуватися вставка нового, отриманого з серверу HTML, або з яких мають видалятися дочірні елементи. Елемент, зміст якого змінюється має бути доступний через <EventObject>.target. Javascript не має нічого знати про структуру HTML, а у іншому випадку ми отримаємо спагетті-код, який важко оновлювати та який дуже схильний до регресій.

Ви використовуєту веб-браузер не правильно

Адресна строка у веб-браузері є одним з найголовніших інтерфейсів. Адреса (URI) вбита у адресну строку має посилатися на гіпертекстовий документ. Різні люди у різних точках нашої планети, використовуючи однакові адреси, мають отримувати один і той же гіпертектовий/HTML документ за умови, що всі вони мають необхідні права доступу.

P.S.

Ця публікація досить поверхнева і покликана лише звернути увагу на проблем веб-розробки. Правильні підходи до веб-розробки я буду висвітлювати у багатьох наступних публікаціях, у т.ч. і на прикладах розробки власних комерційних й Open-Source рішень.