É uma boa idéia fazer interface do usuário 100% em Javascript e fornecer dados por meio de uma API?

Meu trabalho principal do dia é fazer aplicativos HTML. Com isso, quero dizer aplicativos do tipo CRUD usados ​​internamente com muitas visualizações de grade editáveis, caixas de texto, menus suspensos etc. Atualmente, estamos usando formulários da Web ASP.NET, que realizam o trabalho, mas o desempenho é geralmente sombrio e, com frequência, você tem que pular aros para conseguir o que você precisa. Aros pendurados no teto e incendiados.

Então, eu estou querendo saber se talvez seria uma boa idéia mover toda a interface do usuário para o lado do JavaScript. Desenvolva um forte conjunto de controles reutilizáveis, adaptados especificamente às nossas necessidades, e troque apenas dados com o servidor. Sim, eu gosto do paradigma "controle" (também conhecido como "widget"), que é bastante adequado para esses aplicativos. Portanto, no lado do servidor, ainda teríamos um layout básico semelhante à nossa marcação ASPX atual, mas isso seria enviado ao cliente apenas uma vez, e a parte Javascript cuidaria de todas as atualizações subsequentes da interface do usuário.

O problema é que nunca fiz isso antes e nunca vi ninguém fazendo isso, então não sei quais seriam os problemas. Em particular, estou preocupado com:

• Desempenho ainda. O benchmarking mostra que atualmente o principal atraso está no lado do cliente, quando o navegador tenta renderizar novamente a maior parte da página após uma atualização do AJAX. A marcação gerada pelos formulários da Web do ASP.NET dá um novo significado à palavra "web", e os ricos controles Devexpress adicionam sua própria camada de complexidade Javascript. Mas seria mais rápido recalcular todas as alterações necessárias no lado do Javascript e atualizar apenas o que precisa ser atualizado? Observe que estou falando de formulários que têm várias visualizações de grade editáveis, muitas caixas de texto, muitas caixas suspensas, cada uma com itens filtráveis ​​de meio zilhão, etc.
• Facilidade de desenvolvimento . Agora haveria muito mais Javascript, e provavelmente misturaria com a marcação HTML da página. Esse ou algum tipo de novo mecanismo de visualização teria que ser produzido. O Intellisense para Javascript também é muito pior do que para o código C # e, devido à natureza dinâmica do Javascript, não se pode esperar que fique muito melhor. As práticas de codificação podem melhorar um pouco, mas não muito. Além disso, a maioria dos nossos desenvolvedores é primariamente desenvolvedores de C #, portanto haverá alguma curva de aprendizado e erros iniciais.
• Segurança . Muitas verificações de segurança terão que ser feitas duas vezes (no servidor e na interface do usuário), e o servidor de processamento de dados precisará incluir muito mais. Atualmente, se você definir uma caixa de texto para ser somente leitura no lado do servidor, poderá depender de seu valor não ser alterado pela ida e volta do cliente. A estrutura já possui código suficiente para garantir isso (por meio da criptografia do viewstate). Com a abordagem somente de dados, fica mais difícil, porque você precisa verificar tudo manualmente. Por outro lado, talvez seja mais fácil detectar falhas de segurança, porque você terá apenas dados para se preocupar.

Em suma, isso resolverá nossos problemas ou os piorará? Alguém já tentou isso e quais foram os resultados? Existe alguma estrutura por aí que ajude nesse tipo de empreendimento (jQuery e equivalentes morais à parte)?

