Здравствуйте, goto, Вы писали:

G>Фичи имеют приоритеты. Для многих SPA и десктопных поддержка синхронных копий наверняка вообще не рассматривается. для Гугль докс это, наоброт, очень важная, изначально запроектированная функция.
Речь не идёт ни о каких "синхронных" копиях.
Любое веб приложение должно понимать, что нет способа гарантировать "единственность копии". Ваш URL всегда могут открыть разные пользователи, или один и тот же пользователь дважды.
Неумение работать с такой ситуацией — это некомпетентность.

G>По идее, поддержка таких копий требует усилий для синхронизации, сохранения целостности данных, разруливания коллизий — всего такого. Могут быть две и более равнозначные копии приложения, и сервер в синхронизации не участвует (бизнес-логика крутится в броузере, обращений к серверу на каждый чих нет) — тут еще надо мудрить. В итоге обсуждаемый функционал оказывается недешевым во всех смыслах, и разработчику надо иметь веские основания, чтобы им заморачиваться. Как видим в этом топике, недовольство пользователей, привыкших к стандартам веб, прорезается, ожидание такой функциональности как будто бы есть. Но дешевле осчастливливать пользователей другими способами при возможности.
К сожалению, большинство таких ограничений вовсе не являются следствием взвешенного решения, типа "спроектировали нормальную реализацию, посмотрели, решили целенаправленно пожертвовать открытием в параллельных табах ради достижения некоторых плюшек". Как правило, разработчик просто лепит javascript-хэндлер нажатия на линку, и вообще не задумывается о том, как будет работать такая "навигация".

G>Почтовый клиент все же держит в памяти не все 30Гб, а небольшое "окно". Я говорил о приложениях, которые работают с большими данными полностью в памяти. Подобия упоминавшихся Фотошопа и 3д редакторов в веб уже есть.
Никто не работает с большими данными полностью в памяти. Никакой фотошоп не будет держать 30GB в памяти — потому, что ему надо уметь работать в 8GB RAM, а иначе грош ему цена.
S>>Во-вторых, вовсе незачем держать целую отдельную копию всего приложения. Речь идёт всего лишь о том, чтобы иметь два параллельных view одних и тех же данных.
G>С разными view понятно. Я говорю о копиях, потому что топик начался с нового таба, который для SPA копия.
Нет, это вы сами себе придумали про "копию". SPA вовсе не означает необходимости держать все 30GB в памяти браузера. SPA — всего лишь возможность работать без перезагрузки документа.
G>Ограничения, мне кажется, не столько исторические, сколько коммерческие. Это и ограниченные ресурсы на разработку, и использование проторенных путей в той части, где новаторство не обязательно, выгод от него не ожидается, эксперименты и риски не нужны или не приоритетны.
Большинство архитектурных провалов — следствие не ограниченных ресурсов, а неверно принятых решений. Ну вот, лет 15 назад была популярна бредовая идея "давайте реализуем в браузере реплику десктоп приложения — с абсолютно-позиционированными окнами изменяемых размеров, кнопками свернуть/развернуть и прочей порнографией". Тот же ASP.NET проектировался примерно в эту сторону. Человекодесятилетия были выброшены на эти идиотские занятия.
G>Если бы поддерка синхронных копий по каким-то причинам была бы маст хэв (представим), то, видимо, под это уже были бы общеупотребительные api с паттернами и фреймфорками, и такая разработка была бы дешевле. Но поскольку такого массового запроса от человечества не случилось, сейчас такая разработка для обычных приложений — это нечто штучное.
Ещё раз: вы подменяете задачу. Нет никакой необходимости "поддержки синхронных копий". Как правило, ровно то же самое SPA можно совершенно спокойно открыть в другом окне или табе браузера, и оно будет работать совершенно корректно.
Сломана только навигация внутри SPA.
G>Трудно сказать, я не спец. Скажем, обмен данными между окнами броузера через сообщения считается небезопасным.
Во-первых, он не нужен. Нормальное SPA не должно зависеть от межоконного обмена — ведь "окна" могут быть открыты на двух разных машинах.
Напомню, на всякий случай: SPA — в первую очередь веб приложение. То есть реальные данные хранятся где-то там, "в облаке".
Во-вторых, он вполне безопасен и разрешён, с определёнными ограничениями.
G>Насчет остального для "горизонтального" обмена данными между табами, без сервера (localStorage, файловый api, кэш..?) — не знаю.
Естественно все API браузера рассчитаны на параллельную работу из любого числа окон.