gandjustasА может просто утечку починить? Или вы специально держите все данные в памяти? Зачем?

Починить можно. Но...



Смысл проблемы объяснять?

gandjustas$locationProvider.html5mode(true) - не?
Общий расход ресурсов - незначительная величина на пока ты не хочешь 2000+ строк отобразить

Ссылки будут более «правильные», ОК. Но это ничего не изменит для загрузки в отдельной вкладке, где состояние приложения надо будет полностью заново загрузить и проинициализировать. Не понимаю, что даст здесь html5mode

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

Во-первых, кто сказал, что загрузка страницы дорогая? Измерять-то не пробовал? Вот мы пробовали, и нашли, что 300-500 мс особой радости пользователю как-то не доставляет. А с грамотным кешированием, даже наоборот профит, так как данные на серваке уже готовы, и будут отрендерены на клиенте очень быстро независимо от мощностей клиента. Путь у него хоть самый дешёвый Андроид планшет, пользователь не будет испытывать дискомфорта. А во-вторых, загрузка страниц в отдельных вкладках ВСЕГДА быстрей, чем загрузка по маршруту SPA, тут хоть об стену лоб расшиби.

gandjustasОбщий расход ресурсов - незначительная величина на пока ты не хочешь 2000+ строк отобразить

И дело вовсе не в количестве строк. Каждая операция бизнес-процесса, это отдельный набор: шаблон+стили+контроллер+данные, а их много. Это экраны, формы, модальные окна, НЕмодальные окна (MDI), каскадные фильтры, «умная» графика, «живые» графики и показатели, уведомления (системные, операционные, инетрактивные, всплывающие), различные настраиваемые виджеты, личный «рабочий стол» настраиваемый вдоль и поперёк с огромной кучей показателей.

Куда прикажешь всё это девать? При переходе на другой экран, всё выкидывать на помойку, а при возврате загружать всё заново? Ну и в чём тогда смысл в SPA? ЧТобы потешить самолюбие и округлить глаза у начальства, горячо размахивая руками и доказывая что вот ЭТО и есть БУДУЩЕЕ и это есть КРУТО, а всё остальное УГ и прошлый век?

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

gandjustas,

Мы нашли великолепное решение в балансе. Не отказываемся от клиентского MVVM, и тех замечательных преимуществах, что он даёт. Непосредственно контент в HTML не генерится, но в Razor генерится общая разметка, на базе моделей и метаданных, всё очень строго типизировано (разработчики типичных SPA очень многое тярют, отказавшись от Razor). Страницы кешируются на серваке и клиенте, под юзеров, так что получение самой страницы это из кеша или 304, затем подтягиваются данные. Таким образом на каждой странице работает только тот код, который нужен именно на этой странице. Точно также можно методом R.JS подгружать и развивать функциональность. Всё работает очень быстро и органично. Пользователи уже накушались SPA, и видеть его не хотят. А по поводу вкладок я акцентирую внимание, потому что этот момент оказался одним из самых «болезненных» мест. Никто не хочет работать с приложением в одной единственной вкладке.

И самое главное, чего мы стали строго настрого придерживаться: никакого JavaScript в декларативных шаблонах.

На примере того же КО (чтобы было понятней):

ХОРОШО:




ОЧЕНЬ ПЛОХО:




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

gandjustasЯ проблемы не вижу. 100 мб для любого интерактивного приложения это немного. А вот последние 3 пика это или утечка или вы слишком много данных пытаетесь загрузить.

Хм. Нет, это как раз не утечка, и здесь не о мегабайтах речь. Кружочками же обведено, на что надо обратить внимание.

gandjustasКак раз пробовал. 2-3 секунды первоначальная инициализация почти любой страницы занимает, с прогретыми кешами - до секунды. В случае SPA она делается один раз, потом запрос данных (100мс) + рисование (200мс).

Не правда. Если в SPA что-то загружается в первый раз, то SPA кроме данных тянет скрипты (если они не забандлены) и шаблоны, это уж никак не 100мс, вместе с рисованием. Если тянется в первый раз страница, то загружается дольше на 300-500 мс при тех же условиях (первый раз). Второй раз, страница уже закеширована и открывается моментально, 10-20 мс. Ммм?

