Как то с товарищем делали сайт (он JS, я бекенд). И там был момент — размещение заказа типа.

Он мне такой и говорит — а давай как сделаем асинхронным. Типа я на бекенде сделаю вместо одной функции 2 шт. — одна для размещения, другая для отслеживания состояния (или даже через WebSockets). А он у себя типа добавляет колесико и красивую анимацию.

Я посмеялся и сказал что смысла нет, т.к. функционал специально оптимизировали и даже 1000 заказов в секунду оно легко выдержит (а столько в том проекте явно не будет).

Но сейчас смотрю — все стараются делать именно асинхронным, вместо того чтобы оптимизировать бекэенд. Как лучше?

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

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

а как нужно пользователю?
если ему нужен (и это возможно дать) быстрый ответ, то лучше без асинхронщины.
иначе, конечно, лучше показать прогресс.
есть ещё разные нюансы. например, борьба с ботами. но это редкие случаи.

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

Ну, если под словом все ты имеешь в виду некоторые, а по словом вместо ты имеешь в виду вместе, то я тебе отвечу "и правильно делают". Иначе я даже не знаю как тебе ответить.

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


S>Я посмеялся и сказал что смысла нет, т.к. функционал специально оптимизировали и даже 1000 заказов в секунду оно легко выдержит (а столько в том проекте явно не будет).
Пртчем здесь оптимизация? Задержки могут быть и на пути к серверу. Чтобы человек понял что его "клик услышали" анимация не помешает.

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

S>Он мне такой и говорит — а давай как сделаем асинхронным. Типа я на бекенде сделаю вместо одной функции 2 шт. — одна для размещения, другая для отслеживания состояния (или даже через WebSockets). А он у себя типа добавляет колесико и красивую анимацию.

А зачем в этом случае "две функции и WebSocket"? Колёсико, вроде, чисто интерфейсная фича и не требует каких-либо действий от бэкенда. Либо я не понял идею.

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

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

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

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

S>Он мне такой и говорит — а давай как сделаем асинхронным. Типа я на бекенде сделаю вместо одной функции 2 шт. — одна для размещения, другая для отслеживания состояния (или даже через WebSockets). А он у себя типа добавляет колесико и красивую анимацию.

строго говоря колесико и анимацию он должен был прикрутить даже на один запрос, т.к. он все равно асинхронный. синхронные запросы остались наверное только в jQuery и то 100 лет deprecated

async (default: true)
Type: Boolean
By default, all requests are sent asynchronously (i.e. this is set to true by default). If you need synchronous requests, set this option to false. Cross-domain requests and dataType: "jsonp" requests do not support synchronous operation. Note that synchronous requests may temporarily lock the browser, disabling any actions while the request is active. As of jQuery 1.8, the use of async: false with jqXHR ($.Deferred) is deprecated; you must use the success/error/complete callback options instead of the corresponding methods of the jqXHR object such as jqXHR.done().

S>Я посмеялся и сказал что смысла нет, т.к. функционал специально оптимизировали и даже 1000 заказов в секунду оно легко выдержит (а столько в том проекте явно не будет).

важно не сколько выдержит бекенд а какой отклик будет у конкретного клиента, например с медленным и пропадающим интернетом, к тому же заказ наверное меняет статус, поэтому проверка статуса все равно нужна отдельной операцией

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

S>Он мне такой и говорит — а давай как сделаем асинхронным. Типа я на бекенде сделаю вместо одной функции 2 шт. — одна для размещения, другая для отслеживания состояния (или даже через WebSockets). А он у себя типа добавляет колесико и красивую анимацию.

S>Я посмеялся и сказал что смысла нет, т.к. функционал специально оптимизировали и даже 1000 заказов в секунду оно легко выдержит (а столько в том проекте явно не будет).
S>Но сейчас смотрю — все стараются делать именно асинхронным, вместо того чтобы оптимизировать бекэенд. Как лучше?

При чем здесь бакенд? Вот произошел таймаут. Что делать ?

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

S>Но сейчас смотрю — все стараются делать именно асинхронным, вместо того чтобы оптимизировать бекэенд. Как лучше?
0. Присоединяюсь к остальным: лучше и то и другое. Колёсико и вообще умение работать с асинхронностью поможет отработать таймауты и вообще медленный интернет, который не во власти бэкенда.
3. Есть ещё и воспринимаемая производительность. Грубо говоря, 0.3 секунды задержки, во время которых ничего не происходит, субъективно воспринимаются дольше, чем 0.7 секунды, во время которых что-то происходит: крутится колёсико, бежит "прогресс" бар, или ещё какая анимация.