речь не о коллизиях, а том, что я знаю, например, какие файлы открыть, чтобы внести изменения

устарел? Впервые слышу, в jquery он по-моему очень активно используется.

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

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

К тому же все равно есть статическая страница и есть js-компонент. Это в любом случае отдельные вещи. Нельзя избавиться от статической страницы. Разве что написать свой шаблонизатор (сборщик/язык) который будет собирать страницу из js-компонентов, и использовать html как транспорт что ли, или как реализацию. Другими словами создать слой абстракции поверх html, чтобы исправить его "недостатки".

Потом, нельзя оставить в странице только placeholder'ы для вставки компонентов. Что иначе поисковики будут индексировать?

и можешь все же рассказать, как ты делаешь?

Всё равно не понятно. Какие файлы открыть должно быть понятно по названию компонента.


Я, честно говоря, не готов дискутировать о нужности unobtrusive javascript. Слишком много я пишу веб-приложений, и слишком мало обычных сайтов. Могу судить только как пользователь: большинство случаев этого самого unobtrusive javascript выглядят удручающе. Сначала появляется элемент, не обвешанный javascript-ом, потом пауза, потом он обвешивается функциональностью. Пауза посередине зависит от скорости загрузки сайта (DOMContentLoaded), и если какой-то скрипт в конце затупил, то всё плохо.

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

ok, не будем, расскажи лучше, как ты делаешь, если возможно

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

Alt+F7

Да.
Я не исключаю случаи, когда необходима загрузка по требованию, но мне пока такие не попадались.


Так я не знаю, что рассказывать. Все приложения состоят из компонент. Каждая компонента контекстно-независимо. Компоненты легко таскать из проекта в проект. Зависимость между компонентами контролируется с помощью BuildJS (ну или другая фигнюшка, если это яндексовый проект).

да у меня тоже несложно найти. Наверное дело в том, что у меня есть код, привязанный к текущей странице. Т.е. в простых случаях я не создаю компонентов.

ну например, есть компонент, который добавляет label к текстовому полю (типа атрибут placeholder). Он удаляет текстовое поле из страницы и заменяет на свою разметку? Когда он это делает? Сразу в html? В конце body?

У меня таких компонентов нет, у меня же веб-приложение. У меня может быть компонент, который содержит текстовое поле и label с нужным поведением. Т.е. нет компонента -- нет текстового поля.

Над задачей в твоей постановке я думал только в теории. Оптимально, пожалуй, сразу после текстового поля инициализировать его JavaScript-ом. Но тут есть проблема: скрипты надо грузить до основной страницы.

ну так вот я и пытаюсь выяснить, как у тебя. Я привел пример, но он не подошел. Приведи тогда ты.

поэтому я скрываю их сразу в html, а в конце body создаю компонент и показываю.

У меня будет в начале пустая страница, а потом

new PlaceholderInput({
    renderTo: document.body
})

А внутри PlaceholderInput html/css/javascript.


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

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

ага... :)

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

не понял о каком преобразовании речь и как это связано с задержкой перед появлением

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