Конференция по DevOps практикам — DevOps Fest, 20-21 марта. Cпикеры и доклады на сайте >>
×Закрыть

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

Привіт, мене звуть В’ячеслав Колдовський, я 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 року (пізніше Microsoft 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 пропагує ідею так званих статичних сайтів, хоча термін «статичний» тут зовсім недоречний, бо насправді статичними ці сайти не є, просто, на відміну від 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, телеграм-канал, веб-сайт.

LinkedIn

26 комментариев

Подписаться на комментарииОтписаться от комментариев Комментарии могут оставлять только пользователи с подтвержденными аккаунтами.

Чудова стаття. дякую!

Дуже цікава стаття. Ще було б цікаво додати під-розділ — прогнози на майбутнє.

Цiкаво що ви скажете про Svelte.

Мені інпонує його підхід, може стати трендом, я ж про навіть кілька абзаців згадав.
Ще ця штука дуже цікава, може вистрелити: stenciljs.com

Дякую, цікаво було почитати. Веб — це те, з чим постійно перебуваєш у контакті, але ніколи не вистачає часу заглибитись.

Хоч я безпосередньо з вебом мало контактую на рівні розробника, почитати було цікаво. Більшість наведених назв мені знайома, але тепер вони структурувалися у моєму розумінні.
Якщо є ще низка тем, яку неможливо було вмістити в одну статтю, то я обома руками голосую за розширення цієї статті до серії. Фронтенд ніби розжований, а про бекенд буквально два слова. Node.js, ASP.NET, той же python, інструментарій Java тощо. Як вони прийшли до інтернету і з яким успіхом складають конкуренцію заточеному під нього PHP.
Буду радий, в тому числі, і через збільшення обсягу україномовного контенту. Принаймні тепер у людей є вибір.

Станіславе, дякую за відгук! Так, можна подумати про продовження і в такому ключі, є про що поговорити. Стосовно україномовного контенту — маємо робити це, хто ж як не ми самі?
Тобі окремо хочу подякувати за статтю про Китай — дуже захопливо, молодець, що наважився на таку пригоду, та ще й не полінувався поділитися деталями з усіма. Маємо дещо спільне — дипломи одного вузу, але не китайського, а СумДу :)

Спасибо, интересная ретроспектива. Читается легко.

Я бы еще добавил информацию про Prototype — prototypejs.org и script.aculo.us — до JQuery и его популярности именно они были зачинателями.

Та тут писати й писати — просто в якийсь момент редактори ДОУ попросили зупинитися :)

JS delenda est (мастдай по-нашему)

Ne momorderis manum qua nutriris :)

Висновок такий: майбутнє веб (і не тільки) — це Flutter.

Нормальна мова, віджети, композиція компонент :), реактивність, створення інтерфейсів без CSS і його купи хаків, без поліфілів, бандлерів. Працює на всіх девайсах нативно. iOS/Android/Web — скрізь компілюється в рідний код. Нарешті, можна написати раз і запустити на трьох платформах рідний код. А не ганяти жс бандли по мережі в React Native Bridge.

Дійсно Flutter гарна штука, якщо говорити саме про цілісну платформу для UI, але для веба він не зовсім нейтів, хоча, якщо в Google поставлять собі за мету по-справжньому потіснити конкурентів, то це реально, однак їм самим же це може бути не зовсім вигідно. Зокрема, вони дуже сильно вклалися в Angular, то навряд чи на таке підуть. Швидше за все вони не будуть насильно «запихувати» Flutter у веб, а спостерігатимуть за його сприйняттям розробниками. Зараз у вебі я би робив ставку на JAMstack, ну а далі буде видно :)

ангуляр уже роки 2 як труп. його закопав реакт. Flutter прибирає основну проблему веб розробки — css і html. Все пишеться людською мовою і з композиційними віджетами. JAMstack звісно ще буде жити, і по-трошку помирати. Натомість щось родиться на флатері і буде всім щастя :)

Думаю що слухи стосовно смерті ангуляра занадто перебільшені, варто краще розібратися у реальному стані речей. Починаючи з другої версії вийшов такий собі оверінженіринг, який з однієї сторони сильно підняв поріг входження, бо вкупі з самим ангуляром треба ще вивчити купу додаткових речей, зокрема typescript та rxjs, що самі по собі є окремими технологіями, а з іншої — призвів до непомірного роздуття бандлів і проблем зі швидкістю аплікацій. Це його однозначно вибило з сегменту простих проектів, та й тих, для яких швидкість завантаження є особливо критичною, тут особливо реакту нічого протиставити. З іншого боку, якщо говорити про великі корпоративні проекти, то тут позиції ангуляра виглядають значно привабливіше. Власне у цьому випадку його недоліки некритичні, а переваги стають більш помітними. Це повноцінний фреймворк з усіма потрібними залежностями і, найголовніше — невід’ємними best practices до того як будувати рішення. На відміну від реакту, тут менше потреб виникає в тому щоб збирати і мейнтейнити купу залежностей, а команда розробників регулярно видає нові версії з по-справжньому важлими змінами і досить простою процедурою оновлення. Причому з кожною версією воно працює швидше, розміри бандлів зменшуються, команди, що зробити ставки на ангуляр в нових проектах не так часто розглядають варіанти з нього з’їзжати. Серед цікавих останніх нововведень можна говорити про підтримку системи збірки Bazel, новий двигун рендерингу Ivy, спрощення реалізації lazy load. Загальна кількість користувачів рік від року зростає: twitter.com/...​tatus/1069727630734151680
Відповідно вакансії є, вони високооплачувані — а що нам ще треба?
Якщо говорити про тотальне засилля реакту у всіх можливих рейтингах, то це звісно важливо, але я б не переймався стосовно того, достатньо пригадати, що найпопулярнішою бекенд-мовою є PHP, але розробники на інших мовах не сильно від того страждають.
Причому я не являюсь адвокатом ангуляра, давно вже не холіварю, наприклад, сьогодні черговий сайт запустив на реакті (якщо більш точно, то JAMstack з GatsbyJS), але є проекти на ангулярі, і з’їзжати з нього не планую найближчим часом. І як треба буде стартувати щось нове, то у кожному випадку будемо розглядати конкретні плюси
мінуси. А що далі буде — то вже подивимося :)

Цікава статистика, можна інтерпретувати по-різному, наприклад так:
twitter.com/...​08685588587925504?lang=nl :)

дякую за таку розгорнуту відповідь! хотів заагрить, але не вийшло :-)

«А застосування JS для вебу настільки природне, наскільки звично розробнику писати ідентифікатори англійською мовою.»
Конечно природне — десятилетие через кровь, пот, слёзы и отсутствие альтернативы.

а потім уже працює Стокгольмський синдром

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