Критика чистого вебу
Sep. 13th, 2008 04:26 am![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
ichthussДавно збирався викласти свої думки з приводу сучасного стану речей в веб-програмуванні. Ну що ж, поїхали.
Сучасний стан речей в веб-програмуванні мені категорично не подобається. Точніше буде сказати, що мені категорично не подобається сучасне веб-програмування в цілому. Чому — розповідь довга.
Почну, мабуть, з історичного аспекту.
З самого початку веб призначався для розміщення гіпертексту (тексту з лінками, малюнками та ін.) в Інтернеті. Тобто, скажімо, можна розмістити книжку з ілюстраціями і перехресними посиланнями всередині книги та на зовнішні джерела. Мова, яка під ці потреби була розроблена — html — для цих завдань була гарно пристосована. При цьому вона зовсім не була пристосована ні для більш-менш пристойної верстки, ні для динамічної побудови. З часом програмісти зметикували, що, раз віддає клієнту файли програма (веб-сервер), то можна цю саму програму заставити віддавати не лише статичний файл, а і динамічно згенерований контент. Така динаміка була додатковою примочкою, дрібною автоматизацією ручної зміни даних, і використовувалася для таких речей, як лічильник відвідувань, мітки часу на сторінках та ін. Арсенал засобів, які використовувалися, був досить широким, але цілком характерним саме для задач дрібної автоматизації — скажімо, скриптові мови, технологія CGI, яка для кожного веб-запиту утворювала окремий процес операційної системи.
Потім динаміку придумали використовувати для побудови серйозних фрагментів контенту, скажімо, для розділу новин. Це утворило зразу дві проблеми: по-перше, замість вставки в готову html-структуру окремих строк, засоби динамічної генерації контенту почали самостійно будувати структуру html-розмітки. По-друге, обчислювальні потужності, які стали витрачатися на генерацію контенту, стали порівнянні з рештою витрат на роботу веб-сервера. Ця проблема з часом все більше наростала, з неї почали викручуватися різними кривими способами, такими як Fast CGI.
Потім хтось здогадався розробити веб-сервіси. Це було початком кінця.
По-перше, це вимагало все більш віртуозної верстки, складність якої наростала разом з вимогами дизайнерів і клієнтів «зробити красиво». Це поставило проблему динамічної побудови структурованого html-коду у повен зріст: якщо просто побудувати таблицю зі змінною кількістю строк, в залежності від кількості останніх новин — це ще завдання мислиме, то динамічно зверстати сторінку, яка містить верхнє меню, бічне меню, список рубрик, мапу сайту, тексти з коментарями та ще й прогноз погоди в кутку — це вже за гранню.
По-друге, навіть незалежно від складності верстки, html виявився малопридатним для передачі графічного інтерфейсу. Зверніть увагу: якщо зараз вікно деякої програми промальовується більше 1-2 секунд, користувач скаже, що програма гальмує. Виключенням з цього правила є веб-інтерфейс — мало у кого є достатьно широкосмуговий доступ до Інтернету, щоб за 1 секунду відображався будь-який сайт. Це пов’язано з великою кількістю запитів, необхідних для відображення однієї сторінки.
По-третьє, веб виявився абсолютно непристосованим до обробки окремих команд користувача. Фактично, протокол HTTP передбачає повну видачу готової до відображення сторінки у відповідь на кожен запит. Це є нормальним доти, доки запит справді є запитом. Коли ж запит перетворюється на команду, складається безглузда ситуація: у відповідь на додавання, скажімо, коментаря до тексту браузер вимушений перезчитувати повністю весь текст, коментарі і графічні файли оформлення. При тому, що насправді йому не потрібно отримувати інформації більше, ніж просто відповідь, прийнятий коментар чи ні. Клієнт сам може додати коментар до списку.
По-четверте, будь-який сервіс передбачає поняття сеансу — пов'язаної між собою серії віконних форм, які разом складають одну послідовність дій одного користувача. Від початку протокол HTTP не передбачав нічого подібного взагалі. Запити в межах цього протоколу є повністю ізольованими. Сессію доводилось емулювати додаванням фіксованого ідентифікатора сессії в кожен запит. Потім протокол розширили, узаконивши таку емуляцію у трохи іншому вигляді — у вигляді куків.
На цьому проблеми не закінчуються, але залишаються в основному проблеми спеціальні, їх я детальніше розберу в наступних частинах.
no subject
Date: 2008-09-13 10:27 am (UTC)2. Опять же, кто мешает передавать весь интерфейс страницы за раз? Или как поможет какой-либо другой способ организации веб-страниц, если загружать интерфейс только тогда, когда он реально понадобится? Никак.
3. DOM позволяет от этого избавиться. Ни на корре, ни на ютубе я не перезагружаю всю страницу из-за добавления комментария.
no subject
Date: 2008-09-13 12:23 pm (UTC)Я говорю про веб-дизайн у цілому. Проблеми верстки неодмінно відіб'ються на роботі програміста.
>2. Опять же, кто мешает передавать весь интерфейс страницы за раз?
>Или как поможет какой-либо другой способ организации веб-страниц,
>если загружать интерфейс только тогда, когда он реально понадобится?
>Никак.
Інтерфейс будь-якої програми, якою людина користується більш-менш регулярно, має зберігатися локально, якщо не може бути загружений за 0.2-0.3 с.
>3. DOM позволяет от этого избавиться. Ни на корре, ни на ютубе я
>не перезагружаю всю страницу из-за добавления комментария.
Про ajax мова піде далі. Крім того, я розглядаю сучасний стан речей. Зараз мало хто пише веб-додатки нормально, скажімо, з використанням ajax'у для таких операцій, як додавання коментаря. Це не в останю чергу пов'язано зі складністю технічних засобів, які при цьому мають бути задіяні, сама ж ця складність викликана помилками проектування технології, а точніше, застосуванням технології не за призначенням.
no subject
Date: 2008-09-13 08:09 pm (UTC)no subject
Date: 2008-09-13 08:18 pm (UTC)no subject
Date: 2008-09-14 05:29 pm (UTC)И HTML - не предназначена для программирования, это верстка. А верстка - не программирование.
И все те изъяны, которые ты описал, не касаются ни ХТМЛ, ни веб-сервисов напрямую.
>Інтерфейс будь-якої програми, якою людина користується більш-менш регулярно, має зберігатися локально, якщо не може бути загружений за 0.2-0.3 с.
В том и суть, что веб-сервис - не программа.
>Зараз мало хто пише веб-додатки нормально, скажімо, з використанням ajax'у для таких операцій, як додавання коментаря.
Ученые доказали? Я вот на всех современных ресурсах вижу вполне нормальные системы добавления комментариев.
no subject
Date: 2008-09-14 10:00 pm (UTC)>с высокой колокольни можно вот так судить о недостатках.
На момент створення це справді була нормальна технологія, і я про це написав. Застарілою вона була тоді, коли почала використовуватися для створення повномаштабних онлайн-сервісів.
>И HTML — не предназначена для программирования, это верстка. А верстка — не программирование.
Для верстки, до речі, теж не надто пристосований.
>И все те изъяны, которые ты описал, не касаются ни ХТМЛ, ни веб-сервисов напрямую.
Все ще попереду.
>В том и суть, что веб-сервис — не программа.
Якраз суть в тому, що концептуально веб-сервіс — сама звичайна програма. Вона запускається, отримує дані, обробляє їх, зберігає, відображує, передає далі. Різниця тільки технологічна.
>Ученые доказали? Я вот на всех современных ресурсах вижу вполне нормальные системы добавления комментариев.
Ага, британські. Коментарі — лише окремий аспект (хоча і з ним все не так святково). В нормальній технології програмування не повинно, наприклад, щоразу грузитися верхнє меню при виборі іншого повідомлення. Рівно як і бокове.
no subject
Date: 2008-09-21 10:23 pm (UTC)Теперь понил.
>Якраз суть в тому, що концептуально веб-сервіс — сама звичайна програма. Вона запускається, отримує дані, обробляє їх, зберігає, відображує, передає далі. Різниця тільки технологічна.
Как по мне, то наоборот, концептуально - веб-сервис не программа, а вот технологически - это программа. Концептуально - это некоторая служба, доступная через интернет, независимо от того, что ты используешь. И в этом его и преимущества - мне не нужны никакие сторонние программы, чтобы с ним работать. Например, веб-почта гугла (не совсем веб-сервис в каноническом значении термина). Её прелесть в том, что мне не нужно загружать ничего лишнего. Если бы я захотел загрузить что-то дополнительно (интерфейс), я бы мог просто скачать себе почтовый клиент.
Ну и как по мне, программная система должна давать в первую очередь гибкость. Разве сегодняшними средствами нельзя сделать кэширование интерфейса?
no subject
Date: 2008-09-21 11:55 pm (UTC)>а вот технологически — это программа.
Які принципові відмінності для користувача між веб-сервісом та програмою? Я бачу дві: віддалене функціонування та відсутність необхідності встановлення. Однак друге також справедливо для багатьох програм (напр., для тих, що йдуть в комплекті поставки операційної системи). Перше ж, строго кажучи, взагалі не має користувача турбувати, тому що відноситься до деталей реалізації. Тому до написання веб-додатків слід підходити так само, як і до написання локальних програм: абстрагувати інтерфейсний код від функціонального (інтерфейсний код найкраще поділити на модель-представлення-контроллер), бізнес-логіку як від інтерфейсу користувача, так і від інтерфейсу БД, і т.д.
>И в этом его и преимущества — мне не нужны никакие сторонние
>программы, чтобы с ним работать.
На даний момент існує багато технологій, які дозволяють досягти того самого результату — від ява-апплетів до X forwarding. Що характерно, обидві технології дозволяють писати значно толковіший код, ніж PHP. І обидві при правильному застосуванні запобігають десятисекундному завантаженню форми.