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


19

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)?


So on the server side we would still have a basic layout simliar to our current ASPX markup, but that then would get sent to the client only once, and the Javascript part would take care of all the subsequent UI updates.Você está descrevendo exatamente o que é o ASP.NET, o que indica que você provavelmente não o está usando corretamente. :) Nos aplicativos ASP.NET, se você colocar componentes nos painéis de atualização, a biblioteca javascript do ASP.NET executará postagens assíncronas no lado do servidor e somente renderizará novamente os componentes especificados por você.
Maple_shaft

@ maple_shaft - Eu sei, mas de alguma forma isso funciona lentamente como o inferno. Além disso, as grades já fazem retornos de chamada. Para todo o resto, se houver uma postagem, na grande maioria dos casos, você precisará atualizar a maior parte da página de qualquer maneira, porque os controles alteram a visibilidade / capacidade de gravação / etc. E isso é lento.
Vilx-

3
Toda vez que vejo um aplicativo ASP.NET em que alguém coloca tudo na página em um painel Atualização, sinto vontade de jogar meu monitor na parede>. <! Isso derrota praticamente todo o propósito do ASP.NET. Para manter o ciclo de vida do servidor e os eventos do aplicativo, é necessário que ele se comunique com o ViewState inteiro da página. Se você possui 200 controles e uma grade de dados, Joel Spolsky não precisaria prever que você terá grandes problemas de desempenho. Ed Woodcock e AmmoQ resumiram tudo perfeitamente, então não preciso dar uma resposta adicional.
Maple_shaft

1
@ maple_shaft - Desculpe, mas na verdade eu criei um perfil dessas coisas. Também estava lento nos computadores dos desenvolvedores locais, e o Fiddler mostrou claramente que a conexão HTTP foi aberta por menos de um segundo, enquanto a página apareceu apenas alguns segundos depois, e o tempo todo o navegador estava usando a CPU o máximo possível obter e estava basicamente congelado. Esse não é o Viewstate inchado, é o HTML / Javascript inchado.
Vilx-

1
@ Vilx- não há nada errado com o C # /. NET (além do Windows somente / custo). Existem grandes problemas com o inchaço que as estruturas do ASP.NET WebForms colocam em cima dele. Como mencionado, tente Nancy se você gosta do .NET. Mas isso é completamente fora do assunto, era apenas um comentário que você se sairia melhor se você parou de usar webforms
Raynos

Respostas:


10

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!


Não, como eu já comentei a resposta do Darknights, este é um aplicativo interno, sem (bem, pouca) parte voltada para o público, portanto, a dependência do JavaScript é aceitável. E eu fiz o perfil. O lado do servidor é bom. É o lado do cliente que se atola ao HTML pesado gerado (como eu disse, a marcação gerada pelo ASP.NET é sombria) e ao Devexpress Javascript.
Vilx-

1
Os sites ASP.NET do @EdWoodcock são, por natureza, direcionados a Javascript. É assim que ele lida com a comunicação assíncrona do ViewState e da renderização do elemento da página.
Maple_shaft

@ Vilx- Isso pode ser um choque, mas controles como Data Grids são extremamente complexos. Talvez você tenha muitos elementos em uma única página?
maple_shaft

@ Vilx- Talvez seja hora de analisar seu uso de controle, se eles estão gerando uma marcação maluca (na maioria dos casos, os controles padrão do asp.net não estão disponíveis, se você estiver usando coisas como repetidores em vez de DataGrids etc.), então talvez você deve rolar seus próprios controles (ou mover para HTML manuscrito em UserControls).
Ed Ed James

1
@maple_shaft - Ou, mais especificamente, o Flex, que (como eu o entendo) é construído sobre o Flash para exatamente esses fins. É outra ideia com a qual estou brincando há algum tempo. Mas ... por mais que tentei mencionar isso para outras pessoas, só recebi uma resposta negativa, por isso não consigo imaginar fazer isso. Também exigiria que todos nós aprendêssemos algo completamente novo.
Vilx-

8

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.


1
Estou muito confortável com Javascript. Eu sei que outras pessoas não são.
Vilx-

2
Eu fiz isso por vários anos em um trabalho anterior. O ExtJS é muito bom e você pode fazer uma enorme quantidade com ele.
Zachary K

@ZacharyK - Como é o desempenho em formulários realmente complexos? Uns como eu escrevi lá, com várias visualizações de grade, painéis, etc?
Vilx-

2
Muito bem. você precisa pensar em seus modelos de dados, é claro. Para ser sincero, tento evitar formas enormes e compor vários elementos menores. Mas isso tem menos a ver com os limites de ExtJS em seguida, um bom design etc
Zachary K

@ZacharyK - Com preguiça de me repetir. Leia meu comentário sobre a resposta de Ed Woodcock. Não posso simplificar. :(
Vilx

8

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.


Eu gostaria de poder fazer mais do que apenas +1 por causa da sua experiência real!
Vilx-

4

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.


1

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".


Os aplicativos já são pesados ​​em javascript e não funcionam sem ele. Nossos clientes estão bem com isso e nunca reclamaram. E, para ser sincero, ainda não encontrei um usuário com o Javascript desativado hoje em dia. Observe também que esses aplicativos NÃO precisam de nenhum tipo de SEO (seria um desastre se um mecanismo de pesquisa pudesse acessar todas essas informações confidenciais) e NÃO se destinam ao uso em dispositivos móveis. Também estamos pensando em criar algo semelhante para dispositivos móveis, mas isso está apenas em estágios conceituais por enquanto, e nem sabemos se haverá uma demanda.
Vilx-

2
"E, para ser sincero, ainda não encontrei um usuário que tenha o Javascript desativado hoje em dia." Olá, então. Eu tenho o noscript instalado, então o padrão para mim é ter o javascript desativado ao aterrar em um novo site. E, se nada funcionar, geralmente apenas fecho a guia do site.
Arkh

3
@ Arkh, você está pensando como um programador, não como usuário, nós representamos uma pequena minoria no grande esquema das coisas. Não vamos transformar isso em um "para js ou não para js?" porque sua sido feito até à morte em torno destas peças :)
Darknight

1
As pessoas que desativam o JS geralmente sabem que, ao fazer isso, podem encontrar sites que dependem dele e, portanto, não funcionam. Se eles desejam habilitá-lo para um site específico, é a escolha deles, mas se eles desabilitarem propositalmente uma tecnologia padrão, não me importo se eles não conseguirem navegar em um site. Por outro lado, eu não sei sobre o suporte de JS para leitores de tela. Esse pode ser um problema maior. E, claro, há o problema da indexação. Mas quando alguém deseja criar um aplicativo que não precise de indexação e que não seja utilizável por pessoas cegas de qualquer maneira, faz sentido confiar no JS.
1616 Andrea Andrea

1
maple_shaft Eu gosto de você, então direi bem, não vamos correr por esse caminho :) obrigado!
Darknight

1

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.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.