Специализни шаблонца!

Previous Entry Поделиться Next Entry
Отрывочно про веб
Vash
udpn
Добрый вечер+03:00, дорогой читатель. Сегодня я хотел бы поговорить про веб-разработку.

Этот пост был написан довольно давно, и я надеялся его как-то дополнительно причесать, но у меня не хватило сил поднять эту штангу. Так что вот.

Все, наверное, слышали, про такую игру как испорченный телефон. Она описывает именно то социологическое явление, когда изначально правдоподобные данные становятся абсурдно не похожи на оригинал в процессе передачи информации по цепочке людей. А вы слышали доклад Уильяма Танниклифа в Канадской государственной типографии в 1967 году? Я вот не слышал, и даже не смог найти стенограмму. Но почему-то считается, что именно Танниклиф был первым, кто сформулировал принцип разделения представления и содержимого, используемый сейчас для того, чтобы оправдать разделение HTML и CSS.

Если я правильно понимаю, то в этой трактовке за представление отвечает CSS, а за содержимое — HTML. Любой здравомыслящий читатель, способный разделить логичные суждения от собачьего бреда, понимает, к какой категории отнести эту мысль. HTML не отвечает за содержимое.

За него отвечал бы XML, если бы веб вовремя перешёл на XSLT. Да, сейчас ещё есть следы от начала развития XML в вебе: есть XHTML, есть processing instruction xml-stylesheet. Проблема в том, что из JS на странице оригинальный XML стандартным образом получить уже нельзя. Скорее всего, такой подход исключил бы необходимость во всех этих MV*-фреймворках, которыми пестрит веб. "Скорее всего" потому что XSLT Тьюринг-полон, и многие вещи, которые бы мы ожидали видеть происходящими автоматически, вроде сохранения фокуса на input при обновлении XML-DOM, уже не были бы доступны. Всегда можно было бы сделать well-behaved подмножество, но в этом направлении все полимеры уже просраны.

Сейчас я бы мог верстать практически все страницы, используя только div и ещё несколько тегов, всё остальное бы лежало в CSS. Осталось бы некоторое дерево, которое можно было бы считать отвечающим некой реальной структуре данных, представляемых страницой. Но некоторые из этих div мне пришлось бы написать только из-за того, что в CSS просто пока что нет нужных селекторов или свойств. Борьба комитета стандартизации с попыткой вводить ещё больше селекторов и свойств напоминает рыбака, активно черпающего воду из своей прохудившейся лодки. Ничто не сможет исправить тот факт, что CSS это не нормальный Тьюринг-полный язык.

Кстати, даже несмотря на то, что широко распространено мнение, что CSS не Тьюринг-полон, это, скорее всего, не так. Учитывая, что даже крайне простые вещи вроде Rule 110 полны, представляется крайне сомнительным, что в CSS с жирной как тюлень спекой нельзя найти хоть какой-нибудь вычислительный контекст. Комитет стандартизации явно и недвусмыслено с этим борется, конечно, поэтому я потратил добрых 16 часов на поиск такового контекста, подготавливая материал для этого поста, но так и не смог привести рабочий пример. Где-то так же обстоит ситуация с тем, что комитет стандартизации С++ явно пытался сделать так, чтобы порядок объявлений не влиял на семантику программы, но нихрена у них не получилось. Даже частные члены класса можно без всякого undefined behavior воровать. Впрочем, вот, как обстоят дела.

