Quão seguros estão ocultos O AJAX solicita esse desempenho falso?

Não é tanto o desempenho "falso" quanto a capacidade de resposta real. Existem várias razões pelas quais é popular:

• Conexões com a Internet são bastante confiáveis hoje em dia. O risco de uma solicitação do AJAX falhar é muito baixo.
• As operações que estão sendo executadas não são realmente críticas para a segurança. Se seus e-mails não forem excluídos no servidor, o pior que acontece é que você precisa excluí-los na próxima vez que acessar a página.
• Você pode criar sua página para desfazer a ação se a solicitação falhar, mas você não precisa ser tão sutil porque isso significa que sua conexão com o servidor está quebrada. É mais fácil dizer "Conexão perdida. Não é possível salvar as alterações recentes. Tente novamente mais tarde".
• Você pode criar sua página para permitir apenas uma solicitação AJAX pendente, para que seu estado não fique muito fora de sincronia do servidor.
• O navegador avisa se você tentar fechar ou sair de uma página enquanto uma solicitação AJAX está pendente.

Supondo que algo funcionará e exibindo um erro caso ele falhe no lado remoto é muito mais fácil de usar do que bloquear o usuário de fazer qualquer outra coisa até que haja uma resposta do servidor.

Um cliente de e-mail é um exemplo ótimo para isso: Quando eu tenho uma lista com 5 e-mails e a parte superior é selecionada, espero que acesse DEL três vezes os três primeiros emails são excluídos. Com "AJAX sem bloqueio", isso funciona bem - toda vez que clico na tecla, o e-mail selecionado é removido imediatamente. Se algo der errado, um erro será exibido e os e-mails não excluídos adequadamente serão mostrados novamente OU a página será recarregada para se livrar do estado local inconsistente.

Portanto, no caso mais comum - isso é sucesso - melhora a usabilidade. No caso raro - falha - a usabilidade é degradada (o elemento excluído é exibido novamente ou o aplicativo é "reiniciado"), mas ao criar um aplicativo geralmente é necessário ter a melhor usabilidade para casos comuns, não em caso de erros.

Os usuários não se importam com o que seu software está fazendo nos bastidores: eles querem que suas ações tenham um impacto visível e que possam trabalhar em seu ritmo.

Se uma ação for bem-sucedida no lado do cliente, como excluir e-mails, o seu trabalho também será bem-sucedido no lado do servidor. Por que a exclusão falhou? Se for devido a algum tipo de limitação (por exemplo, você não pode remover um email que tenha sido arquivado), o usuário deve estar ciente de que antes sua ação falhou.

Se o erro for causado por algo mais grave (digamos, uma falha no banco de dados), você deve ter uma maneira de salvar a operação e tentar novamente quando o sistema estiver ativo novamente.

Um bom exemplo de como gerenciar isso é o modo como o Facebook lida com o bate-papo. Não há como impedir que um usuário se desconecte de repente, o que significa que não conseguirá ler as mensagens que você enviou antes de saírem. Em vez de exibir um erro, o sistema salva todas as mensagens e as disponibiliza para o usuário quando ele volta. Nenhum dado é perdido.

Você pode comprometer entre as duas opções. Por exemplo, se o usuário excluir um email, você poderá marcá-lo em vermelho ou em cinza até receber uma confirmação do servidor e removê-lo da lista. O usuário ainda pode fazer outras coisas enquanto uma ação está pendente, por isso não está bloqueando, mas ainda deixa um pequeno lembrete para o usuário de que suas ações ainda não foram confirmadas.

O Amazon AWS adota essa abordagem: quando você para / inicia uma instância, a caixa de seleção que permite a seleção se transforma em um controle giratório (assim você não pode fazer nada por alguns segundos), mas isso não impedir que você interaja com outras instâncias.

Acho que isso vem junto com mais e mais sites que tentam se comportar como aplicativos e fazem mais processamento no navegador (como validar dados de formulários) do que os sites mais tradicionais. Eu não vejo muito problema nisso desde que seu código seja confiável e você pode esperar que ele tenha sucesso sob condições normais.

Você diz "É neste momento que o código JavaScript descobre que a solicitação do AJAX falhou. O script pode mostrar uma mensagem de erro, mas, na verdade, isso é inútil".

Por que deveria ser inútil? Você pode voltar na lista de e-mails e fazer a exclusão novamente. Por que esperar em vez disso? Na verdade, não há muito "risco" e eles não "parecem" rápidos, eles trabalham mais rápido. Então, se a atividade não é "crítica", por que ser lento?

Meu 2c é: há situações em que é melhor ter, como você diz, operações Ajax "não-bloqueadoras" e outras onde a escolha é ruim. Exemplo: votar em um vídeo do YouTube. Você não quer que nenhuma parte da página seja bloqueada enquanto você clica no pequeno começo. É melhor falhar silenciosamente. Mesmo uma mensagem de confirmação seria over-kill. No entanto, seu exemplo com exclusão de e-mail eu qualificaria como obrigatório para solicitação de Ajax do tipo de bloqueio.

O Mongo DB faz algo assim (e isso pode ser considerado como um exemplo de aplicativo Desktop). Eles têm várias "Write Concerns" para suas operações, e você pode configurá-lo para valores diferentes para cada operação, desde "retornar imediatamente e não esperar por nada" para "bloquear" até receber confirmação de transferência de rede e em seguida, retorne "para" esperar até que o conteúdo seja agendado adequadamente para gravação em disco na máquina remota antes do seu retorno ". Obviamente, se você criar um cliente thick do Desktop (como C ++) usando o driver Mongo, definiria a preocupação de gravação mais leve para operações de banco de dados de "criticalidade" mínimas (como a verificação de novos emails) e outras questões mais restritas. .

Embora eu veja a utilidade do Ajax sem bloqueio, eu concordo com você que isso está acontecendo demais. Em um ponto, havia pelo menos um famoso site de "redes sociais" que faria isso para o upload de fotos. Você escolheu sua foto para fazer o upload e, em seguida, bam, imediatamente diria que está pronto, e então, no dia seguinte, quando você quiser adicionar mais algumas fotos (ou usar as que você acha que já adicionou), nunca foi encontrado. Mais tarde, eles desistiram disso e, na verdade, tiveram tempo para aguardar a resposta (e, de fato, você às vezes recebia mensagens como "falha ao fazer o upload da foto, tente mais tarde").