Коротка історія вебу: як формувались HTML, мережі та інструменти для сайтів

Усім привіт, мене звати Олександр, я Full-Stack розробник, але у цій статті хочу поговорити не про робочі випадки чи процеси, а в цілому про веб та його розвиток. Сьогодні вебдодатки — це відносно складні системи, що використовують купу різних технологій, мов програмування, фреймворків і т.д. Новачку (і не тільки) досить складно зрозуміти, що взагалі відбувається, як його «хелоу, ворлд» потрапляє на екран та яке місце умовний джаваскрипт займає у велетенській павутині комп’ютерних технологій.

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

❗️ Важливо! Я не претендую на історичну правдивість. А подекуди, може, й спеціально пишу вигадані речі. Ціль статті — дати зрозуміти, чому ми маємо те, що маємо. Які проблеми чи бажання могли до цього призвести.

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

Поїхали...

Уявіть 80-і роки. Комп’ютери вже потроху з’являлися в різних лабораторіях, університетах. Люди (не всі, звичайно) почали звикати до роботи з інформацією на комп’ютерах. Але ділитися цією інформацією з іншими комп’ютерами дуже незручно. Нема такого зручного способу побачити в себе на комп’ютері інформацію, яка знаходиться на іншому пристрої. А хотілось би...

Що якби автор міг створити книгу (чи журнал, чи газету), але не справжню, а якусь магічну, всередині комп’ютера? А читачі, щоб відкрили її, погортали сторінки, почитали, що зацікавить, але також на моніторі комп’ютера. Щоб якимось чином та книга з комп’ютера автора сама з’явилась на комп’ютерах читачів.

Магія! Але з часом вона стала реальністю.

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

І хоча HTML народилася останньою з трьох, я почну саме з неї.

HTML

Так от. Які вимоги могли б бути в людей до такої електронної книги? Ну, має бути текст. І заголовки мають бути більшими і жирнішими за інший текст. Та і відступи різні в різних місцях. А можна ще й курсивом деякі слова виділяти?

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

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

З ідеєю визначились. Залишилось придумати формат (правила створення таких сторінок) і написати програму-зчитувач-рендерер. З форматом могли б придумати, що завгодно. Вирішили, що якщо якусь частинку тексту потрібно відобразити інакше, ніж весь інший текст, то її «обгорнуть» в отакі значки: <спеціальне_слово>тут текст, який має бути відображений інакше</спеціальне_слово>.

Програму ж навчать розрізняти такі спеціальні слова і відповідно до них по-різному відображати текст, що знаходиться всередині. Якщо самого спеціального слова замало, то додаймо скільки завгодно пар ключ=значення поряд зі спеціальним словом: <спец_слово_2 ключ1=значення1 ключ2=значення2>інший текст</спец_слово_2>.

Тепер, маючи таку структуру, можна вигадувати скільки завгодно правил форматування. Головне — не забути навчити програму всіх їх обробляти.

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

Річ у тому, що в усіх книгах є геніальний винахід людства, що дуже полегшує користування ними. Це зміст. Дивлячись на один розділ (зміст), ми можемо знайти адресу будь-якого іншого розділу. І дуже швидко перейти до нього. Хотілося б мати щось схоже і в наших електронних документах. Адже звідки читач буде знати про існування інших документів (крім того, який він бачить в цей момент)?

Довелось вигадати гіперпосилання (hyperlink). Це така можливість перейти до конкретного місця в тому ж документі, або до абсолютно іншого документу. Шматок тексту, до якого прив’язано гіперпосилання, назвали гіпертекст (hypertext). Ми і зараз використовуємо тег a (<a href=...>text</a>) на кожному сайті. Він і є реалізацією гіперпосилання.

Гіпертекст став настільки ключовим принципом, що його включили і в назву формату документів — HTML (HyperText Markup Language), і в назву протоколу передачі таких документів — HTTP (HyperText Transfer Protocol).