CSS явно сделан так, чтобы пройтись по списку всех правил один раз, не возвращаясь обратно. Типичная идея well-founded recursion. Проблема в том, что это относится только к ядру языка.

  • Во-первых, уже существует реализация Rule 110, требующая пользователя нажимать на кнопочки, чтобы передать состояние, сгенерированное на предыдущем этапе, в следующий. Даже в таком виде это приятно, поскольку подсказывает вектор для исследований.

  • Во-вторых, мы можем воспользоваться селектором focus. Если исчезает поле, на котором стоит фокус, то он переходит к следующему полю, и стили пересчитываются. Если возможно сделать так, чтобы focus циклически перемещался по набору полей, до Тьюринг-полноты рукой подать. Этот подход заработал не так хорошо, как мне бы хотелось, потому что в разных браузерах работал по разному. В Chrome все поля теряли фокус, а в Firefox фокус с точки зрения CSS стоял на невыделенном поле. Разобраться, как это должно работать, я так и не смог. Может, кто-то из вас осилит этот собачий бред.

  • В-третьих, state можно сохранять с помощью hover. Мы просто делаем так, что элемент, на котором сейчас стоит hover, скрывается с глаз долой, и попутно это тянет появление другого элемента, у которого тоже обрабатывается hover. Возможно, это не работает, поскольку текущий элемент под hover'ом это состояние нашей программы, а это количество конечно и зависит от того, сколько элементов у нас есть в исходнике. Но точно это хорошо работать не будет, потому что авторы браузеров решили оградить эпилептиков от говнодизайнеров, у которых на страницах в связи с hover появляется мерцание. (В этом примере попробуйте подвести курсор справа к тексту. Если у вас нет эпилепсии, конечно.) Фикс заключается в том, что hover не пересчитывается, если курсор не движется.

  • Наконец, есть media query, которые позволяют получить ширину окна. Засовывая media query внутрь iframe мы можем получить размер обрамляющего элемента, а это означает, что у нас появляется возможность зависеть от результата вычислений CSS наружного документа. Если при этом возможно было бы настроить потенциально бесконечное количество вложенных iframe, то мы получили бы Тьюринг-полноту. Впрочем, этот подход станет намного ближе, когда появятся element query.

Подводя итог: и почему нельзя было бы просто сделать нормальный язык программирования?

Вернёмся, наконец, к брехне про разделение обязанностей между HTML и CSS. Есть ещё такая точка зрения, что их стоило разделить хотя бы потому, что на клиенте так легче кешировать. Мол, CSS обычно переиспользуется в разных частях сайта. Тут я обычно задаю два вопроса:

  • А что, HTML не переиспользуется?

  • А что, если бы язык был один, то часть определений нельзя было бы закешировать?

Обычно после этих двух вопросов этот аргумент отпадает. Остаётся ещё один, относительно более серьёзный: так что мне, повторять style на каждом элементе, как это делалось в раннем вебе (cellspacing помните)?

А почему бы и нет? Давайте писать стиль на самом элементе. Вас не устраивает, что стили будут встречаться более одного раза? Code reuse падает? А что обычно делают люди, чтобы с этим бороться? Вводят бесчисленные селекторы? Или, может, всё-таки переменные, функции и, на худой конец, классы? Функции в случае HTML представить себе очень просто: все серьёзные веб-разработчики так или иначе уже пользуются шаблонами.

Что вы там раньше использовали, миксины в SASS/SCSS? Не напоминает наследование? Не напоминает про ФВП? Так зачем городить дополнительные абстракции, если всё делается старыми добрыми приёмами императивного и функционального программирования?

JS, конечно, тоже бесит. Этот ублюдок Эйха имеет ровно одну положительную сторону: красивый способ работы с событиями. Всё остальное там омерзительно: и коэрции с перегрузками, и прототипное наследование с return в конструкторах, где нельзя сделать прототип функционального объекта, кроме как стандартный Function, и где не работает нормально typeof, который вообще хорошему языку не нужен был бы. Оптимизации хвостовых вызовов нет. Зато есть JIT, работу которого понимают только разработчики, а почти все остальные программисты, даже из команды Google Closure, продолжают настаивать, что это панацея, и что JIT волшебно решит неразрешимую задачу и оптимизирует любой код.

Бесит то, что вообще что-то нужно писать. Я, например, люблю сидеть за компьютером ночью в тёмной комнате. Сейчас так и делаю, кстати. И вот, передо мной интерфейс ЖЖ с чистым белым фоном, освещающий всю чёртову комнату. Ребята, мне глаза режет. Что, прикажете каждому сайту имплементить систему смены фона?

Подобного рода проблемы решались и ранее. В Windows почти все кнопки, независимо от программы, рисуются одинаково, и это зависит от темы. Строки вроде "OK" и "Отмена" в текущей локализации прописаны в user32. Короче говоря, программе позволяют избавиться от того, что можно настроить и общесистемно.

