Вот зачем так делать? В том же Azure Console на ссылку можно только нажать, но нельзя открыть в новом табе. Очень не удобно. Смысл в этом какой?

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

S>Вот зачем так делать? В том же Azure Console на ссылку можно только нажать, но нельзя открыть в новом табе. Очень не удобно. Смысл в этом какой?

Есть еще вариант, когда ссылки открываются (по средней кнопке), но делают/открывают не то, что при простом нажатии. В целом — Лавров.жпг, но какой смысл ныть на форуме?

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

S>Вот зачем так делать? В том же Azure Console на ссылку можно только нажать, но нельзя открыть в новом табе. Очень не удобно. Смысл в этом какой?

Это какой-то фреймворк. Либо кнопели, которые ссылками не являются, либо тупые ссылки с адресом "javascript:void(0);", где сама ссылка находится в скрипте-обработчике. Такие тоже в новом окне или новой вкладке не откроешь.

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

S>>Вот зачем так делать? В том же Azure Console на ссылку можно только нажать, но нельзя открыть в новом табе. Очень не удобно. Смысл в этом какой?

M>Это какой-то фреймворк.

Это не фреймворк. Это так написали код.

Дополнительная работа, которую решили не делать.

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

S>Вот зачем так делать? В том же Azure Console на ссылку можно только нажать, но нельзя открыть в новом табе. Очень не удобно. Смысл в этом какой?

Это не single-page application? Или, может, такое поведение ссылки технически оправдано в том конкретном месте?

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

S>>Вот зачем так делать? В том же Azure Console на ссылку можно только нажать, но нельзя открыть в новом табе. Очень не удобно. Смысл в этом какой?

G>Это не single-page application?

Оно самое

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

G>>Это не single-page application?

S>Оно самое

Тогда логично, что не открывается в новом табе. Это в multi-page app. обычно при нажатии на определенную ссылку на сервер передается все необходимое и генерируется новая, совершенно независимая страница, которую можно открыть в любом табе. А в SPA все хранится и делается внутри одной страницы.

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

S>>Оно самое

G>Тогда логично, что не открывается в новом табе. Это в multi-page app. обычно при нажатии на определенную ссылку на сервер передается все необходимое и генерируется новая, совершенно независимая страница, которую можно открыть в любом табе. А в SPA все хранится и делается внутри одной страницы.

Это неправильно. Когда щелкаешь средней кнопкой, рассчитываешь открыть страницу в новом табе в соответствующем контексте, и чтобы старая тоже осталась. Обычно это нужно из-за и так убогого интерфейса этих SPA, не позволяющего что-то сделать и вернуться обратно.

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

Ops>Это неправильно. Когда щелкаешь средней кнопкой, рассчитываешь открыть страницу в новом табе в соответствующем контексте, и чтобы старая тоже осталась. Обычно это нужно из-за и так убогого интерфейса этих SPA, не позволяющего что-то сделать и вернуться обратно.

Тут просто обманывает привычка. Когда видишь ссылку в броузере, рассчитываешь, что она поведет себя как на обычной веб странице. Но там на самом деле SPA — приложение типа десктопного, где ссылки — аналог кнопок, пунктов меню и прочих десктопных управляющих элементов. Я убожество интерфейса конкретно Azure оценить не могу, т.к. не пользуюсь. Но в целом, как ты себе представляешь себе реакцию контрола на среднюю кнопку в десктопном приложении? Должна создаться копия приложения в том же рабочем состоянии? Вряд ли ты этого будешь ожидать. Логично и от SPA такого не ожидать.

Десктопные приложения пошли в веб — наблюдается некоторый зоопарк. Веб пришел на десктоп — тоже зоопарк. Так и живем.

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

G>Тут просто обманывает привычка. Когда видишь ссылку в броузере, рассчитываешь, что она поведет себя как на обычной веб странице.

А не надо мои привычки обманывать. Их и так в каждом новом интерфейсе на прочность испытывают.

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

Угу. Поперлись в чужой монастырь со своим уставом. Ну что мешает сохранять состояние в сессии, в куке или в локальном хранилище, модифицировать URL в адресной строке, если оно так уж необходимо, что тоже далеко не факт? Или хотя бы оформить ссылку, не работающую как ссылку, в виде кнопки?

