Здравствуйте, Reset, Вы писали:
S>>Если говорить про то, что сейчас. Сейчас его развивают компании, основной актив которых — сервера. Был бы странно, если бы в него добавили что-то настолько «антисерверное».
R>Это типа "у нас много серверов, давайте придумаем что-то, что их нагрузит не по-децки"... Так вряд ли кто-то думает. Сознательно создавать работу для своего оборудования никому не надо. Народ очень хорошо умеет деньги считать.
Лол. Так что ж они не сделают? Если сборка на клиенте действительно снизит нагрузку.
Здравствуйте, Shtole, Вы писали:
S>Какие были инженерные резоны против такого решения?
Статически подставить можно и на сервере (а это еще и кэширование), а динамически — все равно нужен скрипт, который и так может и include, и более сложную логику.
S>То, что был не нужен, не пишите — изрядная доля сайтов на PHP могла бы быть переведена на голый HTML.
На голый html без скриптов? Зачем собирать на каждом клиенте статическую страницу, которую можно было собрать на сервере без всяких пхп, только с SSI/ESI?
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, Shtole, Вы писали:
S>Какие были инженерные резоны против такого решения?
То, что документ не целостный получается? Да и смысл? Если можно собрать документ
из кусочков в браузере, то почему бы не сделать это сразу? (заранее собрать C-препроцессором)
Если речь же об #include управляемом условиями, данными форм, запросами из БД -- то это другое.
Это явно требует исполнения "скрипта" в браузере. Ну так собственно на JavaScript и можно
сделать "#include" путём XHR-запросов кусочков сайта и ручной их композиции (путём вставки
в нужное место DOM). Более того, если откинуть миллион новомодных фреймворков, то это всё
на самом деле относительно удобно делается на голом JS посредством форм (которые нужны, чтоб
адресовать элементы в DOM, иначе XPath-запросты в queryDocumentSelector писать больно муторно.
S>То, что был не нужен, не пишите — изрядная доля сайтов на PHP могла бы быть переведена на голый HTML.
Вот не понял мотивации вообще. Есть же SSI. Только чем он поможет? Как статический "#include"
на стороне сервера он вполне работает (но повторю тезис, тогда документ можно собрать заранее).
А если нужно условное включение кусочков документа -- для этого и есть PHP, который позволяет
собрать статический HTML-документ, отображаемый без JavaScript. Это отличие от подхода описанного выше.
А когда мешают в кучу jQuery/Vue/etc и генерацию статических страниц на PHP -- это от космической дурости.
Тут уж либо статика, либо динамика (javascript на клиенте).
Здравствуйте, ути-пути, Вы писали:
S>>Какие были инженерные резоны против такого решения?
УП>Статически подставить можно и на сервере
Можно и на сервере. Только это требует сервера
Просто у HTML есть огромное число применений, когда никакой сервер в принципе не нужен. А шаблонизация нужна. Иногда можно выкрутиться фреймами, иногда — скриптами, но всё это чертовски неудобно по сравнению с обычной подстановкой, и я не понимаю, почему в самом начале такую возможность не предусмотрели.
S>>То, что был не нужен, не пишите — изрядная доля сайтов на PHP могла бы быть переведена на голый HTML.
УП>На голый html без скриптов? Зачем собирать на каждом клиенте статическую страницу, которую можно было собрать на сервере без всяких пхп, только с SSI/ESI?
Здравствуйте, Shtole, Вы писали:
S>Можно и на сервере. Только это требует сервера
S>Просто у HTML есть огромное число применений, когда никакой сервер в принципе не нужен. А шаблонизация нужна.
В таком случае достаточно взять любой шаблонизатор и 1 раз заранее скомпилировать, если сервер не нужен, динамика не нужна, то все будет так как ты хочешь
Ну, лет 25 назад можно было говорить про увеличение объема на диске при таком подходе, но сейчас это смешно.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, fk0, Вы писали:
S>>Какие были инженерные резоны против такого решения?
fk0> То, что документ не целостный получается? Да и смысл? Если можно собрать документ fk0>из кусочков в браузере, то почему бы не сделать это сразу? (заранее собрать C-препроцессором)
У меня есть два вопроса и два возражения.
Вопросы следующие. Почему вдруг именно C-препроцессором? В Юникс-культуре его использовали для сборки файлов? Мой вопрос во многом обусловлен тем, что я плохо знаю древний Юникс. Не застал-с.
Второй вопрос. Я, к своему стыду, не знаю, как можно пользоваться сишным препроцессором отдельно от компилятора. Для меня это монолит. Точно можно? А в наши дни? В VS2019, например. Или в gcc.
Теперь возражения. Допустим, у нас шаблон на 100К и мы его вставили в 10 файлов. Это уже мегабайт. Я понимаю, что в наши дни, когда «двести метров джаваскрипта грузят текста триста байт» это мало кого волнует, но всё-таки. Только опять вот этого не надо: сервер, gzip... У HTML миллион применений, не везде есть возможность всунуть компрессор.
Второе возражение тут уже кто-то выдвигал (в другом контексте). Кажется, это был Sinclair. Но чтобы не было глухого телефона, я сформулирую его от своего имени, как сам понимаю (т.е. все вопросы ко мне, пожалуйста). Любой конвеер в IT это плохо, это ОЧЕНЬ плохо. От них надо по возможности избавляться. Если у вас в одном случае надо сохранить файл и отдать его в препроцессор, а во втором — просто сохранить файл, второй случай и надо предпочесть. Конечно, если вы хотите простое и недорогое решение. Если лохов путать, то, конечно, конвеер надо делать подлиннее, а шаги позаковыристее.
fk0> Вот не понял мотивации вообще. Есть же SSI.
SSI это server-side. Многие уже, наверно, и не помнят, что MSDN когда-то был приложением.
S>>>Если говорить про то, что сейчас. Сейчас его развивают компании, основной актив которых — сервера. Был бы странно, если бы в него добавили что-то настолько «антисерверное».
R>>Это типа "у нас много серверов, давайте придумаем что-то, что их нагрузит не по-децки"... Так вряд ли кто-то думает. Сознательно создавать работу для своего оборудования никому не надо. Народ очень хорошо умеет деньги считать.
S>Лол. Так что ж они не сделают? Если сборка на клиенте действительно снизит нагрузку.
Каким образом #include снизит нагрузку? Я вижу дополнительный сетевой запрос, который сильно затормозит загрузку страницы. Приведи пример и объясни, за счет чего будет снижена нагрузка.
Здравствуйте, Reset, Вы писали:
S>>>>Если говорить про то, что сейчас. Сейчас его развивают компании, основной актив которых — сервера. Был бы странно, если бы в него добавили что-то настолько «антисерверное».
R>>>Это типа "у нас много серверов, давайте придумаем что-то, что их нагрузит не по-децки"... Так вряд ли кто-то думает. Сознательно создавать работу для своего оборудования никому не надо. Народ очень хорошо умеет деньги считать.
S>>Лол. Так что ж они не сделают? Если сборка на клиенте действительно снизит нагрузку.
R>Каким образом #include снизит нагрузку? Я вижу дополнительный сетевой запрос, который сильно затормозит загрузку страницы. Приведи пример и объясни, за счет чего будет снижена нагрузка.
Я написал очень простую вещь: сейчас HTML развивают компании, основной актив которых — сервера. (Имея в виду Гугл с его Хромом. Как сказал один умный человек, сегодня бери сиплюсплюсный код, из которого он состоит, описывай, вот тебе и будет спецификация HTML, а остальное, включая W3C, просто ширма, чтобы скрыть этот неприглядный факт). Было бы странно, если бы они его развивали в направлении, в котором сервера не нужны.
Причём тут нагрузка? Надо было сразу написать, что она к делу отношения не имеет, а не задавать вопросы, из которых это следует.
Здравствуйте, ути-пути, Вы писали:
УП>Здравствуйте, Shtole, Вы писали:
S>>Второй вопрос. Я, к своему стыду, не знаю, как можно пользоваться сишным препроцессором отдельно от компилятора.
УП>
Здравствуйте, Shtole, Вы писали:
S>Я написал очень простую вещь: сейчас HTML развивают компании, основной актив которых — сервера. (Имея в виду Гугл с его Хромом. Как сказал один умный человек, сегодня бери сиплюсплюсный код, из которого он состоит, описывай, вот тебе и будет спецификация HTML, а остальное, включая W3C, просто ширма, чтобы скрыть этот неприглядный факт). Было бы странно, если бы они его развивали в направлении, в котором сервера не нужны.
Если кто-то сомневается, что Гуглу нахрен не нужен бессерверный HTML, и он его убивает, пусть попробует быстренько открыть .htm-файл на Андроиде. Хоть в чём: хоть в webview, хоть в Chrome, хоть в Mobile Firefox. А потом поделится рецептом.
Андроид был первой на моей памяти операционной системой, выпущенной после 98-ого года, в которой без плясок с бубном это оказалось не сделать.
Здравствуйте, Shtole, Вы писали:
S>Какие были инженерные резоны против такого решения?
Мое имхо: Чистый HTML — это язык разметки для вывода на экран, реализующий его модуль мог не знать ничего про сетевые протоколы.
Это сейчас любой браузер такая банка с червями, а на начальных этапах удобнее было разделять функционал.
Более того, в те времена комп большую часть времени не имел выхода в интернет.
Или это могла быть пришедшая на локальный SMTP-сервак почта в формате HTML. Тогда даже первое обращение к документу происходило при уже выключенном интернете.
Здравствуйте, graniar, Вы писали:
G>Мое имхо: Чистый HTML — это язык разметки для вывода на экран, реализующий его модуль мог не знать ничего про сетевые протоколы.
включаемый файл может лежать рядом. Зачем сетевые протоколы?
Здравствуйте, CRT, Вы писали:
G>>Мое имхо: Чистый HTML — это язык разметки для вывода на экран, реализующий его модуль мог не знать ничего про сетевые протоколы. CRT>включаемый файл может лежать рядом. Зачем сетевые протоколы?
Рядом, это где? Если браузер запросил http://site.com/index.html, то он его и получил, и не узнает, какие еще файлы ему нужны, пока не распарсит.
По идее, сервер мог бы сразу отдавать пачку файлов, как в MIME-сообщении.
Ну вот так реализовано оно было прародителями веба, не все сразу продумали.
Здравствуйте, graniar, Вы писали:
S>>Какие были инженерные резоны против такого решения?
G>Мое имхо: Чистый HTML — это язык разметки для вывода на экран, реализующий его модуль мог не знать ничего про сетевые протоколы. G>Это сейчас любой браузер такая банка с червями, а на начальных этапах удобнее было разделять функционал. G>Более того, в те времена комп большую часть времени не имел выхода в интернет. G>Или это могла быть пришедшая на локальный SMTP-сервак почта в формате HTML. Тогда даже первое обращение к документу происходило при уже выключенном интернете.
А картинки?
Если картинки можно держать во внешних файлах, почему нельзя кусок HTML'я держать во внешнем файле?
Ты же в файле a.html можешь указать <img src="i.png">
и открыть этот файл a.html локально у себя на компьютере в браузере
и браузер без всяких сетевых протоколов попытается прочитать файл i.png с диска
из той же папки где лежит a.html
почему так же нельзя было сделать
<include src="b.html">
?
Картинки это опциональная штука, если не получается загрузить, показывается текст из alt.
S>Если картинки можно держать во внешних файлах, почему нельзя кусок HTML'я держать во внешнем файле?
C недогруженным #include может похериться структура документа.
Чтобы этого не происходило, придумали фреймы. Которые, если не получается загрузить, показывают пустой прямоугольник.
Здравствуйте, Shtole, Вы писали:
S>Какие были инженерные резоны против такого решения?
S>То, что был не нужен, не пишите — изрядная доля сайтов на PHP могла бы быть переведена на голый HTML.
Тут проблема не столько в ответе, сколько в вопросе. Откуда у вас вообще эта идея про #include? Сишный #include — это такой убогий костыль, существующий исключительно из-за отсутствия более зрелой модульности в языке. Т.е. оно конечно работает и покрывает полтора сценария, но стратегически это тупик.
