HTML, который мы потеряли

Привет, Хабр! Представляю вашему вниманию перевод статьи "The HTML we never had" автора Сергея Кучерова.


В этом году исполняется 30 лет с тех пор, как Бернерс-Ли начал разрабатывать язык HTML. С тех пор мы прошли долгий путь, начиная с восхищения новой технологией, и заканчивая лечением интернет-зависимости и цензурой. Каких только бед не принес нам Интернет, взломанные пароли, кража личных данных, компьютерные вирусы, черви, а теперь даже вирусы-вымогатели. Вы когда-нибудь задумывались, почему Сеть до сих пор остается такой нестабильной и уязвимой? Где-то на этом длинном пути мы свернули не туда? Давайте разбираться.


HTML 1.0, опубликованный в 1993 году, включал всего 13 элементов (считая только те, которые сохранились до наших дней):


a, address, base, dd, dir, dl, dt, h1..h6, li, p, plaintext, title, ul

Самый главный из них, разумеется, «anchor» (а). Именно он определяет функциональность, которая отвечает за первые две буквы в заголовке стандарта—гипертекст. Без якорей (или ссылок) HTML был бы просто еще одним языком разметки текста. Именно эта способность отсылать пользователя к любому документу в мире с помощью универсального локатора ресурсов (URL), и создал это удивительное явление под названием World Wide Web. Спустя два года в HTML было добавлено еще несколько полезных элементов: html,head, body, а также элементы для создания форм, таблиц и изображений.



Последний элемент, сыграл, наверное, наиболее значительную роль в истории Интернета. Дав браузеру возможность отображать не только текст, но и картинки, мы сделали новую технологию привлекательной не только для небольшой группы ученых и энтузиастов, но и для миллионов обычных пользователей. Мы можем смело утверждать, что это нововведение даже подтолкнуло индустрию к повышению скорости интернета и его доступности для массового пользователя. Однако есть еще одна особенность этого элемента HTML, которая имеет историческое значение. Смотрите сюда:


<img src="http://ibm.com/ibm-logo.gif" />

Так как нельзя встроить двоичное изображение в текстовый файл (по крайней мере, в то время), то элемент img снабжен атрибутом, который указывает на то место, где браузер может найти требуемый файл. Эта простая идея была ключом к великому изобретению.


Ключом, который мы так никогда и не повернули.


HTML 2.0 был опубликован в ноябре 1995 года. Все были в восторге от новых возможностей, и наверное поэтому ни у кого не возникла мысль предложить: а почему бы нам не позволить всем остальным элементам HTML также использовать этот атрибут? Представьте себе это:


<h1 src="/website/info/title"> </h1>

Этот код означает, что содержание заголовка должно быть загружено из данного URL. Может быть, это не имеет смысла для такого маленького элемента, но как насчет div или article?


<article src="/parts/article/blog1298" />

Ну а сейчас это имеет смысл? Я знаю, что в 1993 году скорость Интернета была не такой высокой как сейчас. Новые функции уже заняли большинство существующей полосы пропускания, да и протокол HTTP был не на высоте. Тем не менее, не было никаких причин, чтобы не допустить такую ​​возможность в стандарте.


Теперь вы, наверное, задумаетесь, а какое влияние этот атрибут мог бы оказать на будущее WWW? Сам по себе, возможно не такое уж и большое. Но если к нему добавить еще одну возможность, то результат мог бы разительно отличаться от того, что мы имеем сейчас. Когда браузер отображает страницу, он транслирует HTML-код в объектную модель документа (DOM) расположенную в памяти. Эта модель остается неизменной до тех пор, пока браузер не получит запрос заменить ее другим HTML-документом. Даже в 1993 году программное обеспечение работало не так примитивно. В том году, когда Netscape Navigator пришел на смену браузеру Mosaic, программе Lotus 123 было уже десять лет, а VisiCalc-ку еще больше. Идея вычисления состояния документа, как функции данных вносимых пользователем, была уже хорошо известна и достаточно проста в реализации. К сожалению, никто не решился применить ее к браузерам. Представьте, что бы было, если бы в HTML 2.0 появилась вот такая возможность:


<div id="name">George</div>
<h1>Welcome, $name</h1>

