Ну вот, опять пугают бедных новичков :)
Они же теперь, как огня innerHTML боятся будут.
А нужно было уточнить — XSS атака здесь возможно только тогда, когда зачем-то понадобиться вставлять на клиенте через innerHTML непроверенные данные, введенные другим пользователем.
Не уверен, что сжатие сможет уменьшить количество запросов :)
Конкатентацию тоже нужно использовать осторожно. Если возможных вариантов сборки будет больше чем исходных файлов, то за счет неоптимального использования кэша это может наоборот всё испортить.
К чему вы это говорите в данной теме?
Очередное начало холивара в стиле, "а вот я слышал от знакомого?"
По этим словам единственное что можно заключить — ваш знакомый, э..., очень сильно начинающий, так сказать, в PHP.
А совместимость с php2 будет?
А если на хостинге стоит только perl, а я хочу писать на php5, есть библиотека реализующая интерпретатор PHP и все его расширения на perl?
Думаю, профессиональному разработчику все равно, как писать. А новичку - как раз проще закрывать все теги в соответствие с xml-стандартом, чем запоминать, какие можно не закрывать.
w3c тоже так думало, когда xhtml продвигало, однако, как показала суровая реальность, всё не так здорово.
большинство server-side фреймворков давно представляют страницу в виде объектов, а не в виде html-кода,
Не один вменяемый фреймворк никогда не должен изображать из себя верстальщика.
То что вы говорите, относится скорее к CMS вида "сваганьте свой сайт за 5 минут".
Согласен. Большинство программистов пользуются универсальными фреймворками, в которых классовое ООП кустарным способом натягивается на прототипное. Я ничего не имею против этого.
Но, когда программист, который не боится "чистого" JS делает вещь, намного эффективнее работающую на его конкретной задаче, а после этого из всех щелей вылезают знатоки с криками: "Не изобретай велосипед! Лучше подключи полметра чужого кода, разберись в нем и наверни это всё поверх своей задачи", вот это меня немного нервирует.
Это квадратное колесо является стандартом де-факто для людей, которые не понимают отличий в ООП-парадигме JS и в том, что они пытаются на неё натянуть.
Кроссбраузерность, первое, что указывают изготовители библиотек при указании их достоинств. Почему-то большинство воспринимает это, как что-то невероятное и не достижимое без использования дымящейся кучи кода сторонних библиотек.
Однако, любой сколько-нибудь квалифицированный JS-программист может писать свои сценарии кроссбраузерно, не сильно при этом напрягаясь и, в большинстве случаев, на автомате.
"Кроссбраузерность", это не то, что нужно писать в преимуществах. Это то, что должно подразумеваться по умолчанию для каждого уважающего себя продукта.
Они же теперь, как огня innerHTML боятся будут.
А нужно было уточнить — XSS атака здесь возможно только тогда, когда зачем-то понадобиться вставлять на клиенте через innerHTML непроверенные данные, введенные другим пользователем.
Конкатентацию тоже нужно использовать осторожно. Если возможных вариантов сборки будет больше чем исходных файлов, то за счет неоптимального использования кэша это может наоборот всё испортить.
Очередное начало холивара в стиле, "а вот я слышал от знакомого?"
По этим словам единственное что можно заключить — ваш знакомый, э..., очень сильно начинающий, так сказать, в PHP.
А если на хостинге стоит только perl, а я хочу писать на php5, есть библиотека реализующая интерпретатор PHP и все его расширения на perl?
w3c тоже так думало, когда xhtml продвигало, однако, как показала суровая реальность, всё не так здорово.
Не один вменяемый фреймворк никогда не должен изображать из себя верстальщика.
То что вы говорите, относится скорее к CMS вида "сваганьте свой сайт за 5 минут".
Но, когда программист, который не боится "чистого" JS делает вещь, намного эффективнее работающую на его конкретной задаче, а после этого из всех щелей вылезают знатоки с криками: "Не изобретай велосипед! Лучше подключи полметра чужого кода, разберись в нем и наверни это всё поверх своей задачи", вот это меня немного нервирует.
Однако, любой сколько-нибудь квалифицированный JS-программист может писать свои сценарии кроссбраузерно, не сильно при этом напрягаясь и, в большинстве случаев, на автомате.
"Кроссбраузерность", это не то, что нужно писать в преимуществах. Это то, что должно подразумеваться по умолчанию для каждого уважающего себя продукта.