G>Десктопные приложения пошли в веб — наблюдается некоторый зоопарк. Веб пришел на десктоп — тоже зоопарк. Так и живем.

Дело не в приложениях, а в погромистах, не способных перестроиться на другую идеологию, или просто ленивых.

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

Ops>А не надо мои привычки обманывать. Их и так в каждом новом интерфейсе на прочность испытывают.

Не все так однозначно. С одной стороны, речь о приложениях, многие из которых напрямую или в основах пришли с десктопа, с другой стороны, это все-таки веб уже со своими традициями. Вот и разрывайся тут между умными и красивыми. Еще мода, предыдущий опыт разработчиков, чьи-нибудь воззрения на UX, целевую аудиторию и т.п.

Ops>Угу. Поперлись в чужой монастырь со своим уставом. Ну что мешает сохранять состояние в сессии, в куке или в локальном хранилище, модифицировать URL в адресной строке, если оно так уж необходимо, что тоже далеко не факт? Или хотя бы оформить ссылку, не работающую как ссылку, в виде кнопки?

Насчет сохранения состояния не согласен. Это дополнительное проектирование, кодинг, тестирование. При этом ведь предъявлять подобные требования к поведению десктопных приложений никому не приходит в голову.

Оформлять кнопку как кнопку — тут я тоже да. Но люди иррациональны, придумывают большей частью всякую ерунду, у всех мнение. К канонам UI какой-нибудь ранней винды мы, может, уже не вернемся.

Ops>Дело не в приложениях, а в погромистах, не способных перестроиться на другую идеологию, или просто ленивых.

Можно сказать, что все проблемы из-за этого. Еще виноват бизнес с его жаждой наживы, ограничением сроков и бюджетов.

Здравствуйте, goto, Вы писали:
G>Насчет сохранения состояния не согласен. Это дополнительное проектирование, кодинг, тестирование. При этом ведь предъявлять подобные требования к поведению десктопных приложений никому не приходит в голову.
Вы валите с больной головы на здоровую. В том смысле, что десктопные приложения обладают некоторыми ограничениями, к которым все привыкли. Это не означает, что эти ограничения чем-то хороши. Я же точно так же могу сказать, что реальный рабочий стол ведёт себя не так, как метафора десктопа в виндовом гуе. И вообще — разве от обычной печатной машинки кому-то приходит в голову требовать поддержки Undo? Давайте тогда и из ворда эту функцию грохнем.

Веб всю жизнь как раз был феерически удобен возможностью делать параллельную навигацию и возвращаться обратно. Кстати, серъёзные десктопные приложения поддерживают концепцию Go back/Go forward (Visual studio, Adobe Reader, всякие дизайнерские тулзы с их go to previous view). Тот же Аутлук умеет "Open in new Window", что позволяет мне быстро переключаться не только между фолдерами в инбоксе, но и удерживать в каждом из них контекст (например, список выделенных писем).

По факту, SPA изначально были попыткой совместить худшие недостатки десктопа (убогая навигация) и веба (отсутствие нормальной интеграции с клипбордом и аппаратурой).
Правильное направление — бороться с недостатками, совмещая лучшие достижения. И это движение я наблюдаю — вот мне тут только что кинули ссылки на то, как можно грамотно управлять состоянием view, одновременно умея минимизировать трафик благодаря отсутствию рефреша, и восстанавливать всё состояние по одному лишь урлу при закрытии сессии (или при передаче ссылке знакомому через почту или IM).
Вон, jira уже умеет обрабатывать самые популярные сценарии по взаимодействию с OS, вроде аттача файлов драг-н-дропом и вставке скриншотов по Ctrl-V.
А вы предлагаете наоборот — наслаждаться искусственными ограничениями, которые только мешают.

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

S>А вы предлагаете наоборот — наслаждаться искусственными ограничениями, которые только мешают.

