gandjustasНе потребление, а content interaction, взаимодействие с контентом. Чистое потребление это блоги и новостные сайты.

Упал чтоли? Twitter, Vkontakte, Facebook и т.д. -- основное и подавляющее использование, это именно потребление контента. Учитывая то, сколько в среднем пользователь потребляет по сравнению с тем, сколько он генерирует, это 99% потребления на 1% генерации (и то, это ещё очень оптимистичная оценка).

В блогах и новостных сайтах тоже часто есть комментарии, оценки, лайки (уж этого добра всегда навалом). Не думаю, что в этом качестве их стоит сравнивать.

gandjustasприкрутить к правильному SPA offline режим довольно просто . И гораздо проще (дешевле), чем приложение сделать. А SPA в свою очередь можно достаточно просто сделать, имея MVC приложение.

Смелое утверждение. Теоретически просто. Но на практике -- нет. Даже близко. Тем более это нафиг ненужно. Для мобилок делают приложения, для планшетов также предпочтительнее приложение. Написать одно SPA приложения вместо нескольких под разные платформы -- это очень наивный способ сэкономит. На столько наивный, что даже не подлежит обсуждению.

gandjustasЭто как раз вырожденный сценарий. Смена view сделает оптимизации бесполезными.

Я говорю про ситуацию в рамках одного view. Если смена view, это полная перегрузка всего, то я вообще не вижу никакого смысла в SPA, только усложнение разработки.

gandjustasВ долгоживущем приложении как раз важно освобождать память, а не экономить на циклах gc.

Важно и то, и другое.

gandjustasЯ тебе уже задавал вопрос чем твой подход с in-page spa отличается от полновесного SPA с навигацией? Только тем, где лежит шаблон? И в чем тогда преимущества? Ты как-то не удосужился ответить.

Вот-вот, с точки зрения пользователя -- ничем. Преимуществ масса, от только что разработка сильно упрощается, это лучше поддаётся тестирование, это гораздо лучше с точки зрения менеджмента памяти (очистить блок памяти ГОРАЗДО проще и быстрей, чем чистить руты -- будешь с этим спорить???), это удобней тем, что на сервере больше ответственности, например роутинг серверный. Я считая, что клиенту в веб-приложении необходимо выдавать как можно меньше ответственности, чем меньше тем лучше. На то он и тонкий клиент. SPA грубо противоречит этому принципу.

gandjustasУтечки вообще возникают когда руками связываешь DOM с объектами JS. Хороший фреймворк, типа angular, большую часть проблем снимает. \

Отличная сказка из разряда «вот этот крем избавляет от всех морщин!»

gandjustasТы, конечно, говорил, но правдой это не является. Иначе бы идея SPA не родилась никогда.

Да ну ты брось. Идея SPA уже тыщу раз вылазила на поверхность, и наросла в вебе наростами типа Adobe Flex, Silverlight, Java аплеты -- и где это всё? Оно вроде есть, и даже где-то используется.

Что касается AngularJS, задолго до него был ExtJS -- и что? Что изменилось?

Давай так. Ты считаешь, что SPA подходит для любого веб-приложения?

Я считаю, что нет. Всё зависит от задачи, её сложности и комплексности, от требований и от многих других факторов. Говорить, что SPA подойдёт для чего угодно, это глупо. Есть удачные применения в масштабах узкоспециализированных задач, ОК. Но стоит сначала подумать. Не надо надеяться на то, что какой-то ангуляр порешает все проблемы. Ничего подобного. Ангуляр ещё та жирнющая корова с постоянно страдающими утечками. И ненадо мне лечить, что это не так. Я об это не по наслышке знаю. Так бы поверил на слово.

gandjustasНе то сравниваешь. В соцсетях потенциально все пользователи генерируют контент, а в блогах и новостных сайтах пользователи, кроме маленькой группы авторов, контент только потребляют.

Это и создает разные сценарии и, соответственно разные решения вроде SPA-неSPA.

Да практически все пользователи генерируют контент, но основной сценарий -- потребление, а не генерация. Вот тематический хабр, по сути нацелен на создание контента (с претензией на качество), но основной сценарий всё же потребление. Для этих целей SPA или не SPA значения вообще никакого нет. Но для Vkontakte, например, SPA действительно, по-настоящему, решает очень конкретную задачу, которую не-SPA приложение решить НУНИКАК не может. Понимаешь разницу? Ты вообще, чувствуешь её? Между стильно/модно/молодёжно и реальным решением задачи? Какую задачу выбор SPA решает? Интерактивность? Ну прекрати смеши меня, интерактивность и без SPA точно также делается. Абсолютно никаких проблем пользователи при этом не испытывают. Offline и веб-приложение -- это совершенно несовместимые понятия, ибо при потери коннекта для любого корпоративного приложения означает буквально РАБОТА ВСТАЛА. И тут оффлайн-режим ничем не поможет. Даже для тупой почты. Чё работнику делать в этом случае? Спам разгребать? Ни ответить ни на одно письмо, ни получить. Нафиг не нужен этот оффлайн.

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

