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

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

Сугубо по звучанию... чем создание каких-то (мегауниверсальных?) "обработчиков" и "складывание их в стопку" отличается от создания аналогичных "функций" и поочерёдного (в порядке стопки) вызова их из обработчика "в зависимости от потребностей"?

Cкажу честно: то, что звучит, звучит криво. Пока для меня оно выглядит примерно так: "я не хочу писать классы TNumberEdit, TTextEdit и TMemoEdit, я хочу использовать один TEdit, навешивая на него по необходимости OnNumberKeyDown, OnMemoInit и кучу других обработчиков, меняющих этот TEdit до неузнаваемости".

AlexsalogДа, в точности. Чем это плохо ?
В первую очередь, это создание того самого мегауниверсального компонента.

Чтобы показать, чем это плохо, стоит сделать следующий шаг по этому пути и мысленно "объединить" компоненты TEdit, TPanel и TButton. В самом деле, каждый из них - прямоугольник с определёнными обработчиками одних и тех же событий.

Мы вполне можем сделать кнопку из панели. Для этого на неё надо навесить обработчики OnMouseEnter, OnMouseLeave, OnMouseDown, OnMouseUp. Если хотим кнопку с картинкой, ещё OnPaint. Если хотим нажимать её с клавиатуры, ещё OnKeyDown. Можно сделать в принципе. Вопрос в том, что для любой кнопки любой формы нашей программы надо будет вешать семь обработчиков. То есть писать семь строк кода, устанавливать семь свойств итп. Одинаковых, раз за разом. Это очень тоскливо. Любой нормальный человек захочет сделать что-нибудь вроде Панель.СтаньКнопкой, чтобы она сразу инициализировалась как положено. Но! В тот момент, когда мы говорим TButton.Create вместо TPanel.Create, мы на самом деле именно это и говорим. Указывая класс, мы собственно и говорим "TObject, стань кнопкой".

Не стоит забывать о том, что разным "конкретным классам" нужны разные свойства. TButton-у нужна картинка, TEdit-у - нет. Делая такой мегауниверсальный компонент, мы должны будем реализовать свойство "картинка" на уровне базового класса и обеспечить ему какое-то разумное поведение в том числе в TEdit-е. Вы представляете себе компонент, объединяющий в себе свойства хотя бы панели Standart? Аналогично, этот мегауниверсальный компонент должен будет работать, инициализированный какой-нибудь бешеной комбинацией свойств и обработчиков, скажем TEdit должен быть checked, иметь выпадающий список и редактироваться как полозок. Такой компонент будет очень сложным и очень глючным. А зачем, собственно?

Такой ценой мы по идее покупаем возможность сделать "TButton с элементами TEdit". Например, кнопку, в которой есть поле ввода. Иногда это нужно, но, назовём так, применимость этого не очень высока. "Стандартные решения" таки нужны гораздо чаще, чем нестандартные.

Итого - не стоит бросаться в крайности. В идеальном дизайне есть место и для жёсткой, априорной типизации TButton/TEdit, и для настройки свойствами, и для кастомизации событиями. Возможности инструментальных средств несколько сдвигают оптимум: например, в интерпретаторах возможность динамически, плагинно добавить объекту свойства и методы снижает потребность в предварительной типизации. Но всё же.... подход jQuery вызван недостатками js как инструмента. Он просто не умеет иначе. И не надо бросаться в эту крайность там, где это не обязательно, имхо.

Отделение логики от представления - не является "подходом дельфи", да и "подходом .нет"

Я не знаю jQuery в объёме сверх "странички инфы", но общего как-то не вижу.

Валер, некто гениальный может утверждать, что js похож на .net и не похож на дельфу, опираясь на тот факт, что в первых двух фигурные скобки, а в третьей - begin/end. Я полагаю, что при всей истинности факта на определение похожести больше влияют другие соображения.