Если в электронной таблице вы можете ссылаться на содержимое других ячеек, то HTML документ мог бы позволить использовать переменные, которые ссылаются на значения других элементов. Например, приведенный выше код будет изображен в виде заголовка Welcome, George. Еще больше пользы переменные могли бы принести в URL:


<article src="http://server.com/blog/$name"></article>

Приведенный выше код загрузит содержимое статьи с URL http://server.com/blog/George. А если значение элемента name изменится, то браузер обновит содержимое только этого одного элемента. Как и сейчас, сервер несет ответственность за логику и генерацию HTML кода. В этом случае, отпадает необходимость в использовании AJAX и JavaScipt. Эта новая, до сих пор никем не предложенная функция, позволила бы легко реализовать окно поиска с динамическими подсказками:


<input list="find" type="text" id="term" />
<datalist id="find" src="http://server.com/search/$term" />

Очевидно, что вычислять выражения гораздо безопаснее, чем выполнять код встроенной программы, последствия которого трудно предсказать. Чтобы сделать HTML еще более совместимым с электронными таблицами, нужно добавить возможность использовать функций:


@CONCATENATE(first,", ",last);


Нет необходимости в JavaScript, теневом DOM и других дорогих и крайне небезопасных функциях. Браузер автоматически рассчитывает изменения в DOM на основе данных, введенных пользователем. Сегодня мы называем это реактивным программированием. Обидно, что нам потребовалось 26 лет, чтобы додуматься до этого. Не поздно ли попробовать реализовать это сейчас?


Вы можете предположить, что последних версий HTML5 + CSS3 + JS вполне достаточно для современных нужд. Я так не думаю. Мы все еще мучаемся с созданием даже простого пользовательского интерфейса, и вынуждены использовать запутанные JS-библиотеки, вроде ​​Angular. А как насчет веб-компонентов? Смогут ли они сделать веб-программирование быстрее, проще и безопаснее? Возможно. А может и нет. Все, что я знаю, что компоненты чрезвычайно легко реализуются поверх того стандарта HTML, которого у нас никогда не было. Разрешите представить вам элемент define:


<head>
  <define tag=“login” src=“http://server.com/components/login”>
  <define tag=“footer” src=“http://server.com/components/footer”>
</head>

<body>
  <login toremember="yes" />
  ...
  <footer />
</body> 

Вот и все. Ресурс, загружаемый по адресу, указанному в URL компонента, является обычным HTML файлом. Он может содержать переменные, функции, а также ссылки на другие компоненты. Такие веб-компоненты могут быть легко использованы не только на одном веб-сайте, но и в качестве стандартной библиотеки в Интернете. Протокол HTTP/2 вводит много полезных возможностей, которые позволят новому HTML работать в полную силу. JavaScript можно оставить, но в большинстве случаев он будет просто не нужен. Когда в последний раз у вас была необходимость использовать макрос в электронной таблице?

Share post

Similar posts