O Linkedin faz isso no site móvel (consulte http://engineering.linkedin.com/nodejs/blazing-fast-nodejs-10-performance-tips-linkedin-mobile parte 4) e, aparentemente, tem sido muito benéfico para eles de um ponto de vista de desempenho.

No entanto, sugiro que você evite fazer o mesmo, por vários motivos.

A primeira é a manutenção: o C # / ASP.net é, por ser uma estrutura do lado do servidor, independente do cliente, enquanto o Javascript não é (mesmo com uma estrutura como o jQuery, você não terá 100% de compatibilidade entre navegadores , não à prova de futuro). Eu diria que também é mais fácil verificar a funcionalidade de um aplicativo estaticamente digitado do que dinâmico, que é algo que você absolutamente deve considerar se estiver criando sites em grande escala.

A segunda é que você achará difícil encontrar outras pessoas capazes (e dispostas) de criar um aplicativo de javascript puro do tipo de complexidade necessária para executar todo o site (em comparação com a facilidade relativa de encontrar. Programadores NET). Isso pode não ser uma preocupação sua diretamente, mas certamente é algo para se pensar a partir de uma perspectiva de longo prazo.

O terceiro problema é a compatibilidade do cliente; se você estiver criando sites voltados para o público, lembre-se de que uma parte razoável da rede ainda não tem o JS ativado (por vários motivos); portanto, você precisa ter certeza absoluta de que não excluirá uma grande parte da sua base de usuários, alternando para um site orientado a JS.

Quanto às suas preocupações com marcadores:

• Eu não me preocuparia muito com o aspecto de segurança, não há razão para que você não possa misturar paradigmas e fazer algum processamento no servidor quando precisar de segurança (você terá um código de renderização de exibição em algum lugar que retorne HTML , não há motivo para que você não possa fazer isso apenas disparar uma chamada AJAX, quando necessário).

• Facilidade de desenvolvimento não é realmente uma preocupação também, na minha opinião, existem ferramentas muito boas disponíveis para o desenvolvimento de JS, não apenas entre no VisualStudio porque você está acostumado! (tente o JetBrains WebStorm, por exemplo).

• O desempenho dos mecanismos de exibição JS é absolutamente bom na maioria dos casos (novamente, na minha experiência), eu os uso intensamente no dia-a-dia. O que eu sugeriria é evitar as estruturas mais pesadas, como knockout.js, etc., e seguir para algo como o micro template de Jon Resig. Dessa forma, você pode conectar o código de suporte de maneira que você confie que é rápido e confiável.

O que eu faria, se fosse você, é realmente examinar as razões por trás dessa mudança; Pode ser que você não esteja aproveitando o .NET de maneira eficaz e precise aprimorar seu jogo, o WebForms não é uma estrutura particularmente lenta pronta para uso, portanto, talvez algumas das bibliotecas de terceiros que você está usando estão desacelerando sua renderização.

Tente fazer um perfil de desempenho do aplicativo usando uma ferramenta de teste e perfil de carga e veja onde estão os seus gargalos antes de dedicar muito tempo e esforço a uma solução mais radical. Você provavelmente ficará surpreso com o que encontra como culpado por sua lentidão!

Use ExtJS se você quiser ir por esse caminho, não reinvente a roda. Mas esteja preparado, isso significa uma mudança completa de paradigma. Suas habilidades em HTML são quase obsoletas. AJAX em qualquer lugar, o servidor geralmente fornece uma API AJAX. Você escreverá muito mais javascript do que nunca, então é melhor garantir que você realmente se encaixa com o javascript.

A equipe da minha equipe decidiu migrar para o ExtJS no final de 2008. Nesse momento, tínhamos um aplicativo PHP de 200.000 linhas que sofria de problemas de front-end. Nossa situação era muito pior que a sua, porque tínhamos uma estrutura de controles de formulário handroll muito ruim e tínhamos muito uso de iframes para carregar seções da página (a arquitetura visual datada de 2005 e a equipe não estava ciente do ajax tão cedo). Tivemos que refatorar o código de qualquer maneira, portanto, isso facilitou a decisão de re-projetar fortemente a base de código para ser principalmente do lado do cliente.

Hoje, o aplicativo possui 300.000 linhas, das quais 60.000 são código extjs, e aproximadamente 3/4 da funcionalidade foi migrada para o ExtJS. O código extjs é um aplicativo de página única, mas ainda incorpora alguns formulários herdados dentro de iframes. Transportamos primeiro o contêiner de navegação e depois migramos as diferentes áreas de recursos aos poucos. Com essa abordagem, conseguimos migrar a migração extjs para o processo regular de desenvolvimento de recursos, sem nos tornar muito lentos.

• atuação

  O código ExtJS provou ser muito mais rápido que o código herdado. O código antigo era obviamente muito ruim em termos de desempenho, mas mesmo assim estamos felizes com os resultados. O código da interface do usuário é todo javascript estático, portanto, faz um cache muito bem (estamos nos estágios de planejamento de lançá-lo em uma CDN). O servidor não está envolvido na renderização do front-end, o que reduz a carga de trabalho. Também ajuda o ExtJS a fornecer muito controle sobre o ciclo de vida da interface do usuário (renderização lenta, descarregamento fácil de elementos invisíveis da interface do usuário). Normalmente, quando o código é inicializado (arquitetura de carregamento sob demanda), a maior parte do tempo de carregamento de uma tela é gasta na chamada de serviço da web para buscar os dados. A grade ExtJS é realmente rápida, especialmente ao usar visualizações em buffer para renderizar as linhas visíveis na rolagem.

• Facilidade de desenvolvimento

  Para ser honesto, este é um saco misto. O ExtJS é um DSL, não é realmente um desenvolvimento da Web no sentido tradicional. Nossos desenvolvedores levaram muito tempo para realmente aprender a API da estrutura, e não vejo essa curva menos acentuada em outras estruturas do lado do cliente. Todos na equipe devem ser um desenvolvedor javascript "sênior" (como regra geral, o livro de crockford não deve conter segredos). Sofremos problemas de inicialização com novos desenvolvedores, porque o conhecimento do lado do cliente não é tão amplo quanto você imagina, e o conhecimento do extjs é quase nulo (na Bélgica, onde estamos localizados).

  Por outro lado, quando você estiver atualizado, a experiência do desenvolvedor é muito boa. O ExtJS é muito poderoso; portanto, se você estiver interessado, poderá criar telas incríveis rapidamente. Em termos de IDE, usamos o PHPStorm, que eu achei competente o suficiente com o código ExtJS.

• Segurança

  A segurança é um dos principais motivos para fazer a interface do usuário do lado do cliente. O motivo é simples: redução da superfície de ataque. As APIs de serviço da web usadas pelo nosso código ExtJS são uma superfície de ataque muito menor do que uma camada de interface do servidor. O ASVS do OWASP especifica que você deve validar todas as entradas no servidor para correção antes de usá-lo. Em uma arquitetura de serviços da Web, é óbvio e fácil quando e como fazer a validação de entrada. Também acho mais fácil raciocinar sobre segurança em uma arquitetura de interface do usuário do lado do cliente. Ainda enfrentamos problemas com o XSS, porque você não se isenta da codificação para HTML, mas no geral somos muito melhores em segurança do que estávamos na antiga base de código. O ExtJS facilita a validação de campos de formulário no servidor, para que não soframos muito por ter que escrever código duas vezes.

Se você pode dar ao luxo de não oferecer suporte a usuários sem script e os mecanismos de pesquisa não lhe interessam, sim, é uma abordagem perfeitamente viável. Aqui está um breve resumo dos prós e contras:

Prós:

• tudo em um só lugar (javascript)
• você pode carregar dados do servidor, não a marcação, o que pode economizar muita largura de banda se feito corretamente
• é mais fácil obter um aplicativo responsivo (a latência da rede ainda está lá, mas a resposta inicial à entrada do usuário é mais rápida)
• o servidor da web não precisa renderizar HTML ou expandir nenhum modelo (ou seja, o esforço de processamento é movido do servidor para o cliente)

Contras:

• tudo precisa estar em javascript (pode ou não ser um problema)
• lógica crítica precisa ser duplicada no servidor
• O estado precisa ser mantido no cliente e no servidor e sincronizado entre os dois
• a segurança pode ser mais difícil de corrigir (considerando como qualquer coisa no código do lado do cliente pode ser manipulada por usuários mal-intencionados)
• você expõe grande parte da sua base de código (o código executado no servidor não pode ser visto de fora)

Pessoalmente, acho que se você seguir esse caminho, o ASP.NET UpdatePanels não será o caminho certo. Eles são ótimos para ajaxificar parcialmente os aplicativos Web existentes, mas ainda enviam HTML pelo AJAX, e o gerenciamento do estado dessa maneira pode ser bastante complicado. É melhor você ir até o fim, servindo apenas um documento HTML estático e depois usar uma biblioteca de modelos javascript para fazer a renderização HTML; o servidor não serve nenhum HTML dinâmico, em vez disso, o cliente faz chamadas no nível da lógica de negócios para o servidor e recebe dados brutos.

Sim você pode, mas ..

Você precisa ter uma "degradação" graciosa para que partes críticas do seu aplicativo ainda funcionem sem Javascript.

É assim que eu construo a maioria dos aplicativos no estilo "HIJAX".

Meu site ainda está em sua infância, mas 100% js ui tem sido bom para mim até agora. A única lógica do servidor que existe no front-end são os mapeamentos de modelo e os URLs do ajax. O servidor não tem nenhum conhecimento sobre a interface do usuário, o que para mim é muito fácil de manter. Se você estiver interessado, pode fazer o checkout do meu site, escrito em ExtJS http://coffeedig.com/coffee/ . Meu site realmente não tem problemas de segurança, mas o cliente ajuda o usuário normal através de uma validação simples. Eu sei que um usuário mal-intencionado pode realmente enviar qualquer ajax para o servidor, para que toda a lógica de "segurança" seja feita no servidor.

Acho que o maior problema para você é que você fará uma reversão completa do que sua equipe está acostumada, haverá uma curva de aprendizado acentuada. Eu acho que a melhor abordagem seria experimentar alguns frameworks js e tentar ter a sensação disso escrevendo algumas telas simples.