Ты мне приписываешь лишнее. Я ничего не оправдываю и не предлагаю, а лишь пытаюсь объяснить. Реализация всех эти гибких и удобных фич требует дополнительных усилий (деньги, сроки) и культуры разработки (которую не всегда купишь). При этом такие фичи исторически не являются стандартом, т.е. могут делаться в виде приятного дополнения, но по дефолту не ожидаются. Я здесь и далее говорю о приложениях десктопных и веб-, которые их имитируют.

Иногда такие фичи просто не нужны объективно. А в случае приложений с тяжелыми данными я не совсем представляю, как это могло бы работать хорошо. Например, для чего-то типа Фотошопа или 3д редактора создавать копию приложения, синхронизировать каждый чих между копиями может быть накладно по ресурсам/тормозам.

Если бы "многокопийное" поведение было стандартом де факто для юзеровских приложений, то для каких-то их классов могли бы вылезти некоторые связанные с этим свои, новые ограничения, в конечном итоге сказывающиеся на возможностях для пользователя. Я это допускаю (органы на плаху не положу). По безопасности веб приложений могут открыться интересные горизонты и побочные эффекты со своими требованиями к коду, мозгам и ресурсам.

Удобные фишки из веб вроде back/forward можно реализовывать другими средствами, без копий. В той же Майе можно гулять туда-сюда по view и по layout'ам экрана в рамках ее воркфлоу, никак не связанного с привычками из веб. Там в этом была необходимость изначально, и все давно было сделано.

Ближе к топику. Если у пользователя одностраничного веб приложения возникает желание открыть копию в новом табе, и невозможность сделать это его бесит, то, весьма вероятно, это приложение просто плохо продумано. Вряд ли дело только в том, что кнопка внешне выглядит как линк.

Юзабельные софты есть и будут, но в целом я пессимистичен. Тенденция не меняется. Кому необходимо или кто может — делает хорошие фичи, а в остальном и среднем просто решается некая задачка, как получится, как побыстрее. Последнее время вообще модно делать MVP (который может быть практически пустым сайтом без вменяемого продукта) и сразу как можно стремительней бежать искать инвестора.

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

G>Ты мне приписываешь лишнее. Я ничего не оправдываю и не предлагаю, а лишь пытаюсь объяснить. Реализация всех эти гибких и удобных фич требует дополнительных усилий (деньги, сроки) и культуры разработки (которую не всегда купишь). При этом такие фичи исторически не являются стандартом, т.е. могут делаться в виде приятного дополнения, но по дефолту не ожидаются. Я здесь и далее говорю о приложениях десктопных и веб-, которые их имитируют.
Эмм, реализация всех фич требует дополнительных усилий. При этом некоторые вещи легко и дёшево делать на десктопе, а некоторые — легко и дёшево делать в вебе.
При этом некоторые разработчики зачем-то вкладывают дорогостоящие усилия в эмуляцию тех "фич" десктопа, которые вообще не нужны.
G>Иногда такие фичи просто не нужны объективно. А в случае приложений с тяжелыми данными я не совсем представляю, как это могло бы работать хорошо. Например, для чего-то типа Фотошопа или 3д редактора создавать копию приложения, синхронизировать каждый чих между копиями может быть накладно по ресурсам/тормозам.
Во-первых, ничего страшного в "тяжёлых" данных нету. Вот у меня мейлбокс в лучшие годы занимал 30GB. Мешало ли это аутлуку показывать его одновременно в двух окнах? Нет, не мешало.
Во-вторых, вовсе незачем держать целую отдельную копию всего приложения. Речь идёт всего лишь о том, чтобы иметь два параллельных view одних и тех же данных.

G>Если бы "многокопийное" поведение было стандартом де факто для юзеровских приложений, то для каких-то их классов могли бы вылезти некоторые связанные с этим свои, новые ограничения, в конечном итоге сказывающиеся на возможностях для пользователя. Я это допускаю (органы на плаху не положу).
Не важно, стандарт это или нестандарт. Ограничения большинства известных нам приложений связаны не с какими-то естественными причинами, а в основном с историческими соображениями.
Тот же Excel прекрасно может показывать один и тот же спредшит параллельно в режиме split view. Но при этом открыть его второй раз в отдельном окне не получится — ни в рамках того же процесса, ни в отдельном процессе. Есть ли объективые причины для этого? Ну, просто тридцать лет назад были приняты определённые архитектурные решения, а сейчас этот продукт находится в maintenance mode, и в него добавляют только мелкие косметические изменения. Денег на сколь-нибудь существенную переработку движка нет примерно с 2003 года.
Почему я думаю, что нет фундаментальных причин не поддерживать "многокопийное" поведение? Да потому что google docs. Там с одним спредшитом прекрасно работает не только один человек через много окон, но и много людей одновременно.

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