gandjustasС дешевым андроидом рисование страницы на клиенте будет также медленно работать, независимо от SPA\не-SPA.

Тут ты пипец как не прав. Мы эту ситуацию реально обрабатывали, теперь можно пользоваться даже на дешёвых Андроедах. С комфортом! А SPA было пользоваться нереально при недостаточных мощностей. Мы ещё требования к железу клиента браузера не прописывали, это нонсенс!

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

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

gandjustasЗЫ. Я сам не очень верю в SPA без оффлайна и тяжелой оптимизации, но утверждать что всегда обычное веб-приложение лучше - я бы не стал.

Не всегда, просто надо знать меру. Всё таки веб -- это многостраничная среда, по самому факту своего существования. И уже сколько технологий полегло на этой теме: Flex, Silverlight, Java апплеты... Но ёжики плакали, кололись, но упорно продолжали жрать кактус. Разобьём все грабли об наш непробиваемый лоб

gandjustasТоже самое с данными - сервер ответит 304 Not Modified и время загрузки сократится до времени раундтрипа.

С какой, интересно, кстати? И кто будет это поддерживать? Etag будешь в каждом запросе передавать? Или что? Чего это за бред вообще...

gandjustasВообще стандартная практика сократить потребление ресурсов - выкидывать все что не нужно как можно быстрее. Тоже самое делалось и в WPF\Silverlight.

Я уже картинку приводил выше, где отмечены красными кружками проблемные места в таком подходе. Как раз наоборот, надо не выкидывать, а замещать. Надо стараться всеми силами как можно меньше озадачивать «сборщика мусора». Я удивлён, что ты как оптимизатор, не знаешь таких банальных вещей.

gandjustasИ на что надо обратить внимание? Что у JS есть GC? Это проблема?

Я думал ты поймешь. Столько разговоров про оптимизацию было... Ну ладно. Бог с ним, забей.

gandjustasУ нормальных людей скрипты забандлены, поэтому разница в объеме - максимум 100кб с сжатом состоянии. Страница + шаблоны в SPA обычно занимают меньше самой страницы, отрендернной на сервере (ибо там шаблоны размноженные). Но больше всего при первой загрузке все равно поедают картинки. так что относительно увеличение времени первой загрузки в в случае SPA будет малозаметно, а последующие движения будут быстрее в случае SPA.

Но для такого поведения надо многое пооптимизироать. Например много отдельных шаблонов делать - жопа, бандлить их нельзя. Поэтому один route - один html, а для директив - писать html внутри JS.

«Писать html внутри JS» -- это что, оптимизация чтоли? Ну и ну... Дожили. Страница + шаблоны занимают меньше, да... Но это крайне несущественно, чтобы об этом вообще говорить.

В любом случае, даже если у SPA всё поголовно закешировано, хеш/html5 ссылка будет в отдельном окне ДОЛЬШЕ открываться, чем обычная страница. Если это конечно этот SPA не примитивный студенческий пример, а реальное многофункциональное приложение.

Это нами (по крайне мере) проверенный факт.

gandjustasЯ тестировал SPA на iPad, на нем значительно лучше работает без полной перезагрузки страницы. Ну и ессесно никаких вкладок там не надо.

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

Я привожу в пример приложение типа CRM на SPA, а ты что?

gandjustasНеобходимость работы с кучей вкладок - это вовсе не SPA сценарий. А на планшетах и телефонах SPA гораздо удобнее (особенно с оффлайн режимом). Может вам нужно два разных UI, а не один, который одинаково хреновый для обоих случаев?

Ну да, точно. Это же Single Page Application, значит вкладок быть не должно априори.... Забыл, это же так очевидно

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

В общем эта. Что-то мне надоело уже дискутировать по поводу SPA. Все о нём говорят, но реальных примеров успешного применения никто не даёт. Чай не вчера придумали этот термин, правда? Уже и фреймворков развелось мульён, и книг понаписано, и статей, и экспертов смотрю пруд пруди.

