Комментарии 138
Только гораздло кривее и менее безопасно, чем даже на JavaScript. Я всегда считал, что JavaScript — это наказание наше за какие-то грехи. Но после прочтения этой статьи понял, что всё могло быть хуже… гораздо хуже.
Куда уж хуже исполняемого на стороне клиента недоверенного кода?Хуже исполняемого на стороне клиента недоверенного кода только код, про который никто не подозревает, что это — код.
А ровно этим бы всё и кончилось. Сделать подобную систему, которая была бы достаточно мощной, чтобы быть полезной и при этом не быть Тьюринг-полной, очень сложно, на самом деле (вот тут интересный список вещей, которые оказались Turing-complete) — и если вы при этом не дадите нормального языка… то люди будут все свои пищалки и перделки реализовывать вот на этом.
Можете себе представить насколько «эффективно» это всё будет работать…
всё могло быть хуже… гораздо хуже..
Вспомните ColdFusion, хотя нет, лучше не вспоминайте…
Не думаю, что вместо одного запроса, который грузит страницу целиком, отправлять кучу мелких запросов — это действительно лучшее решение. Где-то да, но не всегда и не везде.
Со ссылками на другие элементы у вас очень простые примеры. А что если div name содержит разметку, а не простой текст?
С поисковым запросом тоже вопрос, когда будет отправляться? На каждый новый символ? Как быть с отменой предыдущего запроса? С конкуренцией запросов?
Всё довольно сыро и неоднозначно.
С поисковым запросом тоже вопрос, когда будет отправляться? На каждый новый символ? Как быть с отменой предыдущего запроса? С конкуренцией запросов?не всё так страшно. практически реализовал отправку на сервер для поиска и возврата набора найденного по методу like %xxx% and like %dddd% and… Проблем с отменой предыдущего нет — потому как данные уже на клиенте и проще сделать новый запрос с повторными данными (теоретически можно сделать задержку перед отправкой нажатой клавиши… но это лишнее) Конкуренции тоже нет…
Всё довольно сыро и неоднозначно.
Время от нажатия клавиши до отображения результатов найденного — от 4 мс до 16 мс при поиске в 30к строках ( при поиске в 10 000 000 максимальное время 4с это когда введённое явно отсутствует ) (возвращается не всё найденное а 15 первых записей). Без fw…
Ну, как же это нет конкуренции. Вот вы говорите 4сек: получается, что когда я печатаю xxx вы отправите 3 запроса по 4 сёк. Что будет, если ответы вернутся в порядке 3-2-1.
Тут на самом деле более глобальный вопрос: вот вы вынесли все это в разметку, повесив реализацию на браузер, кто сказал, что решение браузера единственно верное и как его поведение переопредилить?
у меня сделано: по двойному клику по ячейки таблицы вызывается веб-компонент и всё внешне выглядит как поиск с выпадающим списком из ячейки таблицы. выбранное можно изменить и сохранить как новое или изменённое. После окончания в ячейке сохранено нужное и соответственно в базе в соответствующей таблице.
даже 100к записей трудно найти в реальных задачах.
с озвученными проблемами я не встретился ни разу.
Тогда сразу получаем проблему, что ввод текста будет тормозить. Даже если запросы будут проходить быстро, задержка всё равно будет, и это весьма неприятный эффект, я вам скажу.можно — не значит нужно, под каждый случай надо сделать свой вариант.
Легко. Вот в русской Википедии 1,5 млн статей, в английской 5,8.даже там не 10м…
но не надо путать разные предназначения поиска — для поиска в вики, поиск по like однозначно не подойдёт, для этих целей существует «полнотекстовой поиск».
и яндекс и гугл справляются с поиском в значительно большем объёме, но у них и возможности намного больше.
TimsTims
А если сервак подвис или умер, и от него нет ответа, потому-что вы отправили запрос "%%"для этого существует защита от дураков. А таких если можно напридумывать много, и на каждое если можно дать решение.
Есть столько настроек и потребностей на самые разные случаи жизни, что где-то тебе надо каждое нажатие клавиши ловить (например при совместном редактировании документа),случаи есть разные, и серебряной пули на все случаи нет, надо под конкретный случай готовить решение. Я привел пример типа заполнения поля в таблице — наподобие как заполнять поле наименование товара в накладной/счёте. Пример совместного редактирования доков можно взять у гуглдок. Там решены многие (если не все) проблемы совместного редактирования и экселевских таблиц и вордовских документов.
При получении ответа нужно либо отобразить выпадающий список, либо сделать редирект, либо показать результаты красиво с картинкамитакое решение тоже есть — у поисковых систем. но это решение явно не подойдёт для какого-то конкретного случая — того же — заполнения накладной.
Имея столько настроек, всё это постепенно превращается в… javascript!без javascript — это просто картинка, как pdf файл.
vvovas
Тут на самом деле более глобальный вопрос: вот вы вынесли все это в разметку, повесив реализацию на браузер, кто сказал, что решение браузера единственно верное и как его поведение переопредилить?для этого и появились веб-компоненты, с помощью которых и получается «переопределить» поведение браузера. Тот же input можно переопределить используя ShadowRoot и template
Ну, пусть даже будет маленький объем данных, кто гарантирует быстрый ответ сервера? Проблемы с сетью, сервером, базой и у вас что попало в интерфейсе.проблемы могут быть на любом этапе, и для каждого этапа свои решения — мой вариант был проверен на канале между странами, где у клиента скорость была в килобитах — клиент неудобства не почувствовал, задержек в получении ответа не было.
Это не значит, что их не существует. В продакшне все бывает совсем не так как на dev окружении.да, но это всё решается — можно поучиться у гугл, яндекс
И под каждый вариант делать свой атрибут (какой-нибудь debounce), реализовывать его в браузере и т.п.? Может тогда проще скриптом?без скриптов не обойтись. в любом случае. Попробуй в ячейку таблицы вставить селект- что получится?
А фронтенду ли не всё равно какой там алгоритм поиска на бэкенде?конечному юзеру — по-барабану, но чтоб это реализовать надо как-то это организовать, выбрать оптимальный вариант
для защиты можно сделать запрет на ввод до получения ответаА если сервак подвис или умер, и от него нет ответа, потому-что вы отправили запрос "%%", а стоило бы отправлять при минимуме символов эдак в 5? Есть столько настроек и потребностей на самые разные случаи жизни, что где-то тебе надо каждое нажатие клавиши ловить (например при совместном редактировании документа), а где-то если не было нажатий 2 секунды. А где-то не 2, а 3. И везде по-разному. При получении ответа нужно либо отобразить выпадающий список, либо сделать редирект, либо показать результаты красиво с картинками.
Имея столько настроек, всё это постепенно превращается в… javascript!
И к автору — а как изменится тег $name=George без js? Перегрузкой родительского фрейма? Окей.
div src=xxx/$test
(загружаемое содержимое xxx/page_addr) div id=name George /div
/div
div src=xxx/$name
(загружаемое содержимое xxx/George) div id=test page_addr /div
/div
И мы получаем бесконечный цикл, поскольку изменение test ведёт к изменению name, которое ведёт к изменению test. Хоршо, мы придумали грузить страницу только при изменении URL в src, мы молодцы. В основном потому что отпилили возможность рефреша и потому что при наличии двух страниц можно добиться того же бесконечного цикла. Не считая того, что вместо скриптов, которые не всегда трогают DOM, нам при загрузке (помимо дёргающегося рендеринга из-за загрузки кучи тегов по тогдашним каналам) придётся регулярно шерстить DOM и перегружать страницы (сначала у нас не было тега id=name, но была ссылка на него, потом мы подгрузили и надо всё перестроить и подгрузить недостающее). А ещё чтобы на всех страницах не было пересекающихся id (это же не фреймы с разными пространствами имён), загрузка с левых доменов, конечно, страшно безопасна (это вы назвали сына ../../../etc/passwd?) Это сейчас более-менее ясно, а когда создавался стандарт такая штука была бы дырой эпических масштабов.
из практики — поиск в 10м — это нечто редкое :)
Вы просто не работали с такими нагрузками, поиск в большом объеме — не редкость.
для защиты можно сделать запрет на ввод до получения ответа.
Ну, пусть даже будет маленький объем данных, кто гарантирует быстрый ответ сервера? Проблемы с сетью, сервером, базой и у вас что попало в интерфейсе.
с озвученными проблемами я не встретился ни разу.
Это не значит, что их не существует. В продакшне все бывает совсем не так как на dev окружении.
Что касается всего остального — то Вы можете заметить, что стандарты в веб ориентируются на наиболее востребованные технологии. Во времена выхода jQuery она могла столько всего, что не мог «pure js», что все диву давались — «ну как изобретатели js до такого не додумались?». Такой вот «эффект послезнания». Прошли годы и все эти фишки — часть стандарта. Пройдут еще годы и частью стандарта будут шаблоны и реактивность.
В JavaScript нет счётчика ссылок, чтоб понять, когда поведение перестало быть нужным, и хватит в него посылать обновления. Нет слабых ссылок, чтоб пока есть подписчик, продолжать знать об этом, а как не стало, так, опять же, хватит посылать в него обновления. И нет способа узнать об освобождении объекта. Пока это остаётся так, ничего хорошего на JavaScript невозможно сделать.
Если б не ограничения JavaScript, был бы интересный проект.
Это, конечно, не значит, что не надо придумывать красивые решения :)
Но реализовали, в конечном итоге, не то, что задумали, а то, что смогли.
Тот факт, что выиграл CSS, а не JSSS — уже привело к диким тормозам в сегодняшнем вебе… если бы выиграло вот это — то вместо WWW прижилось бы что-то совсем другое…
tags.H1.color = "red"
— и содержимое всех тегов H1 стало красным. Если что-то «внутри» было до этого зелёным… оно всё равно стало красным.Это кажется ужасом и страшно неудобным подходом — но сохраняет одно принципиально важное свойство: сложные вещи — и выглядят сложно. А это важно в мире, где большинство фронтенд-разработчиков не то, что не понимают, сколько какие CSS-трюки стоят — они даже не понимают, почему это важно!
Но ведь CSS обычно быстрее JS, а в JSSS я вижу тот самый JS.Да нифига JS не медленный! Особенно с современными движками. Да, возможно раз в 3-5-10 медленнее оптимизированного современными компиляторами C++ — но сравнимо с тем, что было доступно разработчикам лет 20 назад. Притом, что компьютеры на 2-3 порядка быстрее.
Почему же тогда всё томозит? А потому что простейшие манипуляции с DOM требуют пересчитывать и переотрисовывать всю эту многоуровневую CSS-конструкцию. Когда у вас задача, с которой не тормозя справлялся самый первый PC на 4.77MHz, а сегодня требуется больше 10% ресурсов многогигагерцового процессора… это «вот оно».
Потому что у JS один поток на страницу. Сейчас конечно появились различные ServiceWorkers, но работа с DOM всё равно однопоточка.Что хоть как-то ограничивает современных ваятелей. Вот объясните почему какой-нибудь редактор конца XX века спокойно работает на процессорах типа 486 на 100MHz, а для редактирования простеньких формочек одного ядра на 3-4GHz уже не хватает? Только не надо про совместное редактирование документов: когда его добавили в AbiWord, его потребности в ресурсах особо не возрасли.
Всплакнул.
В конце 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!
В целом не очень понятно зачем вкрячивать логику (name $george) в html, т.к. это нарушение принципов mvc в какой-то степени.
<script>
где бы он ни встретился… Это как если бы в JS или Python функции print не было, а вместо неё был бы eval, который бы вёл себя иногда как eval, иногда как print, в зависимости от параметров.P.S. Яркая иллюстрация: habr обрезал мой первый комментарий и я не сразу понял, что это потому, что я указал неэкранированный
<script>
Да, имеющееся у нас "послезнание" об интернете далеко ушло от целей, которые, кажется, стояли перед создателями гипертекста. Всё то, что делают современные веб-приложения, даже если бы было на тот момент очевидным, вряд ли ассоциировалось бы с гипертекстом, интерактивность которого подразумевалась только в ответ на действия пользователя. Никакого блэкджека, никаких куртизанок (ну, кроме упомянутых картинок)… Завоевать мир могло только простое решение, наверное.
К тому же, даже сейчас многие экономят соединения, упаковывая и укрупняя загружаемые модули. А тогда можно было увидеть, как строчки добавляются, пропихиваясь через распоследнюю милю.
Мог ли случиться именно такой гипертекст — большой вопрос. Но то, что после всех мутаций интернет-парадигмы ничего такого у нас нет, это факт. Ну не ходит история задом наперёд, и нет пока такой силы, которая заставит нас выкинуть "всё, что нажито непосильным трудом". Мы просто наворачиваются очередную абстракцию над очередным слоем легаси (но зато универсальнейшего, которое уже работает так или иначе у всех) — и вперёд, только вперёд!
А потом, когда нибудь, мы обернётся, переосмыслили прошлое… Но будет это в нерабочее время. А пока — только вперёд, ни шагу назад!
Пришёл я в этот проект и следующей таской была разработка диалогов, я так посчитал примерное количество запросов каждый раз, когда открываешь диалоги или просто список диалогов и настоял на том, что больше мы эту штуку юзать не будем.
Собственно я к тому, что в идеальном мире абсолютная декларативность конечно могла бы и сработать, но всегда есть ограничения и их довольно много. Для прототипирования такая штука могла быть идеальна, а для мобильного интернета и мобильных устройств, особенно лет 10 назад, — катастрофой.
Хорошо, что в статье приводятся сравнения с таблицами, приходится часто использовать гуглотаблицы, собственно на средней таблице время обновления при внесении изменения в поле, от которого зависят другие поля, может быть довольно заметным. А если в документе карусель из зависимых тегов с подгрузкой данных по ссылке, предсказуемость состояния такого документа будет очень быстро теряться, либо же будет страдать отзывчивость, особенно в случае использования функций для вычисления чего-то прямо в HTML.
Мне нравится в целом посыл и идея, с одной стороны это может выглядеть как React, встроенный в HTML, с другой может использовать схемы а-ля xml для расширения функционала, но куда лучше это всё будет работать, если данные будут разделены с представлением и их обработкой будет заниматься бизнес логика приложения, а не метатэги в HTML.
JavaScript можно оставить, но в большинстве случаев он будет просто не нужен. Когда в последний раз у вас была необходимость использовать макрос в электронной таблице?Сразу же, когда нужна интерактивность.
А потом останется добавить
, , , <array.map>
ведь ждать сервера на каждый символ, на каждое движение курсора будет долго. Так HTML и станет языком программирования.
xhtml легко обрабатывается любыми существующими инструментами понимающими xml.
Валидация…
Извлечение данных…
Преобразование с использованием xslt. Все делается легко и непринужденно.
А вы вот ответьте, плиз: кому реально нужен кривой неоднозначный синтаксис HTML? Один тэг надо закрывать, другой не надо… И чем был бы хуже XHTML5?
За счет автозакрытия тегов браузер может начать рендерить страницу еще до окончания загрузки. Если сделать парсер строгим, то он не сможет ничего распарсить до тех пор пока не придет последний закрывающий </html>
Так он с самого начала невалиден. Вот есть цепочка:
<html>
<head>
<title>Title</title>
</head>
<body>
И пока не придёт завершающее </body></html>
— браузер ничего, кроме заголовка, показать не сможет. Или Вы предлагаете создать "белый список" тегов, которые можно позволить себе закрывать автоматически, а все остальные валидировать строго?
кроме заголовка, показать не сможетЗаголовок тоже не сможет — html открыт, но не закрыт. Он реально невалиден с первой же строчки, пока не придет последняя.
по поводу валидности с тегом body
webref.ru/html/body
Открывающий и закрывающий теги на веб-странице не являются обязательными, однако хорошим стилем считается их использование, чтобы определить начало и конец HTML-документа.
webref.ru/html/html
Элемент является контейнером, который заключает в себе всё содержимое веб-страницы, включая элементы и . Открывающий и закрывающий теги в документе не обязательны, но хороший стиль диктует непременное их использование.
Ресурс, загружаемый по адресу, указанному в URL компонента, является обычным HTML файлом. Он может содержать переменные, функции, а также ссылки на другие компоненты. Такие веб-компоненты могут быть легко использованы не только на одном веб-сайте, но и в качестве стандартной библиотеки в Интернете.
Чем-то напомнило Razor и вставку PartialView в шаблоне, это довольно удобно для внутреннего использования в проекте, но насколько было бы безопасно использовать библиотеки из Интернета? Сразу вспоминаются проблемы в проектах, использующих сторонние js-библиотеки, в которых внезапно решили что-то поменять и сломали.
В норме один XML, на который указывает URL, подгружает для своего отображения множество XSLT.
Но если мы хотим разбросать контент по множественным файлам, то контент должен быть в XSLT, а XML должен быть только для затравки. Помню, хотел, чтоб у меня был сайт именно на XSLT, и вот именно так, как написал. Несколько лет спустя, когда прижало, сделал сайт просто в блокноте. А потом, когда познал SEO, и что поисковики все эти XSLT-дела не оценят, и вовсе забил.
Ещё несколько лет спустя наткнулся в Сети на одного товарища, который придумал альтернативное представление XML, назвал его YML, применил его к XSLT, назвал его YSLT, и получилось нечто напоминающее функциональный язык. На этом YSLT он написал YBlog2.
Это все хорошо, но такое ощущение что автор не осилил ангулар и решил написать свой велосипед. Ничего с опытом пройдет
Какой частью html2 это должно было быть реализовано?
Браузер — программа для отрисовки текста с определённой разметкой, и отображение «графического десктопа установленной ОС» не должно входить в его задачи. Для этого есть куча VNC-клиентов на любой вкус (да и не только VNC)
Сила веба в кросплатформенности и отсутствии необходимости что-то куда-то ставить.
Для этого не обязательно нужен именно веб, можно было бы изобрести другую онлайн-платформу без всех тех костылей, которые имеются в вебе. Вы же пытаетесь впадать в крайности: или веб, или полный оффлайн. Не надо так, мир не делится на белое и чёрное.
С вашими «мне совершенно не нужно» любой, естественно, согласится, но, опять же, для этого не обязательно брать именно веб. Просто так получилось, что взлетел именно веб. И это плохо, потому что альтернативные, более адекватные платформы теперь даже пытаться сделать смысла нет — все продолжат сидеть в переполненном костылями вебе.
Так же, но без костылей. HTML — язык для разметки текста, CSS — язык для раскраски текста, JavaScript — игрушечный язык для перекраски текста по каким-то событиям, в котором при сложении массивов получается строка, и попытки строить на этом приложения порождают ужасных тормознутых уродцев с костылями, а в конкретно JavaScript ещё и всяким гуглам приходися изобретать сверхумные сверхсложные JIT-компиляторы типа V8 и учить всех не использовать какой-нибудь arguments, чтобы оптимизации не полетели к чертям.
Заменить бы HTML/CSS на условный Qt или аналог, JS на WASM, существующие API адаптировать под нужды именно приложений, а не разметки текста, довести до ума многооконность, добавить трей и всё такое — и была бы конфетка, а не то что сейчас. А если разрешить нативный код для доверенных приложений (по возможности с запуском в песочнице, разумеется), то можно было бы смело портировать всякие фотошопы и сонивегасы на такую платформу.
А пока веб-версия UT99 тормозит сильнее чем нативный Doom 2016 и пока Electron-версия Skype тупит, тормозит и жрёт ресурсы сильнее старой доброй Delphi-версии — такая платформа никуда не годится.
пока Electron-версия Skype тупит, тормозит и жрёт ресурсы сильнее старой доброй Delphi-версии — такая платформа никуда не годится.Не знаю на счет электронной, но веб-версия (web.skype.com) работает значительно стабильнее, чем десктопная. У меня 600 контактов и веб-версия просто запускается, а установленная — тупит, думает, подвисает, пару раз падает. И дело не только в новой версии. Такое уже несколько лет
Так же, но без костылей.Складывается впечатление что где-то есть тайная лига сумрачных гениев поклявшихся в ненависти ко всему миру имевшему неслыханную наглость их обидеть и придумывающие коварные козни для изысканной мести.
JavaScript — игрушечный язык для перекраски текста по каким-то событиям, в котором при сложении массивов получается строкаОгромное спасибо js за кросплатформенную среду и понимание того что можно самостоятельно взять и сделать свой собственный компиялтор. Тем более что делать компилятор гораздо проще в js чем в нативный код. Тут и сборщик мусора есть и стандартную библиотеку можно повзаимствовать. И hello world влезет в 100 байт.
Заменить бы HTML/CSS на условный Qt или аналог, JS на WASMВот только почему-то wasm yew TodoMVC собранный со всевозможными оптимизациями весит почти 400 Кб, а отладачная версия чего-то подобного, но уже на Elm собранная без оптимизаций даже до 300 Кб не дотягивает. А если сжать, то и в 50 Кб влезет.
А если разрешить нативный код для доверенных приложений (по возможности с запуском в песочнице, разумеется), то можно было бы смело портировать всякие фотошопы и сонивегасы на такую платформу.Только не нативный. Нативный он уже и так есть и он уже итак прибит гвоздями к архитектуре процессора и операционной системе.
А пока веб-версия UT99 тормозит сильнее чем нативный Doom 2016 и пока Electron-версия Skype тупит, тормозит и жрёт ресурсы сильнее старой доброй Delphi-версии — такая платформа никуда не годится.А у них стояла задача оптимизировать Electron-версию? Есть подсказка: если приложение на Delphi в 2007 попытается воспользоваться 1 Гб памяти, то есть вероятность того что оно упадёт у его разработчика и он начнёт его оптимизировать. А если это произойдёт сейчас, то разработчик этого либо просто не заметит, либо купит планку памяти, либо попросит денег на рефакторинг, где ему откажут. У людей банально нет денег на рефакторинг, им бы в текущие версии костыли вставлять. Даже у всяких гуглов.
emacs между прочим тоже написан на интерпретируемом языке. И наверняка в то время когда памяти было мало его считали неторопливым монстром. Зато сейчас по сравнению с Electron он выглядит быстрым и компактным.
Огромное спасибо js за кросплатформенную среду
Java вы проспали?
можно самостоятельно взять и сделать свой собственный компиялтор
LLVM вы тоже проспали?
чем в нативный код
Байткод вы тоже проспали? Опять вы поделили мир на чёрное и белое, а я не просто так упомянул wasm и теперь уже Java и LLVM
Тут и сборщик мусора есть
Не нужен, см. Rust. А если и нужен, то только в качестве опциональной штуки для ленивых погромистов
Вот только почему-то wasm
Ну значит не wasm, а что-нибудь другое, его я привёл просто как пример
А у них стояла задача оптимизировать Electron-версию?
Вот примерно поэтому я считаю современный мир говном
У людей банально нет денег на рефакторинг
А у меня банально нет денег на оперативку
Даже у всяких гуглов
Да, испоганили гуглопочту просто так на ровном месте
emacs между прочим тоже написан на интерпретируемом языке.
Ещё одно наглядное доказательство того, что современный веб как платформа для приложений никуда не годится
Java вы проспали?Java аплеты были но не взлетели. Внезапно.
LLVM вы тоже проспали?А исполнять что будет? LLVM хорош скорее в плане оптимизации и количестве поддерживаемых архитекутр. До цели wasm в веб страницу засунуть было нечего.
Байткод вы тоже проспали?А какой байткод одинаково хорошо понимает современный смартфон и какой-то старый пк, да ещё и прямо в браузере?
Не нужен, см. Rust. А если и нужен, то только в качестве опциональной штуки для ленивых погромистовПисать на системном языке далеко не всё удобно.
Ну значит не wasm, а что-нибудь другое, его я привёл просто как примерИ как же так страшный javascript выиграл у wasm? Наверное просто повезло.
А у меня банально нет денег на оперативкуВот при составлении ТЗ и запишите. Разумеется если у вас хватит денег на тех кто умеет оптимизировать.
Java аплеты были но не взлетели.
Про Java апплеты я ничего не говорил. На апплетах свет клином не сошёлся, а сама идея Java очень даже хорошая
А исполнять что будет?
Найдётся кто-нибудь. JavaScript же исполняет кто-то?
А какой байткод одинаково хорошо понимает современный смартфон и какой-то старый пк
Вот и задача — изобрести его
да ещё и прямо в браузере?
Вы слишком зациклены на вебе
Писать на системном языке далеко не всё удобно.
А писать всё подряд на прототипно-ориентированном интерпретируемом языке без нормальной типизации тоже так себе идея
Наверное просто повезло.
Ага.
а сама идея Java очень даже хорошаяВажна не только идея. Важна популярность и простота. Именно популярность java дала бы кросплатформенность большого количества софта. Я не прошу драйвера принтера на java, но очередной платформер на java сделать можно. Хотя в то время платформер делали скорее под winapi. Во время хвалёных скайпов на делфи. Очевидно что каждый килобайт памяти берегли.
Найдётся кто-нибудь.
Вот и задача — изобрести его
Именно по этой причине javascript и завоевал популярность. Нет нужды ждать неопределённо долгое время. И потом, за то время пока вы изобретаете замену html + js + css ускорится ещё на определённое количество процентов.
А писать всё подряд на прототипно-ориентированном интерпретируемом языке без нормальной типизации тоже так себе идеяСоздать язык компилируемый в rust и значительно улучшающий его гораздо сложнее чем типизацию для js.
Ага.Вот беда, стандартная библиотека js уже есть в браузере, а wasm должен таскать её внутри.
Вы во всём правы, и именно это меня и печалит
Ну кроме разве что этого:
Создать язык компилируемый в rust
Не нужно так делать, нужно создавать язык, компилируемый в какой-нибудь байткод. Rust компилируется в LLVM IR, а уже оттуда во все нужные платформы, в том числе wasm при желании
wasm должен таскать её внутри
Решается нормальными средствами доставки библиотек и нормальным же кэшированием. Тут в комментариях уже всплывали отдалённые намёки на это в виде src2, magnet и integrity
А если уж мечтать, то об src=«magnet:DEADBEEF»
Круче было бы отдельный формат ссылок, управляемый неким менеджером ресурсов.
Ссылка старого формата, в веб — для обратной совместимости или для ссылки на чужие ресурсы, где всё равно нет второго источника.
Ссылка нового формата:
<script src="resource://..."/>
Подхватывается вашим менеджером ресурсов, у которого есть конфиг с альтернативными урлами, чексуммой и вплоть до magnet-ссылки (если вдруг централизованный интернет окончательно рухнул).
В принципе, почти можно реализовать подключаемой библиотекой. Только с доступом к кэшу браузера проблемы.
Там как раз описывается что-то похожее
Разметка не должна заботится о поддержке фаллбек источников
Во-первых, речи а фаллбеке как таковом пока нет. Разметка указывает, что два источника можно использовать равноправно. Браузер решает, из какого именно загружать, и как он это решает — действительно не дело разметки.
Пример 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, потому что так оно распараллелится.
А если канал не жалко, а вот скорость загрузки существенна — можно и со всех адресов грузить.
Не много ли? Это был бы тихий ужас.
Не много.
№ 2 есть в кеше, но кеш старый.
Очень старый, алгоритм sha256 поменялся?
иметь критерии по которым решать
И это дело браузера. Может вообще не решать, а грузить первый, если не смог, то второй и т.д. Но тогда такой браузер будет медленным и от этого менее популярным.
надо знать что вы их сгруппировали
В смысле "сгруппировали"? По доменам или по элементам? Обе группировки видны невооружённым глазом, браузеру ничего специально сообщать не нужно.
--И это дело браузера.-- сколько браузеров, столько стратегий, да. Полиномиальный взрыв кейсов.
--Обе группировки видны невооружённым глазом--
Ну и пытаетесь отладить, заглядываете в нетворк панель, и видите запросы. Как будете разбираться, какой из групп что загрузилось?
А за вас решает броузер, какую версию использовать.
https://developer.mozilla.org/en-US/docs/Web/Security/Subresource_Integrity
Нет, это я решаю, какой алгоритм использовать для хэширования. Ситуацию, при которой какой-то алгоритм уберут из браузера, считаю маловероятной.
Cколько браузеров, столько стратегий, да. Полиномиальный взрыв кейсов
… не имеющий ни малейшего отношения к разметке. Когда я пишу такой HTML-код, мне всего лишь надо, чтобы загрузился один, любой из указанных файлов. Какой — меня не интересует вообще. Как там разработчики браузеров будут угадывать, что быстрее и что доступно — мне тоже неинтересно.
"Здесь надо выполнить скрипт/показать картинку с таким-то хэшем, найти её можно по одному из следующих адресов". Всё, на первом месте стоит содержание, и только потом — вопрос "где брать".
если загрузится не тот
А какая разница? Хэши одинаковые, значит, и файлы одинаковые. А с какого адреса он грузился — мне всё равно.
вообще не загрузится (по миллиону причин)
То же самое, что и сейчас. Напомните, делал ли что-нибудь гитхаб, когда его CSS-файлы не грузились из-за блокировок?
И когда адреса-ресурсы формируются динамически, и хеши прописывать тут никак не поможет
Динамически генерируемый Javascript-код? Или CSS? Это скорее редкость, разве нет?
пытаетесь отладить, заглядываете в нетворк панель, и видите запросы. Как будете разбираться, какой из групп что загрузилось?
Вопрос лишь интерфейса — рядом с запросом показывать информацию о группе, которой этот запрос принадлежит, и ссылку на HTML-элемент, который инициировал.
К AJAX со товарищи моё предложение, очевидно, отношения не имеет.
Вот, кстати, как такие вещи реализуют с картинками:
https://developer.mozilla.org/ru/docs/Web/HTML/Element/picture
Для разных разрешений я не предлагаю, это просто пример "множественого источника", который уже есть в стандарте.
Если поделитесь хорошей библиотекой, позволяющей реализовать резервирование источников статики — буду благодарен.
А тот факт, что Вам приходилось реализовывать резервирование вручную, только подчёркивает необходимость закрепления в стандарте.
WordPress, однако, ЕМНИП, так не делает. Почему? Да потому что на каких-то страницах нужна только jQuery, а на каких-то ещё и плагин-галерея. А на каких-то ещё какой-нибудь слайдер или кнопка "вверх". Или облако тэгов, красиво летающих по сложным орбитам. И тут либо каждый раз грузить "суперконгломерат", зато с возможностью его закэшировать (в рамках данного сайта), либо бить на мелкие куски. В первом случае страдает пользователь, который зашёл на сайт первый раз — например, из поиска.
выкинуть неиспользуемые функции
А не подскажете инструмент, который справляется с этой задачей для (напомню, динамически типизированного) JavaScript?
В любом случае, всё вышесказанное относится к оптимизации времени загрузки. А изначально речь шла именно о резервировании.
… и всё равно не решает проблему резервирования "редких" библиотек, а также CSS, иконок и шрифтов.
И так ли уж нужны бандлы в светлом мире HTTP/2, SPDY, etc. ?
WordPress, однако, ЕМНИП, так не делает. Почему?Не умеет же! Плюс огромное количество пережитков прошлого(legacy) полагаю.
Да потому что на каких-то страницах нужна только jQuery, а на каких-то ещё и плагин-галерея. А на каких-то ещё какой-нибудь слайдер или кнопка «вверх». Или облако тэгов, красиво летающих по сложным орбитам.jquery не обязывает и даже не призывает писать код в рамках одного приложения. Это просто лоскутное одеяло к которому время от времени пришивают очередной кусок. Соответственно и разобраться потом в этой простыне кода будет не просто.
И тут либо каждый раз грузить «суперконгломерат», зато с возможностью его закэшировать (в рамках данного сайта), либо бить на мелкие куски. В первом случае страдает пользователь, который зашёл на сайт первый раз — например, из поиска.Зависит от объёма сборки. Если сборка будет маленькой, то пользователь даже и не заметит. Я не даром сказал про оптимизацию.
А не подскажете инструмент, который справляется с этой задачей для (напомню, динамически типизированного) JavaScript?Всё просто — надо отказаться от динамической типизации. Вот как это получается у Elm.
В любом случае, всё вышесказанное относится к оптимизации времени загрузки. А изначально речь шла именно о резервировании.А тут и не надо резервировать. Наш сайт жив — скрипт загрузился, сайт упал — уже всё равно ничего не сделать.
$term
лежит HelloFooBar
, а передать или подставить нужно hello-foo-bar
. Или разбить по запятым и получить непустые элементы. И внезапно мы приходим к тому, что поверх всех этих «безопасных» и «легковесных» подстановок снова нужен скриптовый язык — только он еще глубже завязан с HTML. Спасибо, такого веба нам не надо!I. Возможность грузить любой html из других сайтов,
1) будет медленной,
2) будет отваливаться, когда другие сайты не будут доступны,
3) позволит кучу дыр в безопасности, хакеры хакнули популярный источник шаблонов и в половине сайтов рунета, появились половые органы в неожиданных местах, чужая реклама или фишенговые формы «отправь номер своей кридитки»,
4) Потребует кучу головняка вида, надо взять чужой html и наложить свои стили, да так чтобы ничего не сломалось, если в источнике вдруг что-то поменяют,
II. Возможность динамически подставлять данные сразу потребует для любых задач сложнее Hello world функций программирования, например 'пользователь ввел «Вася Иванов» и пол «мужской» нужно вывести «Добро пожаловать, мистер Иванов», следовательно нужно вводить if'ы, текстовые функции и т.п. прямо в язык html. Это значит по факту пришлось бы создавать урезанный JavaScript, встроенный прямо в html, который либо был бы очень убогим, либо превратился бы в полный аналог JavaScript.
И то и другое — хуже, чем сейчас.
Вот и все. Ресурс, загружаемый по адресу, указанному в URL компонента, является обычным HTML файлом.
Ага, а потом появляются нюансы и вся элегантность идет в одно место…
Но идея все-равно интересная, не сочтите за «слив»
Мне для ПО расчета ТПГ (делаю по настроению) делать «морду» для управления с рабочей станции. И почему бы и не сделать на таком принципе? :)
Автору: Это все задумки которых не хватает, или можно еше кучку?
* переменные- что бы вы хотели? (максимально широкую выборку чтоб сделать прикидку на движок)
* src — варианты чего-куда… (для тогоже)
для «xitt» «И какие черви на нем можно было бы писать» — может придумаете в ответе? «не печатает»? :)
Мне очень не хватало этой возможности в IDE. Чтоб можно было внедрять функции из разных файлов. Когда собирается из бинарников там просто куски с кодом (таблицы импорта и экспорта, коректировки адресов,...). А Си требует текст и нужен редактор умеюший дать для редактирования дробный документ, скормить его компилятору и дать коректные номера строк с ошибками и предупреждениями. Тоесть скармливать надо через «фильтр» (или из IDE).
Производительность браузера-
Тестить надо чтоб проверить можно ли выташить скорость не хуже класического и не сильно уйти от класического html.
Потому что запрос элементов потянет заголовок, пусть и усечоный (если сервер умеет помнить поля), адреса можно индексами из таблицы строк (это записано в теле страницы). Или один заголовок с запросом нескольких документов (если сервер умеет, например «архивом»...), но это «архиватор», он как шифрование отдает браузеру распакованый html.
А возврат или специальным «архивным» телом (с масивом) или всетаки с заголовками для каждого документа если клиент не умеет. Можно и на лету генерировать для выдачи старым браузерам, если они не просят им этот формат.
Потянет в требования к серверу загрузку нескольких файлов вместо одного. Маленькие файлы потребуют ФС, чтото вроде БД. В моем случае это будет по умолчанию, форма то возврашает содержимое разных полей «переменных» которые меняются все время. В тегах придется указать тип обновления данных и интервал. Слать всю страницу не резон, присылаются только измененые или их фрагменты.
Мне кажется добрая затея, когда нельзя запихать в МК java :)
HTML, который мы потеряли