Веб-розробка: вчора, сьогодні, завтра

Привіт, мене звуть в'ячеслав Колдовський, я Programming Mentor . У веб-розробці я з 1990-х, тепер працюю в SoftServe над навчальними проектами. Чверть століття я спостерігав за еволюцією вебу, бачив появу та смерть технологій, робив ставки в конкурентних війнах, мене завжди цікавило, куди воно все рухається, — саме про це хочу з вами поговорити, і розмова не буде короткою.

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

Перший веб-сайт побачив світ 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

Переходячи до, ймовірно, найцікавішої складової фронтенду, варто зробити відступ і запитати: а що робить мова програмування на фронтенді взагалі? Тут варто зазначити, що в 1990-х людину, яка займалася веб-сайтом, дуже часто називали веб-майстер, і далеко не завжди це була людина з навичками програмування. Якось на цю тему пожартував Кріс Коєр, засновник css-tricks.com: «Два фронтенд-розробникі сидять поруч у барі. Їм ні про що говорити» . І це не той випадок, коли хтось пише на React, а інший на Angular. Це радше про те, що один типовий програміст — з алгоритмічним мисленням, якому зручніше згенерувати весь контент динамічно та імперативно, досить лише отримати контейнер, а другий, навпаки, людина, для якої ближчою є семантика елементів, структура контенту, стилі, анімації тощо, тобто декларативний підхід. Якщо говорити про філософію, закладену в HTML, то саме другий підхід є коректнішим, хоч би як дивно це здавалось для декого з розробників сьогодні.

Джерело

Власне, сам Тім Бернерс-Лі жодної мови програмування всередині браузера не передбачав, тому не дивно, що історія її виникнення скидається на детектив. Компанія Netscape, заснована у квітні 1994-го випустила першу публічну версію браузера Netscape Navigator з номером 0.9 у листопаді того самого року. Браузер стрімко почав набирати популярність, і вже за чотири місяці займав три чверті всього ринку.

Частка ринку браузера Netscape Navigator, 1994-2007

Засновник компанії Марк Андресс вирішив, що HTML не вистачає саме легковагової скриптової мови програмування, код якої можна було б писати прямо в тексті веб-сторінок. Тож у квітні 1995 року він найняв Брендона Айка, який був тоді відомим фахівцем з мов програмування, для того щоб вбудувати мову програмування Scheme у браузер Netscape Navigator. Однак у мові Scheme досить специфічний синтаксис, а Sun тоді мала сильні ринкові позиції та активно просувала Java, тому однією з вимог, які висунув Брендон Айк до нової мови, була синтаксична подібність з Java. До вимог також належало, щоб мова була досить проста та не містила класів, тож для Брендона вона стала своєрідним челенджем — він вирішив зреалізувати в ній ООП, але без класів.

У Netscape прийнято було працювати дуже швидко, тому Брендон Айк розробив прототип мови за 10 робочих днів явились в місті у 1995 року. Це справді дуже мало для того, щоб створити власну мову програмування з нуля, але, схоже, цілком досить, якщо базуватися на вже готових рішеннях. Саме тому нова мова запозичила синтаксис із Java, основну функціональність із Scheme, а реалізацію ООП із Self.

Також цікавою особливістю мови була вбудована стійкість до помилок — синтаксичних і помилок під час виконання коду; це давало б змогу користуватися нею непрофесійним розробникам. Тому, наприклад, у JS крапка з комою для поділу тверджень є опційною, а арифметичні операції взагалі не переривають хід виконання коду — можна сміливо ділити на нуль чи добувати квадратний корінь з від'від'ємного числа; спроба прочитати значення з масиву за його межами просто поверне undefined, а якщо забути задекларувати змінну і присвоїти раніше незадекларованому ідентифікатору якесь значення, то помилки не виникне, змінна створиться автоматично, однак це навряд чи добре, бо створена змінна буде не на рівні блоку чи функції, а в глобальному просторі імен.

На той момент така гнучкість і стійкість до помилок у коді здавалася важливим досягненням, що залучало б до програмування людей, які до того не мають стосунку. Але час показав, що для професійних розробників, які звикли до строгості й точності в програмуванні, JavaScript здавалася недосить серйозною мовою. Тім більше що деякі рішення були здійснені під тиском обмеженого часу, і навіть сам автор мови визнав їх невдалими. Наприклад, якось 2013 року через твітер у Брендона Айка подали напругу про дивне рішення стосовно відсутності блочної області видимості в JavaScript, на що він відповів, що 10 днів не вистачило на блочну область видимості, та й на тій годину для простої скриптової мови такий підхід здавався цілком прийнятним.

