gandjustasСоцсети - как раз пример высокоинтерактивных приложений. Везде лайки, шары, чаты, лента активностей, новые сообщения\комменты грузятся автоматом. Переход при этом должен как можно быстрее происходить. Идеальный сценарий для SPA.

Согласен. При чём для Vkontakte SPA появился тогда, когда понадобилось во время сёрфинга продолжать проигрывать музыку -- т.е. в этом есть весьма конкретный и определённый смысл.

gandjustasСравни с этим формумом. Интерактив только один - написать\ответить, которым пользуется 1 посетитель из 100. Какая тут может быть польза от SPA?

Да ладно, для форума SPA также вкатывает. Только особого смысла в этом нет.

gandjustasСоцсети направлены на лайки и комменты. Не было бы их, то никто не полез бы читать новости в соцсети.

Всё же расчёт на потребление контента. Вот были раньше чаты: в iframe подгружался полностью обновлённый html раз в несколько секунд. И ничего, никто ведь не жаловался, сидели там стадами.

gandjustashVosttЗачем в корпоративных приложениях offline? Для какой цели? Ещё одна бестолковая никому не нужная «способность»?Для планшетов и телефонов.

Если для планшетов и телефонов требуется offline, то надо делать приложение, а не убогую погремушку на SPA.

gandjustasТы не ответил на вопрос. Как заменить div на form?
Я прекрасно понимаю, что можно заоптимизировать одну форму настолько, что убрать количество аллокаций почти до нуля. Но в масштабах всего приложения это будут спички. Как только делаешь переход на новую страницу у тебя появляется шаблон с другой структурой и совершенно другие данные.

div на form менять не надо. Имелось в виду обновление вместо генерации по одному и тому же шаблону. В масштабах долгоживущего приложения, чем по сути является SPA, это становится важным.

gandjustasЭто видимо твоя практика. Моя практика показывает как минимум то, что перегружать страницу частями - гораздо быстрее, чем полностью. Как с точки зрения нагрузки на канал, так и с точки зрения скорости работы UI. Если у тебя не так, то или особенный сценарий или неумение делать правильные SPA.

Хм. Похоже у нас непонятки. Я не предлагал вместо SPA делать кучу plain HTML страниц сразу с отрендеренными данными на сервере. И хотя не раз на этом акцентировал внимание, всё же повторю. Можно точно также загружать данные ч/з AJAX/REST, затем биндить на страницу, используя все преимущества MVVM, только приложение разбить на несколько страниц. Например, в CRM страницы: «Управление сделками», «Управление задачами», «Рабочий стол» -- это всё разные страницы, но устроены они таким же образом как SPA. Если в SPA, как ты говорил неоднократно, переход по страницам перегружает всё заново, то какая нафиг разница? Находясь на одной странице, точно также подгружаются данные и обновляются её части по той же технологии, точно также используя MVVM фреймворки. Нахера всё с бараньей упёртостью запихивать всё на одну единственную страницу? Если по сути будет происходить ровно всё тоже самое?