Здравствуйте, D. Mon, Вы писали:

DM>Подобные вещи в vibe.d тоже давно есть, когда из простого класса/интерфейса с аннотациями автоматически генерится REST сервис, просто alex_public их не использует у себя.
DM>Пример использования такой генерации клиента и сервера:
DM>https://github.com/rejectedsoftware/vibe.d/blob/master/tests/restclient/source/app.d

Ну да, собственно вот http://vibed.org/api/vibe.web.web/registerWebInterface прямо в документации есть подходящий пример. Только вот мне не кажутся удобными эти url'ы, размазанные по всему коду. Гораздо удобнее, когда это всё задаётся в одном месте (в router'е, в главном файле приложения). А уж если приделывать свою автоматическую систему перевода, то вообще ничего хорошего не выйдет с таким подходом.

Здравствуйте, alex_public, Вы писали:

_>Здравствуйте, Ikemefula, Вы писали:

I>>Про то и речь — string. Где ты в стринге хочешь найти HTTPRequest ?

_>Ну так я тебя и спрашиваю, что будет если у нас в форме не одно поле, а десять — функция, у которой в прототипе десять string'ов? )

I>>Jade это аккурат asp.net 1.0, только синтаксического шума меньше — странная идея работать с декларативным представлением императивным способом.

_>Ну расскажи тогда какие сейчас существуют современные способы формирования страниц на сервере.

Как бы уже.

I>>Современные темплейты в JS это, в частности, Angular или Knockout.

_>Что-то у тебя какая-то каша в голове.

Не у меня, а у тебя. Ты показал и назвал вещи, котороые родом из прошлого века.

>Angular и т.п. — это браузерные фреймворки, работающие на клиентских машинах.

Правильно. Все что нужно ангуляру — источник данных в любом формате — xml, json и тд.

>А мы здесь обсуждаем серверный код.

Серверный код не должен смешивать данные с их представлением, что бы отдать это клиенту. Идея таких темплейтов аккурат из прошлого века.
Современный веб это отделение данных от их представления, чего в твоих темплейтах нет, ибо сервер отдаёт всё. Поменялась строчка — сервер отдаст новую html страницу. А это как раз и не нужно,.

Здравствуйте, Klapaucius, Вы писали:

K>А в хаскеле у нас вот что: если делать выводы из опыта использования UML с ООЯ с расширениями, то никаких проблем с использованием UML и для хаскеля не будет. Если, конечно, кто-нибудь захочет это сделать.

Не вижу логической связи между утверждениями в конце фразы и в начале. Фраза теоретически могла бы быть справедливой при одном из двух условий:
1. Хаскель — это ООЯ с расширениями.
2. В ООЯ с расширениями только эти расширения и используют, а классической частью вообще не пользуются.

Но насколько я знаю, оба эти утверждения не верны.

K>Ну да. В том и дело, что все примеры кода на хаскеле в этой теме, где работа с мутабельными данными есть, смотрятся не хуже, а даже лучше, чем код на C++/D. Именно потому, что в последних языках полно как всякой синтаксической шелухи, так и костылей, которые в нормальных языках не нужны.
K>Если сравнивать хаскель с каким-нибудь нормальным языком без контроля эффектов вроде окамла, то там хаскель-код будет хуже выглядеть из-за синтаксического штрафа за монадический/аппликативный код там, где на окамле можно без него обойтись. Но C++-образные языки обычно настолько страшные, что этот самый "синтаксический штраф" все равно погоды не сделает.

О, вы уже начинаете признавать то, о чём я говорил всё это время...

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

K>Я, например, приводил примеры преобразований кода, доступных благодаря контролю эффектов.

Ну так тогда вас не затруднит кинуть ссылку на конкретное сообщение ваше сообщение? )

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

Хорошая отмазка. ))) Может тогда стоит вообще прекратить дискуссию? )

K>Ладно аргументы — это громко сказано. Вы так ни разу не сказали чем конкретно вам не нравится монадический код и так ни разу и не показали, как такой код по-вашему должен выглядеть. Монады по вашим утверждениям всегда ужасны потому, что ужасны. (на самом деле, наверное, все-таки хаскельная система контроля за эффектами, потому что говоря "монады" вы подразумеваете именно ее)