Діалог у твітері з Брендоном Айком стосовно блочної області видимості

Годі було 1995 року уявити, що одного дня JavaScript стані найпопулярнішою мовою програмування у світі. Власне, тоді, у 1990-х, старт JS серед розробників навряд чи можна було вважати вдалим, бо ця мова сприймалася як щось недосить серйозне, чим слід користуватися, коли треба замінити зображення, поверх якого рухається курсор миші, чи якесь інше схоже завдання.

Варто згадати про тогочасний тренд — унікати написання коду на фронтенді загалом і використовувати інструменти, що дають змогу конструювати сторінки візуально, а код генерувати автоматично. Серед таких інструментів — Vermeer FrontPage, що вийшов 1995 року (пізніше FrontPage) та Macromedia Dreamweaver (пізніше Adobe Dreamweaver), який вийшов 1997-го. Можливість згенерувати код веб-сторінки з її візуального представлення отримав Adobe Photoshop. Тобто дуже часто фронтенд-частина сайту сприймалася як частина проекту, з якою працюють дизайнери — не програмісти, бо для останніх є бекенд.

До речі, програмування на бекенд прийшло значно раніше, ніж на фронтенд, там його місце здавалось логічнішим. Першою такою технологією, що давала змогу динамічно генерувати HTML, була технологія CGI (Common Gateway Interface), створена 1993-го, всього за два роки після запуску першого сайту. Зреалізована вона була дуже примітивно: HTTP-запит від клієнта направлявся на скрипт на сервері, який отримував параметри запиту та генерував відповідь, направивши її на стандартний вивід, що, власне, і отримував браузер у відповідь. CGI дозволяла писати код будь-якою мовою, досить було запустити її на сервері — хоч Perl, хоч C, однак загалом це робилося доволі трудомістко.

Справжнім проривом у веб-розробці стала поява PHP 1995 року — ця мова була спеціально створена для вебу й давала змогу органічно поєднати HTML та синтаксично близьку до C мову програмування. Ідея не напрочуд вдалою і послугувала прообразом для Active Server Pages від Microsoft, що вийшла 1996-го, та багатьох інших технологій, які зайняли свою нішу ринку, проте не змогли наблизитися до популярності PHP навіть чверть століття після того.

Певною мірою своїм успіхом PHP завдячує тому, що браузер тоді не сприймався як серйозна платформа для програмування. Можливості JavaScript у роботі зі сторінкою були дуже обмежені, до того ж у другій половині 1990-х розгорілися браузерні війни: Microsoft випустила свій браузер, у якому імплементувала власну інтерпретацію JavaScript під назвою JScript, і особливо проблемно було створювати кросбраузерний код.

Вісь, наприклад, фрагмент коду з реального сайту 1998 року. Можна лише уявити, яке «задоволення» приносило писати щось таке:

Саме такий вигляд мав кросбраузерний код 1998 року

RIA

Як додаткове підтвердження того, що пара HTML/JavaScript не сприймалася як платформа для розробки, слід назвати появу та розквіт різноманітних плагінів, які малі бути вбудованими веб-сторінки — чі взагалі заміняти їх — і надавати розробникам «повноцінніший» досвід програмування. Зокрема, 1996 року Sun у межах платформи Java випустила Java Applets, а Microsoft представила ActiveX, водночас компанія Macromedia придбала FutureWave Software і випустила свій плагін для браузера — Macromedia Flash, який спочатку позиціювався як медіапрогравач, але згодом ставши повноцінною програмною платформою.

Усі ці плагіни були сторонніми для вебу, потребували годині на завантаження та інсталяцію й не приносили особливого задоволення користувачам браузерів. Водночас можливості для програмування в браузерах саме за допомогою JavaScript розвивалися досить повільно, хоча й були перші зрушення. Зокрема, коли в Netscape відчули серйозну загрозу з боку Microsoft, то вирішили віддати JavaScript на стандартизацію в організацію Ecma International. Організація досить оперативно взялася стандартизувати та розвивати мову й упродовж 1997-1999 років випустила три версії EcmaScript. Також 1997 року світ побачив Microsoft Internet Explorer 4.0 — нищівний для Netscape продукт, завдяки якому MS перемогла в браузерних війнах. Серед його особливостей була задекларовано підтримка Dynamic HTML — набір технологій, до яких входили JavaScript та DOM, що нарешті давали змогу повноцінно маніпулювати вмістом HTML-сторінки на клієнтському боці й навіть динамічно застосовувати стилі.

