Как стать автором
Обновить

Комментарии 138

Автор изобрёл фреймы?..
Нет, автор изобрёл Тьюринговскую трясину. Можете поискать — тут на Excel всякие 3D-движки моделируют и прочее. Вот на этом «ужасе летящем на крыльях ночи» — всё это тоже можно было бы сделать.

Только гораздло кривее и менее безопасно, чем даже на JavaScript. Я всегда считал, что JavaScript — это наказание наше за какие-то грехи. Но после прочтения этой статьи понял, что всё могло быть хуже… гораздо хуже.
Куда уж хуже исполняемого на стороне клиента недоверенного кода? Все эти ява-скрипты нужно было запретить еще в зародыше.
Куда уж хуже исполняемого на стороне клиента недоверенного кода?
Хуже исполняемого на стороне клиента недоверенного кода только код, про который никто не подозревает, что это — код.

А ровно этим бы всё и кончилось. Сделать подобную систему, которая была бы достаточно мощной, чтобы быть полезной и при этом не быть Тьюринг-полной, очень сложно, на самом деле (вот тут интересный список вещей, которые оказались Turing-complete) — и если вы при этом не дадите нормального языка… то люди будут все свои пищалки и перделки реализовывать вот на этом.

Можете себе представить насколько «эффективно» это всё будет работать…
Браузер это вполне доверенный код. А уязвимости можно хоть в просмотрщике изображений сделать.
всё могло быть хуже… гораздо хуже..

Вспомните ColdFusion, хотя нет, лучше не вспоминайте…

Не думаю, что вместо одного запроса, который грузит страницу целиком, отправлять кучу мелких запросов — это действительно лучшее решение. Где-то да, но не всегда и не везде.
Со ссылками на другие элементы у вас очень простые примеры. А что если div name содержит разметку, а не простой текст?
С поисковым запросом тоже вопрос, когда будет отправляться? На каждый новый символ? Как быть с отменой предыдущего запроса? С конкуренцией запросов?
Всё довольно сыро и неоднозначно.

С поисковым запросом тоже вопрос, когда будет отправляться? На каждый новый символ? Как быть с отменой предыдущего запроса? С конкуренцией запросов?
Всё довольно сыро и неоднозначно.
не всё так страшно. практически реализовал отправку на сервер для поиска и возврата набора найденного по методу like %xxx% and like %dddd% and… Проблем с отменой предыдущего нет — потому как данные уже на клиенте и проще сделать новый запрос с повторными данными (теоретически можно сделать задержку перед отправкой нажатой клавиши… но это лишнее) Конкуренции тоже нет…
Время от нажатия клавиши до отображения результатов найденного — от 4 мс до 16 мс при поиске в 30к строках ( при поиске в 10 000 000 максимальное время 4с это когда введённое явно отсутствует ) (возвращается не всё найденное а 15 первых записей). Без fw…

Ну, как же это нет конкуренции. Вот вы говорите 4сек: получается, что когда я печатаю xxx вы отправите 3 запроса по 4 сёк. Что будет, если ответы вернутся в порядке 3-2-1.
Тут на самом деле более глобальный вопрос: вот вы вынесли все это в разметку, повесив реализацию на браузер, кто сказал, что решение браузера единственно верное и как его поведение переопредилить?

из практики — поиск в 10м — это нечто редкое :)… для защиты можно сделать запрет на ввод до получения ответа.
у меня сделано: по двойному клику по ячейки таблицы вызывается веб-компонент и всё внешне выглядит как поиск с выпадающим списком из ячейки таблицы. выбранное можно изменить и сохранить как новое или изменённое. После окончания в ячейке сохранено нужное и соответственно в базе в соответствующей таблице.
даже 100к записей трудно найти в реальных задачах.
с озвученными проблемами я не встретился ни разу.
НЛО прилетело и опубликовало эту надпись здесь
Тогда сразу получаем проблему, что ввод текста будет тормозить. Даже если запросы будут проходить быстро, задержка всё равно будет, и это весьма неприятный эффект, я вам скажу.
можно — не значит нужно, под каждый случай надо сделать свой вариант.
Легко. Вот в русской Википедии 1,5 млн статей, в английской 5,8.
даже там не 10м…
но не надо путать разные предназначения поиска — для поиска в вики, поиск по like однозначно не подойдёт, для этих целей существует «полнотекстовой поиск».
и яндекс и гугл справляются с поиском в значительно большем объёме, но у них и возможности намного больше.

TimsTims
А если сервак подвис или умер, и от него нет ответа, потому-что вы отправили запрос "%%"
для этого существует защита от дураков. А таких если можно напридумывать много, и на каждое если можно дать решение.
Есть столько настроек и потребностей на самые разные случаи жизни, что где-то тебе надо каждое нажатие клавиши ловить (например при совместном редактировании документа),
случаи есть разные, и серебряной пули на все случаи нет, надо под конкретный случай готовить решение. Я привел пример типа заполнения поля в таблице — наподобие как заполнять поле наименование товара в накладной/счёте. Пример совместного редактирования доков можно взять у гуглдок. Там решены многие (если не все) проблемы совместного редактирования и экселевских таблиц и вордовских документов.
При получении ответа нужно либо отобразить выпадающий список, либо сделать редирект, либо показать результаты красиво с картинками
такое решение тоже есть — у поисковых систем. но это решение явно не подойдёт для какого-то конкретного случая — того же — заполнения накладной.
Имея столько настроек, всё это постепенно превращается в… javascript!
без javascript — это просто картинка, как pdf файл.