Comments 137

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

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

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

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

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

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

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

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

                0
                из практики — поиск в 10м — это нечто редкое :)… для защиты можно сделать запрет на ввод до получения ответа.
                у меня сделано: по двойному клику по ячейки таблицы вызывается веб-компонент и всё внешне выглядит как поиск с выпадающим списком из ячейки таблицы. выбранное можно изменить и сохранить как новое или изменённое. После окончания в ячейке сохранено нужное и соответственно в базе в соответствующей таблице.
                даже 100к записей трудно найти в реальных задачах.
                с озвученными проблемами я не встретился ни разу.
                  +3
                  для защиты можно сделать запрет на ввод до получения ответа

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


                  даже 100к записей трудно найти в реальных задачах.

                  Легко. Вот в русской Википедии 1,5 млн статей, в английской 5,8.

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

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

                    vvovas
                    Тут на самом деле более глобальный вопрос: вот вы вынесли все это в разметку, повесив реализацию на браузер, кто сказал, что решение браузера единственно верное и как его поведение переопредилить?
                    для этого и появились веб-компоненты, с помощью которых и получается «переопределить» поведение браузера. Тот же input можно переопределить используя ShadowRoot и template
                    Ну, пусть даже будет маленький объем данных, кто гарантирует быстрый ответ сервера? Проблемы с сетью, сервером, базой и у вас что попало в интерфейсе.
                    проблемы могут быть на любом этапе, и для каждого этапа свои решения — мой вариант был проверен на канале между странами, где у клиента скорость была в килобитах — клиент неудобства не почувствовал, задержек в получении ответа не было.
                    Это не значит, что их не существует. В продакшне все бывает совсем не так как на dev окружении.
                    да, но это всё решается — можно поучиться у гугл, яндекс
                      +2
                      можно — не значит нужно, под каждый случай надо сделать свой вариант.

                      И под каждый вариант делать свой атрибут (какой-нибудь debounce), реализовывать его в браузере и т.п.? Может тогда проще скриптом?


                      но не надо путать разные предназначения поиска — для поиска в вики, поиск по like однозначно не подойдёт, для этих целей существует «полнотекстовой поиск».

                      А фронтенду ли не всё равно какой там алгоритм поиска на бэкенде? Может там вообще СУБД нет, а данные крутятся в ОЗУ между нодами кластера?

                        –1
                        И под каждый вариант делать свой атрибут (какой-нибудь debounce), реализовывать его в браузере и т.п.? Может тогда проще скриптом?
                        без скриптов не обойтись. в любом случае. Попробуй в ячейку таблицы вставить селект- что получится?
                        А фронтенду ли не всё равно какой там алгоритм поиска на бэкенде?
                        конечному юзеру — по-барабану, но чтоб это реализовать надо как-то это организовать, выбрать оптимальный вариант
                          –3
                          Вот интересно за что минус? С чем минусующий не согласен?
                    +5
                    для защиты можно сделать запрет на ввод до получения ответа
                    А если сервак подвис или умер, и от него нет ответа, потому-что вы отправили запрос "%%", а стоило бы отправлять при минимуме символов эдак в 5? Есть столько настроек и потребностей на самые разные случаи жизни, что где-то тебе надо каждое нажатие клавиши ловить (например при совместном редактировании документа), а где-то если не было нажатий 2 секунды. А где-то не 2, а 3. И везде по-разному. При получении ответа нужно либо отобразить выпадающий список, либо сделать редирект, либо показать результаты красиво с картинками.
                    Имея столько настроек, всё это постепенно превращается в… javascript!
                      +1
                      Настройки в тегах, логика в 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?) Это сейчас более-менее ясно, а когда создавался стандарт такая штука была бы дырой эпических масштабов.
                      +2
                      из практики — поиск в 10м — это нечто редкое :)

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

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

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

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

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

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

                      Куда более удобная реактивность была в Knockout.js. В React это скорее виртуальный DOM, шаблоны в JS и компонентизация.

                        0
                        Мои попытки использовать Flapjax были остановлены тем, что там нельзя сказать «горшочек, не вари».

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

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

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

                            Тот факт, что выиграл CSS, а не JSSS — уже привело к диким тормозам в сегодняшнем вебе… если бы выиграло вот это — то вместо WWW прижилось бы что-то совсем другое…
                              0
                              Тот факт, что выиграл CSS, а не JSSS — уже привело к диким тормозам в сегодняшнем вебе…

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

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

                                  Почему же тогда всё томозит? А потому что простейшие манипуляции с DOM требуют пересчитывать и переотрисовывать всю эту многоуровневую CSS-конструкцию. Когда у вас задача, с которой не тормозя справлялся самый первый PC на 4.77MHz, а сегодня требуется больше 10% ресурсов многогигагерцового процессора… это «вот оно».
                                    +2
                                    Да нифига JS не медленный! Особенно с современными движками.

                                    С современными движками может и быстрый. А речь идёт про 20 лет назад, когда никаких Jit в браузерах и в помине не было.
                                    Почему же тогда всё томозит?

                                    Потому что у JS один поток на страницу. Сейчас конечно появились различные ServiceWorkers, но работа с DOM всё равно однопоточка.
                                    Когда у вас задача, с которой не тормозя справлялся самый первый PC на 4.77MHz, а сегодня требуется больше 10% ресурсов многогигагерцового процессора… это «вот оно».

                                    Там это всё таки был баг браузера в частности и протекающие абстракции современного слоёного пирога веба вообще.
                                      –1
                                      Там это всё таки был баг браузера в частности и протекающие абстракции современного слоёного пирога веба вообще.Извините — но баг браузера заключался как раз в том, что что он не сумел закешировать результат сложных вычислений. А вот само кеширование и прочее — требуется именно из-за самой структуры CSS. Каковая и является «самой протекающей абстракций» в современных браузерах…
                                        0
                                        Баг был в том, что браузер хочет отрисовывать курсор, мигающий раз в секунду, с 60 FPS, и это требовало перерисовки большей области, чем нужно.
                                        А в протекающих абстракциях CSS находится весьма высоко. Под ним ещё целая груда из браузера, рантайма языка, операционной системы и виртуализации.
                                        CSS заметно сложнее JSSS, поэтому и требует кеширования, ничего удивительного. Но при этом я не припомню, чтобы странички у меня тормозили из-за лишних и избыточных правил стилей. А вот из-за скриптов, работающих с DOM, запросто. И я не припоминаю, чтобы пересчёт стилей занимал много времени в этом процессе.
                                          0
                                          CSS заметно сложнее JSSS, поэтому и требует кеширования, ничего удивительного.
                                          А вы напишите страницу на JSSS со стилями сопоставимыми с современным CSS. Попробуйте руками всё это анимировать и раскрасить. Очень хочется на это посмотреть.
                                            0
                                            Вы кажется промахнулись с адресатом. Это khim топит за JSSS.
                                        +1
                                        Потому что у JS один поток на страницу. Сейчас конечно появились различные ServiceWorkers, но работа с DOM всё равно однопоточка.
                                        Что хоть как-то ограничивает современных ваятелей. Вот объясните почему какой-нибудь редактор конца XX века спокойно работает на процессорах типа 486 на 100MHz, а для редактирования простеньких формочек одного ядра на 3-4GHz уже не хватает? Только не надо про совместное редактирование документов: когда его добавили в AbiWord, его потребности в ресурсах особо не возрасли.
                                          0
                                          Что хоть как-то ограничивает современных ваятелей.

                                          Серьёзно ограничивает. Производительность на ядро не сильно выросла со времён P4, растёт только число ядер.
                                          Вот объясните

                                          Боюсь это не ко мне. Я могу начать про фреймворки, браузеры и ОС, ноэто будет не столь изящно и красиво, как это описывают другие.
                                            0
                                            Вопрос не в ОС, браузерах и фреймворках. Вопрос, как очень точно заметил alsoijw, — в анимациях и прочих «модных, стильных, молодёжных» перделках. Если бы задача не заключалась на 99% в том, чтобы сделать очередной редизайн и получить за него премию, а в том, чтобы решить реальную задачу (сделать банковский перевод, откомментировать статью и прочее) — то не было бы ни проблем с сайтами на много мегабайт ни с многопоточностью… может пресловутой модели 5150 и не хватило бы — но какого-нибудь 386DX — уже почти наверняка…
                                  0
                                  Не согласна, но написали хорошо! :)
                                  +8
                                  Позанудствую, как всегда ). «The HTML we never had» != «HTML, который мы потеряли», даже по смыслу.
                                    0
                                    HTML, который мы не получили
                                      +14
                                      HTML, которого у нас никогда и не было )
                                        +2
                                        А сейчас HTML, который мы заслужили.
                                        0
                                        > не получили
                                        «Упустили»
                                        +4
                                        Автор поста и автор статьи — один и тот же человек, можно считать это авторским переложением.
                                          +2
                                          Ну это же отсылка к том хрустобулочному фильму девяностых, где рассказывалось, что в Российской империи все-все были дворянами, слушали Шопена и вглядывались в пузырьки шампанского
                                          +7
                                          «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!
                                            +6
                                            А потом моя кошмарная homepage попала на обзор к Носику… и в те сутки мою страницу посетило несколько сотен человек, я думаю это было половина рунета

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

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

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

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


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


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


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

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

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

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

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

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

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

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


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

                                                                +2

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

                                                                  0

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

                                                                    0
                                                                    Медленный интернет?
                                                                      0

                                                                      Я не об этом. В каких конкретно случаях автозакрытие тега позволяет отрендерить страницу раньше, чем ожидание прихода закрывающего тега? По идее это не должно мешать браузеру создать предыдущие ветви DOM-дерева, которые он может начинать рендерить.

                                                                        0
                                                                        Как, если документ ещё не валиден, пока все теги не закрыты?
                                                                          0

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

                                                                            0

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


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

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

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


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

                                                                                      А вы цитируете о парсере html.
                                                                                +3

                                                                                Ну а как SAX-парсеры работают? Приходит в потоке тег <html> — создаём для него узел дерева в корне. Затем приходит <head> — в узле html создаём подузел head, далее приходит <title> и его текстовая нода — создаём подузел, и уже браузер может показать его в заголовке. Далее приходят закрывающие теги, и браузер может возвращаться из поддеревьев. Если что-то пойдёт не так — будет ошибка. В этом и отличие от HTML.

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

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

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

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

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

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

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

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

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

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

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


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

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

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


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


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

                                                                                    0
                                                                                    Еще один стандарт, только без костылей. Да-да, конечно: xkcd.com/927
                                                                                      0
                                                                                      пока Electron-версия Skype тупит, тормозит и жрёт ресурсы сильнее старой доброй Delphi-версии — такая платформа никуда не годится.
                                                                                      Не знаю на счет электронной, но веб-версия (web.skype.com) работает значительно стабильнее, чем десктопная. У меня 600 контактов и веб-версия просто запускается, а установленная — тупит, думает, подвисает, пару раз падает. И дело не только в новой версии. Такое уже несколько лет
                                                                                        +1
                                                                                        Так же, но без костылей.
                                                                                        Складывается впечатление что где-то есть тайная лига сумрачных гениев поклявшихся в ненависти ко всему миру имевшему неслыханную наглость их обидеть и придумывающие коварные козни для изысканной мести.
                                                                                        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 он выглядит быстрым и компактным.
                                                                                          +1
                                                                                          Дык эта. EMACS == Eight Megabytes And Constantly Swapping. Да, когда-то 8 мегабайт считались очень большим объёмом памяти.
                                                                                            0
                                                                                            Огромное спасибо js за кросплатформенную среду

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


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

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


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

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


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

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


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

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


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

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


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

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


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

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


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

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

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

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


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

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


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

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


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

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


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

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


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

                                                                                                Ага.

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

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

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

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


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


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

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


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

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

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

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

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

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

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


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

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

                                                                                            0
                                                                                            Только с доступом к кэшу браузера проблемы.

                                                                                            Кэшировать можно через Service Worker.

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

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


                                                                                              Пример 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, потому что так оно распараллелится.


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

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

                                                                                                  Не много.


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

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


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

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


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

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

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

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

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

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


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


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

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

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

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


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

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


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

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

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

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


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


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

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

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


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


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

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

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


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

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


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

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

                                                                                                        Оптимально тут грузить общие для всех страниц библиотеки и скрипты в одном файле, а частные в другом, возможно, вынеся за пределы этих двух файлов какие-то библиотеки, которые весьма тяжелы и используются на нескольких страницах. Да, это сложно, нужно следить за актуальностью общего бандла и своевременно выкидывать из него неиспользуемые компоненты (или пинать систему сборки CMS, чтобы она не косячила), но оно, ИМХО, того стоит.
                                                                                                          0

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


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

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

                                                                                                            Не вижу проблемы скачать себе на сайт, если используется действительно малопопулярная либа. Доступен сайт — доступна и она.
                                                                                                            И так ли уж нужны бандлы в светлом мире HTTP/2, SPDY, etc. ?

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

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

                                                                                                                0
                                                                                                                И зачем тогда их резервировать? Их не должно быть сильно много, влияние на производительность не будет большим.
                                                                                                          0
                                                                                                          WordPress, однако, ЕМНИП, так не делает. Почему?
                                                                                                          Не умеет же! Плюс огромное количество пережитков прошлого(legacy) полагаю.
                                                                                                          Да потому что на каких-то страницах нужна только jQuery, а на каких-то ещё и плагин-галерея. А на каких-то ещё какой-нибудь слайдер или кнопка «вверх». Или облако тэгов, красиво летающих по сложным орбитам.
                                                                                                          jquery не обязывает и даже не призывает писать код в рамках одного приложения. Это просто лоскутное одеяло к которому время от времени пришивают очередной кусок. Соответственно и разобраться потом в этой простыне кода будет не просто.
                                                                                                          И тут либо каждый раз грузить «суперконгломерат», зато с возможностью его закэшировать (в рамках данного сайта), либо бить на мелкие куски. В первом случае страдает пользователь, который зашёл на сайт первый раз — например, из поиска.
                                                                                                          Зависит от объёма сборки. Если сборка будет маленькой, то пользователь даже и не заметит. Я не даром сказал про оптимизацию.
                                                                                                          А не подскажете инструмент, который справляется с этой задачей для (напомню, динамически типизированного) JavaScript?
                                                                                                          Всё просто — надо отказаться от динамической типизации. Вот как это получается у Elm.
                                                                                                          В любом случае, всё вышесказанное относится к оптимизации времени загрузки. А изначально речь шла именно о резервировании.
                                                                                                          А тут и не надо резервировать. Наш сайт жив — скрипт загрузился, сайт упал — уже всё равно ничего не сделать.
                                                                                                          +1
                                                                                                          ИМХО гораздо логичнее собрать всю эту кучу кода в один файл, выкинуть неиспользуемые функции и сжать.

                                                                                                          К сожалению, JS это не C, тут это так просто не выйдет. Я могу вызывать функцию напрямую, по имени из строки, по дата-атрибуту в HTML элементе, на который нажимает пользователь.
                                                                                                            0
                                                                                                            Это зависит от стиля программирования/компилятора в js и используемых библиотек. Если изменить и то и другое, то проблем не будет. Чуть выше писал про Elm
                                                                                                              0
                                                                                                              Как я понимаю, предлагается выкинуть весь существующий написанный код? Иначе их оптимизация работать не будет.
                                                                                                              Не взлетит.
                                                                                                                0
                                                                                                                Это скорее про то как сейчас писать.
                                                                                                    0
                                                                                                    А представляете как шикарно было бы отлаживать HTML, будь он тьюринг-полным языком. И какие черви на нем можно было бы писать — их бы никто не догнал! Мечта!
                                                                                                      +4
                                                                                                      А потом начнется: у нас в $term лежит HelloFooBar, а передать или подставить нужно hello-foo-bar. Или разбить по запятым и получить непустые элементы. И внезапно мы приходим к тому, что поверх всех этих «безопасных» и «легковесных» подстановок снова нужен скриптовый язык — только он еще глубже завязан с HTML. Спасибо, такого веба нам не надо!
                                                                                                        0
                                                                                                        Создаем 2 документа на разных серверах, каждый пытается загрузить часть себя из другого документа. HTML2-бомба готова.
                                                                                                          0

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

                                                                                                            0
                                                                                                            Большинство браузеров имеет ограничение на вложенность iframe. Можно сказать, что все, если вывести из под определения браузера IE10 и старше ))
                                                                                                          +3
                                                                                                          В теории все красиво, но как подумаешь о практике, понимешь, что не взлетело бы:

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

                                                                                                          II. Возможность динамически подставлять данные сразу потребует для любых задач сложнее Hello world функций программирования, например 'пользователь ввел «Вася Иванов» и пол «мужской» нужно вывести «Добро пожаловать, мистер Иванов», следовательно нужно вводить if'ы, текстовые функции и т.п. прямо в язык html. Это значит по факту пришлось бы создавать урезанный JavaScript, встроенный прямо в html, который либо был бы очень убогим, либо превратился бы в полный аналог JavaScript.
                                                                                                          И то и другое — хуже, чем сейчас.
                                                                                                            +2
                                                                                                            Предложенное вами может быть интересно, как идея языка компилируемого в html/js, нечто вроде директив Angular. Но как расширение html — непродуманная хотелка из серии «грабить корованы».
                                                                                                            Корован 1. Вы забыли про CSS. Как описать и применить стили к подгружаемому контенту?
                                                                                                            Корован 2. Вы изобрели атаку cross-site contenting. Как планируете защищаться?
                                                                                                            Корован 3. Обработка циклических зависимостей. А что там со вложенностью?
                                                                                                            И еще много footgun'ов. Но вместе с тем идея изящная, спасибо.
                                                                                                              +1
                                                                                                              Вот и все. Ресурс, загружаемый по адресу, указанному в URL компонента, является обычным HTML файлом.

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

                                                                                                              Only users with full accounts can post comments. Log in, please.