Почему же тогда сайты не начнут отдавать просто API? Уже просто по описанию функций, которые доступны в API, легко понять, как это должно выглядеть в интерфейсе. Для сложных сайтов можно добавить какие-нибудь легковесные рекомендации по их выводу. Ответов два:

Во-первых, до сих пор нет нормального стандарта на веб-API. REST крайне тяжеловесен и не позволяет делать вызовы с сервера на клиент. WebSocket ничего не говорит про формат отдельного пакета (хотя уже моменты вроде binary/text формата сообщения говорят, что WS это дерьмо, но об этом дальше). Хорошо работает связка WebSocket + ProtoBuf, правда, формат сообщений всё равно приходится описывать. Правильно это выглядело бы просто как одно общее приложение, где лежит код клиента и сервера, и где компилятор сам придумывает всю логику позади вызова c клиента метода, определённого на сервере, и наоборот. Для этого нужно, чтобы клиент и сервер были написаны на одном языке, а генератору нужна статическая типизация. Cерверный JS уже есть, статическую типизацию, наверное, может дать TypeScript.

Во-вторых, уже есть попытки делать что-то подобное. Все хотят пострелять по лягушкам в Германии лазером из космоса со спутника, создавая микроформаты, RSS/Atom, semantic web, pubsubhubbub, OpenID и прочие микроскопически частные способы делиться чем-нибудь относительно структурированным, не замечая леса за деревьями.

Отдельно хотелось бы поговорить про существующие протоколы. Вот вы читаете этот текст. Вы читаете его в исходном виде, или это уже его представление? Вы ведь не можете воспринимать напрямую номера символов, так? Любой текст на компьютере это представление данных в человекочитаемом виде. Тогда объясните, почему у протоколов вроде HTTP тот факт, что они обмениваются "человекочитаемым" текстом, вызывает предоргазменное состояние у их разработчиков? А сделать GUI поумнее нельзя? Ну ладно, вы можете утверждать, что текстового редактора вам достаточно. Ну сделайте стандартный редактор деревьев или стандартизируйте наконец-то формат описания протоколов, чтобы редактор мог подтянуть из файла или сети биекцию бинарного представления и текста, в чём проблема?

Отдельно гадок сам HTTP. Всем известен принцип single responsibility. Почему тогда HTTP занимается запросом страниц, отправкой данных, хранением персистентного состояния на клиенте (cookie), авторизацией, перенаправлениями, отчётами об ошибках всех сортов и ещё кучей всякого дерьма, полное описание которого даже в один RFC не влезло (7230-7237)? Изначально этот протокол вообще должен был использоваться для того, чтобы можно было редактировать страницы веба напрямую в браузере, что потом напрочь забыли, а недавно присунули какой-то нерабочий contentEditable взамен.

Не понятно вообще, зачем делать всякие URL и e-mail текстом, и потом морочиться с его разбором (ой, нерегулярный язык!), если можно это было сделать деревом, и потом его автоматически (де)сериализовать.

Анонимность, криптографические подписи и P2P тоже должны входить в состав новых стандартов веба.

Я вижу только один выход из сложившейся ситуации.

  1. Всё это говно полностью отправляется на помойку.

  2. W3C бойкотируется.

  3. Стандарты начинают разрабатываться с использованием научного метода.

  4. В первую очередь решается, как сделать так, чтобы никакие решения не уходили в legacy. ProtoBuf показывает хороший пример.

  5. В качестве основных языков веба вводятся байткод с содержимым по типу LLVM и статический язык программирования без небезопасных конструкций, но и без GC, JIT и прочих тормозов. В первый компилируются другие ЯП, которые люди хотели бы использовать для веба, второй используется по умолчанию.

  6. Программам на этом языке выдаются разнообразные API, в первую очередь -- canvas, заменяющий HTML.

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

  8. Для существующих браузеров предоставляются расширения, позволяющие ходить в новый веб.

  9. Если кто-то не хочет расширения, тому выдаётся HTML с Asm.js, полученный в результате компиляции чем-то вроде Emscripten.


  • 1
Роскошный текст, спасибо.