G>Удобные фишки из веб вроде back/forward можно реализовывать другими средствами, без копий. В той же Майе можно гулять туда-сюда по view и по layout'ам экрана в рамках ее воркфлоу, никак не связанного с привычками из веб. Там в этом была необходимость изначально, и все давно было сделано.
Ну так и я о том же говорю — навигационный доступ нужен достаточно часто, и реализован даже на десктопе.
Невозможность открыть линку веб-приложения в другом окне тесно связана с навигацией: если линка не открывается в другом окне, то при клике в том же окне она не будет корректно отрабатывать кнопку back.
Ну, если быть совсем точным, то можно сделать такую линку, которая корректно воспроизводит back/forward, но при этом в отдельном табе или окне не открывается.
Но для этого нужны прямо отдельные сознательные усилия.

G>Ближе к топику. Если у пользователя одностраничного веб приложения возникает желание открыть копию в новом табе, и невозможность сделать это его бесит, то, весьма вероятно, это приложение просто плохо продумано. Вряд ли дело только в том, что кнопка внешне выглядит как линк.
Совершенно верно. Речь — именно о том, что приложение плохо продумано. Замена линки на кнопку всего лишь сделает этот факт менее очевидным.

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

В принципе, наверное, современные подходы к приоритизации разработки отчасти виноваты в таких результатах.
В том смысле, что навязываются всякие scenario-based approach, когда менеджмент фокусируется на каких-то конкретных историях. С одной стороны, это позволяет избежать порождения софта в стиле "конструктор", когда пользователь вынужден сам собирать нужный ему сценарий по кусочкам из имеющихся "функций". Иногда с риском так и не собрать его до конца.
С другой стороны, feature-based approach позволяет продумывать поведение приложения и за пределами прописанных в сценарии путей.
Мой любимый пример — устаревший много лет назад API для Microsoft Online Syndication Interface, MOSI. Если бы его проектировали в терминах фич, то там было бы что-то вроде partner can manage the tenant subscriptions. Ок, есть тенант, у него есть подписки. Что такое "manage"? Create, List, Read, Update, Suspend, Resume, Cancel. Поехали, реализуем.
Увы, его проектировали в терминах "сценариев". (Я видел внутренний документ, на основе которого писался код). Сценарий "Партнёр перечисляет подписки тенанта" в список включён не был. В итоге, если клиент фейлился между тем, как он получил результат операции Create, и сохранил ID подписки в свою базу, то подписка тупо утекала. Не было никакого способа восстановить её ID.

С SPA происходит примерно так же — менеджер продукта описывает бизнес-сценарии. Ему не приходит в голову опускаться до универсальных деталей обстановки вроде "кнопки должны нажиматься", или "линки должны поддерживать навигацию вперёд-назад, сохранение в закладки и формирование шорткатов". В итоге девелоперы-нигилисты тупо выбрасывают эти аспекты поведения. В итоге получаем — тексты, которые нельзя скопировать по Ctrl-C, документы, которые невозможно напечатать, и ссылки, по которым можно пройти только один раз.

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

пардон за тормозной постинг.

S>Эмм, реализация всех фич требует дополнительных усилий. При этом некоторые вещи легко и дёшево делать на десктопе, а некоторые — легко и дёшево делать в вебе.

Фичи имеют приоритеты. Для многих SPA и десктопных поддержка синхронных копий наверняка вообще не рассматривается. для Гугль докс это, наоброт, очень важная, изначально запроектированная функция.

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

S>Во-первых, ничего страшного в "тяжёлых" данных нету. Вот у меня мейлбокс в лучшие годы занимал 30GB. Мешало ли это аутлуку показывать его одновременно в двух окнах? Нет, не мешало.

