todomvc.com
Я посмотрел backbone.js версию. Сохранение должно происходить по функции save, но к Backbone применены рантайм патчи в файле backbone.localStorage.js, которые меняют меняют персистенс механизм с запросов к серверу на локалсторадж.
Был проект, где делали реально долгие запросы. Там рисовали спиннеры на экране. Если запрос - сохранение в базу, то обычно ничего не рисуют. Для всяких корпоративных хреней хороший вариант - глобально подписаться на все XHR запросы и на любой запрос рисовать спиннер в углу экрана (как сделано, например, на quakelive.com)
Что происходит на экране во время обращения к серверу?
Был проект, где делали реально долгие запросы. Там рисовали спиннеры на экране. Если запрос - сохранение в базу, то обычно ничего не рисуют. Для всяких корпоративных хреней хороший вариант - глобально подписаться на все XHR запросы и на любой запрос рисовать спиннер в углу экрана (как сделано, например, на quakelive.com)
Я посмотрел backbone.js версию. Сохранение должно происходить по функции save, но к Backbone применены рантайм патчи в файле backbone.localStorage.js, которые меняют меняют персистенс механизм с запросов к серверу на локалсторадж.т.е. в реальности при большинстве событий: поставили галочку complited, завели новое todo, отредактировали старое, удалили, и т.д., будут запросы к серверу?
Для всяких корпоративных хреней хороший вариант - глобально подписаться на все XHR запросы и на любой запрос рисовать спиннер в углу экрана (как сделано, например, на quakelive.com)тут еще такой момент. Если от сервера есть ответ, и в ответе есть нечто, что надо показывать на экране, то во время запроса экран надо лочить, иначе пользователь накликает еще по экрану, а ответ от сервера будет соответствовать старому экрану. В Яндекс словарях эта реализация хорошо видна.
тут еще такой момент. Если от сервера есть ответ, и в ответе есть нечто, что надо показывать на экране, то во время запроса экран надо лочить, иначе пользователь накликает еще по экрану, а ответ от сервера будет соответствовать старому экрану. В Яндекс словарях эта реализация хорошо видна.А после этих вопросов логично спросить. Если всё равно с сервером общаемся интенсивно и экран лочим, то зачем на клиенте сложный код с навороченными архитектурами? Если можно тупо отрендерить html на сервере, как в старые добрые времена?
Ты никак боишься, что js-макаки лишат тебя работы? 
тут еще такой момент. Если от сервера есть ответ, и в ответе есть нечто, что надо показывать на экране, то во время запроса экран надо лочить, иначе пользователь накликает еще по экрану, а ответ от сервера будет соответствовать старому экрану. В Яндекс словарях эта реализация хорошо видна.Можно блокировать только функциональность, для которой эти данные нужны, а не приложение целиком. А для todo-листа все вообще шикарно, на сервер надо отправлять только сохранение состояния, это делается асинхронно, клиент предполагает что запрос успешен и не блокируется.
Если всё равно с сервером общаемся интенсивно и экран лочим, то зачем на клиенте сложный код с навороченными архитектурами? Если можно тупо отрендерить html на сервере, как в старые добрые времена?почитай вот это, например.
Если получение данных, то можно блокировать только функциональность, для которой эти данные нужны, а не приложение целиком.Ты пробовал такое программировать? Там получается писец, код сложный, а внешне этих сложностей почти не видно. В итоге разумнее просто лочить весь экран. Бенефиты от лоченья по частям не стоят затрат на разработку.
почитай вот это, например.
спасибо, почитаю
Ты пробовал такое программировать? Там получается писец, код сложный, а внешне этих сложностей почти не видно. В итоге разумнее просто лочить весь экран. Бенефиты от лоченья по частям не стоят затрат на разработку.Пробовал, получается обычная для js лапша. Что значит "не стоят затрат"? Для бэкофиса на 2,5 бухгалтера конечно не стоят, в случае популярных сайтов утверждение не очевидно.
Пробовал, получается обычная для js лапша. Что значит "не стоят затрат"? Для бэкофиса на 2,5 бухгалтера конечно не стоят, в случае популярных сайтов утверждение не очевидно.Приложение с лапшой сложно развивать.
Да, дополню. Естественно, если есть совсем независимые кусочки экрана, то их можно и по отдельности обновлять. Сейчас речь о реализации всё же связных областей, но не при всех событиях. И вот тут начинается сильное ветвление, которое для пользователя почти незаметно.
Ты думаешь, что на популярных сайтах тебе дадут на порядки больше тратить на разработку единицы функционала?
почитай вот это, например.Хератень, а не статья. Очевидные вещи и не более.
К теме треда почти не имеет отношение.
Why the Client?
While it's not necessarily the case with Battlelog, there are a bunch of really good reasons why you want to render stuff on the client side:
1. You can do partial updates. And you want partial updates since they are good for the user experience.
2. You can mix content together from different resources which is good for caching. If there is information on the page that rarely changes and is the same for each user you can load it from a well cached page and keep it in the client's DOM and never replace it.
3. Generating HTML on the server side is more expensive than on the client. You don't pay for the client side and even the fastest template engine on the server is beaten by an optimized JSON serializer. Faster apps mean more satisfied customers.
1. Уже давно все с сервера присылают несколько кусочков html-я.
3. Ах, я забыл, тут же все пишут настолько нагруженные сайты, похлеще stackoverflow. Такие что ботелнеком являет рендеринг текста. Кстати, в статье Python, а C# в 7 раз быстрее может выдавать текст, поэтому еще вопрос, что будет быстрее Python отдавать JSON или C# — HTML
Да и глупости это, не будет в этом ботелнека.
Ты никак боишься, что js-макаки лишат тебя работы?Как только они сравняются по своей продуктивности, я их тут же сам нанимать буду, поскольку работы много, а они ее задешево сделают. Только, боюсь, такого счастья не настанет.
т.е. в реальности при большинстве событий: поставили галочку complited, завели новое todo, отредактировали старое, удалили, и т.д., будут запросы к серверу?Не совсем понял вопрос. Обычно в интерфейсах есть явная кнопка для сохранения. Если ее нет, то придется конечно на каждое изменение отправлять данные.
тут еще такой момент. Если от сервера есть ответ, и в ответе есть нечто, что надо показывать на экране, то во время запроса экран надо лочить, иначе пользователь накликает еще по экрану, а ответ от сервера будет соответствовать старому экрану.
У меня что-то похожее один раз в практике было. Там пользователь выбирал разные опции, на сервере считалась цена. Пользователь при этом мог продолжать выбор опций. Я при изменении опций отменял предыдущий запрос и отправлял следующий. Вообще, xml http request колбеки могут выполниться в другом порядке чем отправлены запросы.
А после этих вопросов логично спросить. Если всё равно с сервером общаемся интенсивно и экран лочим, то зачем на клиенте сложный код с навороченными архитектурами? Если можно тупо отрендерить html на сервере, как в старые добрые времена?
Если приложение стейтфул по бизнес-логике, то оно будет стейтфул по имплементации. Представь например визард из 10 шагов, результаты сохраняются в базу только напоследнем шаге. Где ты будешь их хранить на предыдущих 9 шагах? В single page app такой проблемы нет.
Как только они сравняются по своей продуктивности, я их тут же сам нанимать буду, поскольку работы много, а они ее задешево сделают. Только, боюсь, такого счастья не настанет.ИМХО, в микрософте опасаются, что js-макаки вытеснят C#-профессионалов, и предпринимают уже отчаянные попытки создать особый микрософтовский джаваскрипт с дебаггером и интеллисенсом, главными инструментами продуктивного программиста. Даже хейлсберга сняли с сишарпа и бросили на это направление.
ИМХО, в микрософте опасаются, что js-макаки вытеснят C#-профессионалов, и предпринимают уже отчаянные попытки создать особый микрософтовский джаваскрипт с дебаггером и интеллисенсом, главными инструментами продуктивного программиста. Даже хейлсберга сняли с сишарпа и бросили на это направление.Это ты совсем мимо. Было ровно наоборот. Майкрософт хотела привлеч js-макак и выпустила новый Виндовс API, и на презентации API дергался JS-ом.
Но после C# этим никто не проникся.
И только потом начали пилить TypeScript.
А TypeScript, скорее всего, пилят, в противовес гуглу, чтобы он вдруг в один прекрасный момент не встроил в Хром какой-нибудь Dart, и не перевел постепенно web разработку на Dart. Майкрософт сейчас в позиции догоняющего, и ей выгодно держаться за старый, но общий стандарт JS. Иначе гугл всё захавает.
Это ты совсем мимо. Было ровно наоборот. Майкрософт хотела привлеч js-макак и выпустила новый Виндовс API, и на презентации API дергался JS-ом.Не понял, js-макаки не прониклись js-ом после C#?
Но после C# этим никто не проникся.
Не понял, js-макаки не прониклись js-ом после C#?js макаки не пошли на Виндовс, а те кто был на Виндовс не захотели работать с JS.
Не понял, js-макаки не прониклись js-ом после C#?Назови мне, где js выигрывает честную конкуренцию? Node.js?
В браузере нет конкуренции, там тупо монополя js-а.
Если приложение стейтфул по бизнес-логике, то оно будет стейтфул по имплементации. Представь например визард из 10 шагов, результаты сохраняются в базу только напоследнем шаге. Где ты будешь их хранить на предыдущих 9 шагах? В single page app такой проблемы нет.А какая проблема в не single page app? Где надо там и хранишь, хранение нелишнего состояния не является проблемой.
Оставить комментарий
6yrop
я тут наткнулся на такой замечательный сайт todomvc.comПосмотрел реализации на нескольких фрейворках. Но не увидел обращений к серверу. В реальности же данные на сервер должны попасть... Вот тут вопрос, когда, по какому событию данные отправляются на сервер? И нюанс тут в том, что обращение к серверу это долгая штука и асинхронная. Что происходит на экране во время обращения к серверу?