vvovas
Тут на самом деле более глобальный вопрос: вот вы вынесли все это в разметку, повесив реализацию на браузер, кто сказал, что решение браузера единственно верное и как его поведение переопредилить?
для этого и появились веб-компоненты, с помощью которых и получается «переопределить» поведение браузера. Тот же input можно переопределить используя ShadowRoot и template
Ну, пусть даже будет маленький объем данных, кто гарантирует быстрый ответ сервера? Проблемы с сетью, сервером, базой и у вас что попало в интерфейсе.
проблемы могут быть на любом этапе, и для каждого этапа свои решения — мой вариант был проверен на канале между странами, где у клиента скорость была в килобитах — клиент неудобства не почувствовал, задержек в получении ответа не было.
Это не значит, что их не существует. В продакшне все бывает совсем не так как на dev окружении.
да, но это всё решается — можно поучиться у гугл, яндекс
НЛО прилетело и опубликовало эту надпись здесь
И под каждый вариант делать свой атрибут (какой-нибудь debounce), реализовывать его в браузере и т.п.? Может тогда проще скриптом?
без скриптов не обойтись. в любом случае. Попробуй в ячейку таблицы вставить селект- что получится?
А фронтенду ли не всё равно какой там алгоритм поиска на бэкенде?
конечному юзеру — по-барабану, но чтоб это реализовать надо как-то это организовать, выбрать оптимальный вариант
Вот интересно за что минус? С чем минусующий не согласен?
для защиты можно сделать запрет на ввод до получения ответа
А если сервак подвис или умер, и от него нет ответа, потому-что вы отправили запрос "%%", а стоило бы отправлять при минимуме символов эдак в 5? Есть столько настроек и потребностей на самые разные случаи жизни, что где-то тебе надо каждое нажатие клавиши ловить (например при совместном редактировании документа), а где-то если не было нажатий 2 секунды. А где-то не 2, а 3. И везде по-разному. При получении ответа нужно либо отобразить выпадающий список, либо сделать редирект, либо показать результаты красиво с картинками.
Имея столько настроек, всё это постепенно превращается в… javascript!
Настройки в тегах, логика в js. Хотя, стоп, у нас же так и сделано (правда, никаких $name в клиентской части, поскольку от этого больше проблем).

И к автору — а как изменится тег $name=George без js? Перегрузкой родительского фрейма? Окей.

div src=xxx/$test
(загружаемое содержимое xxx/page_addr) div id=name George /div
/div

div src=xxx/$name
(загружаемое содержимое xxx/George) div id=test page_addr /div
/div

И мы получаем бесконечный цикл, поскольку изменение test ведёт к изменению name, которое ведёт к изменению test. Хоршо, мы придумали грузить страницу только при изменении URL в src, мы молодцы. В основном потому что отпилили возможность рефреша и потому что при наличии двух страниц можно добиться того же бесконечного цикла. Не считая того, что вместо скриптов, которые не всегда трогают DOM, нам при загрузке (помимо дёргающегося рендеринга из-за загрузки кучи тегов по тогдашним каналам) придётся регулярно шерстить DOM и перегружать страницы (сначала у нас не было тега id=name, но была ссылка на него, потом мы подгрузили и надо всё перестроить и подгрузить недостающее). А ещё чтобы на всех страницах не было пересекающихся id (это же не фреймы с разными пространствами имён), загрузка с левых доменов, конечно, страшно безопасна (это вы назвали сына ../../../etc/passwd?) Это сейчас более-менее ясно, а когда создавался стандарт такая штука была бы дырой эпических масштабов.
из практики — поиск в 10м — это нечто редкое :)

Вы просто не работали с такими нагрузками, поиск в большом объеме — не редкость.

для защиты можно сделать запрет на ввод до получения ответа.

Ну, пусть даже будет маленький объем данных, кто гарантирует быстрый ответ сервера? Проблемы с сетью, сервером, базой и у вас что попало в интерфейсе.

с озвученными проблемами я не встретился ни разу.

Это не значит, что их не существует. В продакшне все бывает совсем не так как на dev окружении.
Полагаю, Если бы такой функционал вошел в стандарт, то это повлияло бы на дальнейшее развитие протокола HTTP и браузеров. Такой веб, отличался бы от нашего. Проблемма множественных запросов к серверу там была бы не актуальна. Там были бы свои, не понятные нам, сложности :)
Между прочим, гениально. Реактивность без Реакта (и прочих <подставьте название любимого фреймворка>), сразу декларативно на уровне языка разметки. Одна из тех идей, которые десятилетиями лежат незамеченными прямо перед глазами.
ммм… нет. Идею реактивности в реакте можно было считать гениальной. Хотя не удивлюсь, если до реакта это «уже было», а они просто довели эту идею до ума.

Что касается всего остального — то Вы можете заметить, что стандарты в веб ориентируются на наиболее востребованные технологии. Во времена выхода jQuery она могла столько всего, что не мог «pure js», что все диву давались — «ну как изобретатели js до такого не додумались?». Такой вот «эффект послезнания». Прошли годы и все эти фишки — часть стандарта. Пройдут еще годы и частью стандарта будут шаблоны и реактивность.
НЛО прилетело и опубликовало эту надпись здесь
Мои попытки использовать Flapjax были остановлены тем, что там нельзя сказать «горшочек, не вари».

В JavaScript нет счётчика ссылок, чтоб понять, когда поведение перестало быть нужным, и хватит в него посылать обновления. Нет слабых ссылок, чтоб пока есть подписчик, продолжать знать об этом, а как не стало, так, опять же, хватит посылать в него обновления. И нет способа узнать об освобождении объекта. Пока это остаётся так, ничего хорошего на JavaScript невозможно сделать.

Если б не ограничения JavaScript, был бы интересный проект.
Масштабные красивые решения применительно к суровой практической реальности оказываются нежизнеспособными, к большому сожалению. Через это проходили все — разработчики микропроцессоров, языков, операционных систем и т.д. Всякие ньюансы (которые тут уже начали перечислять) приводят к отклонениям от «генеральной линии» и либо, в лучшем случае, переработке концепции, либо, в худшем — приделыванию всё новых и новых костылей, чтобы эти возникающие ньюансы учесть.
Это, конечно, не значит, что не надо придумывать красивые решения :)
Заснувший после долгой и упорной вёрстки вебмастер просыпается в прошлом 25 летней давности в теле комитетчика w3c. Сразу осознав, какая ответственная миссия свалилась на его плечи, он приступает к активной работе. Сможет ли простой верстальщик из Саратова переломить ход истории и изменить облик всемирной паутины?
Не сможет. Чтобы изменить историю Интернет 25 лет назад, попадать надо куда-то в Microsoft.
Не сможет. Посмотрите на HTML 3.0 как-нибудь. Там было много интересных идей.