Браузерні війни 1996-2009

Утім, розробникі браузерів та плагінів об'єднання єднали зусилля й запропонували 2002 року концепцію RIA — Rich Internet Applications, у яких ідея користуватися браузерами з плагінами подавалася як необхідність для того, щоб отримувати якісний медіаконтент та досвід роботи із сайтом загалом. Такий підхід значною мірою нівелював ідею вебу як єдиної платформи обміну інформації, бо Flash, Silverlight тощо — це, по суті, окремі незалежні платформи, контрольовані комерційними організаціями, які самостійно визначають правила гри.

Web 2.0/Web.3.0

Вже наприкінці 1990-х стало зрозуміло, що Інтернет загалом та веб зокрема захопили світ, потіснивши всі інші мережі й спосібі представлення інтерактивної інформації. У січні 1999 року вийшла стаття авторства Дарсі Дінуччі, у якій уперше прозвучало про концепцію Web 2.0, авторка назвала наявний на тій годину веб лише ембріоном того, що має прийти в майбутньому. Основною рисою Web 2.0 була робота на пристроях з різними обчислювальними можливостями, розмірами екранів, способами введення інформації та в умовах кардинально різної швидкості зв'язку. Упродовж кількох років концепцію Web 2.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 запустила у 2004-му сервіс Google Suggest, що показавши можливості технології всьму світу. У лютому 2005 року Джеймс Ґаррет опублікував статтю «AJAX: новий підхід до побудови веб-аплікацій» , у якій було запропоновано сам термін та детально описано технологію, що й зумовило активні її застосування.

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

Вже наприкінці першої декади 2000-х стало помітно, що обсяг коду на фронтенді дуже зріс, важливою стає модульність і підтримуваність рішень, jQuery в цьому аспекті мало що могла запропонувати, тому на сцену почали виходити фреймворки Single Page Application, які самою можливістю свого існування мають завдячувати AJAX.

Knockout, Backbone, ExtJS, AngularJS — далеко не повний перелік SPA-фреймворків, які почали тоді з'єднання являтися й здебільшого використовували патерн MVC або його похідні. Сам патерн винайшли ще наприкінці 1970-х, але у веб-розробці його використання стало особливо поширеним. Вважається, що вперше MVC у вебі застосували 1996 року в маловідомому на сьогодні серверного фреймворку WebObjects, потім він швидко поширився на інші серверні фреймворки й загалом дуже комфортно почувався у вебі, накладаючись на традиційну модель комунікацій, яка передбачала перезавантаження сторінки під годину шкірного запиту клієнта.

Однак з появою 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-фреймворки — то завжди гаряча тема. Ми всі прекрасно знаємо: день минає даремно, якщо світ не побачив новий фреймворк. Хоча це чи не найулюбленіша тема для новачків похоліварити, досвідчені розробникі рідко піддаються на провокації та просто спостерігають за трендами й вивчають ті, на що є попит.

Приблизно у 2014-му AngularJS був лідером серед SPA-фреймворків, але відтоді багато що змінилося. Вже кілька років поспіль в абсолютних лідерах React, який формально є більше бібліотекою, ніж фреймворком. Проте популярність — це річ оманлива: по-перше, вона перемінна, постійно тримати корону вдається хіба що jQuery, по-друге, не завжди найпопулярніша технологія є найоплачуванішою — тут варто згадати про PHP.

Багато хто вже «поховав» Angular, але тут не все так просто: у Google переписали AngularJS з нуля, навіть ім'я змінили, повністю поламавши зворотну сумісність, проте навряд чи хтось скаже, що цим вони нікого гірше. Як наслідок — вийшов такий собі мегаконструктор SPA, який не дуже підходить для нескладних проектів, але вдало знайшов свою нішу в корпоративних. Він і далі активно розвивається, Google забезпечує серйозну підтримку — загалом майбутнє видається значно оптимістичнішим, ніж може здатися на перший погляд.

Упродовж кількох останніх років досить упевнено почувається VueJS. Легковаговість і простота — це два основні чинники, які забезпечують його популярність. Він активно розвивається й особливо популярними ставши в Азії — власне це, ймовірно, і варто зарахувати до нечисленних недоліків: часто значно простіше отримати підтримку китайською мовою, ніж англійською.