А вот как раз это мы действительно уже обсуждали и я уже отвечал) Но могу повториться — мне не нравится что это навязанное ограничение (тем более оно выглядит глупо, т.к. при переходе от академических задач к практике, 90% кода уплывает в монады). Никто не мешал добавить в язык те же самые возможности, но опционально. Как в том же D. Хотя в нём это направление совсем не разработано, но я не вижу никаких теоретических препятствий на пути к достижению в точности хаскелевских результатов, но при этом без всяких "синтаксических пенальти". )

K>Видимо вы так пишите чтоб мне подыграть и сделать код на ди пострашнее. Понятно-понятно.

Ну лично мне кажется, что красивее написать q{a>b} или даже "a>b", но естественно можно и (x, y)=> x>y, если вам почему-то нравится только такой вариант. Как видите опять же полная свобода в языке.

K>Ну да. В индустрии некоторые виды недомапов называют мапами (а некоторые — не называют) если таковые недомапы вообще есть (в некоторых популярных языках их нет/не было в самом недавнем времени), потому что в индустриальных языках настоящий мап в настоящий момент нереализуем. Это нормальный подход, пока индустриальный разработчик осознает подводные грабли недомапа (и нормальный разработчик как раз их осознает). Похожая история, например с недосложением плавучки, которое из-за неассоциативности строго говоря сложением не является но называется таковым, а прилагающиеся к нему подводные грабли полностью осознаются.

Думаю, что часть осознаёт, а часть нет. Однако при этом большинство в любом случае подразумевают один и тот же объект при упоминание данного термина. )))

K>Действительно, откуда следует, что при сравнении интервалов времени, отличающихся на единицы процентов нужно учитывать погрешность измерения времени в единицы процентов? Непонятно.

Если результат измерения производительности будет отличаться на пару процентов, то можно смело считать производительность равной. )))

_>>Не те, но я абсолютно точно знаю во сколько раз обсуждаемая версия кода на D быстрее измеренной там версии с until.all.

K>Вы знаете, насколько 64-х битная версия примера написанная так, чтоб побольше памяти выделять медленнее дишной версии, которая этого не делает. 64-х битная версия по понятным причинам выделяет существенно больше памяти, чем 32-х бинтая, время которой измерял я. С очевидными последствиями для времени выполнения. Кстати, сколько байтов в дишном int на x64? В хаскельном Int — 8.

Ооо, кстати, действительно разница в результатах может быть от игр с разрядностью. Там и компиляторы по разному работают... В идеале надо отдельно проводить два тестирования:
1. компилировать в 32 битный код и запускать на машине с 32 битной ОС. Кстати, свои измерения для D я как раз так и делал.
2. компилировать в 64 битный код и запускать на машине с 64 битной ОС.

Причём результаты могут сильно отличаться. Например, помнится ещё недавно было время, когда gcc ощутимо обгонял VC на 64 битном кода и при этом проигрывал на 32 битном.

Кстати, у компилятора dmd есть ключики: -m32 и -m64. Всё очень удобно.

K>Кое-где есть, да. Но в прологе с этим добром дела обстоят очень плохо.

Ну так в моём то случае это не принципиально, т.к. все подобные вещи решает крутой C++ код, который мы прячем за соответствующими встроенными предикатами. )

Здравствуйте, Klapaucius, Вы писали:

K>Про то, что я это не замечаю — это, конечно, неправда. Мы даже уже осудили смехотворный объем этих размещений выше по ветке.

Объём действительно не большой, т.к. большего для данной задачки и не надо. И его всегда можно увеличить, если очень надо. Но мы в данном случае спорили совсем о другом. Так вы наконец то признаёте, что в том моём решение выделялось около миллиона полноценный иммутабельных объектов? )

Здравствуйте, Ikemefula, Вы писали:

_>>Ну расскажи тогда какие сейчас существуют современные способы формирования страниц на сервере.
I>Как бы уже.

Ты показывал пример реакции на ajax запрос. А ты мне покажи где собственно страница создаётся, с которой этот запрос пришёл.

I>Правильно. Все что нужно ангуляру — источник данных в любом формате — xml, json и тд.

Не только. Ещё ему нужно:
1. Как-то оказаться на компьютер пользователя.
2. Иметь декларативное описание (html тэги с их добавками) дизайна страницы.

Или по твоему эти два пункта какой-то магией реализуются? )

I>Современный веб это отделение данных от их представления, чего в твоих темплейтах нет, ибо сервер отдаёт всё. Поменялась строчка — сервер отдаст новую html страницу. А это как раз и не нужно,.