Но реализовали, в конечном итоге, не то, что задумали, а то, что смогли.

Тот факт, что выиграл CSS, а не JSSS — уже привело к диким тормозам в сегодняшнем вебе… если бы выиграло вот это — то вместо WWW прижилось бы что-то совсем другое…
НЛО прилетело и опубликовало эту надпись здесь
И вообще не совсем понятно, почему JSSS был бы быстрее, ведь применение всех стилей, наверное, шло бы по тем же правилам
В том-то и дело, что нет. JSSS — он не каскадный, там всё проще. Написали tags.H1.color = "red" — и содержимое всех тегов H1 стало красным. Если что-то «внутри» было до этого зелёным… оно всё равно стало красным.

Это кажется ужасом и страшно неудобным подходом — но сохраняет одно принципиально важное свойство: сложные вещи — и выглядят сложно. А это важно в мире, где большинство фронтенд-разработчиков не то, что не понимают, сколько какие CSS-трюки стоят — они даже не понимают, почему это важно!
Но ведь CSS обычно быстрее JS, а в JSSS я вижу тот самый JS.
Да нифига JS не медленный! Особенно с современными движками. Да, возможно раз в 3-5-10 медленнее оптимизированного современными компиляторами C++ — но сравнимо с тем, что было доступно разработчикам лет 20 назад. Притом, что компьютеры на 2-3 порядка быстрее.

Почему же тогда всё томозит? А потому что простейшие манипуляции с DOM требуют пересчитывать и переотрисовывать всю эту многоуровневую CSS-конструкцию. Когда у вас задача, с которой не тормозя справлялся самый первый PC на 4.77MHz, а сегодня требуется больше 10% ресурсов многогигагерцового процессора… это «вот оно».
НЛО прилетело и опубликовало эту надпись здесь
Там это всё таки был баг браузера в частности и протекающие абстракции современного слоёного пирога веба вообще.Извините — но баг браузера заключался как раз в том, что что он не сумел закешировать результат сложных вычислений. А вот само кеширование и прочее — требуется именно из-за самой структуры CSS. Каковая и является «самой протекающей абстракций» в современных браузерах…
НЛО прилетело и опубликовало эту надпись здесь
CSS заметно сложнее JSSS, поэтому и требует кеширования, ничего удивительного.
А вы напишите страницу на JSSS со стилями сопоставимыми с современным CSS. Попробуйте руками всё это анимировать и раскрасить. Очень хочется на это посмотреть.
НЛО прилетело и опубликовало эту надпись здесь
Потому что у JS один поток на страницу. Сейчас конечно появились различные ServiceWorkers, но работа с DOM всё равно однопоточка.
Что хоть как-то ограничивает современных ваятелей. Вот объясните почему какой-нибудь редактор конца XX века спокойно работает на процессорах типа 486 на 100MHz, а для редактирования простеньких формочек одного ядра на 3-4GHz уже не хватает? Только не надо про совместное редактирование документов: когда его добавили в AbiWord, его потребности в ресурсах особо не возрасли.
НЛО прилетело и опубликовало эту надпись здесь
Вопрос не в ОС, браузерах и фреймворках. Вопрос, как очень точно заметил alsoijw, — в анимациях и прочих «модных, стильных, молодёжных» перделках. Если бы задача не заключалась на 99% в том, чтобы сделать очередной редизайн и получить за него премию, а в том, чтобы решить реальную задачу (сделать банковский перевод, откомментировать статью и прочее) — то не было бы ни проблем с сайтами на много мегабайт ни с многопоточностью… может пресловутой модели 5150 и не хватило бы — но какого-нибудь 386DX — уже почти наверняка…
Не согласна, но написали хорошо! :)
Позанудствую, как всегда ). «The HTML we never had» != «HTML, который мы потеряли», даже по смыслу.
НЛО прилетело и опубликовало эту надпись здесь
HTML, которого у нас никогда и не было )
> не получили
«Упустили»
Автор поста и автор статьи — один и тот же человек, можно считать это авторским переложением.
Ну это же отсылка к том хрустобулочному фильму девяностых, где рассказывалось, что в Российской империи все-все были дворянами, слушали Шопена и вглядывались в пузырьки шампанского
«HTML, который мы потеряли» — король умер, да здравствует король.
Всплакнул.
В конце 96-го года я вышел из фидо и в блокноте сделал первый свой homepage и разместил его на популярном (и вроде единственном в то время) бесплатном хостинге weekend.ru, адрес выглядел как-то похоже на /users/dandy/
Помню одно из главных требований — страница не должна весить >100кБ. Народ тогда сидел на usr robotics 14400, диалап-линк был нестабильный, пинг мог спокойно уходить за 1000мс, зато tracert показывал всего два-три промежуточных сервера до М9.
А потом моя кошмарная homepage попала на обзор к Носику… и в те сутки мою страницу посетило несколько сотен человек, я думаю это было половина рунета -)! Это была вершина успеха.
А потом вышел frontpage. И сразу с ним — MS Chat и mIRC. Я в мирке сидел сутками.

Я помню синтаксис HTML2 назубок до сих пор и думаю последними моими словами будут
<body>
<h1>end of cycle</h1>
</body> 

HTML Forever!
А потом моя кошмарная homepage попала на обзор к Носику… и в те сутки мою страницу посетило несколько сотен человек, я думаю это было половина рунета

Хабраэффект девяностых?