Але справжнє відкриття 2019 року, яке ще має себе показати у 2020-му, — це «фреймворк, що щезає» — Svelte. Поки React та Vue називають Virtual DOM своїми перевагами, Svelte, навпаки, серед переваг називає його відсутність. Але ключова його особливість полягає в тому, що після збірки аплікації в ній не залишається фреймворку як такого — аплікація компілюється в чистий JS, за допомогою якого і відбуваються маніпуляції з елементами сторінки. Це досить суттєво відрізняє Svelte від інших, хоча такий підхід використали розробникі Angular в останніх версіях із новим двигуном рендерингу Ivy.

Наприкінці 2019 року серед фронтенд-розробників всього світу робили традиційне опитування «State of JS», у якому за рівнем цікавості Svelte посів перше місце.

Рейтинг фреймворків за рівнем цікавості 2019 року

Загалом підхід, використаний у Svelte, можна лише вітати: замість того щоб укотре в браузері будувати мета-платформу, розробникі фреймворку використали можливості браузера. Тут доречно згадати, що розвиток браузерів як платформи теж не стоїть на місці, і серед останніх нововведень особливої уваги варта підтримка WebComponents — механізму, що дає змогу створювати власні елементи в HTML, які мають незалежні стилі й логіку, розв'язків язуючи ті самі завдання, що більшість фронтенд-фреймворків. Тож варто очікувати поширення саме такого підходу, що наближає фреймворки до браузера як платформи, а не віддаляється від нього.

Що з бекендом?

Ще з 1990-х на бекенді заправляє балом стек LAMP і похідні, створені за його образом та подобою. І питання навіть не в конкретному наборі технологій, які його формують, а в загальних принципах роботи — запити з фронтенду обслуговуються динамічно, у процесі залучена база даних та сервер аплікацій, що відносно повільно працюють та добре масштабуються по горизонталі. У такому підході принципово нічого не змінилося навіть з приходом SPA, які дозволили відмовитися від передачі згенерованих сторінок із сервера, переганяючи лише дані за допомогою RESTful API.

Водночас варто зазначити, що розробникам на бекенді доводитися розв'язків язувати типові завдання навіть у різних проектах — зреалізовувати аутентифікацію та авторизацію, створювати типові CRUD-операції для сутностей предметної ділянки, передавати DTO між різними рівнями аплікації, покривати все це тестами тощо. Щоб не повторюватися щоразу й перевикористовувати зроблені раніше рішення, ще з кінця 1990-х стали набирати популярність CMS (Content Management Systems), а з поширенням RESTful API — так звані Headless CMS, що взагалі не мають фронтенду.

Попри те, що CMS вдається розв'язків зв'язати певну частину проблем з перевикористанням кодом, проблеми з розгортанням та підтримкою серверів залишаються. Подальша еволюція таких рішень — це міграція в хмари і використання сервісів, які повністю керуються хмарними провайдерами. У цьому сенсі дуже привабливими видаються рішення, такі як Google Firebase та подібні. Поєднання можливостей аутентифікації, авторизації, API для роботи зі структурованими даними з можливостями хостингу з підтримкою CDN — серйозний аргумент проти того, щоб займатися всіма цими питаннями самостійно. Поділ монолітів на мікросервіси та використання платформ, які беруть на себе масштабування під навантаженням, — такі архітектурні рішення спонукають використовувати хмарні сервіси й не займатися питаннями керування та підтримки інфраструктури.

Одна з цікавих інновацій на бекенді, що швидко набуває популярності й здатна вплинути на прийняті підходи до розробки рішень, — це GraphQL , розроблена у Facebook технологія, що дозволяє на фронтенді сформувати запит до структури даних, які має повернути бекенд. Такий підхід позбавляє бекенд-розробників потреби створювати нескінченні CRUD-операції та загалом є гарною альтернативою до RESTful API.

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

JAMstack

Наприкінці 2017 року вийшла цікава стаття , у якій досить детально було описано стек технологій під загальною назвою JAMstack (JavaScript + API + Markup). Сам термін винайшла та активно просуває компанія Netlify, яка дуже вдало почала просувати ідею альтернативного до SPA підходу, що насправді зовсім не новий, але значно ближчий до оригінальних ідей вебу, ніж SPA.

JAMstack пропагує ідею так з

Опубліковано: 14/01/20 @ 08:00
Розділ Блоги

SEO Блог