"наглая" ложь. Это все не я. Надо писать говнявый код чтоб его коментили(пиши в ЛС научу его писать, за отдельную плату )

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

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

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

ЗЫ Ладно,иду домой ,надеюсь мой комп малые не угрохали

Это решается банальным асинхронным запросом, конечно сложнее в реализации с шаблоном, но всё же. Они включают синхронные запросы ajax после чего вешается страница.

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

Как сказать, как сказать ...
Для каждой задачи свой вариант, но для чистой событийной нет смысла городить огород из MVC, хватает FronController->PageController->(Mapper)->LayerDB->View

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

redreem

Ну в корне не согласен,анимация ,да туповато -медленно,хотя с простыми вещами справляется.Но динамика - это не только анимация.Возьми обычные формы,таблицы,окна и т.д.
Если нужна афигеть графика и анимация,тут понятно что выбор только за флешем,кстати комбинировать его с JS не является проблемой.Все достаточно симпотно получалось.
Насчет тупости страниц,ну не трудно сравнить сколько нужно аяксу данных и сколько на перезагрузку всей страницы.Кроме того JS кешируется браузем,если его прописать в ХТМЛ ,
если будем подгружать в динамике,тогда да,будем каждый раз грузить.
На другие страницы не нужно смотреть, поставь один лайк социалки и ты увидиш сколько он тебе загрузит скриптов ,там ноги растут немного от другого.

Мы не скатились ,а подошли.
Скажи ,у программиста прикладныйх программ или флеш девелопера есть верстальщик?
Нет,а почему? Потому что в контексте ООП он выпадает полностью,так как DOM элемент для ООП является обьектом отображения,а не просто строкой или чем то другим сбоку.
В ПП также заместь элементов есть компоненты GUI ,в флеш есть DisplayObject пакета flash.display, но сам принцип работы с ними остается тот же самый - это все обьекты.
У тебя есть выбор, писать по новому (хотя это совсем не новое,просто в ПХП недавно зарисовались некоторые возможности), но не тащить за собой старое, или оставаться там же.
Если ты позиционируеш свою работу в сторону ООП,тогда тебе нужно перейти на это полностью,несмотря на все трудности, и совершенно изменить подход, просто натягиванием через классы традиционных подходов ,которые уже достаточно жестко устоялись - ты ничего не добьешся.
Или лучше сидеть и писать как самому удобно и не впихивать невпихуемое

Ок ,я надеюсь мы еще похоливарим по новому движку

- это всего лишь инструмент. не понимаю как можно прям так безапелляционно говорить. в двиге могут быть и ООП и процедурно-функциональные куски. все зависит от целесообразности и контекста.

Скажу более 99% флеш прогеров тоже так делают ,более того такой же процент ориентируется на событийную модель .Более того в пакете VStudio была среда называлась WebDev насколько помню,где так же само раставлялись хтмл елементы и строились ASP страницы. Это еще было бог знает когда.
Еще есть куча других редакторов ,где можно тоже раставлять элементы ,что это меняет?

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

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

Да, да и ещё раз да. Это есть увеличение производительности отклика за счёт уже подгруженного шаблона. Что это даёт - кэширование шаблона на стороне клиента! без подгрузки нового html. При последующих запросах подгружаются только пакеты данных и вставляются в кэшированный html шаблон, который хранится в памяти компьютера самим интерпретатором JS. То есть позже шаблон уже не подтягивается с сервера. Мало того подгрузка данных на клиенте может легко создаваться в виде отложенной, наподобие запросов к БД отложенных, что опять же увеличивает производительность. Эти плючы уже давно своё место нашли, проблема в этом только одна SEO и индексация поисковиками, вот здесь да проблема.

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

Ну и это она из дополнительных нагрузок

Нет, всё таки SEO. Сложно индексировать, только гугл додумался в ботах вставить интерпретатор JS c ajax. Все остальные на тупую рубят только загруженный html.

Ерунда, раз сделал и поддерживай как и всё.

что сложного в индексации готового html-документа?

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

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

Теперь про шаблон, почему программный и почему на JS?
Понятно что сейчас все пишут (или верстают) на HTML и при этом эффективность управления им минимальна- это очевидно и даже не обсуждается.
А что мешает шаблон собирать из классов?
Думаю мешает только крутизна собственных яиц.
redreem же собрал управление шаблоном через классы на сервере.
Что мешает сделать тоже самое на клиенте иметь сразу непосредственное управление ,полный контроль и сборку шаблона на месте?

Простой пример.
Имеем главный класс Page реализующий основной каркас страницы в DOM и который наследует обьекты классов Header, Menu,Content ,Footer реализующие собственные каркасы в DOM и функционал.
Класс Header может наследовать классы лого или банер в шапке или флеш-ролик или слайдер или все сразу и включать\отключать эти обьекты отображения когда это необходимо.
Тоже самое с классом Menu,он может наследовать кнопки ,выезжающие списки и аякс для передачи контента в обьект класса Content.
Здесь мы можем каждой кнопке присвоить свой аякс и тогда переключаясь не дождавшись загрузки контент будет дозагружен в фоне и вернувшись мы получим выдачу моментально,так как обьекты отображения удаляются из списка отображения но остаются жить дальше,поэтому могут быть добавлены с уже содержащимся в ним контентом.
Тоже самое можно сказать и про класс Content который может наследовать
обьекты Article ,Comment,Paginator, AddPost и т.д.
Тоесть выстраивая классы в древовидную иерархию путем наследования , мы можем получить практически любую комбинацию, по принципу точно такому же
как выстраиваются элементы в DOM.
Все что я выше написал является обьектной моделью, тоесть обьекты отображения находятся внизу иерархии классов и их события там же.
Можно строить событийную модель , где обьекты отображения находятся на вершине иерархии и их события управляют другими обьектами. Здесь пути ООПистов расходятся и каждый свой путь выбирает сам.
Могу сказать только одно ,в событийной модели все очень прозрачно и понятно касамое событий и управления другими обьектами, но у этого кода плохая маштабируемость и динамика,то есть на этом подходе универсального солдата кода не построиш , но очень легко заточить под конкретную задачу.
В обьектной все наоборот, отличная маштабируемость,динамика,компактный код , но универсальность заставляет тщательно продумывать абстракцию классов.События внизу иерархии классов не будет давать спокойно жить,
всегда нужно будет думать как мы будем связывать обьекты.

ЗЫ Ну вот ,меня очередной раз "понесло" ,начал с простого примера - закончил философией на пять страниц

это да.

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