Идея с src отчасти реализовывалась через ssi, но его постепенно вытеснил php.
В целом не очень понятно зачем вкрячивать логику (name $george) в html, т.к. это нарушение принципов mvc в какой-то степени.
НЛО прилетело и опубликовало эту надпись здесь
ИМХО, главная проблема веба — отсутствие разделения между кодом и данными. Когда всё склеивается в один текстовый файл (в лучших традициях #include) и затем бедный браузер обязан выполнять
бедный браузер обязан выполнять
<script>
где бы он ни встретился… Это как если бы в JS или Python функции print не было, а вместо неё был бы eval, который бы вёл себя иногда как eval, иногда как print, в зависимости от параметров.

P.S. Яркая иллюстрация: habr обрезал мой первый комментарий и я не сразу понял, что это потому, что я указал неэкранированный
<script>

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


К тому же, даже сейчас многие экономят соединения, упаковывая и укрупняя загружаемые модули. А тогда можно было увидеть, как строчки добавляются, пропихиваясь через распоследнюю милю.


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


А потом, когда нибудь, мы обернётся, переосмыслили прошлое… Но будет это в нерабочее время. А пока — только вперёд, ни шагу назад!

Как-то на одном из проектов лет 5-6 назад была чудо-разработка в виде атрибута, по которому в тэг по ссылке из атрибута грузились данные.

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

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

Хорошо, что в статье приводятся сравнения с таблицами, приходится часто использовать гуглотаблицы, собственно на средней таблице время обновления при внесении изменения в поле, от которого зависят другие поля, может быть довольно заметным. А если в документе карусель из зависимых тегов с подгрузкой данных по ссылке, предсказуемость состояния такого документа будет очень быстро теряться, либо же будет страдать отзывчивость, особенно в случае использования функций для вычисления чего-то прямо в HTML.

Мне нравится в целом посыл и идея, с одной стороны это может выглядеть как React, встроенный в HTML, с другой может использовать схемы а-ля xml для расширения функционала, но куда лучше это всё будет работать, если данные будут разделены с представлением и их обработкой будет заниматься бизнес логика приложения, а не метатэги в HTML.
JavaScript можно оставить, но в большинстве случаев он будет просто не нужен. Когда в последний раз у вас была необходимость использовать макрос в электронной таблице?
Сразу же, когда нужна интерактивность.

А потом останется добавить , , , <array.map> ведь ждать сервера на каждый символ, на каждое движение курсора будет долго. Так HTML и станет языком программирования.
Парсер съел теги if else array
Разрешите напомнить, что HTML (т.е. гипертекст) это не только веб, но есть и офф-лайн приложеия. Нпр., предпочитаю, когда help какой-то программы раскрывается в моем любимом браузере, и сам так делаю в своих программах, нпр. ИМХО с точки зрения офф-лайн использований предложения статьи были бы полезны.
Мне больше нравился xhtml, но его благополучно похоронили в угоду html 5
Пока не похоронили. Никто не мешает писать HTML 5 в соответствии с XHTML.
Чем нравился? Какие преимущества он вам давал?

xhtml легко обрабатывается любыми существующими инструментами понимающими xml.
Валидация…
Извлечение данных…
Преобразование с использованием xslt. Все делается легко и непринужденно.


А вы вот ответьте, плиз: кому реально нужен кривой неоднозначный синтаксис HTML? Один тэг надо закрывать, другой не надо… И чем был бы хуже XHTML5?

За счет автозакрытия тегов браузер может начать рендерить страницу еще до окончания загрузки. Если сделать парсер строгим, то он не сможет ничего распарсить до тех пор пока не придет последний закрывающий </html>

НЛО прилетело и опубликовало эту надпись здесь
Медленный интернет?
НЛО прилетело и опубликовало эту надпись здесь
Как, если документ ещё не валиден, пока все теги не закрыты?
НЛО прилетело и опубликовало эту надпись здесь

Так он с самого начала невалиден. Вот есть цепочка:


<html>
  <head>
    <title>Title</title>
  </head>
  <body>

И пока не придёт завершающее </body></html> — браузер ничего, кроме заголовка, показать не сможет. Или Вы предлагаете создать "белый список" тегов, которые можно позволить себе закрывать автоматически, а все остальные валидировать строго?

кроме заголовка, показать не сможет
Заголовок тоже не сможет — html открыт, но не закрыт. Он реально невалиден с первой же строчки, пока не придет последняя.
браузеры сами могут вставлять отсутствующие закрывающие тэги.
И чем это будет отличаться от того, что есть сейчас — с официально нестрогим парсером?
Это и есть работа этого парсера.
по поводу валидности с тегом body
webref.ru/html/body
Открывающий и закрывающий теги на веб-странице не являются обязательными, однако хорошим стилем считается их использование, чтобы определить начало и конец HTML-документа.
webref.ru/html/html
Элемент является контейнером, который заключает в себе всё содержимое веб-страницы, включая элементы и . Открывающий и закрывающий теги в документе не обязательны, но хороший стиль диктует непременное их использование.
Спасибо, капитан, вот ваша лодка!


Если влезаете в обсуждение, то прочтите не только последний комментарий. Мы обсуждаем парсер xhtml 5

А вы цитируете о парсере html.
НЛО прилетело и опубликовало эту надпись здесь
Ошибка может быть ниже текущего элемента
Ресурс, загружаемый по адресу, указанному в URL компонента, является обычным HTML файлом. Он может содержать переменные, функции, а также ссылки на другие компоненты. Такие веб-компоненты могут быть легко использованы не только на одном веб-сайте, но и в качестве стандартной библиотеки в Интернете.

Чем-то напомнило Razor и вставку PartialView в шаблоне, это довольно удобно для внутреннего использования в проекте, но насколько было бы безопасно использовать библиотеки из Интернета? Сразу вспоминаются проблемы в проектах, использующих сторонние js-библиотеки, в которых внезапно решили что-то поменять и сломали.
У Эксплолера была очень похожая технология, можно погуглить слова datasrc/datafld, вот тут я писал «песню про пиво» с использованием этой штуки: bolknote.ru/all/1642
Поправьте меня пожалуйста, но вроде XML с XSL уменют это делать?
Насколько я понимаю, там задом наперёд надо развернуть логику, и тогда начнёт получаться.

В норме один XML, на который указывает URL, подгружает для своего отображения множество XSLT.

Но если мы хотим разбросать контент по множественным файлам, то контент должен быть в XSLT, а XML должен быть только для затравки. Помню, хотел, чтоб у меня был сайт именно на XSLT, и вот именно так, как написал. Несколько лет спустя, когда прижало, сделал сайт просто в блокноте. А потом, когда познал SEO, и что поисковики все эти XSLT-дела не оценят, и вовсе забил.

Ещё несколько лет спустя наткнулся в Сети на одного товарища, который придумал альтернативное представление XML, назвал его YML, применил его к XSLT, назвал его YSLT, и получилось нечто напоминающее функциональный язык. На этом YSLT он написал YBlog2.

Это все хорошо, но такое ощущение что автор не осилил ангулар и решил написать свой велосипед. Ничего с опытом пройдет

Ага, вот я открываю сайт, вижу список серверов. Нажимаю на 'open console', у меня открывается новое окно, в котором графический десктоп установленной ОС. Всё это в браузере с нулём флеша или java.

Какой частью html2 это должно было быть реализовано?

Браузер — программа для отрисовки текста с определённой разметкой, и отображение «графического десктопа установленной ОС» не должно входить в его задачи. Для этого есть куча VNC-клиентов на любой вкус (да и не только VNC)

Альтернативы браузеру не взлетели. И это хорошо. Или вы предпочитаете ставить по приложению для каждого сайта с проприетарным api прибивающий гвоздями даже там где это не нужно? Сила веба в кросплатформенности и отсутствии необходимости что-то куда-то ставить. Мне совершенно не нужно ставить гугл карты на свой пк, чтобы раз в пол года что-то посмотреть. Мне совершенно не нужно выкачивать весь репозиторий, ставить IDE, чтобы посмотреть пару строчек кода с github или попробовать какой-то язык программирования. Мне совершенно не нужно ставить клиент ютуба, скачивать видео для просмотра какого-то обзора.
Сила веба в кросплатформенности и отсутствии необходимости что-то куда-то ставить.

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


С вашими «мне совершенно не нужно» любой, естественно, согласится, но, опять же, для этого не обязательно брать именно веб. Просто так получилось, что взлетел именно веб. И это плохо, потому что альтернативные, более адекватные платформы теперь даже пытаться сделать смысла нет — все продолжат сидеть в переполненном костылями вебе.

И в чём будет отличие этого не веба от текущего веба? И главное как в этом не вебе решить озвученные мной проблемы?

Так же, но без костылей. HTML — язык для разметки текста, CSS — язык для раскраски текста, JavaScript — игрушечный язык для перекраски текста по каким-то событиям, в котором при сложении массивов получается строка, и попытки строить на этом приложения порождают ужасных тормознутых уродцев с костылями, а в конкретно JavaScript ещё и всяким гуглам приходися изобретать сверхумные сверхсложные JIT-компиляторы типа V8 и учить всех не использовать какой-нибудь arguments, чтобы оптимизации не полетели к чертям.


Заменить бы HTML/CSS на условный Qt или аналог, JS на WASM, существующие API адаптировать под нужды именно приложений, а не разметки текста, довести до ума многооконность, добавить трей и всё такое — и была бы конфетка, а не то что сейчас. А если разрешить нативный код для доверенных приложений (по возможности с запуском в песочнице, разумеется), то можно было бы смело портировать всякие фотошопы и сонивегасы на такую платформу.


А пока веб-версия UT99 тормозит сильнее чем нативный Doom 2016 и пока Electron-версия Skype тупит, тормозит и жрёт ресурсы сильнее старой доброй Delphi-версии — такая платформа никуда не годится.

Еще один стандарт, только без костылей. Да-да, конечно: xkcd.com/927
пока Electron-версия Skype тупит, тормозит и жрёт ресурсы сильнее старой доброй Delphi-версии — такая платформа никуда не годится.
Не знаю на счет электронной, но веб-версия (web.skype.com) работает значительно стабильнее, чем десктопная. У меня 600 контактов и веб-версия просто запускается, а установленная — тупит, думает, подвисает, пару раз падает. И дело не только в новой версии. Такое уже несколько лет
Так же, но без костылей.
Складывается впечатление что где-то есть тайная лига сумрачных гениев поклявшихся в ненависти ко всему миру имевшему неслыханную наглость их обидеть и придумывающие коварные козни для изысканной мести.
JavaScript — игрушечный язык для перекраски текста по каким-то событиям, в котором при сложении массивов получается строка
Огромное спасибо js за кросплатформенную среду и понимание того что можно самостоятельно взять и сделать свой собственный компиялтор. Тем более что делать компилятор гораздо проще в js чем в нативный код. Тут и сборщик мусора есть и стандартную библиотеку можно повзаимствовать. И hello world влезет в 100 байт.
Заменить бы HTML/CSS на условный Qt или аналог, JS на WASM
Вот только почему-то wasm yew TodoMVC собранный со всевозможными оптимизациями весит почти 400 Кб, а отладачная версия чего-то подобного, но уже на Elm собранная без оптимизаций даже до 300 Кб не дотягивает. А если сжать, то и в 50 Кб влезет.
А если разрешить нативный код для доверенных приложений (по возможности с запуском в песочнице, разумеется), то можно было бы смело портировать всякие фотошопы и сонивегасы на такую платформу.
Только не нативный. Нативный он уже и так есть и он уже итак прибит гвоздями к архитектуре процессора и операционной системе.
А пока веб-версия UT99 тормозит сильнее чем нативный Doom 2016 и пока Electron-версия Skype тупит, тормозит и жрёт ресурсы сильнее старой доброй Delphi-версии — такая платформа никуда не годится.
А у них стояла задача оптимизировать Electron-версию? Есть подсказка: если приложение на Delphi в 2007 попытается воспользоваться 1 Гб памяти, то есть вероятность того что оно упадёт у его разработчика и он начнёт его оптимизировать. А если это произойдёт сейчас, то разработчик этого либо просто не заметит, либо купит планку памяти, либо попросит денег на рефакторинг, где ему откажут. У людей банально нет денег на рефакторинг, им бы в текущие версии костыли вставлять. Даже у всяких гуглов.

emacs между прочим тоже написан на интерпретируемом языке. И наверняка в то время когда памяти было мало его считали неторопливым монстром. Зато сейчас по сравнению с Electron он выглядит быстрым и компактным.
Дык эта. EMACS == Eight Megabytes And Constantly Swapping. Да, когда-то 8 мегабайт считались очень большим объёмом памяти.
Огромное спасибо js за кросплатформенную среду

Java вы проспали?


можно самостоятельно взять и сделать свой собственный компиялтор

LLVM вы тоже проспали?


чем в нативный код

Байткод вы тоже проспали? Опять вы поделили мир на чёрное и белое, а я не просто так упомянул wasm и теперь уже Java и LLVM


Тут и сборщик мусора есть

Не нужен, см. Rust. А если и нужен, то только в качестве опциональной штуки для ленивых погромистов


Вот только почему-то wasm

Ну значит не wasm, а что-нибудь другое, его я привёл просто как пример


А у них стояла задача оптимизировать Electron-версию?

Вот примерно поэтому я считаю современный мир говном


У людей банально нет денег на рефакторинг

А у меня банально нет денег на оперативку


Даже у всяких гуглов

Да, испоганили гуглопочту просто так на ровном месте


emacs между прочим тоже написан на интерпретируемом языке.

Ещё одно наглядное доказательство того, что современный веб как платформа для приложений никуда не годится

Java вы проспали?
Java аплеты были но не взлетели. Внезапно.
LLVM вы тоже проспали?
А исполнять что будет? LLVM хорош скорее в плане оптимизации и количестве поддерживаемых архитекутр. До цели wasm в веб страницу засунуть было нечего.
Байткод вы тоже проспали?
А какой байткод одинаково хорошо понимает современный смартфон и какой-то старый пк, да ещё и прямо в браузере?
Не нужен, см. Rust. А если и нужен, то только в качестве опциональной штуки для ленивых погромистов
Писать на системном языке далеко не всё удобно.
Ну значит не wasm, а что-нибудь другое, его я привёл просто как пример
И как же так страшный javascript выиграл у wasm? Наверное просто повезло.
А у меня банально нет денег на оперативку
Вот при составлении ТЗ и запишите. Разумеется если у вас хватит денег на тех кто умеет оптимизировать.
Java аплеты были но не взлетели.

Про Java апплеты я ничего не говорил. На апплетах свет клином не сошёлся, а сама идея Java очень даже хорошая


А исполнять что будет?

Найдётся кто-нибудь. JavaScript же исполняет кто-то?


А какой байткод одинаково хорошо понимает современный смартфон и какой-то старый пк

Вот и задача — изобрести его


да ещё и прямо в браузере?

Вы слишком зациклены на вебе


Писать на системном языке далеко не всё удобно.

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


Наверное просто повезло.

Ага.

а сама идея Java очень даже хорошая
Важна не только идея. Важна популярность и простота. Именно популярность java дала бы кросплатформенность большого количества софта. Я не прошу драйвера принтера на java, но очередной платформер на java сделать можно. Хотя в то время платформер делали скорее под winapi. Во время хвалёных скайпов на делфи. Очевидно что каждый килобайт памяти берегли.
Найдётся кто-нибудь.

Вот и задача — изобрести его

Именно по этой причине javascript и завоевал популярность. Нет нужды ждать неопределённо долгое время. И потом, за то время пока вы изобретаете замену html + js + css ускорится ещё на определённое количество процентов.
А писать всё подряд на прототипно-ориентированном интерпретируемом языке без нормальной типизации тоже так себе идея
Создать язык компилируемый в rust и значительно улучшающий его гораздо сложнее чем типизацию для js.
Ага.
Вот беда, стандартная библиотека js уже есть в браузере, а wasm должен таскать её внутри.

Вы во всём правы, и именно это меня и печалит


Ну кроме разве что этого:


Создать язык компилируемый в rust

Не нужно так делать, нужно создавать язык, компилируемый в какой-нибудь байткод. Rust компилируется в LLVM IR, а уже оттуда во все нужные платформы, в том числе wasm при желании


wasm должен таскать её внутри

Решается нормальными средствами доставки библиотек и нормальным же кэшированием. Тут в комментариях уже всплывали отдалённые намёки на это в виде src2, magnet и integrity

А еще автор забыл, что HTML в значительной своей части предназначался и для оффлайна тоже. Как вы представляете себе <div src… /> в оффлайне?
Ну очевидно так же как и <img src… />
Я не понимаю другого. Откуда всеобщая уверенность в безотказности всего и вся? Откуда эта чёртова дилемма «грузить jQuery с гугла, задействуя кэш — или со своего сервера, будучи независимым»? Почему до сих пор не такой вот стандартной конструкции:
Заинтриговали)