В случае SPA это можно понять. Крайне высокие трудозатраты. Приведу безымённый пример, с чем я недавно столкнулся. Солнечная Калифорния, пилят стартап SPA приложение. Руссишен девелопмент оккупантен. Две основные команды, практически никак не пересекающиеся. Одна команда пилит клиента, другая сервер. Делают уже 2-ой год. Релиза до сих пор нет. Но находятся постоянно в стагнации: «вот-вот уже...». Опять запоёшь старую песню на тему того, что это просто там руководство дауны, разработчики дебилы, архитекторы умалишённые, и никто ничего не умеет? Делали бы классическое веб-приложение, давно бы уже зарелизили хоть что-нибудь.

gandjustasВ чем усложнение? ng-view и $routeProvider имеет ту же сложность, что и MVC, но дает больше возможностей (см выше про оффлайн)

Чёй-то? Это каких таких возможностей? Оффлайн также можно пилить и на MPA, хватет уже про него говорить.

gandjustasКак раз интересует технически. Мне кажется различий гораздо меньше, чем ты хочешь показать. Это значит и проблем, которые ты пытаешься решить, по сути нет, или они тобой и созданы.

Технически, это развёртывание целого приложения на клиенте в рамках одной страницы. Какую задачу это решает? Для чего? Высокий уровень интерактивности? На сколько высокий? Согласен принять средний показатель от 3-5 секунд увеличения скорости отзывчивости (с точки зрения пользователя), но это ведь не так, даже вовсе наоборот.

Со вкладкой приведу пример. Пусть ты не открываешь вкладок, молодец, но пользователи открывают. Открытие SPA во вкладке -- это убийство нервной системы пользователя, всё равно что из гаубицы по ней лупить. Так что увольте(сь)

gandjustasЕсли сравнивать с рукопашным байндингом, то совсем не сказка, а суровая реальность.

Байндинг байндинку рознь. Взять, например, MithrilJS -- он AngularJS втаптывает в грязь по части производительности (да и по использованию памяти тоже). Но не модно же. Ангуляр модно. Его же гугл двигает. Это тебе не в тапки ходить.

gandjustasВсе это сдохло как раз по причине того, что это не HTML+JS, ибо работает не везде.
Но до SPA им все равно было далеко. Суть SPA в двух аспектах:
1) Страница не перегружается полностью при переходах, заменяется только view
2) С сервера тянутся только данные, разметка генерируется на клиенте

Оба пункта прекрасно работают и с MPA. Так что не вижу пока сути.

Один пример я приводил, это Vkontakte: надо ходить по страницам и слушать при этом музыку. Таким же макаром выполнен, например, Jango.

Другой пример, в приложении надо между переходами страниц сохранять некое накапливаемое состояние, например в приложении для формирования заявок на материальные ресурсы (МТР), требуется ходить по каталогу, закидывать в заявку позиции, и держать эту заявку «под рукой», как корзину в интернет магазине. С точки зрения подтверждения заявки, исполнителю требуется работать с несколькими заявками сразу, сравнивая их, чтобы сформировать запросы на МТР подразделения. Это укладывается в задачи SPA, можно подумать над его использованием.

А всякие заявления на тему того, что выбор SPA обусловлен «высокой интерактивностью» -- это наивные глупости, больше подходящие студентам, начитавшихся хабра.

gandjustasЭто разные библиотеки. Angular решает совершенно другие задачи по сравнению с ExtJS.

Естественно. ExtJs предлагал кроме всего прочего, UI. И на заре его развития небыло History API. Но концепция та же. Хотя ExtJs-а потом сношали с бекбоном и получали ровно тоже самое -- могучее SPA приложение

gandjustasЯ уже писал - spa хорош при высокой интерактивности и для мобильных устройств . Большинство корпоративных приложений как раз попадают в эту категорию.

Выделенное жирным и красным -- совершенно точно НЕТ, ты очень сильно в этом заблуждаешься. Уж незнаю откуда такие выводы. Нет, нет и ещё раз нет. На мобилках SPA нахрен не сдалось. Оно там не выживет никогда. Особенно учитывая, что одной адаптивностью там не обойдёшься (эти сказки любят вещать разносторнне развитые личности, которые и на ассемлере пишут, и в UI разбераются, и продавать умеют, и на дудке играть, и платья шить и хороводы водить).