Веб-розробка: вчора, сьогодні, завтра
Привіт, мене звуть В’ячеслав Колдовський, я Programming Mentor. У веб-розробці я з
Історія часто цинічно жартує з людськими винаходами: далеко не завжди задумане ставало реальністю, дуже часто реальністю ставало те, що задуманим не було. Схоже, вся історія вебу й відповідно веб-розробки — те, із чого воно все починалося, як розвивалося, куди направлялося й де опинилося тепер, — яскравий приклад цього твердження.
Перший веб-сайт побачив світ 6 серпня 1991 року. Це був набір примітивних веб-сторінок, які, власне, і презентували всесвітню павутину — World Wide Web. Цікаво, що він і досі доступний за тією самою адресою, що й майже три десятиліття тому.
Якщо ви перейдете на той сайт і заглянете в його код, то вас може спіткати когнітивний дисонанс: попри те, що сайт відкривається і відображається цілком нормально на сучасних браузерах, його код лише віддалено нагадує той, який ми пишемо сьогодні. Саме в цьому полягають краса й біль веб-розробки — потреба створювати рішення, що мають такий самий вигляд і працюють незмінно в умовах середовища та інструментів, стабільність яких лише в тому, що вони постійно змінюються. Сьогодні вже виросло не одне покоління розробників, які не задумуються про те, що Інтернет як мережа існувала задовго до презентації WWW, веб мав стати всього-на-всього одним із сервісів, які вона надавала. Навряд чи хтось міг подумати під час запуску, на що він перетвориться, — власне, у цьому і є корінь проблем, про які ми поговоримо далі.
HTML
Як сам батько вебу — фізик-контрактор CERN Тім Бернерс-Лі — його уявляв, можна побачити на тому самому першому сайті: «The WorldWideWeb (W3) is a wide-area hypermedia information retrieval initiative aiming to give universal access to a large universe of documents». У вільному перекладі звучить так: це така собі бібліотека документів, пов’язаних між собою гіперпосиланнями. Тобто мовиться про всього-на-всього документи, які подані у форматі гіпертексту та поєднані між собою гіперпосиланнями. Ключові терміни тут: «документи», «гіпертекст» та «гіперпосилання».
Цікаво, що Тім Бернерс-Лі не був автором ні ідеї, ні самого терміна «гіпертекст». Термін винайшов ще 1963 року Тед Нельсон, який працював над проектом Xanadu — спробою переосмислити поняття документа й роботою з інформацією взагалі. Xanadu — це проект усього життя Теда Нельсона, а його ідеї випередили час. Але як нерідко трапляється в реальному світі, успішним стає не оригінальний автор науково обґрунтованої рафінованої ідеї, що часто відірвана від реальності, а той, хто побачив, як поєднати ідею з реальністю, навіть пожертвувавши якимись її важливими принципами. Тут можна згадати класичний випадок, коли автор ООП Алан Кей жорстко розкритикував C++ як невдалу імплементацію його задумів: «Коли я винайшов ООП, то не мав на увазі C++». Те саме можна сказати й про винахід Теда Нельсона — йому не надто сподобалося, як його ідеї були зреалізовані у WWW. Ось цікаве відео з 2008 року, де автор демонструє робочий прототип і пояснює ключові концепції свого проекту. Там на власні очі можна переконатися: воно дуже відрізняється від того, що зреалізував Тім Бернерс-Лі.
Крім концепції гіпертексту та гіперпосилань, варта уваги й імплементація веб-сторінок за допомогою HTML. Усі веб-розробники знають про сучасну п’яту версію HTML, але мало кому відомо, що першою формальною версією цієї мови є HTML 2.0, яка вийшла у форматі RFC аж у листопаді 1995 року. До того моменту як такого стандарту мови взагалі не було. Тім Бернерс-Лі запозичив ідею мови в SGML, але водночас досить вільно інтерпретував її, а тому веб-сторінки не були коректними SGML-документами, хоча й використовували синтаксичні конструкції мови, такі як теги та атрибути. Утім, версії HTML із другої по четверту будувалися як SGML-документи, однак уже в HTML5 від такої ідеї відмовилися. Для охочих залишається можливість зреалізувати веб-сторінки у форматі XHTML, але сенсу в тому небагато, бо виникають деякі побічні ефекти, наприклад селектори CSS стають чутливими до реєстру тощо. Історія показала, що ідея підтягнути HTML відповідно до SGML із самого початку була нелогічною, — схоже, треба вміти вчасно відрубати кінці минулих ідей і не тягти із собою в майбутнє ворох минулого — веб у цьому сенсі гарний антиприклад.
Якщо говорити про веб-сторінки загалом і HTML зокрема, то варто зазначити, що формат сам по собі є не чим іншим, як формою представлення інформації у вигляді структурованого документа, що може містити текст, інформацію у вигляді списків і таблиць, зображення, аудіо та відео, а також, звісно, гіперпосилання. Усе це призначено лише для того, щоб показати інформацію користувачу, ще й у досить статичній формі, подібно до сторінки книжки, газети чи журналу. Інтерактивність в HTML зреалізована за допомогою елементів форми, завдання яких — «узяти» інформацію в користувача й відправити її на сервер.
Якщо ж говорити про використання HTML як UI для аплікацій, то вона для цього мало пристосована, і, наприклад, будь-який звичний для UI елемент у формі табів та прив’язаних до них блоків сторінки просто відсутній у HTML. Те саме стосується «карусельки» з елементів чи відомого всім бургер-меню — звісно, їх усі можна зреалізувати, але не тільки засобами чистого HTML, що вкотре доводить: мова для цього не була задумана. Особливо цікаво, що таких елементів у чистому HTML немає дотепер, хоча й трапляються вони мало не на кожному сучасному сайті. Для дружнього до UI середовища було б логічним мати можливість програмно «намалювати» щось на екрані — досить дати координати й усе. Однак це не зовсім легко, бо не можна просто так узяти й намалювати щось поверх інших тегів сторінки, ми обмежені DOM-деревом і не можемо малювати «просто на сторінці», необхідно використати canvas, спозиціювати його тощо.
CSS
Думаю, досить про HTML, поговорімо про CSS. Скільки болю доводилося бачити в очах цих молодих людей, що з ентузіазмом починали вивчати веб-розробку, з легкістю опановували основи HTML, а потім обривали свій політ, зіткнувшись із суворою реальністю роботи з таким чудовим винаходом, як каскадні таблиці стилів.
Вважається, що автором CSS є норвежець Гокон Лі (Håkon Wium Lie), який запропонував ідею Тімові Бернерс-Лі в жовтні 1994 року, а перша версія стандарту вийшла два роки після того. До CSS як такого поділу на представлення і контент в HTML не існувало, і ідею розділити обов’язки можна було б вважати геніальною, якби вона не була одним з фундаментальних принципів розробки програмних проектів. Але, як ми знаємо, зло ховається в деталях, і найбільше це стосується CSS. Іронічно, що сайт винахідника CSS не дуже добре виглядає ні на занадто широких, ні на вузьких екранах, і навіть валідатор CSS має до нього претензії.
Можливо, і не варто було аж так прискіпуватися, але на те є серйозна причина: попри купу різноманітної функціональності в CSS, підтримки цілісного й продуманого підходу до розміщення елементів на сторінці довго не існувало, і робилося це комбінацією якихось трюків та хаків, зрозуміти які непідготовленій людині було вкрай нетривіально, взяти хоча б використання властивості float, яка задумувалася для роботи із зображеннями, однак на тривалий час стала опорою для адаптивної верстки. Згодом float уступила своє місце Flexible Layout, який насправді, незважаючи на всю свою гнучкість, теж не зовсім призначений для повноцінної верстки складних макетів, і лише з Grid Layout, що з’явився зовсім недавно, усе більш-менш стало на свої місця.
Написання коду на чистому CSS приносить мало задоволення, особливо тому, що в ньому практично відсутні були механізми реалізації одного з найважливіших принципів розробки — DRY (Do Not Repeat Yourself). Донедавна змінних не існувало, для вкладених елементів DOM доводиться повторювати ланцюжки селекторів, а можливості перевикористовувати код, модифікуючи його поведінку залежно від певних умов, немає й тепер.
Саме тому досвідчені розробники рідко виявляють бажання мати справу з чистим CSS, і натомість використовують препроцесори, тобто переходять на метамову, що, своєю чергою, має певні наслідки — від потреби в компіляції до ускладнення відладки, через те що реальний код, який виконується браузером, часто суттєво відрізняється від того, який написаний в IDE.
Узагалі CSS — такий потужний і гнучкий інструмент, що його часто застосовують не за призначенням, скажімо, виправляючи хиби HTML. Наприклад, у HTML є тег, який дозволяє зробити горизонтальну лінію, логічно було б мати тег, який робить вертикальну. Однак такого немає, і щоб намалювати вертикальну, доводиться креативити, багато хто робить це по-різному і використовує CSS. Водночас особливо цинічний випадок такого застосування — це трансформувати елемент горизонтальної лінії в лінію вертикальну. «Цинічний» — бо якщо сприймати код HTML семантично, то тег hr, що має створювати горизонтальну лінію, повинен створювати саме горизонтальну лінію. (Якщо говорити про семантично коректний підхід до того, як розв’язати це завдання, то тут ліпше створити власний елемент в HTML, стандарт це дозволяє, ось приклад).
JavaScript
Переходячи до, ймовірно, найцікавішої складової фронтенду, варто зробити відступ і запитати: а що робить мова програмування на фронтенді взагалі? Тут варто зазначити, що в
Власне, сам Тім Бернерс-Лі жодної мови програмування всередині браузера не передбачав, тому не дивно, що історія її виникнення скидається на детектив. Компанія Netscape, заснована у квітні
Частка ринку браузера Netscape Navigator,
Засновник компанії Марк Андрессен вирішив, що HTML не вистачає саме легковагової скриптової мови програмування, код якої можна було б писати прямо в тексті веб-сторінок. Тож у квітні 1995 року він найняв Брендона Айка, який був тоді відомим фахівцем з мов програмування, для того щоб вбудувати мову програмування Scheme у браузер Netscape Navigator. Однак у мови Scheme досить специфічний синтаксис, а Sun тоді мала сильні ринкові позиції та активно просувала Java, тому однією з вимог, які висунув Брендон Айк до нової мови, була синтаксична подібність з Java. До вимог також належало, щоб мова була досить проста та не містила класів, тож для Брендона вона стала своєрідним челенджем — він вирішив зреалізувати в ній ООП, але без класів.
У Netscape прийнято було працювати дуже швидко, тому Брендон Айк розробив прототип мови за 10 робочих днів у травні 1995 року. Це справді дуже мало для того, щоб створити власну мову програмування з нуля, але, схоже, цілком досить, якщо базуватися на вже готових рішеннях. Саме тому нова мова запозичила синтаксис із Java, основну функціональність із Scheme, а реалізацію ООП із Self.
Також цікавою особливістю мови була вбудована стійкість до помилок — синтаксичних і помилок під час виконання коду; це давало б змогу користуватися нею непрофесійним розробникам. Тому, наприклад, у JS крапка з комою для поділу тверджень є опційною, а арифметичні операції взагалі не переривають хід виконання коду — можна сміливо ділити на нуль чи добувати квадратний корінь з від’ємного числа; спроба прочитати значення з масиву за його межами просто поверне undefined, а якщо забути задекларувати змінну і присвоїти раніше незадекларованому ідентифікатору якесь значення, то помилки не виникне, змінна створиться автоматично, однак це навряд чи добре, бо створена змінна буде не на рівні блоку чи функції, а в глобальному просторі імен.
На той момент така гнучкість і стійкість до помилок у коді здавалася важливим досягненням, що залучало б до програмування людей, які до того не мають стосунку. Але час показав, що для професійних розробників, які звикли до строгості й точності в програмуванні, JavaScript здавалася недосить серйозною мовою. Тим більше що деякі рішення були здійснені під тиском обмеженого часу, і навіть сам автор мови визнав їх невдалими. Наприклад, якось 2013 року через твітер у Брендона Айка запитали про дивне рішення стосовно відсутності блочної області видимості в JavaScript, на що він відповів, що 10 днів не вистачило на блочну область видимості, та й на той час для простої скриптової мови такий підхід здавався цілком прийнятним.
Діалог у твітері з Брендоном Айком стосовно блочної області видимості
Годі було 1995 року уявити, що одного дня JavaScript стане найпопулярнішою мовою програмування у світі. Власне, тоді, у
Варто згадати про тогочасний тренд — уникати написання коду на фронтенді загалом і використовувати інструменти, що дають змогу конструювати сторінки візуально, а код генерувати автоматично. Серед таких інструментів — Vermeer FrontPage, що вийшов 1995 року (пізніше Microsoft FrontPage) та Macromedia Dreamweaver (пізніше Adobe Dreamweaver), який вийшов
До речі, програмування на бекенд прийшло значно раніше, ніж на фронтенд, там його місце здавалося логічнішим. Першою такою технологією, що давала змогу динамічно генерувати HTML, була технологія CGI (Common Gateway Interface), створена
Справжнім проривом у веб-розробці стала поява PHP 1995 року — ця мова спеціально була створена для вебу й давала змогу органічно поєднати HTML та синтаксично близьку до C мову програмування. Ідея виявилася напрочуд вдалою і послугувала прообразом для Active Server Pages від Microsoft, що вийшла
Певною мірою своїм успіхом PHP завдячує тому, що браузер тоді не сприймався як серйозна платформа для програмування. Можливості JavaScript у роботі зі сторінкою були дуже обмежені, до того ж у другій половині
Ось, наприклад, фрагмент коду з реального сайту 1998 року. Можна лише уявити, яке «задоволення» приносило писати щось таке:
Саме такий вигляд мав кросбраузерний код 1998 року
RIA
Як додаткове підтвердження того, що пара HTML/JavaScript не сприймалася як платформа для розробки, слід назвати появу та розквіт різноманітних плагінів, які мали бути вбудованими у веб-сторінки — чи взагалі заміняти їх — і надавати розробникам «повноцінніший» досвід програмування. Зокрема, 1996 року Sun у межах платформи Java випустила Java Applets, а Microsoft представила ActiveX, водночас компанія Macromedia придбала FutureWave Software і випустила свій плагін для браузера — Macromedia Flash, який спочатку позиціювався як медіапрогравач, але згодом став повноцінною програмною платформою.
Усі ці плагіни були сторонніми для вебу, потребували часу на завантаження та інсталяцію й не приносили особливого задоволення користувачам браузерів. Водночас можливості для програмування в браузерах саме за допомогою JavaScript розвивалися досить повільно, хоча й були перші зрушення. Зокрема, коли в Netscape відчули серйозну загрозу з боку Microsoft, то вирішили віддати JavaScript на стандартизацію в організацію Ecma International. Організація досить оперативно взялася стандартизувати та розвивати мову й упродовж
Утім, розробники браузерів та плагінів об’єднали зусилля й запропонували 2002 року концепцію RIA — Rich Internet Applications, у яких ідея користуватися браузерами з плагінами подавалася як необхідність для того, щоб отримувати якісний медіаконтент та досвід роботи із сайтом загалом. Такий підхід значною мірою нівелював ідею вебу як єдиної платформи обміну інформації, бо Flash, Silverlight тощо — це, по суті, окремі незалежні платформи, контрольовані комерційними організаціями, які самостійно визначають правила гри.
Web 2.0 / Web.3.0
Уже наприкінці
Як бачимо, концепція Web 2.0 виявилася пророчою, бо тепер веб дуже подібний до того образу, який створили два десятиліття тому.
Однак батько вебу Тім Бернерс-Лі дещо по-іншому хотів би бачити його майбутнє, тож зосередив свої зусилля на так званому семантичному вебі, назвавши його Web 3.0.
Мета семантичного вебу — дати можливість машинам розуміти дані, які описує HTML. Досягнути її можна, використовуючи такі технології, як RDF (Resource Description Framework) та OWL (Web Ontology Language).
Семантичний веб дає змогу описати схему даних, які представлені в HTML-коді, і в ідеалі мав би надати можливість машинам читати дані так, як це роблять люди.
Наприклад, звичайний елемент div, що містить інформацію про людину, доповнений RDF-атрибутами, може мати такий вигляд:
У браузері відвідувачі сайту бачитимуть звичайний текст, а машини, наприклад пошукові системи, зможуть отримати структуровану інформацію.
Попри те, що семантичний веб набув певного поширення, важко стверджувати, що це стало трендом чи буде ним у найближчому майбутньому. Причин можна назвати багато, однак одна з них — це ігнорування веб-розробниками семантичної розмітки, що, своєю чергою, позбавляє сенсу подальші зусилля в напрямку використання семантичних даних у веб-сторінках. Виходить своєрідне замкнене коло, і, попри разючу поширеність вебу та обсяг інформації в ньому, інформація значною мірою досі неструктурована, — отже, поки що навряд чи можна сказати, що мрія батьків-засновників про таку собі всесвітню бібліотеку структурованих знань здійснилася.
AJAX
Незважаючи на появу DHTML, у фронтенд-програмуванні тривалий час була одна фундаментальна проблема: класична модель комунікації браузер-сервера передбачає надсилання чи отримання даних із сервера разом із запитом, який направляє браузер лише в момент переходу чи оновлення сторінки (або фрейму, що фактично є незалежною сторінкою). Це означає, що можливості отримати чи надіслати дані, не оновивши водночас сторінку, з моменту створення вебу не існувало.
Однак 1999 року разом із браузером MS IE версії 5.0 Microsoft випустила оновлену версію ActiveX бібліотеки MSXML, однією з особливостей якої була підтримка можливості без перезавантаження сторінки та асинхронно, не блокуючи потоку виконання JavaScript-коду, надіслати запит на сервер, отримати результат і за допомогою DHTML вбудувати його в сторінку.
Цікаво, що кілька років таку можливість не помічали: хоча її і використовували на певних сайтах, але загалом про масове поширення не йшлося доти, поки Google не запустила у
AJAX фактично був останнім фрагментом у тому пазлі технологій, які перетворювали рідні компоненти вебу — HTML, CSS та JavaScript — на повноцінну платформу програмування.
jQuery
З появою AJAX інтерес до програмування за допомогою JavaScript у браузері суттєво зріс, однак писати кросбраузерний код не стало простіше навіть за умов монополії браузера від Microsoft, оскільки додалися проблеми сумісності різних версій IE.
2006 року світ побачила перша версія бібліотеки jQuery, яку розробив Джон Резіґ, що надихнувся ідеєю вибору елементів HTML за допомогою селекторів CSS в іншої бібліотеки cssQuery, але вдало поєднав її зі зручними методами маніпуляції DOM та вбудував можливість робити AJAX-запити.
Для багатьох розробників, які випробовували свої сили в браузерному програмуванні, jQuery стала саме тою рятівною соломинкою, що дозволяла вибратися з трясини кросбраузерного програмування та сфокусуватися на самому завданні, а не способах його розв’язання. Інтерес до «рідного» програмування в браузері, а не до сторонніх плагінів почав суттєво зростати.
HTML5 / EcmaScript 2015
У січні 2008 року вперше побачила світ чернетка нової, п’ятої версії HTML. Крім власне модифікації самої мови розмітки, вона містила також опис значної кількості API, що перетворювали браузер на повноцінну платформу програмування. Якщо говорити власне про мову розмітки, то серед важливих змін варто назвати появу семантичних тегів і відмову від деяких тегів, що відповідали за представлення. Вихід HTML5 як стандарту затягнувся на цілих шість років. Утім, як розробники самих браузерів, так і веб-розробники сприйняли його дуже позитивно, адже нарешті він перетворював браузер на повноцінну програмну платформу, нівелюючи потребу в такому сторонньому для вебу створінні, як плагіни для RIA.
Паралельно з роботою над HTML5 велася робота й над черговою версією JavaScript. 2009 року виходить EcmaScript 5, рівно через 10 років після попередньої версії. На диво, змін за десятиліття було запропоновано відносно небагато, незважаючи на те що вже почали відчуватися ті хиби мови, які були закладені під час її створення. Лише через шість років світ побачив по-справжньому оновлений стандарт мови під назвою EcmaScript 2015, і разом з ним мова нарешті позбулася деяких дитячих хвороб, які її переслідували (наприклад, уже згадана раніше блочна область видимості), а також отримала оновлений синтаксис, зберігаючи водночас зворотну сумісність з ES5.
Саме парочку HTML5 / ES2015 варто вважати переходом веб-платформи в період зрілості, потреба в jQuery суттєво зменшилася, програмувати на чистому JS стало значно комфортніше.
Шлях стандартизації HTML5 був непростим, тривалий час існувало два окремі стандарти: від W3C та WHATWG, і лише 2019 року двом організаціям вдалося домовитися про єдиний стандарт — тепер це просто HTML Living Standard без номерів версій, над яким оригінально працювала WHATWG. У стандартизації EcmaScript також відбулися важливі зміни: нова версія стандарту мови тепер виходить щороку, мова розвивається динамічніше й водночас зміни не навантажують розробників великими порціями.
SPA
Уже наприкінці першої декади
Knockout, Backbone, ExtJS, AngularJS — далеко не повний перелік SPA-фреймворків, які почали тоді з’являтися й здебільшого використовували патерн MVC або його похідні. Сам патерн винайшли ще наприкінці
Однак з появою AJAX гармонія MVC почала руйнуватися, бо, крім традиційних запитів на контролер, які мають оновити представлення, з’явилися запити, які не зовсім вкладаються в патерн. І саме за допомогою SPA цю гармонію вдалося відновити. Також у пригоді став створений на початку двотисячних Дуґласом Крокфордом формат передачі даних JSON — значно зручніший за XML. За десять років SPA розквітли й закріпилися на фронтенді, практично монополізувавши його як підхід до створення веб-рішень. Багато веб-розробників навіть не бачили альтернатив і не задумувалися про них, та й узагалі навряд чи запитували себе, чи потрібно щось інше, ніж SPA.
Справді, з погляду класичних розробників, для яких важливі принципи розподілу обов’язків, модульності та структурування рішень, патернів і всього того, що навчає сучасна інженерія програмного забезпечення, SPA — це дуже гарне рішення для побудови проектів. Однак якщо поглянути на це з погляду філософії та духу вебу й запитати, що зі SPA не так, то відповідь буде дуже проста: усе не так!
Спочатку така відповідь може збентежити, але якщо задуматися, то складно не погодитися з тим, що Single Page — це не дуже добре, оскільки в самій природі вебу закладено мати багато сторінок, щоб з’єднати їх гіперпосиланнями. І ці сторінки не мають бути просто імітацією в браузері, вони мають бути доступні будь-якому клієнту, який робить HTTP-запит до сервера за конкретною адресою, а не лише тому, який отримає мініміфікований код на JavaScript, виконає його та імперативно збудує сторінку — у такому разі ми втрачаємо декларативну сутність вебу, підміняючи його аплікаціями. Власне, тут і стає зрозумілим, що Application теж зайва — хіба ми не визначилися з тим, що HTML значно ближче до книжки чи журналу, ніж до графічного інтерфейсу комп’ютерних аплікацій?
Слід визнати, хоч би як це було прикро сучасним розробникам, які не уявляють фронтенд без SPA, що ця концепція насправді чужа для вебу, бо намагається підмінити ідеї, закладені у веб, підходами, що прийшли з розробки аплікацій з графічним інтерфейсом користувача. Хтось, можливо, вважатиме, що це не принципово, і якщо воно працює, то яка різниця, як саме воно зроблено. Але практика показує, що це не так. Усе-таки SPA виконуються в браузері, і щонайменше залишається потреба мати можливість робити посилання на окремі сторінки. Для цього почали реалізовувати deep linking, перенаправляючи будь-які запити на бекенд на одну сторінку, що є точкою входу в аплікацію, і виводячи потрібну сторінку на фронтенді. Але потім стало зрозуміло, що не можна цілком відмовитись від декларативного HTML на фронтенді й повністю підмінити його динамічною аплікацією, ліпше мати HTML-контент на сервері, як наслідок — виникло поняття Server-Side Rendering. Однак, реалізуючи SSR, виникає завдання передати стан із сервера до клієнта, це теж потребує певних зусиль на реалізацію. Також не дуже тривіальною виявляється підтримка доступності (accessibility) для SPA-аплікацій, декларативний HTML для цього ліпше пристосований. І так далі — скидається на безперервний процес, у якому розв’язання одних проблем призводить до появи інших.
Загалом складність розробки і супроводу SPA для вебу починає виходити за розумні межі, дедалі складніше переконувати клієнтів у тому, що цьому підходу немає альтернатив. І чи це справді так?
А що в нас із фреймворками?
JavaScript-фреймворки — то завжди гаряча тема. Ми всі прекрасно знаємо: день минає даремно, якщо світ не побачив новий фреймворк. Хоча це чи не найулюбленіша тема для новачків похоліварити, досвідчені розробники рідко піддаються на провокації та просто спостерігають за трендами й вивчають те, на що є попит.
Приблизно у
Багато хто вже «поховав» Angular, але тут не все так просто: у Google переписали AngularJS з нуля, навіть ім’я змінили, повністю поламавши зворотну сумісність, проте навряд чи хтось скаже, що цим вони зробили гірше. Як наслідок — вийшов такий собі мегаконструктор SPA, який не дуже підходить для нескладних проектів, але вдало знайшов свою нішу в корпоративних. Він і далі активно розвивається, Google забезпечує серйозну підтримку — загалом майбутнє видається значно оптимістичнішим, ніж може здатися на перший погляд.
Упродовж кількох останніх років досить упевнено почувається VueJS. Легковаговість і простота — це два основні чинники, які забезпечують його популярність. Він активно розвивається й особливо популярним став в Азії — власне це, ймовірно, і варто зарахувати до нечисленних недоліків: часто значно простіше отримати підтримку китайською мовою, ніж англійською.
Але справжнє відкриття 2019 року, яке ще має себе показати у
Наприкінці 2019 року серед фронтенд-розробників всього світу проводилося традиційне опитування «State of JS», у якому за рівнем цікавості Svelte посів перше місце.
Рейтинг фреймворків за рівнем цікавості 2019 року
Загалом підхід, використаний у Svelte, можна лише вітати: замість того щоб укотре в браузері будувати мета-платформу, розробники фреймворку використали можливості браузера. Тут доречно згадати, що розвиток браузерів як платформи теж не стоїть на місці, і серед останніх нововведень особливої уваги варта підтримка WebComponents — механізму, що дає змогу створювати власні елементи в HTML, які мають незалежні стилі й логіку, розв’язуючи ті самі завдання, що більшість фронтенд-фреймворків. Тож варто очікувати поширення саме такого підходу, що наближає фреймворки до браузера як платформи, а не віддаляється від нього.
Що з бекендом?
Ще з
Водночас варто зазначити, що розробникам на бекенді доводиться розв’язувати типові завдання навіть у різних проектах — зреалізовувати аутентифікацію та авторизацію, створювати типові CRUD-операції для сутностей предметної ділянки, передавати DTO між різними рівнями аплікації, покривати все це тестами тощо. Щоб не повторюватися щоразу й перевикористовувати зроблені раніше рішення, ще з кінця
Попри те, що CMS вдається розв’язати певну частину проблем з перевикористанням коду, проблеми з розгортанням та підтримкою серверів залишаються. Подальша еволюція таких рішень — це міграція в хмари і використання сервісів, які повністю керуються хмарними провайдерами. У цьому сенсі дуже привабливими видаються рішення, такі як Google Firebase та подібні. Поєднання можливостей аутентифікації, авторизації, API для роботи зі структурованими даними з можливостями хостингу з підтримкою CDN — серйозний аргумент проти того, щоб займатися всіма цими питаннями самостійно. Поділ монолітів на мікросервіси та використання платформ, які беруть на себе масштабування під навантаженням, — такі архітектурні рішення спонукають використовувати хмарні сервіси й не займатися питаннями керування та підтримки інфраструктури.
Одна з цікавих інновацій на бекенді, що швидко набуває популярності й здатна вплинути на прийняті підходи до розробки рішень, — це GraphQL, розроблена у Facebook технологія, що дозволяє на фронтенді сформувати запит до структури даних, які має повернути бекенд. Такий підхід позбавляє бекенд-розробників потреби створювати нескінченні CRUD-операції та загалом є гарною альтернативою до RESTful API.
Як наслідок — дедалі активніше спостерігається тенденція використовувати можливості CDN, щоб розміщувати статичний контент веб-рішень максимально близько до клієнта, а динамічну частину веб-рішення будувати так, щоб вона адаптувалася до рівня навантажень, використовуючи для цього можливості платформ хмарних провайдерів, а не просто переносячи в хмари монолітні аплікації в незмінному вигляді.
JAMstack
Наприкінці 2017 року вийшла цікава стаття, у якій досить детально було описано стек технологій під загальною назвою JAMstack (JavaScript + API + Markup). Сам термін винайшла та активно просуває компанія Netlify, яка дуже вдало почала просувати ідею альтернативного до SPA підходу, що насправді зовсім не новий, але значно ближчий до оригінальних ідей вебу, ніж SPA.
JAMstack пропагує ідею так званих статичних сайтів, хоча термін «статичний» тут зовсім недоречний, бо насправді статичними ці сайти не є, просто, на відміну від SPA, їхній звичайний стан — це заздалегідь відрендерений статичний HTML-контент, розміщений на CDN, і динамічні вставки лише там, де треба. Бекенд розглядається у вигляді набору API, до яких можна звертатися за допомогою JavaScript, і це далеко не завжди кастомний бекенд, це можуть бути вже готові сервіси, які реалізують аутентифікацію, сервіси збереження даних і таке інше. Текстовий контент не обов’язково тримати у вигляді HTML, для цього доцільно застосувати якусь із мов розмітки, наприклад Markdown. А сам сайт оновлюється за допомогою процесів CI/CD, які стартують за тригером, наприклад після оновлення коду в системі контролю версій.
Оскільки статичний контент може бути на CDN максимально близько до клієнта, а також не потребує часу на динамічний рендеринг, то сайти, створені за допомогою JAMstack, — надзвичайно швидкі. Для індексації пошуковими системами та deep linking немає потреби в якихось додаткових діях — це спрощує і в кінцевому підсумку здешевлює розробку.
Імовірно, JAMstack не підійде до всіх можливих сайтів, однак цілком придатний до великої кількості поширених категорій, таких як блоги, сайти новин і навіть онлайн-магазини. На відміну від SPA, JAMstack ідеологічно значно ближчий оригінальним ідеям вебу: контент не відтворюється імперативно за допомогою JavaScript, а представлений декларативно в сторінках, розміщених на сервері, хоча можливість робити динамічні ставки є, зокрема можна відмовитися від переходу між сторінками за допомогою браузера й робити це в стилі SPA.
GatsbyJS — один з найвдаліших фреймворків для JAMstack, на DOU навіть є цикл публікацій про нього, він поєднує в собі підтримку React, GraphQL, Markdown і досить гнучкий, щоб адаптуватися до різних сценаріїв використання.
Цікаво, що деякі компоненти JAMstack не новинка, однак вдале їх поєднання та врахування специфіки вебу, схоже, і є тим каталізатором, що має забезпечити успіх нового стеку.
JAMstack формують добре відомі складники
WebAssembly
Одна з технологій, вплив на веб-розробку якої непросто передбачити, — це WebAssembly. Можна сказати, що це скринька Пандори для альтернативних до JavaScript мов програмування в браузері. Якби її підтримка з’явилася ще років десять тому, то в JavaScript було б значно менше шансів у битві проти інших, «серйозніших» мов програмування. Однак тепер я розцінюю шанси як рівні, до того ж сам роблю ставку на JavaScript, бо ця мова суттєво оновилася упродовж кількох останніх років, а її застосування для вебу настільки природне, наскільки звично розробнику писати ідентифікатори англійською мовою.
Оскільки серед основних аргументів на користь WebAssembly називають швидкість, то ми, ймовірно, спостерігатимемо процес, коли десь там «під капотом» у реєстрі npm оновлюватимуться бібліотеки, які будуть оптимізовуватися за швидкістю з використанням альтернативних до JavaScript мов, однак їхні інтерфейси так само залишатимуться на JavaScript.
Звісно, WebAssembly поступово почне «відкушувати» частину розробників у JavaScript, цьому сприятимуть такі проекти, як, наприклад, Microsoft Blazor, призначені здійснити давню мрію бекенд-розробників: позбавити себе задоволення вивчати JS. Проте ці процеси навряд чи відбуватимуться швидко, і якщо говорити про перспективу кількох найближчих років, то монополії JavaScript на фронтенді це навряд чи суттєво загрожуватиме.
Імовірно, єдина мова, яка в найближчій перспективі хоч якось помітно здатна потіснити JavaScript у вебі, — це TypeScript, але її навряд чи можна назвати альтернативою до JS, це радше такий собі «JavaScript наступного рівня». Він опційний для використання і стає потрібен тоді, коли проект значно розростається. Тож важливо мати не лише статичну типізацію, а й інтерфейси, декоратори та інші складові, які є в TS.
Висновок
Ця тема така розлога, що про неї можна видати цілу книжку, але рано чи пізно розмову варто завершувати. Історія вебу особливо цікава тим, що вона не стояла на місці: тут завжди все активно розвивається, щось бурлить і вибухає, дещо шумно приходить, а потім непомітно зникає. Враховуючи роль вебу у світовому бізнесі, нічого немає дивного в тому, що він був, є і, поза сумнівом, буде в майбутньому полем битви великих корпорацій за свій вплив на звичайних користувачів і розробників.
У цій боротьбі завжди з’являється хтось, хто відчуває в собі сили та бажання підім’яти під себе веб, встановивши монополію на браузер чи певні технології, які мають використовувати розробники. Спочатку це була Netscape, потім її витіснила Microsoft, згодом у вебі почала панувати Google, яку, своєю чергою, витісняє Facebook. Але втримувати корону ще складніше, ніж її одержати, бо сила вебу — у відкритості стандартів, і щоразу, коли його намагаються монополізувати чи інфікувати сторонніми складниками, — як, наприклад, було з RIA, — він знаходить сили оновитися й позбутися їх. Але веб не робить це самостійно — це роблять розробники, що своїми руками сьогодні надають йому тих форм, які він матиме завтра. І щоб розробляти під веб, треба розуміти його, треба відчувати його філософію, ідеї, які заклали в нього його творці. Саме тому я закликаю розробників відповідальніше ставитися до тих рішень, які ми ухвалюємо, і підходів, які ми застосовуємо, старатися менше використовувати сторонніх для вебу речей, а більше того, що нам він дає як платформа, бо, як казав геніальний Алан Кей, «немає найліпшого способу передбачити майбутнє, ніж створити його».
Контакти автора: LinkedIn, телеграм-канал, веб-сайт.
