LINUX.ORG.RU

Сайты на древних технологиях - Во имя бобра!

 , , ,


5

3

LOR славится своими специалистами по самым шизанутым вопросам. И вот у меня их есть.

Короче, современный веб - это звездец. Сайты жрут дохера ресурсов, бесконечные прокрутки, оптимизированный под мобилу размер текста итд.

У всего этого много разных причин, но одна из них - а потому что современные веб-технологии это позволяют.

Что же касается негативных эффектов у этой ситуации, то есть один, о котором задумываются редко. Чем сложнее веб - тем сложнее создать и поддерживать под него веб-браузер. Соответственно, рынок браузеров поделён между буквально несколькими крупными игроками: Хром Идж Фокс Сафари, а остальные браузеры в рамках статпогрешности. И это не есть хорошо.

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

Короче идея такая чтобы сайты были на примитивных технологиях. Но не ради прикола или ностальгии, а так сказать с практическими целями: А) Чтобы работало на медленном коннекте (не везде в мире интернет быстрый, да и приколы со всякими замедлениями итп никто не отменял), Б) Чтобы не жрало ресурсы (опять же, не у всех в мире компы мощные, и ситуации в экономике тоже бывают разными: сегодня у тебя типа блокчейн крипта нейронки, а завтра ты в землянке с аналогом IBM PC XT из веток), В) Чтобы работало не только в крутых мейнстримовых брозуерах, но и в стареньких или доморощенных.

Я бы запилил, но у меня лапки. Может оно уже есть?



Последнее исправление: jsx_ (всего исправлений: 2)

Короче, современный веб - это звездец.

Веб всё время своего сущестования оценивался как «звиздец», потому, как он всегда потреблял много ресурсов. Когда половина пользователей работала под DOS в строю были 286 и 386 машины, HTML тоже выглядел как трата ресурсов в пустую.

lbvf50txt
()

Cначало, для реализации реализации, подобных затений нужня упростить стек используемых web - технологий, и сделать на уровне стандарта, пусть даже неофициального. Вернуть к сути первых версий html, убрать все лишнее. Как это реализовать? Здесь нужны идеи и люди, готовые их воплощать в реальность, с последним большие проблемы.

nager
()

парни, если кто не понял: я не призывал отказываться от js.

и тем более от нормального отображения изображений (как учудили шизики в gemini)

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

вы вообще читать умеете?

anonymous
()
Ответ на: комментарий от egzakharovich

HTMX нарушает стандарты HTML, по которым у элементов могут быть только определенные поддерживаемые браузерами атрибуты, а все остальное размещается в data- атрибутах. За невалидную разметку ваш результат может быть пессимизирован поисковыми системами или об нее могут ломаться разные библиотеки. Все тоже самое, что предлагает HTMX только по-человечи, можно сделать при помощи WebComponents и CustomElements определив свои компоненты с какими-угодно атрибутами и кодом за ним стоящим.

Syncro ★★★★★
()

на старых технологиях код получался тяжелым для поддержки и развития с проблемами в плане модульности и производительности. На технологиях типа популярных фронтенд фреймворков (react, vue, angular) он остается не очень эффективным плане производительности(т.к. они колхозят софтверный рендеринг), но это становится заметно восновном на больших проектах. И такой код получается полным всяких казуальных решений типа перемешивания верстки и кода или процедурного стиля кодирования, или типанебезопасное связывание слоев. На веб-компонентах можно писать нормальный модульный ООП-код со сложной бизнес-логикой для фронтенда.

Syncro ★★★★★
()
Последнее исправление: Syncro (всего исправлений: 1)
Ответ на: комментарий от anonymous

вы вообще читать умеете?

Привыкайте. На форумах и в чатах мало кто вникает в детали поста. Чем больше букв, тем меньше процент вникающих.

lbvf50txt
()
Последнее исправление: lbvf50txt (всего исправлений: 1)

Короче идея такая чтобы сайты были на примитивных технологиях.