Что же касается протобуфа, то, потрахавшись с решениями на тему "как нам в протобуфе переслать изменения в массиве", я перестал смотреть на него как на панацею или вообще как на решение. Так, поделка.

Я на протобафах делал разделение стейта игровой логики для игры среднего размера, и пересылал изменения в графе (сериализация графов поверх протобафов руками тоже, да), поэтому очень хорошо понимаю, о чём вы говорите. Офис месяц слушал вырывающиеся маты, и это при том, что с протобафами непосредственно я не работал, а работал с прослойкой protobuf-net, которая из рефлексии и своего API для схем может всю эту гадость генерировать.

Нужно развивать эту тему просто. Thrift вот есть, там больше всего, но тормозит.

На протобафы я в тексте положительно ссылался один раз, в заключении, где предполагал, что у них неплохо сделана версионируемость: новые клиенты со старыми серверами (и наоборот) можно легко заставить работать. У торрентов с их bencode это выглядит похуже, а в большинстве остальных протоколов просто забивают на тонкую совместимость, и делают втупую, версиями, что мне сильно не нравится.

Edited at 2015-04-15 23:21 (UTC)

Отличный текст, тянет на статью в fprog :)

Ну, покритиковать можно, конечно. Ниже не то чтобы критика, а скорее просто мысли.

Тьюринг-полный нельзя, потому что тогда юниксоиды портируют GTK и будут его везде тулить. Тут кроется ответ: переделку надо начинать с нормального графического стека, от векторной графики до виджетов. Пока такового нет, и даже непонятно, как он будет выглядеть, можно пожить на лигаси. Лет 5 ещё, я думаю, к этому времени все вроде Firefox OS с OpenGL/OpenVG наиграются.

СSS изначально делалcя из-за засилия вонючих b/i/u/font color с копипастой. И с устранением как тегов, так и копипасты, справляется на ура.

В-общем, говорить о том, что избавление от вонючих тегов - это и есть отделение данных от представления, довольно смешно.

Также смешно говорить о том, что HTML - это гипертекст. У нас теперь снова есть гипертекст, примерно соответствующий возможностям HTML 2.0 - это маркдаун и аналоги.

А остальное исполняет функции подобия WPF.

Получается, нужен WPF с гипертекстовыми виджетами :)

И мы опять приходим к мысли, что раз хорошего WPF нет (майкрософтофский довольно удачен ещё по сравнению с), то и делать ничего не стоит.

Ещё, кстати, есть такой идиотизм как мобильные аппы. Где-то половина (из установленных у меня) аппов под ведроид - это просто сайты, задизайненые по нормальным канонам, чтобы говнища на экране поменьше было.

Соответственно, достаточно просто пилить стеки для написания аппов, пока не произойдет конвергенция с вебом. Тогда лигаси-веб станет ненужным.

Можно просто сделать новый браузер и позиционировать его как средство делать кросс-платформенные аппы под win10,ведроид и айос.

Вшпоминается Adobe Air - такой вот "новый браузер как средство делать кросс-платформенные аппы", внутри свой аналог WPF - Flex, крутится на ВМ с байткодом и джитом. И где оно щас?

Идеи разделения представления и содержания изначально уёбищны, так как противоречат человеческому восприятию. Фокус внимания и различение фигура/фон динамичны. "Оформление" может быть основным "содержанием". А может менять смысл фрагмента информации на противоположный.

В техническом плане различий presentation/content также не существует. Шрифты, цвета и отступы могут частично задаваться общей визуальной темой. Но и тексты могут частично задаваться локализацией. А логика пользовательского интерфейса динамически зависеть от параметров устройства или особенностей песочницы (например, браузера).

Найти общие решения, чтобы далее многократно применить их - задача, решаемая в полноценных языках через функции, функции высших порядков и иные удобные абстракции. Каких-то особенные "языки стилей" - самовыражение отдельных фетишистов. Достаточно виртуалочки и хорошего API для Scene Tree (включающего текстовые глифы, вектор, растр, фильтры и видео). А уж какие документы передаются с сервера, в человекочитаемых (Markdown, TeX, ...) и машиночитаемых форматах - зависит от задач приложения/сервиса.