Ну так и чем это плохо на практике? )

Здравствуйте, alex_public, Вы писали:
...
I>>Современный веб это отделение данных от их представления, чего в твоих темплейтах нет, ибо сервер отдаёт всё. Поменялась строчка — сервер отдаст новую html страницу. А это как раз и не нужно,.

_>Ну так и чем это плохо на практике? )
Точно. Задолбали уже своими макросами.

Здравствуйте, alex_public, Вы писали:

_>Ты показывал пример реакции на ajax запрос. А ты мне покажи где собственно страница создаётся, с которой этот запрос пришёл.

На клиенте. Клиент получает шаблон, js, css, картинки — всё это статика. Сервер тупо отдаёт статику без какой либо самодеятельности.

_>Не только. Ещё ему нужно:
_>1. Как-то оказаться на компьютер пользователя.
_>2. Иметь декларативное описание (html тэги с их добавками) дизайна страницы.

Это статика. Её даже полу-сервер на джаваскрипте отдаёт быстрее, чем твоя генерированая по шаблону страница.

I>>Современный веб это отделение данных от их представления, чего в твоих темплейтах нет, ибо сервер отдаёт всё. Поменялась строчка — сервер отдаст новую html страницу. А это как раз и не нужно,.

_>Ну так и чем это плохо на практике? )

Тормоза. Конский трафик. Долгое время обновления UI.

Здравствуйте, Ikemefula, Вы писали:

I>На клиенте. Клиент получает шаблон, js, css, картинки — всё это статика. Сервер тупо отдаёт статику без какой либо самодеятельности.

ОК, понятно, шаблоны статичные. А на каком языке ты их пишешь? На голом html?

I>Это статика. Её даже полу-сервер на джаваскрипте отдаёт быстрее, чем твоя генерированая по шаблону страница.

А вот и нет. Выдача информации, генерируемой статическим кодом, в сеть работает быстрее, чем поиск информации на диске, чтение её и только потом выдача в сеть. Можно конечно попытаться оптимизировать выдачу статических страниц, разместив их где-то типа ram диска, ну или использовать всякие там memcached... Тогда возможно скорость станет близкой, но всё равно не факт что догонит. Естественно мы говорим о варианте страниц без каких-то дополнительных вычислений (типа обращений к базам данных и т.п.)

I>Тормоза. Конский трафик. Долгое время обновления UI.

Я говорю не о реакциях на нажатия кнопок на странице (отменять ajax глупо, скорее наоборот можно его больше внедрить в браузер), а о первоначальной загрузке страницы. Тебе нравится вариант, в котором грузится статическая страница с шаблоном и js скриптом, которая потом самая запрашивает себе данные. Так вот объясни какие преимущества привносит этот вариант с дополнительным запросом, в сравнение с вариантом, когда у нас отдаётся сразу страница и с шаблоном и с js и с данными (а вот при щелчках на ней уже работает ajax и нет никаких обновлений всей страницы).

Здравствуйте, alex_public, Вы писали:

I>>На клиенте. Клиент получает шаблон, js, css, картинки — всё это статика. Сервер тупо отдаёт статику без какой либо самодеятельности.

_>ОК, понятно, шаблоны статичные. А на каком языке ты их пишешь? На голом html?

На каком хочешь, на таком и пиши. Важно, что они отдаюся как статика, а процессятся на клиенте за смешное количество времени.

I>>Это статика. Её даже полу-сервер на джаваскрипте отдаёт быстрее, чем твоя генерированая по шаблону страница.

_>А вот и нет. Выдача информации, генерируемой статическим кодом, в сеть работает быстрее, чем поиск информации на диске, чтение её и только потом выдача в сеть.

Алё — я тебе о чем и говорю — статика отдаётся быстрее всего. Отдавать статику тупо статическим кодом это всего лишь один из сотен возмножных вариантов оптимизации, а есть еще серверные кеши, клиентские, промежуточные, CDN и всякая хрень.

>Можно конечно попытаться оптимизировать выдачу статических страниц, разместив их где-то типа ram диска, ну или использовать всякие там memcached... Тогда возможно скорость станет близкой, но всё равно не факт что догонит.

Не смеши. Ты хочешь процессить шаблон на лету, а это значит, что надо откуда то подтянуть все нужные данные. Наприер из базы и тд. Опаньки !

I>>Тормоза. Конский трафик. Долгое время обновления UI.

_>Я говорю не о реакциях на нажатия кнопок на странице (отменять ajax глупо, скорее наоборот можно его больше внедрить в браузер), а о первоначальной загрузке страницы. Тебе нравится вариант, в котором грузится статическая страница с шаблоном и js скриптом, которая потом самая запрашивает себе данные. Так вот объясни какие преимущества привносит этот вариант с дополнительным запросом, в сравнение с вариантом, когда у нас отдаётся сразу страница и с шаблоном и с js и с данными (а вот при щелчках на ней уже работает ajax и нет никаких обновлений всей страницы).

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

Здравствуйте, Ikemefula, Вы писали:

I>На каком хочешь, на таком и пиши. Важно, что они отдаюся как статика, а процессятся на клиенте за смешное количество времени.

Ну так на том же jade их гораздо приятнее писать, даже если они и будут статическими файлами на сервере. Ну и кстати если использовать шаблонизатор типа того, что в vibe.d, то это получается быстрее, чем отдача статического файла!

Т.е. вообще говоря идея в vibe.d не противоречит никакому варианту клиентского программирования. Мы можем хоть страницы с данными генерировать, хоть шаблоны для js фреймворка и реакции на ajax запросы за данными. И это будет в большинстве случаев быстрее аналогичных решений.

_>>А вот и нет. Выдача информации, генерируемой статическим кодом, в сеть работает быстрее, чем поиск информации на диске, чтение её и только потом выдача в сеть.
I>Алё — я тебе о чем и говорю — статика отдаётся быстрее всего. Отдавать статику тупо статическим кодом это всего лишь один из сотен возмножных вариантов оптимизации, а есть еще серверные кеши, клиентские, промежуточные, CDN и всякая хрень.

Ты не правильно прочитал фразу... ))) "Выдача информации, генерируемой статическим кодом" — это как раз работа шаблонизатора того фреймворка в D. А "поиск информации на диске, чтение её и только потом выдача в сеть" — это как раз отдача статического файла с диска.

I>Не смеши. Ты хочешь процессить шаблон на лету, а это значит, что надо откуда то подтянуть все нужные данные. Наприер из базы и тд. Опаньки !

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

I>Очевидно — время первоначальной загрузки меньше. Стилей, скриптов и картинок одинаково в обоих случаях, а моем будет загружен шаблон в пару килобайт, а у тебя полноценный html и чем больше размер страницы, тем сильнее будет тормозить твой вариант.

А с чего это ты не учитываешь последующий запрос за данными в твоём варианте? ) Зачем нам нужна страница без данных? )

Здравствуйте, alex_public, Вы писали:

_>Ну так на том же jade их гораздо приятнее писать, даже если они и будут статическими файлами на сервере. Ну и кстати если использовать шаблонизатор типа того, что в vibe.d, то это получается быстрее, чем отдача статического файла!

jade это asp.net 1.0 толко без скобочек. Ты точно думаешь, что вещица 13 летней давности это прорыв ?

_>Т.е. вообще говоря идея в vibe.d не противоречит никакому варианту клиентского программирования. Мы можем хоть страницы с данными генерировать, хоть шаблоны для js фреймворка и реакции на ajax запросы за данными. И это будет в большинстве случаев быстрее аналогичных решений.

Нет, не будет.

I>>Алё — я тебе о чем и говорю — статика отдаётся быстрее всего. Отдавать статику тупо статическим кодом это всего лишь один из сотен возмножных вариантов оптимизации, а есть еще серверные кеши, клиентские, промежуточные, CDN и всякая хрень.

_>Ты не правильно прочитал фразу... ))) "Выдача информации, генерируемой статическим кодом" — это как раз работа шаблонизатора того фреймворка в D. А "поиск информации на диске, чтение её и только потом выдача в сеть" — это как раз отдача статического файла с диска.

Покажи, где я говорю что статику надо отдавать не иначе как с диска ? Это ты себе какую то мантру придумал. Статика в большинстве случаев отдаётся напрямую или почти напрямую из RAM, например(например) это варианты кешей.

_>Речь была про выдачу статической страницы (в смысле без информации из бд и т.п.), но с помощью шаблонизатора.

Ты в самом деле думаешь, что генерировать и отдавать конскую страницу это быстрее, чем такую же статическую информацию но в пару килобайт кода ?

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

"два последовательных запроса" — тут я смеялся. У тебя и так будут последовательные запросы, например скрипты, стили, картинки.
Если всунешь это в один кусок, внезапно, последующие запросы будут педалить.

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