Однако говорят все про какого-то мифического ишака в вакууме. Я-то знаю, что Gmail -- это SPA. Но это ж почта. Это отличное применение, в смысле, что есть одна весьма конкретная задача (для gmail -- работа с почтой). Есть ещё GDrive, который тоже вроде как SPA, однако документы открываются в отдельной вкладке, хотя... как-же-это-так??? Ну ладно. Есть ещё вики, и бессметная куча ToDo-шек. И ещё есть пару сотен тысяч стартапов, которые обязательно делаются на SPA / Angular.JS -- ну там, супер новый сервис квартиру продать/купить/подобрать, к доктору записаться, запилить фото с котиком с комментом. Ну дак ниче против не имею.

Но вопрос в топике изначально поднимался о портале . Ну дак покажите примеры SPA-порталов? Да хоть бы один, хиленький. Или CRM или ещё чего-нить такого ядрёного. Где?

Нету? Раз нет, то и суда нет. Чё зря болтать?

gandjustasEtag или last-modified, а в чем проблема?

Я на хабре писал как это делать в ASP.NET:
http://habrahabr.ru/post/227129/
http://habrahabr.ru/post/240269/

Не заметил в статьях ни слова про предмет нашего обсуждения. Кеширование страничег и PartialView? При чём тут SPA? Мы ж грим про AJAX GET/POST/PUT/DELETE запросы? Предлагаешь замутить свой костыль для вкорячивания ETag и обработки кода 304 прямо в скрипты клиента? А кеш куда вкорячивать? В LocalStorage? Т.е. состряпать ещё и свой провайдер кеша на клиенте? Как раз всё то, что нативно поддерживает браузер, мы перепишем по-своему? Ты заплатишь за всё это?


gandjustasИ как же ты будешь замещать? Вот у тебя есть объект загруженный с сервера (шаблон или данные - не важно). Пользователь перешел на другой URL. объект стал не нужен. Как его заменить? Ты же загружаешь данные с сервера у тебя уже есть новый объект, что на что ты заменишь? Поэтому нормальный подход - старый объект выкидывается (ссылка на него стирается). Чем меньше ссылок на объекты, тем быстрее отрабатывает GC.

Нет, ты не прав. И должно быть очень стыдно, как оптимизатору говорить такие вещи. Я бы постыдился. Серьёзно.

Переиспользование выделенной памяти актуально везде, где память используется. Если речь идёт о длительном процессе. А SPA -- длительный процесс.

Память страницы растёт в связи с тем, что приложение содержит очень много функций. Основная Прелесть SPA не в экономии на спичках (загрузка RAW данных, вместо HTML), а в том, что загруженные части могут моментально переиспользоваться. Если всё точно также как в классическом вебе надо загружать заново, на кой чёрт нужен этот SPA? Усложнение разработки в разы, и ради чего? Сэкономить пару кбайт и пару сотен мс? И то, на деле (по факту реальной эксплуатации), это оказалось далеко не так. Кеширование, которое поддерживает сам браузер, это вещь оочень мощная, которую вообще не стоит недооценивать.

gandjustasПользователь перешел на другой URL. объект стал не нужен. Как его заменить?

Во-первых, с чего вдруг не нужен? Он перешёл на другой «URL» (который вовсе не URL), посмотрел, и вернулся. Браузер такую ситуацию обработает моментально! 5мс. Что сделат SPA? Полезет за данными, потом отренедрит? Нафиг этот SPA.

А как замещать, да элементарно. Не выкидываешь ссылки на объекты и всё. Обновляешь данные (а не удаляешь, затем добавляешь), тогда ДОМ просто обновится, а не будет сгенерирован заново. В общем, это сложно конечно в разработке, но если уж оптимизировать, то придётся делать именно так.

gandjustasЧто-то типа "личный кабинет руководителя". Несколько экранов, на каждом небольшой (до 30 элементов) того, что заслуживает внимания. В бекэнде СЭД.
Собственно этот SPA и появился, потому что СЭД имела перегруженный веб-интерфейс, который по 15-20 секунд в среднем открывался на планшете. Как раз типичный веб-интерфейс, где весь контент отдается с сервера, а потом прикручивается куча интерактива с jquery(-ui)

А ну по тому, что я понял, это вполне годно для СПА. А если весь СЭД делать на СПА?


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

Так об этом и речь!

gandjustasА зачем вкладки? Я пользуюсь Dynamics CRM, который SPA. Мне крайне редко приходится несколько вкладок открывать.
Кстати у DCRM разный UI для устройств и десктопов.