Проблемы старого и современного веба идут от неграмотности стандартизаторов, начиная с самого Тима Б-Л. И даже откровенно бредовый XML был продавлен бюрократами как "мы не умеем писать парсеры, поэтому надо переиспользовать айбиэмовский говнокод от SGML".

Где-то то же самое хотел написать, но забыл. Хороший поинт.

Что-то я представил себе вожделимое... да ну его, знаете.

>Программам на этом языке выдаются разнообразные API, в первую очередь -- canvas, заменяющий HTML.

Угу, и все сайты будут сделаны под дезайгнерские fullHD 1920x1080. А как оно будет на планшете или на топовом монике 4к - всем пофиг.

В гроб.


ЗЫ. уеб-дезайгнерам вообще надо максимально руки выкручивать, чтобы их поделями пользоваться можно было.

Edited at 2015-04-16 11:03 (UTC)

(Удалённый комментарий)
> понятиями, почему надо делать на том уровне, как удобно, вместо уровней атомов и проводков
> для этого дополнительные абстракции и придумываются -- для удобства людей

Всё следует упрощать до тех пор, пока это возможно, но не более того. Очевидно, ты считаешь, что у меня есть желание сделать "более того", но нет. Просто там, где LESS справляется переменными, экстендами, миксинами, параметрическими миксинами и рулсетами, всего лишь одна абстракция, функции высшего порядка, справилась бы без проблем, да ещё и решила бы кучу проблем, которые сейчас не решаются никак. Сейчас же авторы всех этих над-цсс болезненно изобретают велосипеды, вместо того, чтобы наконец-то ознакомиться с матчастью.

> джаваскрипт вебдизайнеры потому и ограничивают для себя библиотеками, чтобы не висло

Теперь ограничивают. Наконец-то допёрли, что в функциональном программировании есть ФВП, и что нужно их добавить. В Haskell этот подход использовался повсеместно в 1998 году.

> но конкретно в данном случае причина -- чтобы было практически невозможно сделать зацикливающуюся вёрстку

Хм, а нет ли тут некоторой закономерности? Ну, там, если мы можем заменить небезопасную рекурсию на ФВП вроде foldl или map, которые не будут зависать, то в случае HTML/CSS нам запретит то же самое делать тот факт, что...

> не хватало, чтобы ещё дырку с рпц клиенты выставляли в интернет

Вебсокеты уже выставляют в Интернет свои задницы, причём проблема с несанкционированным доступом решается аж тем, что клиент первый устанавливает хендшейк с сервером по его доменному имени. Удивление!

> ну хттп этот принцип нарушает, и что?

Да засунь себе в задницу своё "и чо", вот что. Если ты не знаешь, почему этот принцип нужно соблюдать, и не способен даже нагуглить матчасть, прежде чем это обсуждать, съеби нахуй из профессии.

> для удобства программистов, разумеется

Какого, к чёрту, удобства? Почему вместо тупого обращения к полю я должен сначала прогнать поверх этого текста какую-то либу, которую практически невозможно самому написать по RFC, а только потом обращаться к полю?

> вы ж на сях пишете программу не деревом, а "текстом, и потом морочиться с его разбором"

Во-первых, на сях я не пишу. Во-вторых, структура URI позволяет намного более простой способ сериализации, чем "здесь поставим ://, а тут &, а вот там @, because fuck you that's why", и в большинстве случаев нас интересует только бинарная сериализация этого дерева.

> не, не надо!

"Не надо, потому что я тупица и нихера не знаю ни матчасти, ни области применения", я правильно понял?

> да, и ещё экономика регулируется научно, выдавая людям научно обоснованные количества ресурсов для удовлетворения потребностей

И ты можешь это обосновать?

> автор, можете опубликовать формальное доказательство какой-нибудь своей реальной программы?

Я агрессивным троллям в своём жж публикую баны, а не свои личные данные. Иди поучи матчасть вроде bedrock или ATS.

(Удалённый комментарий)
> В качестве основных языков веба вводятся байткод с содержимым по типу LLVM и статический язык программирования без небезопасных конструкций, но и без GC, JIT и прочих тормозов. В первый компилируются другие ЯП, которые люди хотели бы использовать для веба, второй используется по умолчанию.