_>А с чего это ты не учитываешь последующий запрос за данными в твоём варианте? ) Зачем нам нужна страница без данных? )

Наоборот, я всё учитываю.

Здравствуйте, Ikemefula, Вы писали:

I>jade это asp.net 1.0 толко без скобочек. Ты точно думаешь, что вещица 13 летней давности это прорыв ?

Ну во-первых не просто без скобочек, ну да ладно, не будем вникать в мелкие детали. А почему обязательно прорыв то? ) Просто удобный инструмент. Это если мы говорим про jade (инструмент из node.js). А если говорить про Diet (аналог jade из vibe.d), то там действительно небольшой прорыв в связи с быстродействием этого решения.

I>Покажи, где я говорю что статику надо отдавать не иначе как с диска ? Это ты себе какую то мантру придумал. Статика в большинстве случаев отдаётся напрямую или почти напрямую из RAM, например(например) это варианты кешей.

Вообще то все http-демоны отдают статику как раз с диска. И решения типа размещения этого диска в оперативке я довольно редко вижу. Чаще применяются прокси между демоном и сетью, кэширующие запросы в оперативке. Но в любом случае это всё чуть уступает по скорости прямой записи как в vibe.d. Ну ты же сам должен понимать это. Смотри, если по показывать по упрощённой аналогии, то аналог обычного сервера это:

ifstream fs(url);
string s;
fs>>s;
cout<<s;

Аналог варианта с кэшем выглядит так:

map<string> table;
if(table[url].empty()){
    ifstream fs(url);
    fs>>table[url];
}
cout<<table[url];

А аналогом шаблонизатора будет тогда код вида:

if(url=="/index"){
    cout<<"hello ";
    cout<<"world";
}else if(url==...) {...}

Как ты думаешь, какой код эффективнее? ) Да, и понятно что писать код типа 3-го варианта руками — это бред. Но вот если научить компилятор генерировать его автоматически по некоторому удобному шаблону, то...

I>Ты в самом деле думаешь, что генерировать и отдавать конскую страницу это быстрее, чем такую же статическую информацию но в пару килобайт кода ?

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

Здравствуйте, alex_public, Вы писали:

I>>jade это asp.net 1.0 толко без скобочек. Ты точно думаешь, что вещица 13 летней давности это прорыв ?

_>Ну во-первых не просто без скобочек, ну да ладно, не будем вникать в мелкие детали. А почему обязательно прорыв то? ) Просто удобный инструмент. Это если мы говорим про jade (инструмент из node.js). А если говорить про Diet (аналог jade из vibe.d), то там действительно небольшой прорыв в связи с быстродействием этого решения.

Нет там никакого прорыва. jade и его аналоги это конец прошлого века. Вещи навроде MVC гораздо более удобны.

I>>Покажи, где я говорю что статику надо отдавать не иначе как с диска ? Это ты себе какую то мантру придумал. Статика в большинстве случаев отдаётся напрямую или почти напрямую из RAM, например(например) это варианты кешей.

_>Вообще то все http-демоны отдают статику как раз с диска.
...
_>Как ты думаешь, какой код эффективнее? ) Да, и понятно что писать код типа 3-го варианта руками — это бред. Но вот если научить компилятор генерировать его автоматически по некоторому удобному шаблону, то...

Я вижу, что статика почти с любого сервера отдаётся практически мгновенно, а всё остальное требует времени.

I>>Ты в самом деле думаешь, что генерировать и отдавать конскую страницу это быстрее, чем такую же статическую информацию но в пару килобайт кода ?

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

А ты покажи, как ты будешь отдавать и шаблон и данные для него в одном респонсе.

Здравствуйте, alex_public, Вы писали:

_>Вообще то все http-демоны отдают статику как раз с диска. И решения типа размещения этого диска в оперативке я довольно редко вижу. Чаще применяются прокси между демоном и сетью, кэширующие запросы в оперативке. Но в любом случае это всё чуть уступает по скорости прямой записи как в vibe.d.
ОМГ. А как насчёт отдачи статики без выхода из нулевого кольца? Добро пожаловать в мир http.sys.
Одно переключение в юзермоду для вызова вашего vibe.d будет стоить больше, чем всё время его работы.
Надо понимать, что редкий сайт сейчас хранит гигабайты статики (если мы не говорим про специализированные контент-хостинги); это означает, что коробочная Windows Server 2012 Web Edition способна отдавать HTML быстрее, чем любые ваши интерпретируемые фреймворки.

