Привет, Хабр! Представляю вашему вниманию перевод статьи "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 можно оставить, но в большинстве случаев он будет просто не нужен. Когда в последний раз у вас была необходимость использовать макрос в электронной таблице?
Комментарии (125)
vvovas
14.02.2019 19:45+2Не думаю, что вместо одного запроса, который грузит страницу целиком, отправлять кучу мелких запросов — это действительно лучшее решение. Где-то да, но не всегда и не везде.
Со ссылками на другие элементы у вас очень простые примеры. А что если div name содержит разметку, а не простой текст?
С поисковым запросом тоже вопрос, когда будет отправляться? На каждый новый символ? Как быть с отменой предыдущего запроса? С конкуренцией запросов?
Всё довольно сыро и неоднозначно.
BigDflz
14.02.2019 20:05-1С поисковым запросом тоже вопрос, когда будет отправляться? На каждый новый символ? Как быть с отменой предыдущего запроса? С конкуренцией запросов?
не всё так страшно. практически реализовал отправку на сервер для поиска и возврата набора найденного по методу like %xxx% and like %dddd% and… Проблем с отменой предыдущего нет — потому как данные уже на клиенте и проще сделать новый запрос с повторными данными (теоретически можно сделать задержку перед отправкой нажатой клавиши… но это лишнее) Конкуренции тоже нет…
Всё довольно сыро и неоднозначно.
Время от нажатия клавиши до отображения результатов найденного — от 4 мс до 16 мс при поиске в 30к строках ( при поиске в 10 000 000 максимальное время 4с это когда введённое явно отсутствует ) (возвращается не всё найденное а 15 первых записей). Без fw…vvovas
14.02.2019 20:25Ну, как же это нет конкуренции. Вот вы говорите 4сек: получается, что когда я печатаю xxx вы отправите 3 запроса по 4 сёк. Что будет, если ответы вернутся в порядке 3-2-1.
Тут на самом деле более глобальный вопрос: вот вы вынесли все это в разметку, повесив реализацию на браузер, кто сказал, что решение браузера единственно верное и как его поведение переопредилить?BigDflz
14.02.2019 23:16из практики — поиск в 10м — это нечто редкое :)… для защиты можно сделать запрет на ввод до получения ответа.
у меня сделано: по двойному клику по ячейки таблицы вызывается веб-компонент и всё внешне выглядит как поиск с выпадающим списком из ячейки таблицы. выбранное можно изменить и сохранить как новое или изменённое. После окончания в ячейке сохранено нужное и соответственно в базе в соответствующей таблице.
даже 100к записей трудно найти в реальных задачах.
с озвученными проблемами я не встретился ни разу.staticlab
15.02.2019 00:44для защиты можно сделать запрет на ввод до получения ответа
Тогда сразу получаем проблему, что ввод текста будет тормозить. Даже если запросы будут проходить быстро, задержка всё равно будет, и это весьма неприятный эффект, я вам скажу.
даже 100к записей трудно найти в реальных задачах.
Легко. Вот в русской Википедии 1,5 млн статей, в английской 5,8.
BigDflz
15.02.2019 08:49Тогда сразу получаем проблему, что ввод текста будет тормозить. Даже если запросы будут проходить быстро, задержка всё равно будет, и это весьма неприятный эффект, я вам скажу.
можно — не значит нужно, под каждый случай надо сделать свой вариант.
Легко. Вот в русской Википедии 1,5 млн статей, в английской 5,8.
даже там не 10м…
но не надо путать разные предназначения поиска — для поиска в вики, поиск по like однозначно не подойдёт, для этих целей существует «полнотекстовой поиск».
и яндекс и гугл справляются с поиском в значительно большем объёме, но у них и возможности намного больше.
TimsTims
А если сервак подвис или умер, и от него нет ответа, потому-что вы отправили запрос "%%"
для этого существует защита от дураков. А таких если можно напридумывать много, и на каждое если можно дать решение.
Есть столько настроек и потребностей на самые разные случаи жизни, что где-то тебе надо каждое нажатие клавиши ловить (например при совместном редактировании документа),
случаи есть разные, и серебряной пули на все случаи нет, надо под конкретный случай готовить решение. Я привел пример типа заполнения поля в таблице — наподобие как заполнять поле наименование товара в накладной/счёте. Пример совместного редактирования доков можно взять у гуглдок. Там решены многие (если не все) проблемы совместного редактирования и экселевских таблиц и вордовских документов.
При получении ответа нужно либо отобразить выпадающий список, либо сделать редирект, либо показать результаты красиво с картинками
такое решение тоже есть — у поисковых систем. но это решение явно не подойдёт для какого-то конкретного случая — того же — заполнения накладной.
Имея столько настроек, всё это постепенно превращается в… javascript!
без javascript — это просто картинка, как pdf файл.
vvovas
Тут на самом деле более глобальный вопрос: вот вы вынесли все это в разметку, повесив реализацию на браузер, кто сказал, что решение браузера единственно верное и как его поведение переопредилить?
для этого и появились веб-компоненты, с помощью которых и получается «переопределить» поведение браузера. Тот же input можно переопределить используя ShadowRoot и template
Ну, пусть даже будет маленький объем данных, кто гарантирует быстрый ответ сервера? Проблемы с сетью, сервером, базой и у вас что попало в интерфейсе.
проблемы могут быть на любом этапе, и для каждого этапа свои решения — мой вариант был проверен на канале между странами, где у клиента скорость была в килобитах — клиент неудобства не почувствовал, задержек в получении ответа не было.
Это не значит, что их не существует. В продакшне все бывает совсем не так как на dev окружении.
да, но это всё решается — можно поучиться у гугл, яндексstaticlab
15.02.2019 10:04+2можно — не значит нужно, под каждый случай надо сделать свой вариант.
И под каждый вариант делать свой атрибут (какой-нибудь debounce), реализовывать его в браузере и т.п.? Может тогда проще скриптом?
но не надо путать разные предназначения поиска — для поиска в вики, поиск по like однозначно не подойдёт, для этих целей существует «полнотекстовой поиск».
А фронтенду ли не всё равно какой там алгоритм поиска на бэкенде? Может там вообще СУБД нет, а данные крутятся в ОЗУ между нодами кластера?
BigDflz
15.02.2019 10:16-1И под каждый вариант делать свой атрибут (какой-нибудь debounce), реализовывать его в браузере и т.п.? Может тогда проще скриптом?
без скриптов не обойтись. в любом случае. Попробуй в ячейку таблицы вставить селект- что получится?
А фронтенду ли не всё равно какой там алгоритм поиска на бэкенде?
конечному юзеру — по-барабану, но чтоб это реализовать надо как-то это организовать, выбрать оптимальный вариант
TimsTims
15.02.2019 01:34для защиты можно сделать запрет на ввод до получения ответа
А если сервак подвис или умер, и от него нет ответа, потому-что вы отправили запрос "%%", а стоило бы отправлять при минимуме символов эдак в 5? Есть столько настроек и потребностей на самые разные случаи жизни, что где-то тебе надо каждое нажатие клавиши ловить (например при совместном редактировании документа), а где-то если не было нажатий 2 секунды. А где-то не 2, а 3. И везде по-разному. При получении ответа нужно либо отобразить выпадающий список, либо сделать редирект, либо показать результаты красиво с картинками.
Имея столько настроек, всё это постепенно превращается в… javascript!roscomtheend
15.02.2019 10:40+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?) Это сейчас более-менее ясно, а когда создавался стандарт такая штука была бы дырой эпических масштабов.
vvovas
15.02.2019 08:43из практики — поиск в 10м — это нечто редкое :)
Вы просто не работали с такими нагрузками, поиск в большом объеме — не редкость.
для защиты можно сделать запрет на ввод до получения ответа.
Ну, пусть даже будет маленький объем данных, кто гарантирует быстрый ответ сервера? Проблемы с сетью, сервером, базой и у вас что попало в интерфейсе.
с озвученными проблемами я не встретился ни разу.
Это не значит, что их не существует. В продакшне все бывает совсем не так как на dev окружении.
Kozack
15.02.2019 15:46+1Полагаю, Если бы такой функционал вошел в стандарт, то это повлияло бы на дальнейшее развитие протокола HTTP и браузеров. Такой веб, отличался бы от нашего. Проблемма множественных запросов к серверу там была бы не актуальна. Там были бы свои, не понятные нам, сложности :)
maslyaev
14.02.2019 19:53+10Между прочим, гениально. Реактивность без Реакта (и прочих <подставьте название любимого фреймворка>), сразу декларативно на уровне языка разметки. Одна из тех идей, которые десятилетиями лежат незамеченными прямо перед глазами.
DemianFrai
15.02.2019 07:56ммм… нет. Идею реактивности в реакте можно было считать гениальной. Хотя не удивлюсь, если до реакта это «уже было», а они просто довели эту идею до ума.
Что касается всего остального — то Вы можете заметить, что стандарты в веб ориентируются на наиболее востребованные технологии. Во времена выхода jQuery она могла столько всего, что не мог «pure js», что все диву давались — «ну как изобретатели js до такого не додумались?». Такой вот «эффект послезнания». Прошли годы и все эти фишки — часть стандарта. Пройдут еще годы и частью стандарта будут шаблоны и реактивность.staticlab
15.02.2019 10:14+2Идею реактивности в реакте можно было считать гениальной. Хотя не удивлюсь, если до реакта это «уже было», а они просто довели эту идею до ума.
Куда более удобная реактивность была в Knockout.js. В React это скорее виртуальный DOM, шаблоны в JS и компонентизация.
frog
14.02.2019 20:05+1Масштабные красивые решения применительно к суровой практической реальности оказываются нежизнеспособными, к большому сожалению. Через это проходили все — разработчики микропроцессоров, языков, операционных систем и т.д. Всякие ньюансы (которые тут уже начали перечислять) приводят к отклонениям от «генеральной линии» и либо, в лучшем случае, переработке концепции, либо, в худшем — приделыванию всё новых и новых костылей, чтобы эти возникающие ньюансы учесть.
Это, конечно, не значит, что не надо придумывать красивые решения :)
inferrna
14.02.2019 20:26+15Заснувший после долгой и упорной вёрстки вебмастер просыпается в прошлом 25 летней давности в теле комитетчика w3c. Сразу осознав, какая ответственная миссия свалилась на его плечи, он приступает к активной работе. Сможет ли простой верстальщик из Саратова переломить ход истории и изменить облик всемирной паутины?
Alexey2005
14.02.2019 21:11Не сможет. Чтобы изменить историю Интернет 25 лет назад, попадать надо куда-то в Microsoft.
khim
15.02.2019 01:36Не сможет. Посмотрите на HTML 3.0 как-нибудь. Там было много интересных идей.
Но реализовали, в конечном итоге, не то, что задумали, а то, что смогли.
Тот факт, что выиграл CSS, а не JSSS — уже привело к диким тормозам в сегодняшнем вебе… если бы выиграло вот это — то вместо WWW прижилось бы что-то совсем другое…
sumanai
15.02.2019 20:07Тот факт, что выиграл CSS, а не JSSS — уже привело к диким тормозам в сегодняшнем вебе…
Но ведь CSS обычно быстрее JS, а в JSSS я вижу тот самый JS.
TheShock
15.02.2019 21:40И вообще не совсем понятно, почему JSSS был бы быстрее, ведь применение всех стилей, наверное, шло бы по тем же правилам
khim
15.02.2019 23:16В том-то и дело, что нет. JSSS — он не каскадный, там всё проще. Написали
tags.H1.color = "red"— и содержимое всех тегов H1 стало красным. Если что-то «внутри» было до этого зелёным… оно всё равно стало красным.
Это кажется ужасом и страшно неудобным подходом — но сохраняет одно принципиально важное свойство: сложные вещи — и выглядят сложно. А это важно в мире, где большинство фронтенд-разработчиков не то, что не понимают, сколько какие CSS-трюки стоят — они даже не понимают, почему это важно!
khim
15.02.2019 23:26-1Но ведь CSS обычно быстрее JS, а в JSSS я вижу тот самый JS.
Да нифига JS не медленный! Особенно с современными движками. Да, возможно раз в 3-5-10 медленнее оптимизированного современными компиляторами C++ — но сравнимо с тем, что было доступно разработчикам лет 20 назад. Притом, что компьютеры на 2-3 порядка быстрее.
Почему же тогда всё томозит? А потому что простейшие манипуляции с DOM требуют пересчитывать и переотрисовывать всю эту многоуровневую CSS-конструкцию. Когда у вас задача, с которой не тормозя справлялся самый первый PC на 4.77MHz, а сегодня требуется больше 10% ресурсов многогигагерцового процессора… это «вот оно».sumanai
15.02.2019 23:38+2Да нифига JS не медленный! Особенно с современными движками.
С современными движками может и быстрый. А речь идёт про 20 лет назад, когда никаких Jit в браузерах и в помине не было.
Почему же тогда всё томозит?
Потому что у JS один поток на страницу. Сейчас конечно появились различные ServiceWorkers, но работа с DOM всё равно однопоточка.
Когда у вас задача, с которой не тормозя справлялся самый первый PC на 4.77MHz, а сегодня требуется больше 10% ресурсов многогигагерцового процессора… это «вот оно».
Там это всё таки был баг браузера в частности и протекающие абстракции современного слоёного пирога веба вообще.khim
15.02.2019 23:50-1Там это всё таки был баг браузера в частности и протекающие абстракции современного слоёного пирога веба вообще.Извините — но баг браузера заключался как раз в том, что что он не сумел закешировать результат сложных вычислений. А вот само кеширование и прочее — требуется именно из-за самой структуры CSS. Каковая и является «самой протекающей абстракций» в современных браузерах…
sumanai
16.02.2019 19:47Баг был в том, что браузер хочет отрисовывать курсор, мигающий раз в секунду, с 60 FPS, и это требовало перерисовки большей области, чем нужно.
А в протекающих абстракциях CSS находится весьма высоко. Под ним ещё целая груда из браузера, рантайма языка, операционной системы и виртуализации.
CSS заметно сложнее JSSS, поэтому и требует кеширования, ничего удивительного. Но при этом я не припомню, чтобы странички у меня тормозили из-за лишних и избыточных правил стилей. А вот из-за скриптов, работающих с DOM, запросто. И я не припоминаю, чтобы пересчёт стилей занимал много времени в этом процессе.alsoijw
16.02.2019 20:02CSS заметно сложнее JSSS, поэтому и требует кеширования, ничего удивительного.
А вы напишите страницу на JSSS со стилями сопоставимыми с современным CSS. Попробуйте руками всё это анимировать и раскрасить. Очень хочется на это посмотреть.
khim
16.02.2019 18:35Потому что у JS один поток на страницу. Сейчас конечно появились различные ServiceWorkers, но работа с DOM всё равно однопоточка.
Что хоть как-то ограничивает современных ваятелей. Вот объясните почему какой-нибудь редактор конца XX века спокойно работает на процессорах типа 486 на 100MHz, а для редактирования простеньких формочек одного ядра на 3-4GHz уже не хватает? Только не надо про совместное редактирование документов: когда его добавили в AbiWord, его потребности в ресурсах особо не возрасли.sumanai
16.02.2019 19:49Что хоть как-то ограничивает современных ваятелей.
Серьёзно ограничивает. Производительность на ядро не сильно выросла со времён P4, растёт только число ядер.
Вот объясните
Боюсь это не ко мне. Я могу начать про фреймворки, браузеры и ОС, ноэто будет не столь изящно и красиво, как это описывают другие.
itconsulting
14.02.2019 20:58+2Позанудствую, как всегда ). «The HTML we never had» != «HTML, который мы потеряли», даже по смыслу.
msin
14.02.2019 22:04HTML, который мы не получили
Vilgelm
15.02.2019 03:24Автор поста и автор статьи — один и тот же человек, можно считать это авторским переложением.
ganqqwerty
15.02.2019 15:25+1Ну это же отсылка к том хрустобулочному фильму девяностых, где рассказывалось, что в Российской империи все-все были дворянами, слушали Шопена и вглядывались в пузырьки шампанского
kagarich
14.02.2019 21:36+1«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!Cerberuser
15.02.2019 04:31+1А потом моя кошмарная homepage попала на обзор к Носику… и в те сутки мою страницу посетило несколько сотен человек, я думаю это было половина рунета
Хабраэффект девяностых?
edogs
14.02.2019 21:41+5Идея с src отчасти реализовывалась через ssi, но его постепенно вытеснил php.
В целом не очень понятно зачем вкрячивать логику (name $george) в html, т.к. это нарушение принципов mvc в какой-то степени.aleki
15.02.2019 14:28Я бы не назвал это логикой. Data binding скорее. Да и не одним MVC едины, тем более на front-end'е.
evocatus
14.02.2019 21:46ИМХО, главная проблема веба — отсутствие разделения между кодом и данными. Когда всё склеивается в один текстовый файл (в лучших традициях #include) и затем бедный браузер обязан выполнять
evocatus
14.02.2019 21:52-1бедный браузер обязан выполнять
где бы он ни встретился… Это как если бы в JS или Python функции print не было, а вместо неё был бы eval, который бы вёл себя иногда как eval, иногда как print, в зависимости от параметров.<script>
P.S. Яркая иллюстрация: habr обрезал мой первый комментарий и я не сразу понял, что это потому, что я указал неэкранированный<script>
Danik-ik
14.02.2019 22:43Да, имеющееся у нас "послезнание" об интернете далеко ушло от целей, которые, кажется, стояли перед создателями гипертекста. Всё то, что делают современные веб-приложения, даже если бы было на тот момент очевидным, вряд ли ассоциировалось бы с гипертекстом, интерактивность которого подразумевалась только в ответ на действия пользователя. Никакого блэкджека, никаких куртизанок (ну, кроме упомянутых картинок)… Завоевать мир могло только простое решение, наверное.
К тому же, даже сейчас многие экономят соединения, упаковывая и укрупняя загружаемые модули. А тогда можно было увидеть, как строчки добавляются, пропихиваясь через распоследнюю милю.
Мог ли случиться именно такой гипертекст — большой вопрос. Но то, что после всех мутаций интернет-парадигмы ничего такого у нас нет, это факт. Ну не ходит история задом наперёд, и нет пока такой силы, которая заставит нас выкинуть "всё, что нажито непосильным трудом". Мы просто наворачиваются очередную абстракцию над очередным слоем легаси (но зато универсальнейшего, которое уже работает так или иначе у всех) — и вперёд, только вперёд!
А потом, когда нибудь, мы обернётся, переосмыслили прошлое… Но будет это в нерабочее время. А пока — только вперёд, ни шагу назад!
411
15.02.2019 01:10Как-то на одном из проектов лет 5-6 назад была чудо-разработка в виде атрибута, по которому в тэг по ссылке из атрибута грузились данные.
Пришёл я в этот проект и следующей таской была разработка диалогов, я так посчитал примерное количество запросов каждый раз, когда открываешь диалоги или просто список диалогов и настоял на том, что больше мы эту штуку юзать не будем.
Собственно я к тому, что в идеальном мире абсолютная декларативность конечно могла бы и сработать, но всегда есть ограничения и их довольно много. Для прототипирования такая штука могла быть идеальна, а для мобильного интернета и мобильных устройств, особенно лет 10 назад, — катастрофой.
Хорошо, что в статье приводятся сравнения с таблицами, приходится часто использовать гуглотаблицы, собственно на средней таблице время обновления при внесении изменения в поле, от которого зависят другие поля, может быть довольно заметным. А если в документе карусель из зависимых тегов с подгрузкой данных по ссылке, предсказуемость состояния такого документа будет очень быстро теряться, либо же будет страдать отзывчивость, особенно в случае использования функций для вычисления чего-то прямо в HTML.
Мне нравится в целом посыл и идея, с одной стороны это может выглядеть как React, встроенный в HTML, с другой может использовать схемы а-ля xml для расширения функционала, но куда лучше это всё будет работать, если данные будут разделены с представлением и их обработкой будет заниматься бизнес логика приложения, а не метатэги в HTML.
alsoijw
15.02.2019 01:10+1JavaScript можно оставить, но в большинстве случаев он будет просто не нужен. Когда в последний раз у вас была необходимость использовать макрос в электронной таблице?
Сразу же, когда нужна интерактивность.
А потом останется добавить, , , <array.map>ведь ждать сервера на каждый символ, на каждое движение курсора будет долго. Так HTML и станет языком программирования.
third112
15.02.2019 02:54Разрешите напомнить, что HTML (т.е. гипертекст) это не только веб, но есть и офф-лайн приложеия. Нпр., предпочитаю, когда help какой-то программы раскрывается в моем любимом браузере, и сам так делаю в своих программах, нпр. ИМХО с точки зрения офф-лайн использований предложения статьи были бы полезны.
Nexta
15.02.2019 04:11Мне больше нравился xhtml, но его благополучно похоронили в угоду html 5
TheShock
15.02.2019 12:06+1Чем нравился? Какие преимущества он вам давал?
npocmu
15.02.2019 22:14+2xhtml легко обрабатывается любыми существующими инструментами понимающими xml.
Валидация…
Извлечение данных…
Преобразование с использованием xslt. Все делается легко и непринужденно.
А вы вот ответьте, плиз: кому реально нужен кривой неоднозначный синтаксис HTML? Один тэг надо закрывать, другой не надо… И чем был бы хуже XHTML5?
justboris
16.02.2019 14:13+1За счет автозакрытия тегов браузер может начать рендерить страницу еще до окончания загрузки. Если сделать парсер строгим, то он не сможет ничего распарсить до тех пор пока не придет последний закрывающий
</html>staticlab
16.02.2019 15:48Что-то не могу придумать пример, который обосновывал бы этот аргумент.
Chamie
16.02.2019 19:38Медленный интернет?
staticlab
16.02.2019 20:59Я не об этом. В каких конкретно случаях автозакрытие тега позволяет отрендерить страницу раньше, чем ожидание прихода закрывающего тега? По идее это не должно мешать браузеру создать предыдущие ветви DOM-дерева, которые он может начинать рендерить.
Chamie
16.02.2019 21:51Как, если документ ещё не валиден, пока все теги не закрыты?
staticlab
16.02.2019 22:51Ну как станет невалидным, тогда и показать ошибку. Ничего страшного не случится.
Cerberuser
17.02.2019 06:24Так он с самого начала невалиден. Вот есть цепочка:
<html> <head> <title>Title</title> </head> <body>
И пока не придёт завершающее
</body></html>— браузер ничего, кроме заголовка, показать не сможет. Или Вы предлагаете создать "белый список" тегов, которые можно позволить себе закрывать автоматически, а все остальные валидировать строго?
Avitale
15.02.2019 09:39Ресурс, загружаемый по адресу, указанному в URL компонента, является обычным HTML файлом. Он может содержать переменные, функции, а также ссылки на другие компоненты. Такие веб-компоненты могут быть легко использованы не только на одном веб-сайте, но и в качестве стандартной библиотеки в Интернете.
Чем-то напомнило Razor и вставку PartialView в шаблоне, это довольно удобно для внутреннего использования в проекте, но насколько было бы безопасно использовать библиотеки из Интернета? Сразу вспоминаются проблемы в проектах, использующих сторонние js-библиотеки, в которых внезапно решили что-то поменять и сломали.
bolk
15.02.2019 09:55+1У Эксплолера была очень похожая технология, можно погуглить слова datasrc/datafld, вот тут я писал «песню про пиво» с использованием этой штуки: bolknote.ru/all/1642
zim32
15.02.2019 14:10-4Это все хорошо, но такое ощущение что автор не осилил ангулар и решил написать свой велосипед. Ничего с опытом пройдет
amarao
15.02.2019 14:14+1Ага, вот я открываю сайт, вижу список серверов. Нажимаю на 'open console', у меня открывается новое окно, в котором графический десктоп установленной ОС. Всё это в браузере с нулём флеша или java.
Какой частью html2 это должно было быть реализовано?
andreymal
16.02.2019 00:57Браузер — программа для отрисовки текста с определённой разметкой, и отображение «графического десктопа установленной ОС» не должно входить в его задачи. Для этого есть куча VNC-клиентов на любой вкус (да и не только VNC)
alsoijw
16.02.2019 13:51Альтернативы браузеру не взлетели. И это хорошо. Или вы предпочитаете ставить по приложению для каждого сайта с проприетарным api прибивающий гвоздями даже там где это не нужно? Сила веба в кросплатформенности и отсутствии необходимости что-то куда-то ставить. Мне совершенно не нужно ставить гугл карты на свой пк, чтобы раз в пол года что-то посмотреть. Мне совершенно не нужно выкачивать весь репозиторий, ставить IDE, чтобы посмотреть пару строчек кода с github или попробовать какой-то язык программирования. Мне совершенно не нужно ставить клиент ютуба, скачивать видео для просмотра какого-то обзора.
andreymal
16.02.2019 15:13Сила веба в кросплатформенности и отсутствии необходимости что-то куда-то ставить.
Для этого не обязательно нужен именно веб, можно было бы изобрести другую онлайн-платформу без всех тех костылей, которые имеются в вебе. Вы же пытаетесь впадать в крайности: или веб, или полный оффлайн. Не надо так, мир не делится на белое и чёрное.
С вашими «мне совершенно не нужно» любой, естественно, согласится, но, опять же, для этого не обязательно брать именно веб. Просто так получилось, что взлетел именно веб. И это плохо, потому что альтернативные, более адекватные платформы теперь даже пытаться сделать смысла нет — все продолжат сидеть в переполненном костылями вебе.
alsoijw
16.02.2019 15:37И в чём будет отличие этого не веба от текущего веба? И главное как в этом не вебе решить озвученные мной проблемы?
andreymal
16.02.2019 16:00Так же, но без костылей. HTML — язык для разметки текста, CSS — язык для раскраски текста, JavaScript — игрушечный язык для перекраски текста по каким-то событиям, в котором при сложении массивов получается строка, и попытки строить на этом приложения порождают ужасных тормознутых уродцев с костылями, а в конкретно JavaScript ещё и всяким гуглам приходися изобретать сверхумные сверхсложные JIT-компиляторы типа V8 и учить всех не использовать какой-нибудь arguments, чтобы оптимизации не полетели к чертям.
Заменить бы HTML/CSS на условный Qt или аналог, JS на WASM, существующие API адаптировать под нужды именно приложений, а не разметки текста, довести до ума многооконность, добавить трей и всё такое — и была бы конфетка, а не то что сейчас. А если разрешить нативный код для доверенных приложений (по возможности с запуском в песочнице, разумеется), то можно было бы смело портировать всякие фотошопы и сонивегасы на такую платформу.
А пока веб-версия UT99 тормозит сильнее чем нативный Doom 2016 и пока Electron-версия Skype тупит, тормозит и жрёт ресурсы сильнее старой доброй Delphi-версии — такая платформа никуда не годится.
TheShock
16.02.2019 17:20пока Electron-версия Skype тупит, тормозит и жрёт ресурсы сильнее старой доброй Delphi-версии — такая платформа никуда не годится.
Не знаю на счет электронной, но веб-версия (web.skype.com) работает значительно стабильнее, чем десктопная. У меня 600 контактов и веб-версия просто запускается, а установленная — тупит, думает, подвисает, пару раз падает. И дело не только в новой версии. Такое уже несколько лет
alsoijw
16.02.2019 18:09+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 он выглядит быстрым и компактным.khim
16.02.2019 18:25+1Дык эта. EMACS == Eight Megabytes And Constantly Swapping. Да, когда-то 8 мегабайт считались очень большим объёмом памяти.
andreymal
16.02.2019 18:53Огромное спасибо js за кросплатформенную среду
Java вы проспали?
можно самостоятельно взять и сделать свой собственный компиялтор
LLVM вы тоже проспали?
чем в нативный код
Байткод вы тоже проспали? Опять вы поделили мир на чёрное и белое, а я не просто так упомянул wasm и теперь уже Java и LLVM
Тут и сборщик мусора есть
Не нужен, см. Rust. А если и нужен, то только в качестве опциональной штуки для ленивых погромистов
Вот только почему-то wasm
Ну значит не wasm, а что-нибудь другое, его я привёл просто как пример
А у них стояла задача оптимизировать Electron-версию?
Вот примерно поэтому я считаю современный мир говном
У людей банально нет денег на рефакторинг
А у меня банально нет денег на оперативку
Даже у всяких гуглов
Да, испоганили гуглопочту просто так на ровном месте
emacs между прочим тоже написан на интерпретируемом языке.
Ещё одно наглядное доказательство того, что современный веб как платформа для приложений никуда не годится
alsoijw
16.02.2019 19:30Java вы проспали?
Java аплеты были но не взлетели. Внезапно.
LLVM вы тоже проспали?
А исполнять что будет? LLVM хорош скорее в плане оптимизации и количестве поддерживаемых архитекутр. До цели wasm в веб страницу засунуть было нечего.
Байткод вы тоже проспали?
А какой байткод одинаково хорошо понимает современный смартфон и какой-то старый пк, да ещё и прямо в браузере?
Не нужен, см. Rust. А если и нужен, то только в качестве опциональной штуки для ленивых погромистов
Писать на системном языке далеко не всё удобно.
Ну значит не wasm, а что-нибудь другое, его я привёл просто как пример
И как же так страшный javascript выиграл у wasm? Наверное просто повезло.
А у меня банально нет денег на оперативку
Вот при составлении ТЗ и запишите. Разумеется если у вас хватит денег на тех кто умеет оптимизировать.andreymal
16.02.2019 19:37Java аплеты были но не взлетели.
Про Java апплеты я ничего не говорил. На апплетах свет клином не сошёлся, а сама идея Java очень даже хорошая
А исполнять что будет?
Найдётся кто-нибудь. JavaScript же исполняет кто-то?
А какой байткод одинаково хорошо понимает современный смартфон и какой-то старый пк
Вот и задача — изобрести его
да ещё и прямо в браузере?
Вы слишком зациклены на вебе
Писать на системном языке далеко не всё удобно.
А писать всё подряд на прототипно-ориентированном интерпретируемом языке без нормальной типизации тоже так себе идея
Наверное просто повезло.
Ага.
alsoijw
16.02.2019 19:55а сама идея Java очень даже хорошая
Важна не только идея. Важна популярность и простота. Именно популярность java дала бы кросплатформенность большого количества софта. Я не прошу драйвера принтера на java, но очередной платформер на java сделать можно. Хотя в то время платформер делали скорее под winapi. Во время хвалёных скайпов на делфи. Очевидно что каждый килобайт памяти берегли.
Найдётся кто-нибудь.
Вот и задача — изобрести его
Именно по этой причине javascript и завоевал популярность. Нет нужды ждать неопределённо долгое время. И потом, за то время пока вы изобретаете замену html + js + css ускорится ещё на определённое количество процентов.
А писать всё подряд на прототипно-ориентированном интерпретируемом языке без нормальной типизации тоже так себе идея
Создать язык компилируемый в rust и значительно улучшающий его гораздо сложнее чем типизацию для js.
Ага.
Вот беда, стандартная библиотека js уже есть в браузере, а wasm должен таскать её внутри.andreymal
16.02.2019 20:17Вы во всём правы, и именно это меня и печалит
Ну кроме разве что этого:
Создать язык компилируемый в rust
Не нужно так делать, нужно создавать язык, компилируемый в какой-нибудь байткод. Rust компилируется в LLVM IR, а уже оттуда во все нужные платформы, в том числе wasm при желании
wasm должен таскать её внутри
Решается нормальными средствами доставки библиотек и нормальным же кэшированием. Тут в комментариях уже всплывали отдалённые намёки на это в виде src2, magnet и integrity
WebMonet
15.02.2019 14:37-1А еще автор забыл, что HTML в значительной своей части предназначался и для оффлайна тоже. Как вы представляете себе <div src… /> в оффлайне?
NickKolok
15.02.2019 14:43Я не понимаю другого. Откуда всеобщая уверенность в безотказности всего и вся? Откуда эта чёртова дилемма «грузить jQuery с гугла, задействуя кэш — или со своего сервера, будучи независимым»? Почему до сих пор не такой вот стандартной конструкции:
xitt
15.02.2019 16:46+1Разделение консернов. Разметка не должна заботится о поддержке фаллбек источников (хотя никто не мешает это водрузить на тот же JS). Направте на проксю и рулите там, или напишите код клиента.
NickKolok
15.02.2019 17:30Разметка не должна заботится о поддержке фаллбек источников
Во-первых, речи а фаллбеке как таковом пока нет. Разметка указывает, что два источника можно использовать равноправно. Браузер решает, из какого именно загружать, и как он это решает — действительно не дело разметки.
Пример 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, потому что так оно распараллелится.
А если канал не жалко, а вот скорость загрузки существенна — можно и со всех адресов грузить.
xitt
15.02.2019 18:20Чтобы браузеру решать, 1) ему надо знать что вы их сгруппировали 2) иметь критерии по которым решать. № 2 есть в кеше, но кеш старый. № 1 нет в кеше но грузится быстрее чем № 3, потому что закеширован на проксе. Но погодите, № 3 оказывается тоже есть в кеше, но к сожалению CORS политика не позволяет загрузить. А там по соседству такая же группа сорцов, но 1 и 3 поменяны местами.
Не много ли? Это был бы тихий ужас.NickKolok
15.02.2019 18:28Не много.
№ 2 есть в кеше, но кеш старый.
Очень старый, алгоритм sha256 поменялся?
иметь критерии по которым решать
И это дело браузера. Может вообще не решать, а грузить первый, если не смог, то второй и т.д. Но тогда такой браузер будет медленным и от этого менее популярным.
надо знать что вы их сгруппировали
В смысле "сгруппировали"? По доменам или по элементам? Обе группировки видны невооружённым глазом, браузеру ничего специально сообщать не нужно.
xitt
15.02.2019 21:21Очень старый, алгоритм sha256 поменялся? — очень старый, это значит что вам не подходит. А за вас решает броузер, какую версию использовать.
--И это дело браузера.-- сколько браузеров, столько стратегий, да. Полиномиальный взрыв кейсов.
--Обе группировки видны невооружённым глазом--
Ну и пытаетесь отладить, заглядываете в нетворк панель, и видите запросы. Как будете разбираться, какой из групп что загрузилось?NickKolok
15.02.2019 21:34А за вас решает броузер, какую версию использовать.
https://developer.mozilla.org/en-US/docs/Web/Security/Subresource_Integrity
Нет, это я решаю, какой алгоритм использовать для хэширования. Ситуацию, при которой какой-то алгоритм уберут из браузера, считаю маловероятной.
Cколько браузеров, столько стратегий, да. Полиномиальный взрыв кейсов
… не имеющий ни малейшего отношения к разметке. Когда я пишу такой HTML-код, мне всего лишь надо, чтобы загрузился один, любой из указанных файлов. Какой — меня не интересует вообще. Как там разработчики браузеров будут угадывать, что быстрее и что доступно — мне тоже неинтересно.
"Здесь надо выполнить скрипт/показать картинку с таким-то хэшем, найти её можно по одному из следующих адресов". Всё, на первом месте стоит содержание, и только потом — вопрос "где брать".xitt
15.02.2019 22:49— Когда я пишу такой HTML-код, мне всего лишь надо, чтобы загрузился один, любой из указанных файлов. — я же не спорю, интересно вам или нет. Будет интересно, что вы будете делать, если загрузиться не тот, или вообще не загрузится (по миллиону причин). И когда адреса-ресурсы формируются динамически, и хеши прописывать тут никак не поможет. Ладно, я все сказал вроде.
NickKolok
15.02.2019 23:25+1если загрузится не тот
А какая разница? Хэши одинаковые, значит, и файлы одинаковые. А с какого адреса он грузился — мне всё равно.
вообще не загрузится (по миллиону причин)
То же самое, что и сейчас. Напомните, делал ли что-нибудь гитхаб, когда его CSS-файлы не грузились из-за блокировок?
И когда адреса-ресурсы формируются динамически, и хеши прописывать тут никак не поможет
Динамически генерируемый Javascript-код? Или CSS? Это скорее редкость, разве нет?
NickKolok
15.02.2019 21:40+1пытаетесь отладить, заглядываете в нетворк панель, и видите запросы. Как будете разбираться, какой из групп что загрузилось?
Вопрос лишь интерфейса — рядом с запросом показывать информацию о группе, которой этот запрос принадлежит, и ссылку на HTML-элемент, который инициировал.
К AJAX со товарищи моё предложение, очевидно, отношения не имеет.
Вот, кстати, как такие вещи реализуют с картинками:
https://developer.mozilla.org/ru/docs/Web/HTML/Element/picturexitt
15.02.2019 23:13Не поддерживается эксплорерами толком. То что вы предлагаете (в том числе для разных разрешений) я делал с помощью того же ажакс и жкваери года три назад.
NickKolok
15.02.2019 23:27Для разных разрешений я не предлагаю, это просто пример "множественого источника", который уже есть в стандарте.
Если поделитесь хорошей библиотекой, позволяющей реализовать резервирование источников статики — буду благодарен.
А тот факт, что Вам приходилось реализовывать резервирование вручную, только подчёркивает необходимость закрепления в стандарте.
alsoijw
15.02.2019 21:39+1ИМХО гораздо логичнее собрать всю эту кучу кода в один файл, выкинуть неиспользуемые функции и сжать. Работает и уже сейчас. В итоге размер сборки может легко быть меньше пустого фрейморка, не содержащего нашей логики. Всё равно использовать все плюсы разделяемых библиотек в вебе не получается. Исправление багов/уявимостей одинакого меняют хеш, плюс из-за исправления бага может какой-то костыль отвалится. Кеширование библиотек? Это хорошо работает только когда на сайтах используются одни и те же библиотеки. Кроме того это устранит ситуации когда десяток библиотек загружаются ради одной функции.
NickKolok
15.02.2019 21:56WordPress, однако, ЕМНИП, так не делает. Почему? Да потому что на каких-то страницах нужна только jQuery, а на каких-то ещё и плагин-галерея. А на каких-то ещё какой-нибудь слайдер или кнопка "вверх". Или облако тэгов, красиво летающих по сложным орбитам. И тут либо каждый раз грузить "суперконгломерат", зато с возможностью его закэшировать (в рамках данного сайта), либо бить на мелкие куски. В первом случае страдает пользователь, который зашёл на сайт первый раз — например, из поиска.
выкинуть неиспользуемые функции
А не подскажете инструмент, который справляется с этой задачей для (напомню, динамически типизированного) JavaScript?
В любом случае, всё вышесказанное относится к оптимизации времени загрузки. А изначально речь шла именно о резервировании.
sumanai
15.02.2019 22:31И тут либо каждый раз грузить «суперконгломерат», зато с возможностью его закэшировать (в рамках данного сайта), либо бить на мелкие куски.
Оптимально тут грузить общие для всех страниц библиотеки и скрипты в одном файле, а частные в другом, возможно, вынеся за пределы этих двух файлов какие-то библиотеки, которые весьма тяжелы и используются на нескольких страницах. Да, это сложно, нужно следить за актуальностью общего бандла и своевременно выкидывать из него неиспользуемые компоненты (или пинать систему сборки CMS, чтобы она не косячила), но оно, ИМХО, того стоит.NickKolok
15.02.2019 22:38… и всё равно не решает проблему резервирования "редких" библиотек, а также CSS, иконок и шрифтов.
И так ли уж нужны бандлы в светлом мире HTTP/2, SPDY, etc. ?
sumanai
15.02.2019 23:30… и всё равно не решает проблему резервирования «редких» библиотек, а также CSS, иконок и шрифтов.
Не вижу проблемы скачать себе на сайт, если используется действительно малопопулярная либа. Доступен сайт — доступна и она.
И так ли уж нужны бандлы в светлом мире HTTP/2, SPDY, etc. ?
Кто знает…NickKolok
15.02.2019 23:37Не вижу проблемы скачать себе на сайт, если используется действительно малопопулярная либа. Доступен сайт — доступна и она.
Под "редкими" имелись в виду библиотеки, которые используются на малом количестве страниц сайта и которые не входят в бандлы.
sumanai
15.02.2019 23:40И зачем тогда их резервировать? Их не должно быть сильно много, влияние на производительность не будет большим.
alsoijw
16.02.2019 14:11WordPress, однако, ЕМНИП, так не делает. Почему?
Не умеет же! Плюс огромное количество пережитков прошлого(legacy) полагаю.
Да потому что на каких-то страницах нужна только jQuery, а на каких-то ещё и плагин-галерея. А на каких-то ещё какой-нибудь слайдер или кнопка «вверх». Или облако тэгов, красиво летающих по сложным орбитам.
jquery не обязывает и даже не призывает писать код в рамках одного приложения. Это просто лоскутное одеяло к которому время от времени пришивают очередной кусок. Соответственно и разобраться потом в этой простыне кода будет не просто.
И тут либо каждый раз грузить «суперконгломерат», зато с возможностью его закэшировать (в рамках данного сайта), либо бить на мелкие куски. В первом случае страдает пользователь, который зашёл на сайт первый раз — например, из поиска.
Зависит от объёма сборки. Если сборка будет маленькой, то пользователь даже и не заметит. Я не даром сказал про оптимизацию.
А не подскажете инструмент, который справляется с этой задачей для (напомню, динамически типизированного) JavaScript?
Всё просто — надо отказаться от динамической типизации. Вот как это получается у Elm.
В любом случае, всё вышесказанное относится к оптимизации времени загрузки. А изначально речь шла именно о резервировании.
А тут и не надо резервировать. Наш сайт жив — скрипт загрузился, сайт упал — уже всё равно ничего не сделать.
sumanai
15.02.2019 22:15+1ИМХО гораздо логичнее собрать всю эту кучу кода в один файл, выкинуть неиспользуемые функции и сжать.
К сожалению, JS это не C, тут это так просто не выйдет. Я могу вызывать функцию напрямую, по имени из строки, по дата-атрибуту в HTML элементе, на который нажимает пользователь.
xitt
15.02.2019 16:48А представляете как шикарно было бы отлаживать HTML, будь он тьюринг-полным языком. И какие черви на нем можно было бы писать — их бы никто не догнал! Мечта!
impwx
15.02.2019 18:09+4А потом начнется: у нас в
$termлежитHelloFooBar, а передать или подставить нужноhello-foo-bar. Или разбить по запятым и получить непустые элементы. И внезапно мы приходим к тому, что поверх всех этих «безопасных» и «легковесных» подстановок снова нужен скриптовый язык — только он еще глубже завязан с HTML. Спасибо, такого веба нам не надо!
iig
15.02.2019 18:34Создаем 2 документа на разных серверах, каждый пытается загрузить часть себя из другого документа. HTML2-бомба готова.
vedenin1980
15.02.2019 19:16В теории все красиво, но как подумаешь о практике, понимешь, что не взлетело бы:
I. Возможность грузить любой html из других сайтов,
1) будет медленной,
2) будет отваливаться, когда другие сайты не будут доступны,
3) позволит кучу дыр в безопасности, хакеры хакнули популярный источник шаблонов и в половине сайтов рунета, появились половые органы в неожиданных местах, чужая реклама или фишенговые формы «отправь номер своей кридитки»,
4) Потребует кучу головняка вида, надо взять чужой html и наложить свои стили, да так чтобы ничего не сломалось, если в источнике вдруг что-то поменяют,
II. Возможность динамически подставлять данные сразу потребует для любых задач сложнее Hello world функций программирования, например 'пользователь ввел «Вася Иванов» и пол «мужской» нужно вывести «Добро пожаловать, мистер Иванов», следовательно нужно вводить if'ы, текстовые функции и т.п. прямо в язык html. Это значит по факту пришлось бы создавать урезанный JavaScript, встроенный прямо в html, который либо был бы очень убогим, либо превратился бы в полный аналог JavaScript.
И то и другое — хуже, чем сейчас.
stardust_kid
15.02.2019 19:18+2Предложенное вами может быть интересно, как идея языка компилируемого в html/js, нечто вроде директив Angular. Но как расширение html — непродуманная хотелка из серии «грабить корованы».
Корован 1. Вы забыли про CSS. Как описать и применить стили к подгружаемому контенту?
Корован 2. Вы изобрели атаку cross-site contenting. Как планируете защищаться?
Корован 3. Обработка циклических зависимостей. А что там со вложенностью?
И еще много footgun'ов. Но вместе с тем идея изящная, спасибо.
YemSalat
15.02.2019 22:48+1Вот и все. Ресурс, загружаемый по адресу, указанному в URL компонента, является обычным HTML файлом.
Ага, а потом появляются нюансы и вся элегантность идет в одно место…
Но идея все-равно интересная, не сочтите за «слив»
kinall
Автор изобрёл фреймы?..
khim
Нет, автор изобрёл Тьюринговскую трясину. Можете поискать — тут на Excel всякие 3D-движки моделируют и прочее. Вот на этом «ужасе летящем на крыльях ночи» — всё это тоже можно было бы сделать.
Только гораздло кривее и менее безопасно, чем даже на JavaScript. Я всегда считал, что JavaScript — это наказание наше за какие-то грехи. Но после прочтения этой статьи понял, что всё могло быть хуже… гораздо хуже.
genuimous
Куда уж хуже исполняемого на стороне клиента недоверенного кода? Все эти ява-скрипты нужно было запретить еще в зародыше.
khim
А ровно этим бы всё и кончилось. Сделать подобную систему, которая была бы достаточно мощной, чтобы быть полезной и при этом не быть Тьюринг-полной, очень сложно, на самом деле (вот тут интересный список вещей, которые оказались Turing-complete) — и если вы при этом не дадите нормального языка… то люди будут все свои пищалки и перделки реализовывать вот на этом.
Можете себе представить насколько «эффективно» это всё будет работать…
alsoijw
Браузер это вполне доверенный код. А уязвимости можно хоть в просмотрщике изображений сделать.
YemSalat
Вспомните ColdFusion, хотя нет, лучше не вспоминайте…