Почтовый клиент все же держит в памяти не все 30Гб, а небольшое "окно". Я говорил о приложениях, которые работают с большими данными полностью в памяти. Подобия упоминавшихся Фотошопа и 3д редакторов в веб уже есть.

S>Во-вторых, вовсе незачем держать целую отдельную копию всего приложения. Речь идёт всего лишь о том, чтобы иметь два параллельных view одних и тех же данных.

С разными view понятно. Я говорю о копиях, потому что топик начался с нового таба, который для SPA копия.

S>Не важно, стандарт это или нестандарт. Ограничения большинства известных нам приложений связаны не с какими-то естественными причинами, а в основном с историческими соображениями.

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

Если бы поддерка синхронных копий по каким-то причинам была бы маст хэв (представим), то, видимо, под это уже были бы общеупотребительные api с паттернами и фреймфорками, и такая разработка была бы дешевле. Но поскольку такого массового запроса от человечества не случилось, сейчас такая разработка для обычных приложений — это нечто штучное.

S>Нет никаких интересных горизонтов для безопасности веб приложений. Веб приложения всю жизнь умели работать в многих копиях. Чтобы это поведение сломать, нужно принимать специальные меры в разработке приложения.

Трудно сказать, я не спец. Скажем, обмен данными между окнами броузера через сообщения считается небезопасным. Насчет остального для "горизонтального" обмена данными между табами, без сервера (localStorage, файловый api, кэш..?) — не знаю.

Ниже я поскипал, т.к. согласен либо не знаком с конкретными вещами, которые ты упоминаешь, могу только по-своему догадываться.

Здравствуйте, 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 браузера рассчитаны на параллельную работу из любого числа окон.

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

S>Речь не идёт ни о каких "синхронных" копиях.
S>Любое веб приложение должно понимать, что нет способа гарантировать "единственность копии". Ваш URL всегда могут открыть разные пользователи, или один и тот же пользователь дважды.

"Синхронная копия" появилась, поскольку в теме присутсвовал и десктоп.

S>Неумение работать с такой ситуацией — это некомпетентность.

Тут я должен признать, что был не прав. Отстал от жизни, недооценил современные подходы к разработке. Посмотрел специально 2 онлайновых 3д редактора: Autodesk Tinkercad и Clara.io, который был начат энтузиастом-одиночкой и был очень прост, затем получил спонсоров и развился. Оба работают корректно в смысле синхронизации, видимо, такая работа уже считается нормой. Они, похоже, работают через сервер, лаг заметен. Меня специально интересовали софты с заведомо "тяжелыми" данными.

S>Никто не работает с большими данными полностью в памяти. Никакой фотошоп не будет держать 30GB в памяти — потому, что ему надо уметь работать в 8GB RAM, а иначе грош ему цена.

S>Нет, это вы сами себе придумали про "копию". SPA вовсе не означает необходимости держать все 30GB в памяти браузера. SPA — всего лишь возможность работать без перезагрузки документа.

Ранний Фотошоп славился именно возможностью работать с огромными данными при тогдашней малой ОП, в веб можно попытаться повторить подобное, работая, например, с тайлами. Для 3д редактора такое представить уже сложнее.

S>Во-первых, он не нужен. Нормальное SPA не должно зависеть от межоконного обмена — ведь "окна" могут быть открыты на двух разных машинах.

Меня тут слегка затянуло в личное, в предварительные собственные прикидки. Меня интересуют приложения с "тяжелыми" данными, которые через сервер гоняются не очень быстро. К тому же хотелось минимизировать работу с сервером (примерно до уровня Open\Save), отсюда думы о локальном межоконном обмене. Т.е. тема для меня оказалась полезной, отрезвляющей, спасибо.

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

G>Тогда логично, что не открывается в новом табе. Это в multi-page app. обычно при нажатии на определенную ссылку на сервер передается все необходимое и генерируется новая, совершенно независимая страница, которую можно открыть в любом табе. А в SPA все хранится и делается внутри одной страницы.
У меня в текущем проекте тоже SPA, но ссылки отлично открываются вновом окне.
Что я делаю не так?