Если сайты пишут программисты для программистов, то правило хорошего тона - сайт может функционировать без JS. Как следствие практичекски не потребляет ресурсов, не требователен к версии браузера. LOR тому яркий пример. Грубо говоря, чем серъездней проект, тем меньше он зависит от JS на клиенте (не всегда, но часто).

lbvf50txt
()
Последнее исправление: lbvf50txt (всего исправлений: 1)
Ответ на: комментарий от lbvf50txt

чем серъездней проект, тем меньше он зависит от JS на клиенте

Предлагаю подумать над тем, как бы выглядел, например, Google Docs без JS на клиенте (куда уж серьезней) и навсегда перестать педалировать эту тухлую тему.

FishHook
()
Ответ на: комментарий от FishHook

Google Docs - это проект общего пользования. Пример сайта написанного программистами для программистов это сайт с версиями ядра Linux.

Примеры:

https://www.kernel.org/
https://llvm.org/
https://distrowatch.com/

lbvf50txt
()
Ответ на: комментарий от lbvf50txt

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

FishHook
()
Ответ на: комментарий от Syncro

На веб-компонентах можно писать нормальный модульный ООП-код со сложной бизнес-логикой для фронтенда.

Как бороться с требованием уникальности имён этих компонентов?

static_lab ★★★★★
()
Ответ на: комментарий от static_lab

Это не проще. Такое себе может позволить Microsoft, выделить отдельную команду на разработку приложения. И вообще делать приложение без JS - это «пацаны не поймут», такой подход понимают и ценят только в рамках определенной культуры.

lbvf50txt
()
Последнее исправление: lbvf50txt (всего исправлений: 1)
Ответ на: комментарий от Infra_HDC

Модуль CGI вынесли из базовой поставки Perl, теперь он требует несколько зависимостей, но хоть можно архив скачать и забандлить что бы этим CPAN не пользоваться. Как шаблонизатор мне больше нравится HTML::Template, а Catalyst слишком жирен.

Учитывая количество зависимостей в Perl, PHP самое то, много не требует, работает быстро, все есть из коробки.

MOPKOBKA ★★★★
()
Последнее исправление: MOPKOBKA (всего исправлений: 1)
Ответ на: комментарий от static_lab

это обычная инкапсуляция и с ней не надо бороться. Вы можете зарегистрировать любое число новых компонентов унаследовашись от существующих. Был элемент my-button, сделали my-sidebar-button из его наследника и там навертели как захотели.

Syncro ★★★★★
()
Ответ на: комментарий от witaway

Я предлагаю пофантазировать о другом.

Просто представь весь веб, построенный на открытых HATEOAS апишках. В то же время браузер — это система управления рендерерами, которые сами, имея апишные данные, билдят страницы для отображения.

Остаётся придумать что-то вроде «соглашений» или «протоколов». Мол вот такая форма данных — имеет вот такую семантику. Её можно отображать вот таким образом. Название протокола можно передавать как HTTP-заголовок.

Всё концепции современных HTML и CSS сохраняем, но не для браузера, а для рендерера, который реализует тот или иной протокол.

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

современные сайты и браузеры сделаны неправильно. это путь в никуда из-за требований с совместимостями движка и прочими его quirks особенностями реализации некорректного html.

исходники firefox 2Gb, blink 20Gb (до 30 при сборке).

это тоже путь в никуда. поворот в никуда.

dillo, netsurf и прочие более компактны ибо написаны на С.

но в целом, сам веб структурирован неправильно. интерпретируемый JavaScript вместо компилируемых документов типа бинарного PDF (но реализованного как ООБД объектов).

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

вот возьмём например язык CURL: CURL old.computerra

и посмотрим на его ранние 1.0 версии, с выложенными исходниками.

здесь есть одна сильная унифицирующая идея: один язык вместо CSS, HTML, JS – унифицирующий их всех.