Тепер точно все є. Наприклад, захотів хтось зробити збірку біографій відомих людей. Кожну окрему біографію можна створити окремим html-файлом. У файлі steve_jobs.html буде біографія Стіва Джобса, у файлі bill_gates.html — біографія Білла Гейтса, і т.д. Який файл відкриєш браузером, таку біографію й почитаєш.

А щоб читач знав, які взагалі файли існують, можна створити файл зі змістом — він буде основним, знати треба тільки про нього (наприклад, index.html). В цьому файлі буде список гіпертекстів, клацнувши на які буде автоматично відкриватись інший документ. Клацнув на ім’я Білла Гейтса — браузер відкрив файл bill_gates.html. І читачу вже не потрібно запам’ятовувати його. Отака магія. А якщо автор вирішить додати біографію Джефа Безоса, то він створить новий файл jeff_bezos.html, а в index.html в список додасть ще один гіпертекст: «Джеф Безос».

Пізніше з’явилася технологія CSS (Cascading Style Sheets), що значно розширила можливості форматування, але то нам не цікаво в даній статті.

Все виглядає круто, але поки що, щоб усім цим чудом скористатися, потрібно мати всі файли в себе на комп’ютері. Так, очевидно, не спрацює. Має бути зручний механізм передачі файлів з комп’ютера автора до комп’ютерів читачів.

Мережа

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

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

Те ж саме треба було зробити і для обміну інформацією між комп’ютерами. Кожен під’єднаний до мережі комп’ютер мусить мати унікальний ідентифікатор. Таким ідентифікатором стала IP-адреса. Не будемо вдаватись в деталі, нехай це буде рандомний набір цифр. Але основна умова — він має бути унікальним. Тобто, кожен учасник мережі буде мати унікальну IP-адресу.

Тепер, знаючи IP-адресу конкретного комп’ютера, ми можемо відправити меседж саме йому. Стало краще. Але з’явилась нова проблемка: люди дуже погано запам’ятовують числа... Тим більше великі числа... Тим більше рандомні числа (які для них нічого не означають). Уявіть, що ви користуєтесь десятком ресурсів і мусите знати число типу 123.456.789.012 для кожного з них. Так собі перспектива.

Набагато простіше запам’ятовувати слова, тим паче якщо вони логічно пов’язані з темою ресурсу. Тому люди подумали і вирішили, нехай десь буде записана відповідність вигаданих імен до реальних IP-адрес. Ми будемо відправляти повідомлення на якесь ім’я, а спеціальна програма буде знаходити відповідну IP-адресу, підміняти нею ім’я, і насправді запит піде вже на IP-адресу. Але нам, людям, то вже не цікаво, ми запам’ятаємо лише буквене ім’я. Так і зробили. Імена назвали доменами, а таблички, де зберігаються співвідношення доменів до IP-адрес, — DNS (Domain Name System). Домени (чи доменні імена) виглядають так: geniusbiographies.com, news.in.ua і т.д. Чому з крапками, і що це за букви вкінці — тут нам це не цікаво.

Тепер, здається, є все необхідне для успішного обміну інформацією. Але ніт. Маючи IP-адресу, ми можемо доставити повідомлення до потрібного комп’ютера. Але хто (чи що) на тому комп’ютері має обробити наш запит?

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

Отже, з’явилась дуже схожа проблема, що й була з ідентифікацією комп’ютерів. Тільки тепер потрібно ідентифікувати програму, яка має опрацювати конкретне повідомлення. І знову вирішили використовувати рандомні числа. Цього разу вони будуть меншими, оскільки програм на комп’ютері буде явно менше, ніж можливих комп’ютерів в мережі. І тут вже точно рандом, тобто, ніякої логіки в їх формуванні немає. Ці ідентифікатори назвали портами. Вони можуть мати значення від 0 до 65535.

Кожна програма, що запускається на комп’ютері і хоче обробляти якісь вхідні повідомлення, має вказати, який порт вона «слухає». Тобто, програма буквально говорить операційній системі: «якщо від когось прийде меседж, в якому буде вказано порт ХХХ, то віддай цей меседж мені, я знаю, що з ним робити.»

