Doctor_IT , у меня профессиональный интерес. А Вы можете поделиться ссылками на некоторые ваши особо сложные Google Docs, которые необходимо было конвертировать в статью на vc.ru?
К сожалению, в публикации примеры документов не указаны.
Вообще такая технология есть и ей лет 15-20 - называется IFRAME. Вставляете IFRAME со всеми нужными политиками безопасности на свои страницы. Тот грузит скрипты внутри себя. Далее получаете ссылку на объект window этого iframe (через свойство iframe.contentWindow) И вперед.
А вообще, общий кеш в браузере вряд ли будет, в первую очередь по причине безопасности. Например, с такой технологией подключить к вредоносному сайту банковский скрипт с данными станет легко, даже куки не надо воровать.
Ресурсы, такие как unpkg.com и jsdelivr.com, в некоторой степени помогают уменьшить дублирование, поскольку если несколько сайтов ссылается на один и тот же ресурс на unpkg.com, то все они будут использовать один и тот же объект из кэша браузера.
Как они помогают? Я бы еще могу согласиться в том случае, если бы речь шла о загрузке таких скриптов через IFRAME. Вот в таком случае мы точно с вами могли бы говорить об экономии трафика. А если идет речь об идентичных прямых ссылках на внешний скрипт на различных сайтах, то кэширование будет распространяться на каждый отдельный ресурс. Посещая таких 2 сайта, идентичный файл библиотеки вы скачаете 2 раза.
почему бы не хранить npm‑пакеты (или хотя бы транспилированные значимые объекты кода) прямо в браузере, учитывая версионность и другие свойства, присущие пакету?
Да никто и сейчас Вам не мешает это делать даже без бандлеров и хранить в браузере. Есть прекрасный механизм import maps, который по сути является картой импортов. Эту карту импортов можно и в ручную писать, если есть надобность, а так видел на npm пакет, который конвертирует package.json в карту.
При проектировании кода, в котором задействованы возможности фреймворка, приходится идти на уступки из-за т.н. инверсии управления (к слову, наличие которой является ключевым отличием библиотек от фреймворков). Поэтому та часть проекта, в которой используется фреймворк, с огромной вероятностью, будет использовать архитектуру, навязанную фреймворком. Собственно, если проект целиком и полностью состоит из системы, контролируемой фреймворком, то, что "прокричит" ваш фреймворк, такая архитектура и будет.
Сложилось впечатление, что Автор призывает использовать сервисную модель.
Чтобы скачков не было в бесконечных списках обычно используют position: absolute.
Полностью согласен, что упираемся в расчеты, которые не хочется проводить на клиенте. Но и это решаемо, потому что именно разработчик компонента (возможно с поддержкой дизайнера) решает как он должен отображаться. Я к тому что чем больше строгости, тем проще расчеты.
В том числе расчеты могут быть отложенными и незаметными для пользователя. И могут даже корректироваться, переходя от приближенных расчетов высот к более точным ) Потому что нам будет все равно, что условный компонент, который ниже вьюпорта на 5000px на самом деле должен быть 4950px. При скроллинге это незаметно.
Чтобы продемонстрировать что я имею в виду, накидал небольшой сниппет для замены комментариев Хабра теми самыми текстовыми блоками.
let nodes = Array.from(document.querySelectorAll(".tm-comment-thread__comment"));
for (let i=0; i<nodes.length; i++) {
let node = nodes[i];
let rect = node.getClientRects()[0];
let text = node.innerText;
let div = document.createElement("div");
div.style.height = `${rect.height}px`;
div.innerText = text;
node.replaceWith(div);
}
браузерному поиску это не поможет, ибо он будет не туда, куда надо.
<div style="height: 90px">long text </div>
<div style="height: 120px">long text 2 </div>
...
<div style="height: 20px">needle in a haystack </div>
...
<div style="height: 200px">text </div>
Div мог бы быть в исходном контенте параграфом или таблицей. Это неважно потому что тут главное позиционирование текстовых блоков (следование друг за другом с учетом их размеров).
Поэтому, как мне кажется, если искать needle, то браузер покажет его в нужном и правильном месте только в случае проведенных предварительных расчетов высот таких элементов. Или я что-то упускаю?
Если же блок получится слишком высоким, то очевидно, что браузер покажет найденный текст не там, где надо. А для небольших, которые вмещаются, например, в четверть экрана, то проблемы особой не вижу.
Кстати, можно не уничтожать невидимый контент, а в невидимых для пользователя частях страницы можно рисовать блок, который будет содержать исключительно текст без украшательств. Что это дает: во-первых не нужно на странице реализовывать свой поиск, и во-вторых очевидно памяти не так много потратится, потому что на каждый блок с известной высотой будет приходиться всего 1 тег.
При прокрутке уже отрисовывать нужную часть страницы так, как она должна выглядеть.
"Текстовые" блоки можно лениво рендерить, чтобы браузер не тормозил.
Решение на файлах - такое себе. Данные можно хранить хоть в json, но масштабируемости не будет. Наверняка потом надо будет учитывать время устаревания ссылки или аналитику провести.
Ну и кстати на ру-хостингах на некоторых тарифах еще любят ограничение делать в 10000 файлов на VPS.
Поэтому я за решение с использованием БД. Адрес короткого урла тоже довольно просто можно сгенерить, например: base62(index) . base62(md5(url)).
Я не из секты @nin-jin но мне в принципе понятно, как работает этот код. С root по clear - Это ссылки на DOM-элементы, а textContent и childNodes это нативные свойства элементов. И геттеры также работали бы, даже если бы не было вызова $mol_wire_dom. Очевидно, что реактивность над DOM можно получить за счет на подписок события модификации элементов.
Заглянул в $mol_wire_dom, так оно и оказалось.
А так, согласен с Вами, что нет легкого старта. Собственно, если высокий порог вхождения и нет явного коммерческого интереса, то туда никто и не войдет.
Doctor_IT , у меня профессиональный интерес. А Вы можете поделиться ссылками на некоторые ваши особо сложные Google Docs, которые необходимо было конвертировать в статью на vc.ru?
К сожалению, в публикации примеры документов не указаны.
Вообще такая технология есть и ей лет 15-20 - называется IFRAME. Вставляете IFRAME со всеми нужными политиками безопасности на свои страницы. Тот грузит скрипты внутри себя. Далее получаете ссылку на объект window этого iframe (через свойство iframe.contentWindow) И вперед.
А вообще, общий кеш в браузере вряд ли будет, в первую очередь по причине безопасности. Например, с такой технологией подключить к вредоносному сайту банковский скрипт с данными станет легко, даже куки не надо воровать.
Как они помогают? Я бы еще могу согласиться в том случае, если бы речь шла о загрузке таких скриптов через IFRAME. Вот в таком случае мы точно с вами могли бы говорить об экономии трафика. А если идет речь об идентичных прямых ссылках на внешний скрипт на различных сайтах, то кэширование будет распространяться на каждый отдельный ресурс. Посещая таких 2 сайта, идентичный файл библиотеки вы скачаете 2 раза.
Да никто и сейчас Вам не мешает это делать даже без бандлеров и хранить в браузере. Есть прекрасный механизм import maps, который по сути является картой импортов. Эту карту импортов можно и в ручную писать, если есть надобность, а так видел на npm пакет, который конвертирует package.json в карту.
При проектировании кода, в котором задействованы возможности фреймворка, приходится идти на уступки из-за т.н. инверсии управления (к слову, наличие которой является ключевым отличием библиотек от фреймворков). Поэтому та часть проекта, в которой используется фреймворк, с огромной вероятностью, будет использовать архитектуру, навязанную фреймворком. Собственно, если проект целиком и полностью состоит из системы, контролируемой фреймворком, то, что "прокричит" ваш фреймворк, такая архитектура и будет.
Сложилось впечатление, что Автор призывает использовать сервисную модель.
Большое спасибо за подробное разъяснение.
С большим интересом читаю Ваши комментарии. Но я уже сам запутался. Можно как-то доступнее? :)
П.С. Я уже на старте проверять код на массивы и форичи.
Чтобы скачков не было в бесконечных списках обычно используют position: absolute.
Полностью согласен, что упираемся в расчеты, которые не хочется проводить на клиенте. Но и это решаемо, потому что именно разработчик компонента (возможно с поддержкой дизайнера) решает как он должен отображаться. Я к тому что чем больше строгости, тем проще расчеты.
В том числе расчеты могут быть отложенными и незаметными для пользователя. И могут даже корректироваться, переходя от приближенных расчетов высот к более точным ) Потому что нам будет все равно, что условный компонент, который ниже вьюпорта на 5000px на самом деле должен быть 4950px. При скроллинге это незаметно.
Чтобы продемонстрировать что я имею в виду, накидал небольшой сниппет для замены комментариев Хабра теми самыми текстовыми блоками.
Div мог бы быть в исходном контенте параграфом или таблицей. Это неважно потому что тут главное позиционирование текстовых блоков (следование друг за другом с учетом их размеров).
Поэтому, как мне кажется, если искать needle, то браузер покажет его в нужном и правильном месте только в случае проведенных предварительных расчетов высот таких элементов. Или я что-то упускаю?
Если же блок получится слишком высоким, то очевидно, что браузер покажет найденный текст не там, где надо. А для небольших, которые вмещаются, например, в четверть экрана, то проблемы особой не вижу.
Кстати, можно не уничтожать невидимый контент, а в невидимых для пользователя частях страницы можно рисовать блок, который будет содержать исключительно текст без украшательств. Что это дает: во-первых не нужно на странице реализовывать свой поиск, и во-вторых очевидно памяти не так много потратится, потому что на каждый блок с известной высотой будет приходиться всего 1 тег.
При прокрутке уже отрисовывать нужную часть страницы так, как она должна выглядеть.
"Текстовые" блоки можно лениво рендерить, чтобы браузер не тормозил.
Решение на файлах - такое себе. Данные можно хранить хоть в json, но масштабируемости не будет. Наверняка потом надо будет учитывать время устаревания ссылки или аналитику провести.
Ну и кстати на ру-хостингах на некоторых тарифах еще любят ограничение делать в 10000 файлов на VPS.
Поэтому я за решение с использованием БД. Адрес короткого урла тоже довольно просто можно сгенерить, например: base62(index) . base62(md5(url)).
Я не из секты @nin-jin но мне в принципе понятно, как работает этот код. С root по clear - Это ссылки на DOM-элементы, а textContent и childNodes это нативные свойства элементов. И геттеры также работали бы, даже если бы не было вызова $mol_wire_dom. Очевидно, что реактивность над DOM можно получить за счет на подписок события модификации элементов.
Заглянул в $mol_wire_dom, так оно и оказалось.
А так, согласен с Вами, что нет легкого старта. Собственно, если высокий порог вхождения и нет явного коммерческого интереса, то туда никто и не войдет.