<script src1="..." src2="..." ... srcN="..." integrity="..."/>
411, спасибо, пофиксил.

Весёленькая будет отладка, если на разных src откажутся слегка разные файлы.

А если уж мечтать, то об src=«magnet:DEADBEEF»
С одинаковым sha256, который и указывают в integrity? Нет, можно такую конструкцию и без integrity, но это ССЗБ.

Круче было бы отдельный формат ссылок, управляемый неким менеджером ресурсов.
Ссылка старого формата, в веб — для обратной совместимости или для ссылки на чужие ресурсы, где всё равно нет второго источника.
Ссылка нового формата:


<script src="resource://..."/>

Подхватывается вашим менеджером ресурсов, у которого есть конфиг с альтернативными урлами, чексуммой и вплоть до magnet-ссылки (если вдруг централизованный интернет окончательно рухнул).
В принципе, почти можно реализовать подключаемой библиотекой. Только с доступом к кэшу браузера проблемы.

НЛО прилетело и опубликовало эту надпись здесь
Возможно, этот proposal вас заинтересует: github.com/WICG/import-maps
Там как раз описывается что-то похожее
Разделение консернов. Разметка не должна заботится о поддержке фаллбек источников (хотя никто не мешает это водрузить на тот же JS). Направте на проксю и рулите там, или напишите код клиента.
Разметка не должна заботится о поддержке фаллбек источников