Отже, відправляючи повідомлення, ми можемо вказати не тільки IP-адресу, а ще й порт. IP-адреса буде використана для доставки повідомлення до конкретного комп’ютера, а порт — для передачі повідомлення правильному обробнику на тому комп’ютері.

Але от біда, звідки ми, як відправник, можемо знати, який в біса порт слухає потрібний нам обробник на якомусь комп’ютері, який хтозна-де знаходиться і хтозна-ким налаштовується?

Правильно, нізвідки. Тому, вирішили домовитись. Нехай, всі програми, які виконують таку функцію, слухають такий порт. А ті, що виконують отаку функцію, слухають отакий порт, і т.д. Наприклад, програма, яка займається передачею файлів, нехай слухає порт 21, а програма, яка займається імейлами — порт 995. Ніякої логіки в цих числах, просто домовленість, стандарт.

Якщо люди, що створюють/ встановлюють/ налаштовують такі програми, будуть дотримуватись стандартів, то для відправника зовсім не складно «вгадати», на який порт слати запит.

Оскільки поняття сайту до цього ще не існувало і, відповідно, не було програмного забезпечення, яке б обробляло новий тип повідомлень (про нього поговоримо далі), то потрібно було створити нову програму(-ми) і придумати порт, який вона буде слухати. Такі програми назвали вебсервери, а портом стало число 80.

Перші вебсервери мали робити дуже просту роботу: слухати порт (бажано 80), і, отримавши вхідний запит, знаходити і повертати html-файл, адреса якого і вказувалася в запиті.

Тепер відправник, що хоче отримати доступ до інформації сайту може цілком резонно припустити, що повідомлення потрібно слати на порт 80.

Наприклад, якщо користувач клікне по гіпертексту «Bill Gates» (приклад з попереднього розділу), то браузер надішле запит, щось на кшталт «GET geniusbiographies.com:80/biographies/bill_gates.html». Операційна система комп’ютера-адресата віддасть повідомлення вебсерверу, що слухає порт 80. А вебсервер, отримавши таке повідомлення, витягне з нього рядок «biographies/bill_gates.html», знайде такий файл на своєму комп’ютері і відправить його контент браузеру.

Чи може таке бути, що хтось запустить вебсервер, що слухає інший порт? Авжеж може. Але тоді відбудеться одне із двох.

  1. Потенційні клієнти мають якимось чином дізнатися, який порт актуальний і, відповідно, слати повідомлення на нього. Це майже нереальний кейс.
  2. Потенційні клієнти будуть слати повідомлення на 80 порт (бо вони так в стандарті вичитали), повідомлення буде доставлятись до потрібного комп’ютера (бо на це порт не впливає), але на тому комп’ютері операційна система не знайде жодної програми, яка б слухала цей порт. Тому, повідомлення не буде оброблено і у відповідь полетить якась стандартна помилка, типу «я не знаю, що мені з оцим усім робити». Цей варіант імовірніший.

На цьому все? Ну, майже. Річ у тім, що спілкування між двома комп’ютерами передбачає двосторонній процес. Тобто, питання-відповідь (так звана модель клієнт-сервер). А отже, вебсервер, опрацювавши запит, має повернути якусь відповідь. Але куди?

Для цього в повідомленні потрібно вказати адресу відправника. Точно так, як ми робимо на паперових листах.

Добре, додаймо нашу IP-адресу в кожне повідомлення. Так вебсервер знатиме, на який комп’ютер слати відповідь. Але на комп’ютері відправника теж може бути декілька програм, які відправляють запити на різні сервери і очікують кожна свою відповідь. Як зрозуміти, кому (якій програмі) передати конкретну відповідь.

І знову не обійтись без портів. Цього разу ніяких домовленостей (хіба що про діапазон портів, які можна використовувати, щоб не перетинатися зі стандартизованими). Тобто, нехай комп’ютер-відправник вибере будь-який вільний порт і прив’яже до програми, що ініціює запит. В такому випадку в повідомленні окрім самого контенту буде інформація про IP-адресу та порт отримувача, а також IP-адресу та порт відправника. Тепер повідомлення може бути доставлене до програми-обробника на комп’ютері-отримувачі, а відповідь доставлена до програми-обробника на комп’ютері-відправнику.

