а маркетинг при чем? Это проблемы обеспечения совместимости. Как обеспечение совместимости в любом случае (doom))), так и повсеместное пренебрежение ею (развитие) - тупиковые пути. Т.е. если планируется развитие проекта надо что-то ломать, но не все подряд

твое предложение заключается в том, чтобы минимизировать количество общедоступного ПО? Но это путь к монополии. А считается, что монополия вредна для потребителя. Конкуренция же наоборот

ну раз для тебя это слишком кардинально давай вспомним, что можно писать Java-апплеты и ActiveX-компоненты, на статических языках, не таких зыбких

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

Я каждый день делаю что-то нестандартное или то, что никогда не делал.

Свои ошибки исправить легко, ошибки фреймворка -- трудно.

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

Что значит пишешь сам? Для чего вообще фрейворки используются?

Для выборки элементов? При грамотной верстке getElementById и getElementsBy(Tag|Class)Name хватит. А это максимум 10 строчек с различными плюшками.

Для навешивания событий? Это вообще 4 строчки.

Для анимации? При той же грамотной верстке анимация любой сложности не представляет труда при помощи одной вспомогательной функции в 10 строк.

Для XHR? Вся кроссбраузерность, включая утечки памяти в ИЕ, не больше 2-х экранов текста.

Что еще?

Для более абстрактного, упрощённого написания кода, и улучшения code reuse. При этом, понятие фреймворк весьма относительное. И даже может коррелировать с "новым языком" (если очень усилить абстракцию). Всё, что ты описал - это же для тебя не фреймворк, так? А выложи в общее пользование - для них станет фреймворк.

думаю, могут быть нюансы с определением ширины или еще каких-нибудь свойств, которые фреймворки могут решать

фреймворки могут делать код более компактным/читабельным

еще можно виджеты писать O_o

в конце концов за тебя это уже написано, остается только пользоваться

Считаешь, что сопровождение (книги, доки, обучение, плагины, популярность, вижуалапи и проч. хвосты) вообще не сидят в голове у программиста, который планирует коррекцию, тем более кардинальную? Чем длиннее хвост, тем сложнее, в этом смысле показателен мучительно "быстрый" прогресс у Internet Explorer 6+.
Точно! Только пропущено слово "плохого" ПО. Скриптопомойки набиты скриптами (общедоступное ПО... типа), и каждый день на энный форум приходит энный ньюб с аццким скриптом 98-ого года с аццким eval-ом внутри и просит его адаптировать под его нужды. В ответ скрипт моментально хоронят все, кому не лень - eval там не к месту, document.all там не к месту, проверка браузера бешеная и так далее. Отвечают хором и знаешь почему? Потому что потребовались годы пропаганды "здорового кода", горы разъяснений, чтобы возник этот хор. Та же самая история с универсальными либами, никто не может встать поперёк их выхода (увы) и мощной пропаганды, но можно их обсуждать, рекомендовать или не рекомендовать, в этом кстати, их позитивная роль - дискуссионный полигон. Это похоже на местами плохую книгу, которая уже написана, остаётся только писать рецензии, ничего больше, но рецензия не борется с книгами вообще.
Это самоуспокаивающая мантра слепых ведомых. Напомню тебе о PGP с открытым кодом, где, как думалось, все тут же найдут ошибку (открыто же), но вышло по-другому (или даже я несколько лет назад за 5 минут нечаянно нашёл баг в TrueCrypt, когда пароль открытым текстом хранился в памяти). Это я к тому, что не надо надеяться на тысячи "умных" последователей, тысячи сайтов и открытость кода. Большинство последователей слабо или вообще не представляют себе, как это работает, большинство сайтоюзверей баги вообще не описывают, будь это хоть гугль, всё держится на dev-ах и fan-ах, которых может быть и 1 штука, и 10 штук и у всех разная подготовка.

т.е. ты категорически против совместимости:
- Граждане Рима, должны ли мы продолжать строить дворцы для себя или построить достойное жилье для бедных?
- (хором) К черту бедных!

другими словами, из одной крайности кинулись в другую

я не про безопасность говорил. С безопасностью сложнее. О проблемах с ней ты узнаешь, когда ей (а точнее ее отсутствием) воспользовались. При чем неизвестно насколько быстро. Если же речь об доступе к элементу по id, то bugtracker фреймворка завалят, если оно работать не будет

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

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

Ты для таких задач подключаешь 1000 строк кода, я -- меньше десятка.

Чушь. От программиста зависит.

А без фреймворка нельзя чтоли?

Так и у меня все написано, я пользуюсь. Только я знаю что использую, а ты нет.


Впрочем ухожу из темы, бессмысленна она :)

Ага, метко сказал. Только бороться с нынешней крайностью тяжелее.
Совместимость с изданной книжкой, с плагинами? Это ж скрипт. Никто не заставлял обзывать плагинами скрипты для скрипта.
Я тоже. Оно относительное.