Во-первых, речи а фаллбеке как таковом пока нет. Разметка указывает, что два источника можно использовать равноправно. Браузер решает, из какого именно загружать, и как он это решает — действительно не дело разметки.


Пример 1.
src2 есть в кэше, а src1 нет? Грузим src2 из кэша!


Пример 2.


<script src1="domain1.com/..." src2="domain2.com/..."  integrity="..."/>
...
<script src1="domain3.com/..." src2="domain2.com/..."  integrity="..."/>

Грузим c domain2.com, потому что это одно соединение вместо двух. Или, наоборот, грузим с 1 и 3, потому что так оно распараллелится.


А если канал не жалко, а вот скорость загрузки существенна — можно и со всех адресов грузить.

Чтобы браузеру решать, 1) ему надо знать что вы их сгруппировали 2) иметь критерии по которым решать. № 2 есть в кеше, но кеш старый. № 1 нет в кеше но грузится быстрее чем № 3, потому что закеширован на проксе. Но погодите, № 3 оказывается тоже есть в кеше, но к сожалению CORS политика не позволяет загрузить. А там по соседству такая же группа сорцов, но 1 и 3 поменяны местами.
Не много ли? Это был бы тихий ужас.

Не много.


№ 2 есть в кеше, но кеш старый.

Очень старый, алгоритм sha256 поменялся?