Хух, ніби все по мережі. Ну, хіба ще пару слів про протоколи)

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

Для цього потрібно формувати повідомлення за певними правилами. І ці правила мають знати обидві сторони — відправник і отримувач. Уявіть двох людей, що намагаються поговорити на різних мовах. При чому, кожен з них знає тільки свою. Перший буде говорити, другий все прекрасно чутиме. Але розібрати і зрозуміти таку інформацію не зможе. І навпаки.

Те ж саме з комп’ютерами. Кожен має знати правила формування меседжа ще до початку спілкування. Типу, перші n циферок — це айпі, далі m циферок — це порт, далі скількись циферок до певної комбінації — це якась потрібна інформація для конкретної програми, і т.д.

Але для різних цілей інформація може бути дуже різною, тому і наборів правил існує багато. Кожен такий набір правил називають протоколом. І так, він теж вказується в повідомленні.

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

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

Тепер точно все. Вийшло довго, але все воно важливе. Йдемо далі.

На цей момент люди вже могли створювати сайти, генерувати скільки завгодно html-документів (і зв’язувати їх гіперпосиланнями), придумувати доменні імена, що легко запам’ятовуються, і всім цим ділом користуватися за допомогою браузера.

Але їм цього виявилось замало. По-перше, юзери могли тільки споживати інформацію, але ніяк на неї не впливати (такий собі read only mode). По-друге, чому це воно все таке статичне? Ніяких тобі анімацій, ніяких реакцій на прогортування, кліки тощо.

Для вирішення обох проблем треба мати можливість задавати алгоритм дій, який буде залежати від певних умов. Ці алгоритми можуть бути абсолютно різними (все залежить від польоту фантазії автора). Десь захочеться змінити колір тексту, коли на нього навели курсором, десь — показати додаткове меню при кліку на якусь картинку. Хтось захоче дати своїм читачам можливість писати коментарі... Одним словом, потрібна максимальна гнучкість. Без написання програм тут не обійтись.

Програмування

Основні елементи комп’ютера — це процесор та оперативна пам’ять. Процесор виконує інструкції (команди), використовуючи пам’ять як джерело команд і даних, а також як місце, куди записувати результати. Тобто, щоб змусити комп’ютер щось робити, треба написати ряд інструкцій, покласти їх в пам’ять і сказати процесору, хай зчитує і виконує.

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

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

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

Тому ідея не просто повертати статичний html-файл, а формувати його на льоту в залежності від певних умов здається логічною. Подумайте самі, кожен файл біографії з нашого прикладу містить багато однакової інформації: хедер, футер, посилання на зміст тощо. Мало того, що все це потрібно копіювати для кожної нової біографії (і витрачати на це місце на диску), так ще й при потребі змінити один символ в хедері прийдеться редагувати всі файли. Знову незручність, яку потрібно виправляти.

Що якби елементи, що повторюються, лежали в окремих файлах? А сервер, отримавши вхідний реквест, запустив би певний алгоритм, який знайде файл хедера, файл потрібної біографії, файл футера, зліпить все докупи і віддасть все той же html, але згенерований динамічно. Браузеру все одно, як сформувався результат, головне, щоб був html.

Інше питання, як юзер міг би передавати інформацію від себе, тим самим змінюючи контент? Наприклад, написати коментар, лайкнути статтю тощо. В принципі, передати — то не проблема. Адже й так передається http-реквест. Потрібно його просто розширити. Але як на це має реагувати сервер?

Коротше, з’явилася ідея. Нехай вебсервер, отримавши реквест, не просто знайде і поверне файл, а запустить певну програму і передасть їй все, що знає про реквест. А та програма проаналізує отримані дані, виконає якусь логіку, сформує вихідний html-рядок і передасть його вебсерверу. А він вже поверне його клієнту за старою схемою.

Яка мова програмування буде виконувати прописану людиною логіку, взагалі не важливо. Нехай це буде Perl. А потім вигадаємо та заюзаємо ще повну торбу інших мов. Наприклад, PHP, ASP.NET, PYTHON, RUBY, JAVA...

З таким підходом сайти отримали величезний поштовх для розвитку. Тепер стало можливо не тільки ставити лайки, а й, наприклад, реєструватися і мати власний кабінет (профіль). Далі все залежить від уяви розробників.

Тут варто ще згадати про бази даних. Отриману від юзера інформацію (і не тільки) потрібно було десь зберігати. Звичайно, можна було менеджити це питання самотужки. Наприклад, створювати файли на диску і в них якоюсь структурою записувати все, що потрібно. Але зберігання, швидкий пошук, надійність, консистентність... даних — то, знову ж, ціла наука. Тому простіше скористатись сторонніми сервісами, які заточені саме на це.

Системи управління базами даних (СУБД), як Oracle чи MySql — якраз те, що треба. Можна довго говорити про переваги та фічі, які вони дають, але ми не будемо :). Нам достатньо розуміти, що програми, які виконують алгоритми, навчили конектитись до СУБД і використовувати їх як сховища для своєї інформації.

Все вищезгадане в даному розділі стосується сервера. Але і від видимої частини сайту теж хотілося більшого.

Оскільки «видима частина» — це те, що красиво малює браузер (базуючись на html), то завдання очевидне: потрібно навчити браузер виконувати логіку, написану розробником. Тобто, браузер сам має стати тією програмою, що «розуміє» певний синтаксис і перетворює його в зрозумілий процесору двійковий код.

Коротко кажучи, так народився JavaScript — синтаксис, який браузер міг розпарсити, застосувати магію, і врешті-решт, виконати видиму або бекграундну команду. Наприклад, розробник міг написати джаваскрипт код, який знайде елемент на сторінці і змінить колір його тексту. Або відслідковувати кліки мишки по кнопці і вставляти нові елементи в будь-яке місце документа. Далі, знову ж, все залежить від фантазії.

JavaScript можна було вставляти блоками в html, або ж писати в окремий файл і підключати в html файлі.

Проміжний висновок

Коротко, як працювали вебсайти (чи вже правильніше — вебдодатки) на цьому етапі еволюції:

  • людина вводить в адресний рядок браузера ім’я сайту (geniusbiographies.com) і натискає ентер;
  • браузер з допомогою операційної системи знаходить відповідну ip адресу;
  • браузер формує http-запит на знайдений IP на порт 80 (якщо юзер не вказав порт);
  • браузер з допомогою операційної системи відправляє запит в мережу;
  • комп’ютер-сервер приймає запит і передає його вебсерверу (базуючись на порту);
  • вебсервер запускає програму, яка буде виконувати логіку, і передає інформацію про запит їй;
  • програма щось робить/ створює/ видаляє і т.д., формує html-рядок з вкрапленнями JavaScript-коду або з вказанням адреси JavaScript-файлу, який треба буде підключити;
  • програма віддає готовий html рядок вебсерверу;
  • вебсервер відправляє http-респонс клієнту;
  • клієнт (браузер) отримує html рядок і рендерить (малює) сторінку;
  • якщо є вкраплення JavaScript-коду, браузер виконує його;
  • якщо є підключення JavaScript-файлу, то браузер робить ще один http-запит вже на JavaScript-файл, отримує і виконує його;
  • коли юзер клікає на гіперпосилання або сабмітить форму (про що ми не говорили, і нічого страшного), то все починається спочатку — браузер формує і відправляє http-запит, але вже, скоріш за все, не в корінь сайту, а на якийсь рядок, розділений слешами (entity/ identificator/ action).

Наша ера

Все, про що я писав вище, відбувалося в часи, коли українці переживали страшну інфляцію, ухвалювали конституцію, вводили гривню та страйкували через рецесію. Тобто, відносно давно.

Що ж далі змушувало людей розвивати веброзробку? Не подобався той факт, що для будь-якої взаємодії з сервером потрібно повністю перезавантажувати сторінку. Тобто, щоб на сторінці оновити одне слово, отримане з сервера, юзер має дивитись, як вся сторінка пропадає, браузер показує лоадер, робить запит на сервер, отримує майже той самий html і заново малює сторінку. Та і сервер через кожну дрібницю мусить генерувати той самий html знову і знову.