язык типа лиспа, в котором есть документ-литерал и {теги в {curly} {{braces} {скобочках} }

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

а в {тегах} – лисп-подобные макросы. и можно делать динамические переменные, прицепляемые к гаджетам, классы, процедуры.

в ранних версиях это всё транспилировалось через схему в си и tk виджеты, потом выполнялось в VM в песочнице.

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

можно взять какой-то компактный лисп, например, схему Kernel c vau-expressions от John Shutt и first class objects, first class environment.

например, эту реализацию на акторном языке (поверх Си, но можно и например, rust или pony): organix/kernel_abe64 Semantic Extensibility with Vau

It’s actors all the way down!

так что браузер теперь должен стать запускалкой таких curl-подобных объектов на лиспе вроде kernel с first class environments.

и веб-страницы автоматически становятся компилируемыми, а не интерпретируемыми.

то есть, рендерер пишется не на каком-то там DOM а например на обычном нормальном языке.

при этом вся страница формируется динамически.

см. примеры в wikibooks: Curl.wikibooks

например, Example6 со штрих-кодами

или чятик в браузере Example5

круги определяя свои классы и теги Example4

таблица формируемая динамически Example3

anonymous
()
Ответ на: комментарий от anonymous

парни, если кто не понял: я не призывал отказываться от js.

а я призываю. js не нужен – нужен curl или kernel scheme, kernel abe_64 на котором свой curl на tcl/tk переизобрести.

и тем более от нормального отображения изображений (как учудили шизики в gemini)

html странички прекрасно качаются через гофер, со всеми картинками.

curl странички ещё лучше качались бы в конпелируемый гипертекст.

anonymous
()
Ответ на: комментарий от static_lab

поэтому регистрация компонента должна происходить не внутри, а снаружи, в идеале после конфигураций компонентных классов, тогда можно определить Dependency Injection и все такое, как вот тут например:

https://www.npmjs.com/package/skinny-widgets#connections

Ну если кто-то назовет, вы можете зарегистрировать свой my-super-sidebar-button, имена тегов это условность если у вас компоненты конфигурируемые или изолированные. Я для решения по ссылке выше определился так, что если в ходе связывания выясняется, что компонент уже зарегистрирован, то мы его не инициализируем повторно, не пытаемся заменить, а переиспользуем как родной, и так у меня получилась модульность. А вообще можно по-разному придумать, можете реализовать неймспейсы на уровне имен тегов при конфигурировании и связывании.

Syncro ★★★★★
()
Последнее исправление: Syncro (всего исправлений: 4)
Ответ на: комментарий от Radjah

Да не, нужна адаптация под реалии. Ну например декларативное описания ajax. Например, автоподгружаемый список и т.д.

Правда тут в том, что как md заточен под написание статей, так эта штука должна быть заточена под работу с сайтами (магазинами, форумами и т.д.).

special-k ★★★★
()
Последнее исправление: special-k (всего исправлений: 2)
Ответ на: комментарий от FishHook

и он будет летать и грузиться за сотую долю секунды

Это с каких пирогов он так начнет работать?)))) Тормозит ВСЕГДА бэк. Фронт старается это маскировать как может (поэтапной загрузкой, аккуратными запросами (без лишних данных), превьюшками, лоадерами, прочей херней). Хотите кинуть юзера в пучину веба 1.0?) Ну удачи)))

special-k ★★★★
()
Ответ на: комментарий от Radjah

Ну да, я об этом и говорю. Браузер чрезвычайно мощный и гибкий инструмент в плане визуализации. А здесь речь и идет о более узкой задаче «нормального» отображения текстовых данных с некоторым количеством изображений. Также неплохо бы как-то учитывать стиль оформления ОС.

Я кстати понял, это надо на флаттере писать.

special-k ★★★★
()
Последнее исправление: special-k (всего исправлений: 1)
Ответ на: комментарий от anonymous

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

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

прочими его quirks особенностями реализации некорректного html

Алгоритм разбора некорректного HTML специфицирован и занимает незначительную часть кода браузера. Quirks mode скорее всего реализован просто альтернативным встроенным CSS специально для этого режима. Это довольно тривиально.

исходники firefox 2Gb, blink 20Gb (до 30 при сборке)

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

dillo, netsurf и прочие более компактны ибо написаны на С