иметь критерии по которым решать

И это дело браузера. Может вообще не решать, а грузить первый, если не смог, то второй и т.д. Но тогда такой браузер будет медленным и от этого менее популярным.


надо знать что вы их сгруппировали

В смысле "сгруппировали"? По доменам или по элементам? Обе группировки видны невооружённым глазом, браузеру ничего специально сообщать не нужно.

Очень старый, алгоритм sha256 поменялся? — очень старый, это значит что вам не подходит. А за вас решает броузер, какую версию использовать.

--И это дело браузера.-- сколько браузеров, столько стратегий, да. Полиномиальный взрыв кейсов.

--Обе группировки видны невооружённым глазом--
Ну и пытаетесь отладить, заглядываете в нетворк панель, и видите запросы. Как будете разбираться, какой из групп что загрузилось?
А за вас решает броузер, какую версию использовать.

https://developer.mozilla.org/en-US/docs/Web/Security/Subresource_Integrity


Нет, это я решаю, какой алгоритм использовать для хэширования. Ситуацию, при которой какой-то алгоритм уберут из браузера, считаю маловероятной.


Cколько браузеров, столько стратегий, да. Полиномиальный взрыв кейсов

… не имеющий ни малейшего отношения к разметке. Когда я пишу такой HTML-код, мне всего лишь надо, чтобы загрузился один, любой из указанных файлов. Какой — меня не интересует вообще. Как там разработчики браузеров будут угадывать, что быстрее и что доступно — мне тоже неинтересно.
"Здесь надо выполнить скрипт/показать картинку с таким-то хэшем, найти её можно по одному из следующих адресов". Всё, на первом месте стоит содержание, и только потом — вопрос "где брать".

— Когда я пишу такой HTML-код, мне всего лишь надо, чтобы загрузился один, любой из указанных файлов. — я же не спорю, интересно вам или нет. Будет интересно, что вы будете делать, если загрузиться не тот, или вообще не загрузится (по миллиону причин). И когда адреса-ресурсы формируются динамически, и хеши прописывать тут никак не поможет. Ладно, я все сказал вроде.
если загрузится не тот

А какая разница? Хэши одинаковые, значит, и файлы одинаковые. А с какого адреса он грузился — мне всё равно.


вообще не загрузится (по миллиону причин)

То же самое, что и сейчас. Напомните, делал ли что-нибудь гитхаб, когда его CSS-файлы не грузились из-за блокировок?


И когда адреса-ресурсы формируются динамически, и хеши прописывать тут никак не поможет

Динамически генерируемый Javascript-код? Или CSS? Это скорее редкость, разве нет?

пытаетесь отладить, заглядываете в нетворк панель, и видите запросы. Как будете разбираться, какой из групп что загрузилось?

Вопрос лишь интерфейса — рядом с запросом показывать информацию о группе, которой этот запрос принадлежит, и ссылку на HTML-элемент, который инициировал.


К AJAX со товарищи моё предложение, очевидно, отношения не имеет.


Вот, кстати, как такие вещи реализуют с картинками:
https://developer.mozilla.org/ru/docs/Web/HTML/Element/picture

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

Для разных разрешений я не предлагаю, это просто пример "множественого источника", который уже есть в стандарте.


Если поделитесь хорошей библиотекой, позволяющей реализовать резервирование источников статики — буду благодарен.


А тот факт, что Вам приходилось реализовывать резервирование вручную, только подчёркивает необходимость закрепления в стандарте.

ИМХО гораздо логичнее собрать всю эту кучу кода в один файл, выкинуть неиспользуемые функции и сжать. Работает и уже сейчас. В итоге размер сборки может легко быть меньше пустого фрейморка, не содержащего нашей логики. Всё равно использовать все плюсы разделяемых библиотек в вебе не получается. Исправление багов/уявимостей одинакого меняют хеш, плюс из-за исправления бага может какой-то костыль отвалится. Кеширование библиотек? Это хорошо работает только когда на сайтах используются одни и те же библиотеки. Кроме того это устранит ситуации когда десяток библиотек загружаются ради одной функции.

WordPress, однако, ЕМНИП, так не делает. Почему? Да потому что на каких-то страницах нужна только jQuery, а на каких-то ещё и плагин-галерея. А на каких-то ещё какой-нибудь слайдер или кнопка "вверх". Или облако тэгов, красиво летающих по сложным орбитам. И тут либо каждый раз грузить "суперконгломерат", зато с возможностью его закэшировать (в рамках данного сайта), либо бить на мелкие куски. В первом случае страдает пользователь, который зашёл на сайт первый раз — например, из поиска.


выкинуть неиспользуемые функции

А не подскажете инструмент, который справляется с этой задачей для (напомню, динамически типизированного) JavaScript?


В любом случае, всё вышесказанное относится к оптимизации времени загрузки. А изначально речь шла именно о резервировании.

НЛО прилетело и опубликовало эту надпись здесь

… и всё равно не решает проблему резервирования "редких" библиотек, а также CSS, иконок и шрифтов.


И так ли уж нужны бандлы в светлом мире HTTP/2, SPDY, etc. ?