Искренне советую перед рассуждениями космического масштаба подучить матчасть.

Здравствуйте, Ikemefula, Вы писали:

I>А ты покажи, как ты будешь отдавать и шаблон и данные для него в одном респонсе.
теоретически всё можно получить на основе src="data:".
Но на практике я бы повнимательнее присмотрелся к вопросам кэширования: склеивание высокодинамичных (данные) и низкодинамичных (шаблон) видов контента выглядит не очень многообещающе.

Здравствуйте, Ikemefula, Вы писали:

I>Нет там никакого прорыва. jade и его аналоги это конец прошлого века. Вещи навроде MVC гораздо более удобны.

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

I>А ты покажи, как ты будешь отдавать и шаблон и данные для него в одном респонсе.

А в чём проблема то? ) Вот тебе примерчик простейший на тему шаблонов, данных и т.п:

- data=[]; for(var i=0; i<5; i++) data.push({name: "n"+i, value: "v"+i});
html(ng-app="Test")
  head
    script(src="angular.js")
    script
      | angular.module('Test', []).controller('TestCtrl', function($scope){
      |   $scope.data=!{JSON.stringify(data)};
      | });
  body(ng-controller="TestCtrl")
    ul
      li(ng-repeat="d in data")
        {{d.name}}:{{d.value}}

Здесь jade шаблон генерирует на сервере страницу, содержащую angular шаблон и данные для него. Да, кстати, а data вполне может быть взято из базы данных (локальной в данном случае, т.к. это серверный код), а не создано на ходу, как в примере.

Здравствуйте, alex_public, Вы писали:

_>Ты всё время путаешь клиентский код и серверный. И плюс тебе похоже кажется, что возможен только один вариант. Так что в упор не видишь вариантов, о которых я тебе говорю. Вполне реально могут сосуществовать в одном проекте и серверные и клиентские шаблоны. Причём одни могут генерировать другие.

I>>А ты покажи, как ты будешь отдавать и шаблон и данные для него в одном респонсе.

_>А в чём проблема то? ) Вот тебе примерчик простейший на тему шаблонов, данных и т.п:

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

_>Здесь jade шаблон генерирует на сервере страницу, содержащую angular шаблон и данные для него. Да, кстати, а data вполне может быть взято из базы данных (локальной в данном случае, т.к. это серверный код), а не создано на ходу, как в примере.

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

Здравствуйте, Sinclair, Вы писали:

S>ОМГ. А как насчёт отдачи статики без выхода из нулевого кольца? Добро пожаловать в мир http.sys.
S>Одно переключение в юзермоду для вызова вашего vibe.d будет стоить больше, чем всё время его работы.
S>Надо понимать, что редкий сайт сейчас хранит гигабайты статики (если мы не говорим про специализированные контент-хостинги); это означает, что коробочная Windows Server 2012 Web Edition способна отдавать HTML быстрее, чем любые ваши интерпретируемые фреймворки.

О, ну так раз вы так разбираетесь, то конечно же без проблем озвучите среднее время необходимое на переключение в нулевое кольцо и среднее время необходимое для считывания одного кластера данных со стандартного жёсткого диска? )

S>Искренне советую перед рассуждениями космического масштаба подучить матчасть.

Ага, ага. Видимо её надо подучить и подавляющему большинству проектировщиков высоконагруженных систем, т.к. они все почему-то сидят на nginx или собственных велосипедах, а не на "Windows Server 2012 Web Edition". )

Здравствуйте, Ikemefula, Вы писали:

I>Проблема в том, шаблон и данные меняются с различной частотой. Данные могут меняться несколько раз в секунду, а шаблон сильно вряд ли будет меняться хотя бы раз в день.

Ну так а следующие запросы к данным же идут через ajax, а не через обновление страницы. )

Здравствуйте, alex_public, Вы писали:

I>>Проблема в том, шаблон и данные меняются с различной частотой. Данные могут меняться несколько раз в секунду, а шаблон сильно вряд ли будет меняться хотя бы раз в день.

_>Ну так а следующие запросы к данным же идут через ajax, а не через обновление страницы. )

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

Это если использовать Ангуляр. А что твоими темплейтами ? Они ведь "как jade", то есть ничего подобного ангуляру не умеют и работают на сервере.