Они компактны, потому что почти ничего не умеют. У Dillo, кстати, большая часть кода всё-таки на C++.

интерпретируемый JavaScript вместо компилируемых документов типа бинарного PDF

PDF тоже интерпретируемый, по сути это подмножество интерпретируемого PostScript, только с бинарными потоками для компактности. Кстати требования тщательного аккуратного разбора бинарного формата никто не отменит, ибо иначе можно получить уязвимости. Если бы JavaScript прилетал в виде промежуточного байткода, это принципиально ничего бы не изменило. Кстати вот сейчас так прилетает код WASM.

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

Чудес не бывает. Либо будут компактные аплеты, но жирная виртуальная машина, либо компактная виртуальная машина, но жирные аплеты. В первом случае в пределе имеем существующие браузеры, которые поддерживают кучу технологий. Во втором это будет виртуальная машина, которая сама почти ничего не умеет типа WASM, а аплеты будут тащить за собой все графические библиотеки, растеризаторы шрифтов, парсеры форматов и прочее.

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

то есть, рендерер пишется не на каком-то там DOM

Рендерер в браузерах пишется не на DOM, а на плюсах (ну или на расте), DOM — это API для дерева объектов на странице.

браузер теперь должен стать запускалкой таких curl-подобных объектов на лиспе вроде kernel с first class environments

а например на обычном нормальном языке

Всё будет писаться исключительно на лиспе или код из другого «нормального» языка типа C++ должен будет транспилироваться в лисп?

и веб-страницы автоматически становятся компилируемыми, а не интерпретируемыми.

Я так понимаю, вся фиксация исключительно на идее компилируемости?

см. примеры в wikibooks: Curl.wikibooks

Контент, разметка, стили и код перемешаны ещё хуже, чем в React + Styled components. Там хоть как-то стараются разделять эти сущности. При этом нельзя сказать, что сам язык более выразителен в плане кода, чем TypeScript.

static_lab ★★★★★
()
Ответ на: комментарий от Syncro

Я не веб-макака, а сисадмин. И про HTMX я узнал, пока пытался понять, как попроще нарисовать фронтэнд к бэку на python, чтобы не пришлось обмазываться nodejs и тем более — npm.

Но на сайте webcomponents.org я так и не нашёл, каким образом мне CustomElements помогут заменять куски HTML страницы, по эвенту, на то, что нарисовал и прислал сервер.

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

egzakharovich
()
Ответ на: комментарий от MOPKOBKA

Что по вашему определению «нормальные» сайты?

Кроме ЛОРа и opennet. Они не считаются, потому что им многалет и пережили взлёт и падение 100500 фреймворков, не особо меняя своей сути и не переписываясь.

egzakharovich
()
Последнее исправление: egzakharovich (всего исправлений: 1)

Я тоже за все хорошее и против всего плохого, так что на тебе два чая.

А теперь предлагаю подумать, как это реализовать? Сами по себе и HTML5, и JS, и СSS полезны. Видео как-то надо показывать, содержимое желательно динамически менять без обновления страницы, содержание важно отделить от формы. Проблема не в технологиях, а в методологии разработки, где ехал фреймворк через фреймворк, видит фреймворк во фреймворке фреймворк. Потому что разработчик дорогой, а электронный мусор дешёвый.

То есть, нам нужны не древние технологии, а некий стандарт ванильности и лёгкости.

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

Ну и народ-то где? Сайты - сплошные соцсети, екоммерс и банкинг. Быстро работает только банкинг и ЛОР. А хоумпаги мертвы. Василий Пупкин нонеча сам в соцсетях.

Vidrele ★★★
()
Ответ на: комментарий от egzakharovich

Я сисадмин

Кто это?

не пришлось обмазываться nodejs и тем более — npm

А это, есть основное предназначение костыля в виде HTMX.

Тип на пол шишки решил присесть?)) Скажи лучше разрабам, они запилят за 5 минут без этих всяких твоих суеверий.

special-k ★★★★
()
Последнее исправление: special-k (всего исправлений: 1)