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

P>>Ты согласился с тем, что у одних и тех же людей с жээс получается лучше.
CC>Я согласился что они менее сурово косячат.

Именно. Речь идет именно про этот эффект — "менее сурово косячат". Менее — значит где есть и более. И разница исключительно в ЯП, раз уже люди одни и те же.

P>> Следовательно, жээс уменьшает количество багов.
CC>Мда. С логикой ты не дружишь.

Читай себя выше: "менее сурово косячат"

P>>Я говорю о скриптовании внутри страницы браузера
CC>

Сравниваем яблоки с яблоками, а не скриптинг внутри страницы со склейкой строк в CGI.

P>>Так пилились например всякие плагины-аддоны-сайдбары-меню для интернет-эксплорера
CC>Это не "скриптование"

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

P>> dhtml-диалоги и многие другие вещи.
CC>А где в dhtml был client-side C++?

В MFC, например. Цельный CDHTMLDialog. Там писали вообще всю логику формы на C++. Аналогичная механика была и в ATL/WTL.
Чаще конечно IE использовали как компонент, обмазывали его С++ кодом см. пример выше.

Типичный кейс — сайдбар для IE. Это плагин к IE, который содержит IE как компонент.
Очевидно, все скриптование делалось на С++ используя COM.
Логика ровно та же, что в примере выше ну или в нынешних скриптах на greasemonkey например или плагинах для хрома.

P>>Не просто "чуть более удобный", а полностью убирает простыни кода.
CC>Большинство операций как были однострочными так и остаются.

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

P>>Скажем, уже такой результат обеспечивают далеко не все компоненты.
CC>Этот результат обеспечивает рендерер браузера.

Каждый уровень рендерит в единицах нижележащих уровней — иначе не бывает. Мне казалось, что это очевидно.
Забавно, что ты все стараешься подменить тему на "не жээс записывает eax в порт xyz"

P>> У многих вообще сглаживания нет, а потому смотрится вырвиглазно.
CC>Это функция рендерера а не PDF парсера. Прикрути к ним да хоть тот же DirectWrite backend и будет тебе и сглаживание и даже GPU acceleration.

Похоже, у тебя только то рендерер, что "на С++ и чтото там рисует и начинается с class Renderer:"
Рендерер это функция вида репрезентация=>репрезентация, т.е. мы можем pdf рендерить во что угодно — в текст, в примитивы 2d графики, в пикселы, xml, json, итд итд
А wav мы можем рендерить как в синусоиду на экране, так и в сигнал в аналоговом тракте усилителя.

P>>То есть, на пдфжээсе можно делать вещи, которые на большинстве нативных компонентов просто недоступны.
CC>Тут нет ни малейшей заслуги JS per se, рендеринг выполняется нативным кодом браузера.

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