> Программам на этом языке выдаются разнообразные API, в первую очередь -- canvas, заменяющий HTML.

На этом делается DOM и интерпретатор JS, и все снова счастливы :)

А почему бы и нет? Я не против. Разница в том, что высокопроизводительный компактный код поверх JS делать уже не выйдет. Как бы там с asm.js не старались, это всё не то. Здесь же в случае деградации каких-то распространённых утилит и библиотек всегда есть возможность фолбека до нижнего уровня и реимплементации стека без малейших проблем для пользователя и имплементоров браузеров.

Я бы тоже мог зарядить текст на овер дохуя символов. Но напишу только TL;DR Пишем на типизированном ML-like с Пи-калкулусом, типа эрланга. Этот же язык и XSLT, он же DOM, он же SVG, он же CSS для стилей или rule-based layouts. Есть JavaScript фронт-енд для этого языка. Виртуальная машина LING либо LLVM статическа компиляция с удалением типов. Система Fsub + F:> Ой, да о чем это я, это же как раз то, что мы делаем. Вот те на.

Edited at 2015-04-16 16:46 (UTC)

Но вы ведь поверх существующих технологий это накатываете. Да, я сам мог бы придумать хороший способ накатить на существующий веб такую прослойку. Думаю, довольно быстро пришёл бы к тому же, что и вы (например, с пи-калкулусом я знаком довольно слабо, даже с сахаром).

Речь же идёт про то, чтобы веб наконец-то заменить. Заменять его сразу на то, что вы предлагаете, категорически нельзя. Если впоследствии оказывается, что подход был неправильным, и что-то на нём заимплементить "нельзя" (медленно, пространно или что-нибудь такое), то мы снова сталкиваемся с проблемой, что нужно переписывать веб.

Я же предлагаю сделать веб эквивалентным native приложениям. Прогресс NaCl, кстати, весьма впечатляет в этом отношении. Потом уже можно и эрланги на эту инфраструктуру класть.

про канвас чуть скажу. интеграция сайтов друг с другом и с хост-девайсом-как?

Канвас это просто способ рендеринга. Поверх него можно накатывать что угодно.

1. Интеграция на уровне графики/iframe. Для такой цели вводится стандарт в духе OLE/ActiveX, который позволяет вставлять GUI с чужих сайтов к себе. Если стандарт получается унылый, пишется новый.

2. Семантическая интеграция. Сайтики и клиенты обмениваются друг с другом "бинарными RDFами", рендеринг сайта проходит с помощью клиентских стилей. При отрисовке GUI клиента вообще не интересует, с какого сайта идут какие ноды GUI.

Про интеграцию сайтиков с хост-девайсом я не понял. Если приведёте пример, постараюсь разобраться.

системный фикс

Все беды - от того что один стандарт. Монополия. И вы тоже предлагаете сделать один стандарт (но очень-очень хороший).
А проблему решить можно только системно. То есть. Нужно обеспечить возможность со-существования РАЗНЫХ стандартов. Разных "платформ". Наподобие флэша. Вполне себе платформа, со своими минусами, но можно полностью не то что страничку, приложение собрать не выходя в html. Вот о таком уровне "платформ" я говорю. Silverlight туда же.
И если бы пользователю было легко "посещать" и старые и новые платформы, т.е. если бы прозрачно для юзера было, где он находится - то была бы нормальная конкуренция. Адобе баги не фиксит? Разработчики валят на "Хром-флэш" (придумал название). Там тоже плохо? Идут на сильвер-лайт (тьфу-тьфу-тьфу).
Не должно мешать что платформа не популярна. Нужно чтобы какой-то комитет платформу завалидировал и разрешил скачивать без тысячи предупреждений и всё. (Вот это да, достойная работа для "консорциумов" всяких. А не стандарт один для всех выписывать.)

В итоге что будем иметь? Конкуренцию html+css, флэша, сильвер-лайта, вашего лучшего на свете языка с llvm, и других подобных вещей. А без конкуренции - будем колоться, плакать, но продолжать есть кактусы.

  • 1
?

Log in

No account? Create an account