НЛО прилетело и опубликовало эту надпись здесь
Не вижу проблемы скачать себе на сайт, если используется действительно малопопулярная либа. Доступен сайт — доступна и она.

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

НЛО прилетело и опубликовало эту надпись здесь
WordPress, однако, ЕМНИП, так не делает. Почему?
Не умеет же! Плюс огромное количество пережитков прошлого(legacy) полагаю.
Да потому что на каких-то страницах нужна только jQuery, а на каких-то ещё и плагин-галерея. А на каких-то ещё какой-нибудь слайдер или кнопка «вверх». Или облако тэгов, красиво летающих по сложным орбитам.
jquery не обязывает и даже не призывает писать код в рамках одного приложения. Это просто лоскутное одеяло к которому время от времени пришивают очередной кусок. Соответственно и разобраться потом в этой простыне кода будет не просто.
И тут либо каждый раз грузить «суперконгломерат», зато с возможностью его закэшировать (в рамках данного сайта), либо бить на мелкие куски. В первом случае страдает пользователь, который зашёл на сайт первый раз — например, из поиска.
Зависит от объёма сборки. Если сборка будет маленькой, то пользователь даже и не заметит. Я не даром сказал про оптимизацию.
А не подскажете инструмент, который справляется с этой задачей для (напомню, динамически типизированного) JavaScript?
Всё просто — надо отказаться от динамической типизации. Вот как это получается у Elm.
В любом случае, всё вышесказанное относится к оптимизации времени загрузки. А изначально речь шла именно о резервировании.
А тут и не надо резервировать. Наш сайт жив — скрипт загрузился, сайт упал — уже всё равно ничего не сделать.
НЛО прилетело и опубликовало эту надпись здесь
Это зависит от стиля программирования/компилятора в js и используемых библиотек. Если изменить и то и другое, то проблем не будет. Чуть выше писал про Elm
НЛО прилетело и опубликовало эту надпись здесь
Это скорее про то как сейчас писать.
А представляете как шикарно было бы отлаживать HTML, будь он тьюринг-полным языком. И какие черви на нем можно было бы писать — их бы никто не догнал! Мечта!
А потом начнется: у нас в $term лежит HelloFooBar, а передать или подставить нужно hello-foo-bar. Или разбить по запятым и получить непустые элементы. И внезапно мы приходим к тому, что поверх всех этих «безопасных» и «легковесных» подстановок снова нужен скриптовый язык — только он еще глубже завязан с HTML. Спасибо, такого веба нам не надо!
Создаем 2 документа на разных серверах, каждый пытается загрузить часть себя из другого документа. HTML2-бомба готова.

Кажется это и сейчас с iframe можно сделать

НЛО прилетело и опубликовало эту надпись здесь
В теории все красиво, но как подумаешь о практике, понимешь, что не взлетело бы:

I. Возможность грузить любой html из других сайтов,
1) будет медленной,
2) будет отваливаться, когда другие сайты не будут доступны,
3) позволит кучу дыр в безопасности, хакеры хакнули популярный источник шаблонов и в половине сайтов рунета, появились половые органы в неожиданных местах, чужая реклама или фишенговые формы «отправь номер своей кридитки»,
4) Потребует кучу головняка вида, надо взять чужой html и наложить свои стили, да так чтобы ничего не сломалось, если в источнике вдруг что-то поменяют,

II. Возможность динамически подставлять данные сразу потребует для любых задач сложнее Hello world функций программирования, например 'пользователь ввел «Вася Иванов» и пол «мужской» нужно вывести «Добро пожаловать, мистер Иванов», следовательно нужно вводить if'ы, текстовые функции и т.п. прямо в язык html. Это значит по факту пришлось бы создавать урезанный JavaScript, встроенный прямо в html, который либо был бы очень убогим, либо превратился бы в полный аналог JavaScript.
И то и другое — хуже, чем сейчас.
НЛО прилетело и опубликовало эту надпись здесь
Вот и все. Ресурс, загружаемый по адресу, указанному в URL компонента, является обычным HTML файлом.

Ага, а потом появляются нюансы и вся элегантность идет в одно место…
Но идея все-равно интересная, не сочтите за «слив»
Спасибо :)

Мне для ПО расчета ТПГ (делаю по настроению) делать «морду» для управления с рабочей станции. И почему бы и не сделать на таком принципе? :)

Автору: Это все задумки которых не хватает, или можно еше кучку?
* переменные- что бы вы хотели? (максимально широкую выборку чтоб сделать прикидку на движок)
* src — варианты чего-куда… (для тогоже)

для «xitt» «И какие черви на нем можно было бы писать» — может придумаете в ответе? «не печатает»? :)

Мне очень не хватало этой возможности в IDE. Чтоб можно было внедрять функции из разных файлов. Когда собирается из бинарников там просто куски с кодом (таблицы импорта и экспорта, коректировки адресов,...). А Си требует текст и нужен редактор умеюший дать для редактирования дробный документ, скормить его компилятору и дать коректные номера строк с ошибками и предупреждениями. Тоесть скармливать надо через «фильтр» (или из IDE).

Производительность браузера-
Тестить надо чтоб проверить можно ли выташить скорость не хуже класического и не сильно уйти от класического html.

Потому что запрос элементов потянет заголовок, пусть и усечоный (если сервер умеет помнить поля), адреса можно индексами из таблицы строк (это записано в теле страницы). Или один заголовок с запросом нескольких документов (если сервер умеет, например «архивом»...), но это «архиватор», он как шифрование отдает браузеру распакованый html.

А возврат или специальным «архивным» телом (с масивом) или всетаки с заголовками для каждого документа если клиент не умеет. Можно и на лету генерировать для выдачи старым браузерам, если они не просят им этот формат.

Потянет в требования к серверу загрузку нескольких файлов вместо одного. Маленькие файлы потребуют ФС, чтото вроде БД. В моем случае это будет по умолчанию, форма то возврашает содержимое разных полей «переменных» которые меняются все время. В тегах придется указать тип обновления данных и интервал. Слать всю страницу не резон, присылаются только измененые или их фрагменты.

Мне кажется добрая затея, когда нельзя запихать в МК java :)
Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории