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

Не осилил читать всю дискуссию, но мнение имею. Другие языки, другие технологии, другие стандарты — их никому насильно не навязать. Но до распространения адаптивности и вот это вот всё у многих сайтов была мобильная версия: m.чототам.ru или типа того. Которые открывались хоть в lynx. И вот это как раз можно стандартизировать. Говорит тебе браузер: давай попроще, и ты ему такую версию отдаёшь. Отсталую, не интерактивную, ну так оно и не везде надо.

Говорит тебе браузер: давай попроще, и ты ему такую версию отдаёшь. Отсталую, не интерактивную, ну так оно и не везде надо.

Заманаешься юзерам объяснять, с какого суахили у него каких-то кнопок нет, тогда как у соседа есть.

Веб неоднороден. Он не весь состоит из интернет-магазинов, соцсетей и прочего интерактивного. Даже если представить, что статьи никому не нужны, есть лендинги вполне коммерческие. Кроме кнопки «дайте я дам вам денег» там хоть что-то интерактивное есть?

И юзерам ничего не надо. Просто простые браузеры получают упрощённую страницу.

вебкомпоненты работают на стандартизированных браузерных апи. У любой ноды дом дерева можно вызвать метод insertAdjacentHTML для вставки html из строки или даже по-старому, через присваивание строки в .innerHTML, но это уже не везде одинаково. При этом строка будет распарзена и если в ней есть теги кастомных элементов они будут проинициализированы как компоненты.

И юзерам ничего не надо. Просто простые браузеры получают упрощённую страницу.

Во времена, когда «у многих сайтов была мобильная версия», мобильный телефон был экзотическим способом доступа в интернет. А в 2024м это основной способ доступа. У ваших «простых браузеров» будет аудитория как у lynx

https://werc.cat-v.org/

https://suckless.org/

А кто за меня будет ходить на сервер по эвенту, чтобы получить новую порцию кода?

Вы путаете тёплое с мягким. Или иначе говоря, я вам про Васю, а вы мне про Петю.

HTMX никак не мешает использовать эти ваши компоненты и вообще не про то.

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

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

А то что он якобы нарушает стандарт, всем положить. Vue вон тоже нарушает со своими v-for, и ничего. Пусть у него и виртуальный DOM.

ох жеж:

https://softpanorama.org/Articles/Ershov/ershov72.shtml

Кто это?

Я мягкий знак забыл? Ой.

Тип на пол шишки решил присесть?))

Да, а что, нельзя?

Скажи лучше разрабам

Каким? У нас таких нет. Всё сами. Сами себе таблички рисуем и отчётики.

Можно конечно к БД тупо Microsoft Access/Excel подрубить, но Microsoft как-бэ не в почёте, как и гугол…

Да, а что, нельзя?

Пацаны говорят нельзя - не советуют)

Всё сами.

Стало быть это точка роста.

https://youtu.be/_CEBG_s92P8?list=RDQMNNFOzJIaCM0 Zed A. Shaw - The Web Will Die When OOP Dies

Считаю что важную информацию надо держать в текстовых файлах. А получать их через wget и читать в консоле. Тогда браузер вообще не нужен будет

Пока — возможного роста. Мне с текущей РАБотой даже на общественно полезную деятельность не хватает времени, не то что гугол таблички для бухгалтеров переписывать на что-то локальное.

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

Можно, конечно, и совмещать… Но, тогда будет гораздо сложнее. А мне чем проще, тем лучше. Керакс, керакс и в продакшен.

С одной сторны подписываюсь под каждым его словом, с другой, с 2012 действительно многое поменялось, и даже js теперь не такой убогий как раньше:

// теперь можно делать так
arr.forEach(({a, b}) => `${a} ${b}`);
// и так
const a = (...vars) => console.log(vars);
// и даже так
a(someVar, ...someArr);

Это тот самый сахар. И аудио, и видео, и кастомные элементы - все появилось. Надеюсь этот человек теперь счастлив)

Но хтмл по-прежнему - говоно, css - говно. Я в повседневности использую браузер как графическую платформу для весьма интерактивных приложений, которые используют и canvas и webgl и для меня все эти сложности оправданы. Но вот чтобы решить проблему этого человека

попроще нарисовать фронтэнд к бэку на python

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

https://perfectmotherfuckingwebsite.com/

И такие вещи тоже должны идти из коробки, а не со 105-ой попытки.

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

это и так уже произошло, очнись. периодически присылают например HTML5 уникодный на почту, ну а в TheBat движок всю эту фигню не показывает.

попробуй открыть «современный веб» в каком-нибудь Netscape 3.2/4.5

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

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

а что случилось? мы же за совместимость? а по факту её нет и не было никогда.

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

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

нет, это довольно не тривиально.

например, браузер Charon в Inferno занимает примерно 40-60k исходников.

там HTML 4.0 правильный парсится YACC-ом.

ну и догадайся сам, как выглядит в нём «современный HTML»

и когда этот «правильный парсер» в теории по факту совсем не работает.

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

они компактны – потому что и не должны много уметь в одном монолите.

в Dillo например плагинами сделали протоколы вполне компактно. чуть ли не shell скриптом на десяток строк.

PDF тоже интерпретируемый, по сути это подмножество интерпретируемого PostScript, только с бинарными потоками для компактности.

это да, там Display Model от PostScript плюс его виртуальная машина это упрощённый PostScript.

но сам по себе формат – это словарь ОО объектов с версиями и поколениями.

и некоторые потоки бинарные через текстовые кодировки.

то есть сам по себе формат – это ООБД. с некоторыми потоками чисто бинарными и не требующими интерпретации. с возможность открыть сразу нужную страницу из словаря объектов – а не интерпретировать всё предыдущее – как в PostScript.

с формами, цифровыми подписями и JavaScript для валидации форм в новых стандартах – там наворотили лишнего, впрочем.

где-то и анимации на JavaScript в таких PDF видел.

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

и это более правильный способ ибо базовая запускалка «компонент» и не должна сильно много уметь.

зачем мне к примеру смотрелка PDF реализованная через js в монолитном браузере?

зачем мне зависимость от GPU и прочих кодеков в монолитном браузере?

зачем мне javascript вообще – если только не сам интерфейс GUI браузера на него сильно завязан как в Mozilla Chrome и XUL?

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

со всеми недостатками объектной модели С++ и GIL в интерпретаторах JS и самом рендер движке этих XUL-подобных компонент либо ещё жырнее в Blink.

на лиспе тут могло бы быть CLOS с мультиметодами и метаобъектный протокол.

то есть совершенно другой, более правильный DOM.

например, в том же CURL хотя там объектная модель не лисповая в духе CLOS а всё ещё обычная мейнстримная – MVC сделано отдельным модулем, библиотекой.

которая не обязана завязываться на всякие костыли типа «virtual DOM», «shadow DOM» и прочее.

DOM — это API для дерева объектов на странице.

навязывающее GIL, блокировки, недостатки С++ объектной модели и прочее

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

всё должно писаться на компактном модульном лиспе с повышенной рефлексивностью, акторами встроенными в язык, first class objects = first class environments встроенными в язык.

затем эти разные DSL лиспа могут транспилироваться через лисп в итоговый С.

который может использовать обычные С (или чуть сложнее, С обёртки к С++) батарейки.

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

скорее на повышенной модульности и раздельной компиляции самодостаточных лисп-объектов, реализованных через акторы изначально асинхронно без всяких там GIL и прочих блокировок.

separate compilation а не independent compilation и модульное а не монолитное.

Контент, разметка, стили и код перемешаны ещё хуже

потому что они пытались максимально копировать HTML только с {такими скобками} а <не такими тегами>

но тем не менее. есть обычные полноценные процедуры, функции и классы.

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

логично что здесь могут быть и какие-то compile time макросы.

но в основном, ещё есть dynamic переменные. которые можно тупо связать сразу с виджетом как в matlab, red/rebol реактивном или каком-нибудь там jupiter notebook.

без всяких обёрток ненужных в духе DOM, или тех же костыльных сущностей типа shadow/virtual DOM

потому что нужен не DOM с ОО моделью мейнстримовой в стиле C++ и сложный его API со встроенным GIL

а скорее CLOS и MOP. или вообще просто тупо динамические переменные виджетов, гаджетов – вообще БЕЗ всякой объектной модели (она там тупо и не нужна), ну в крайнем случае возможно что-то компактное как в том же RED с лайвкодингом и реактивностью и экселем в 14 строчек на реактивности.

При этом нельзя сказать, что сам язык более выразителен в плане кода, чем TypeScript.

он всё же более выразителен – ибо это по сути лисп только в новомодных {curly braces}

лисп в духе Dylan с алгольным синтаксисом, схемы goo с Functional Objects объектами

с макросами, динамическими и лексическими областями видимостями, и прочими прелестями.

только ООП там не правильное, шибко мейнстримное.

ещё лучше было бы то же CLOS из Common Lisp либо ILOS из ISLISP.

вот например, берём eisl ISLISP который элементарно с Си интегрируется, с тем же tk.

и изображаем на нём first class environments.

в общем, исходники того же curl 1.0 изначального конца 90х начала 2000х годов на сайте с соотвествующими whitepapers показывают прототип, который тупо в с конпелируется и tk виджеты использует.

реализуя 120% функционала типичного браузера и веб-страничек (учитывая что в tk можно добавлять например свои виджеты, контролы).

вот в примерно этом направлении и нужно двигаться – а немного не в том, в котором CURL RTE современный (8.0-версии, кажется?) с апплетами в браузере движется.

нужна тупо запускалка апплетов модульных компонентных простых и лёгких акторных а не монолитное барахло на 30Гб в которое всё там заколочено на С++ так что наглухо не отдерёшь.

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

более правильные веб-технологии могли бы быть проще и легче – если избавиться от С++ и его объектной модели; монолитности браузера; навязанных DOM, GIL, JS костылей и подпорок.

проще срыть всё это нафиг ненужное и сделать более правильный веб заново – на модульном акторном лиспе с first class environments без всех этих ненужных костылей.

это уже не исправить – жги господь

или на red взять реактивность и акторы, на red/system написать что-то типа kernel_abe64 и поверх такой kernel лисп с vau конпелируемый в red/system с C-подобным ABI. red/system по сути примерно тот же си только в новой упаковке.

в общем, виджеты можно брать и не из tk а из ребола и red VID например.

REBOL iOS, «internet OS» – отличная же идея была. как раз про более модульные, компактные самодостаточные интернет-объекты.

были и странички с reblets и прочие удобно программируемые объекты.

ещё до RED для rebol 2 и особенно rebol 3 какой-то акторный фреймворк написали.

а например chayenne вместо апача – это веб-сервер написанный на REBOL и ASP/PHP-подобными тегами со страничками со встроенными реболом.

вики и форумная bbs там очень компактные получались.

пытались уже. WML не взлетело на мобилках.

Сайты на древних технологиях

это BBS

через curl (которая утилита) можно и в гофере.

ещё бы запускать curl (который язык) – конпелируемый кибертекст, а не недоделанный гипертекст.

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

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

HTML – говно, CSS, DOM – говно. гипертекст в таком виде – говно.

javascript тоже говно.

веб-программеры суть веб-макаки.

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

но для этого нужно смотреть сквозь скобки на суть его семантики.

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

сочувствую морской свинке – она и не свинья и плавать не умеет.

и соболезную javascript – который ни к java, ни к script имеет весьма опосредованное отношение.

эстетика современного веб – это dive into python/javascript/whatever ещё новомодное, вот это вот всё.

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

поэтому даже COPYBOOK в древнем коболе ближе к просветлению – к литературно грамотному, точному описанию нужной семемы, структуры, модуля – чем #include <говно.hpp> или require говно.js там где модулей по сути то и нет.

литературное, грамотное программирование := структурное объяснение + структурное программирование.

COBOL, REBOL, ALGOL ближе к изначальным истокам правильной, грамотно точной семемы, концепции, слоя, аспекта.

чем монолитное плохо структурированное говно на C++ или прочем супе из тегов, концепций, шаблонов через шаблоны богу шаблонов, конпелируемое по два часа с метанием икры на 30гб.

лисп бы мог это исправить, потенциально. но эстет Дейкстра ниасилил лисп, обосрав PL/I и кобол по ходу.

тупо, вот читаем recursive.pdf Джона Маккарти про математическую нотацию лиспа через частично определённые функции

Recursive Functions of Symbolic Expressions and Their Computation by Machine, Part I
John McCarthy, Massachusetts Institute of Technology, Cambridge, Mass. ∗ April 1960

пруфлинк

и вроде бы – ну да, всё понятно. эстетично, красиво же, мультистадийно и метациклически.

а читает эту статью, например Эдсгер Дейкстра – и смотрит в книгу, а видит – фигу.

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

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

и про «структурное программирование» хайпануть и протроллить:

те, кто обучают бейсику или коболу – вредители, их дальше не исправить, господь

и это «структурное программирование» превращается в очередной hype и cargo cult programming structured_programming_as_religious_cult

вообще, любопытно за последнее 40 лет посмотреть волны моды и волны хайпа в программировании.

наверное ООП тоже одна из таких же волн.

с другой стороны, вот Дональд Кнут умел писать книжки. но не понимал как писать программы.

«решение очевидно», yo dawg – писать программу как книжку.

писать на алголе, на SAIL, на паскале. метатекст и кибертекст.

из которого одной утилитой метапрограммировать в tangle исподников, а другой weave – в красивую, эстетически правильную pretty printed документацию со всеми индексами, оглавлениями и гиперссылкаме.

писать для людей что, а не для робатофф как.

до сих пор TeX the program and the book читать приятно. хотя некоторые его решения (например, почему не 8-bit free а cork encoding, зачем там кодировать нечто старшим битом) – вызывают удивление.

с другой стороны, это было за 10 лет до уникода и за сколько там лет до PDF и TTF.

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

или вот для того самого Pascal-H изначального что в книжке – нормальную реализацию сделали.

похоже в tectonic примерно это и происходит – процедурными AST макросами раста пишут недокомпилятор этого самого Pascal-H.

в общем, символизм как миропонимание.

говорит о том, что помимо эстетики и пассивного миросозерцания, любомудрия и прочего мировозрение – активное -понимание получается не само собой,а в процессе некоторого перфоманса.

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

художник-символист по Андрею Белому (математику Николаю Бугаёву) – это тот, что понимает «законы сохранения» духовных объектов (в духе всякого там Н.Кузанского, треугольников, кругов бесконечного радиуса с центром в нигде, дифференциальной алеброгеометрии а не только лишь начал евклидовых) — то есть, для них так же как и для мат. объектов тоже справедливы некоторые законы развития, теоремы в духе евклидовых начал, монады и коэффекты, эндоморфизмы, изоморфизмы и зигохистоморфные препроморфизмы – вот это всё, для духовных объектов.

для этих символов есть свои законы развития тех. систем, ЗРТС ну почти.

как миропонимание.

пока что мы имеем в существующих веб-технологиях самый примитивно реализованный гипертекст.

он мне чисто эстетически даже не нравится.

всё это давно уже превратилось в плохо структурированную кашу в духе cargo cult programming.

ибо мейнстрим, С++, java, Bulb programming – вот это вот всё.

Feature considered harmful

EEE =>

1. Steal
2. Add Bloat
3. Original Trashed

«Разумный человек приспосабливается к миру; неразумный — упорно пытается приспособить мир к себе. Поэтому «прогресс» зависит от неразумных людей» — Б. Шоу.

т.н. «прогресс» is-a лишняя feature ползучего featurism-а.

назад, в опрощение.

или has-a. там композиция или агрегация?

Если когда-либо А.Хейли напишет роман «Вычислительный центр», вы увидите, что это будет самый увлекательный его бестселлер.

«А я был в компьютерном городе!» обложка энциклопедия профессора Фортрана и его энциклонги

пикча tl;dr tlDOr

В. Одоевский воляпюк «Городок в табакерке»
В. Одоевский 4338-й_год:_Петербургские_письма 1835 год – про блоги и социальные сети с инстаграммами, фотками котиков и фотографиями еды, блогозаписи и магнетические телеграфы с камера-обскуро-нот-со-смартфонами

Городок в табакерке

страшная повесть для бесстрашных школьников

В. Одоевский

В 1823—1825 годах председатель юношеского общества любомудров

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

Откуда ты такой на свет вылез? Это не сахар, а конкретное решение определённых задач.

А то, что FP надо учить, чтобы не писать дичь, этор

одно из ибо : https://codeforces.com/blog/entry/2139

писк какой-то слышу…

Бэкуса?

модульный лисп

А что не кобол, или там брэйнфак. Всегда в какой-то момент выползут аникейщики с идиотскими предложениями.

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

В новом вебе что-то лучше стало? Или браузеров меньше стало?

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

Зарегистрируйся на https://galya.ru/ и общайся там на здоровье. Хоть из землянки с аналогом IBM PC XT.

векторный федянет?

Ты выбрал ДВА частных случая, и на основании этого утверждаешь, что JS не нужен в принципе. Cherry picking — очень плохой способ доказать свою правоту

блог одной из разработчиц OpenBSD — dataswamp.org/~solene

этот пост - самая интересная информация, которую удалось получить в сети за последнее время.

я на 6 дней завис конкретно на одном этом ресурсе на Old Computer Challenge.

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

и на основании этого утверждаешь, что JS не нужен в принципе

Такого я не утверждал. Читайте внимательней.

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

Как будто на роутерах нет никакого бекенда

Предлагаю подумать над тем, как бы выглядел, например, Google Docs без JS на клиенте

Существование Google Docs — это отличный аргумент против JS, а не за. Браузер не для этого нужен, такое должно быть отдельной софтиной.

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

Что это за религиозные подходы? «Не для того тебя Господь создал чтобы ты <небогоугодное деяние>…». Глупости это, если работает и приносит пользу - значит для того, нет никакой скрижали, которая бы диктовала, вот тут браузер использовать кошерно, а вот тут - харам.