Некоторым пользователям это тоже не нужно, а некоторым очень нужно. Разве Dynamics SPA? Реально ВСЁ на одной единственной странице? Уверен?

gandjustasТы о чем? Браузер сам кеширует любой GET запрос, с учетом заголовков которые отдает сервер. И сам же передает if-modified-since и\или if-none-match. Тебе для этого ничего делать не надо.
А вот что можно еще руками сделать - так это складывать данные в localStorage и показывать "моментально" страницу при повторном заходе, а в фоне делать запрос обновлений и при наличии обновлений показывать пользователю ("у вас X новых сообщений, нажмите чтобы обновить"). Но это делать надо, а горе SPA-писатели до такого не доходят никогда.

Собственно об этом и речь. Ты предлагаешь запилить дополнительное управление кешем на клиенте, а это ещё одна дополнительная нагрузка на клиента, но ещё большая -- на разработчика. А сложность итак достаточно высока, даже при использовании готовых фреймворков. Работать с If-Modified-Since в AJAX, вообще лишнее, так как сам факт того, что клиент запрашивает данные -- значит надо их отдать, и не заниматься ненужным лишним усложнением. Либо передавать таймстамп в JSON. В зависимости от ситуации. А то смешалось в сё в кучу, кони, люди. Я бы лично крайне не советовал этим страдать.

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

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

Конечно будет, но требуется не избавиться от "зубьев", а максимально сгладить их (уменьшить провалы) там, где это возможно. Большая часть провалов приходится на очистку/генерацию ДОМ, а не на сами данные. Поэтому ДОМ лучше по возможности обновить, а не регенерировать.


gandjustasЧто значит "моментально переиспользоваться"? Вот ты зашел на стартовую страницу, потом на страницу А, потом на страницу Б. Внимание вопрос: что делать со всеми объектами страницы А? Оставить в памяти, чтобы "переиспользовать" или выкинуть?
Кажется что оставить - хорошая идея. На практике память быстро кончается. Я это много раз видел.
На практике самая хорошая идея - выкинуть все то, что было нужно только для формирования страницы А, а если пользователь на нее вернется, то большая часть необходимых данных поднимется из кеша.

Удивительное противоречие с тем, что SPA пытается взять лавры desktop приложения, как раз в этом качестве. Допустим ты открываешь окошко некой записи, окошко не закрываешь, открываешь ещё одно, так что делать с открытыми окошками? Окошки в смысле немодальные окна, ну или вкладки внутри приложения. Тут конечно уже by design, как говорится. А вот выкинуть всё и загрузить заново -- это основная идея веб. При чём память железно очищается, при чём быстро, одним махом, а не бегая по корням ссылок. Или F5 грубо говоря, это же оно и есть. Но мы вместо того, что просто использовать нативные развитые встроенные возможности браузера, будем эмулировать это поведение сами, попутно наступая на грабли, да?

gandjustasПотому что "все" с точки зрения обычных страниц и SPA - две большие разницы. В обычных веб страницах только 10% тратится на HTML. Остальное скрипты, кратинки, стили итп. Даже при мощном кешировании браузер все равно парсит и обрабатывает html\js\css каждый раз.

С какого перепугу??? Закешированный на клиенте HTML поднимается моментально вместо со всем барахлом, что к нему приатачено. И JS, и стили, и картинки. Это же профит в чистом виде.


gandjustasА в SPA все это происходит один раз, потом только небольшая часть HTMLя меняется. Этим достигается как увеличение скорости загрузки. На каждую страницу нужно только грузить один маленький json + html шаблон если он не был закеширован, а не весь HTML, который потом с нуля процессится.

Ничего подобного вообще. Если ты имеешь в виду HTML с данными -- да. Я имею в виду HTML без данных, загружается HTML, он загружает данные. Почти SPA, только страниц много. Каждая страница кешируется и открывается ____моментально______, при чём на борту несёт только то, что ей нужно. Затем вытаскиваются данные из AJAX или точно также из кеша или LocalStorage. Скажи в чём разница? Я скажу, в том, что память при этом девственно чистая, и очищается за пару микросекунд, так как сборщику мусора не надо скакать по кучам. Всё остально тож самое. Страница поднимается из кеша браузера, моментально. Это 10-20 мс, сам проверь.