Добре було б не чіпати всю сторінку, а десь в бекграунді тихенько робити запит, отримувати мінімальну потрібну інформацію з сервера і обновляти потрібний клаптик на сторінці.

То ж, браузер почали вчити робити мережеві запити й отримувати респонси, не оновлюючи сторінку, взагалі без видимих користувачу ефектів.

Так з’явився AJAX (Asynchronous JavaScript and XML). Не звертайте уваги на «XML» в назві, просто колись інформація передавалась в такому форматі. Ця технологія дозволила значно пришвидшити зміну картинки в браузері і частково розвантажила сервер.

Також не забуваємо, що пристрої, на яких юзери запускають браузери, постійно розвивались і ставали все потужнішими.

Тож, цілком логічно, що люди почали все більше логіки переносити в браузер. За допомогою джаваскрипту в браузері можна генерувати html, змінювати окремі елементи в потрібний час, робити певні обчислення... Ресурсів більшості юзерських пристроїв для цього вже вистачало.

Оскільки код в браузері почав виконувати багато завдань, логічно, що почали з’являтись бібліотеки та цілі фреймворки (jQuery, Backbone.js, Ember.js, React.js...) для полегшення створення додатків. Для серверної частини такі «заготовки» почали з’являтись пачками набагато раніше, і для кожної мови програмування, що використовувалася вебсервером.

Тож, на 2023 рік вебдодаток — це, частіше за все, два додатки. Один — той, що виконується в браузері (фронт-енд), інший — той, що на сервері (бек-енд). За відображення відповідає перший, тому html від сервера йому вже не потрібен. Частіше за все, сервер відправляє просто інформацію (списки, об’єкти) в форматі json. А вже фронт-енд додаток вирішує, як і коли її показати.

Що буде далі, побачимо, але точно щось буде )

Висновки зробіть самі.

👍ПодобаєтьсяСподобалось21
До обраногоВ обраному9
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Коментар порушує правила спільноти і видалений модераторами.

І тут вже точно рандом, тобто, ніякої логіки в їх формуванні немає. Ці ідентифікатори назвали портами. Вони можуть мати значення від 0 до 65535.

так, логіки взагалі ніякої нема

А подекуди, може, й спеціально пишу вигадані речі.

я щиро сподіваюся, що ви позначили ці речі

Вони ніяк не впливають на суть. Наприклад, сайт з біографіями — то вигадана історія. Але вона дає загальне розуміння проблеми/виклику

автор мабуть не в курсі про до інтернетну глобальну сітку Фідонет та й те, що здоровезні об’єми даних досі ганяють через XML, ну то таке..

так, не в курсі. але як це стосується статті, розуміння роботи веб додатків?

у вашому варіанті «історії вебу» зник здоровезний та значний шматок той самої історії, яка до так званого «вебу» й привела.
штош, виросло нове покоління, у них своя історія вебу, ок..
стосується саме тому, що топік статті про історію, а не про

розуміння роботи веб додатків

так, нажаль, таке покоління...
та і про мови ассемблера нічого не згадано, а саме з них починалось програмування... сумно

Usenet ше, кажуть, жива :)

Fido... Якщо не згадати, то і не олдфаг ти/я -)
p.s. Що вмерло — то вмерло, навіщо згадувати?
p.p.s. Не. може ще хтось користується, але який сенс у тому?

Історія цікава у деталях.
Приклад — тег img. Тоді засновник браузеру mosaic (згодом більш відомий як netscape) запропонував включити його до стандарту але його зустріла буря критики типу як це під кодний тип контенту новий тег будемо ще вводити?
Але розробник просто включив його у реліз і відправив у продакшен. Бо народ хотів бачити зображення на веб сторінках, а не купу срачу на форумах з цього приводу.
Браузер набув популярності і народ почав кліпати сторінки із цим тегом
В кінці кінців і W3C були вимушені включити img до стандарту.
Прекрекрасна демонстрація роботи відкритого комьюніті

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