Estou tentando entender o cenário de diferentes abordagens e práticas recomendadas em torno do desenvolvimento de JavaScript complexo do lado do cliente.
Não sei o que rotular esta classe de aplicativo, talvez pesado AJAX ou RIA (mas não plugins como Flash / Silverlight). Estou me referindo a aplicativos da web com essas características:
- Emular UX de desktop rico / nativo em JavaScript
- Contenha a maioria / todo o comportamento em JS do lado do cliente, usando o servidor como uma API de dados (JSON / Html-Templates).
Isso contrasta com o uso do servidor da Web para renderização da interface do usuário, produzindo todo o HTML em um modelo de atualização de página.
Alguns exemplos são:
- Google Docs / Gmail
- Mindmeister
- Pivotal Tracker
À medida que avançamos para o HTML5, vejo esse estilo de desenvolvimento de RIA, com JavaScript pesado, se tornando cada vez mais comum e necessário para competir.
PERGUNTA: Então, quais são as abordagens comuns que surgem em torno do gerenciamento desses tipos de desenvolvimentos pesados de JS?
O código do lado do cliente, à medida que um aplicativo cresce em recursos, é incrivelmente complicado. Há problemas para dimensionar um esforço de desenvolvimento em várias equipes com JS bruto (ou pelo que ouvi dizer e posso acreditar).
O Google abordou o problema criando GWT que compila de uma linguagem de nível superior (Java) para JS, apoiando-se na infraestrutura de desenvolvimento existente que a linguagem de nível superior possui (ferramentas Eclipse, digitação forte, refatoração), além de abstrair a compatibilidade do navegador e outros problemas fora do desenvolvedor.
Existem outras ferramentas, como o Script # para C #, que fazem algo semelhante. Tudo isso coloca JS mais no papel de uma IL (Linguagem Intermediária). ie "Você nunca mais escreve nessa 'linguagem de baixo nível'".
Mas essa 'compilação para JS' não é a única abordagem. Não é aparente que o GWT seja a abordagem dominante ... ou realmente se tornará.
O que as pessoas estão fazendo com JavaScript de cliente avançado? Algumas questões orientadoras:
- A maioria das lojas está criando JS manualmente (em cima de bibliotecas como jQuery et al)?
- Ou existem muitas abordagens diferentes, sem as melhores práticas claras emergentes?
- A maioria das lojas está evitando o desenvolvimento da escala de RIA em favor do modelo mais simples de desenvolver do lado do servidor / redesenho de página? Se sim, isso vai durar?
- A compilação para JS talvez seja uma tendência futura emergente? Ou isso é apenas errado?
- Como eles gerenciam a complexidade e a refatoração do JS do cliente?
- Modularização e distribuição do trabalho entre equipes?
- A aplicação, aplicação e teste de padrões do lado do cliente, como MVC / MVP etc.
Então, quais são as tendências emergentes neste futuro pesado de JavaScript e HTML5?
Obrigado!
fonte
Respostas:
A maioria dos aplicativos da Web que vejo (e desenvolvedores da Web com quem conversei) que estão se movendo nessa direção está usando o jQuery como base.
Todo o raciocínio por trás do GWT (e linguagens multiníveis semelhantes) é que o JavaScript é muito flácido / muito frágil / muito mutável para que "programadores reais" usem. Mas se você tem uma estrutura que lida com os bits flakey / frágil / mutável para você, não há razão para adicionar essa camada extra de complexidade.
Apenas minha opinião…
fonte
Eu diria que o GWT é arriscado. Depois de decidir usá-lo, você fica preso a ele. Basicamente, significa que você trata sua marcação, DOM e alguns aspectos do CSS como um ambiente de execução. Está ficando muito difícil misturar JavaScript escrito manualmente com o GWT, à medida que o código do cliente se torna cada vez mais sofisticado. O GWT possui métodos nativos, mas esses são bastante limitados em termos de possível aplicabilidade. Essa é uma grande troca e é uma grande aposta.
O Google tenta vender o GWT como um ambiente de execução da plataforma X muito rápido, com uma integração decente do lado do servidor. Mas, como outros já apontaram, não é mais o caso - JQuery e YUI são tão rápidos, se não mais rápidos. E é muito mais fácil criar um perfil e otimizar suas páginas quando montadas manualmente, para que você tenha controle total sobre CSS, marcação e JavaScript.
O GWT tenta ocultar a plataforma subjacente, o que pode ser uma maneira errada de fazer as coisas. Muitos dos chamados frameworks web de componentes fizeram o mesmo. Você deveria escrever um código ambíguo derivado de XML com tags EL e personalizadas inseridas. A saída seria uma bagunça de HTML mal formado com pequenos pedaços de JavaScript de baixa qualidade espalhados por todo o lugar. As páginas eram lentas, com erros e totalmente insustentáveis.
Em nosso projeto atual, usamos Stripes - uma estrutura baseada em ações de baixo nível - e JQuery no lado do cliente. É muito fácil fazer o Ajax depois de ver claramente todas as peças de um quebra-cabeça: aqui está o código do lado do servidor que opera com dados. Aqui está o código do lado do cliente - para recuperação de dados e para que as coisas aconteçam nas páginas. Aqui está o seu CSS, a sua marcação, o seu modelo - tudo está limpo e dissociado. Facilmente extensível, hackável, ajustável e depurável. Eu amo isso.
Eu amo o JQuery com sua atitude em relação à velocidade e simplicidade. Eu amo o YUI3 por modularidade e widgets abrangentes. Eu amo o YUI CSS por me dar consistência entre os navegadores. Adoro JavaScript para boas peças. Eu amo Java por me deixar fazer o trabalho.
Apenas beijo, e você vai ficar bem!
fonte
Eu ouvi esses chamados "aplicativos de página única".
Este é um novo ambiente, e as regras ainda não foram totalmente escritas. Eu trabalhei em um aplicativo de página única relativamente importante no ano passado (2010), e essas são as ferramentas que usamos.
O backend era Java, usando servlets para fornecer um serviço JSON, que a página usou para finalmente enviar o pedido preparado. Este serviço também foi usado para algumas etapas de validação e preços.
O código do front-end era javascript. Usamos o jQuery para manipular os elementos da página, o Pure para modelagem e o RequireJs para dividir o código em módulos. (A ferramenta de construção do RequireJs foi usada para fornecer downloads mais ideais.)
Escrevemos nossos testes usando o qUnit e tínhamos um teste do jUnit que usava a unidade html para executar cada teste do qUnit, raspa a saída para obter resultados e passa ou falha com base no status de aprovação / falha do qUnit. Eles foram adicionados aos nossos testes jUnit para o back-end e rolados para o nosso ci, usando Hudson / Jenkins .
fonte
Eu trabalho em um aplicativo desse tipo, construído sobre o Ext JS. O aplicativo é organizado de forma modular. Módulos diferentes são implementados como componentes independentes que são limpos após serem removidos da hierarquia de componentes Ext. Carregadores sob demanda carregam componentes adicionais antes de serem necessários (um arquivo js = um componente).
Descobri que essa abordagem não é tão difícil de dimensionar. Os únicos limites reais em que me deparei estão relacionados a ter muitos elementos DOM na árvore ao mesmo tempo no IE. A solução existe para descarregar estrategicamente partes ocultas do aplicativo. Como toda manipulação do DOM ocorre através da hierarquia do componente Ext, o DOM é quase totalmente abstraído e o desenvolvimento permanece direto.
fonte
Pessoalmente, acho que estruturas como o jQuery são vitais não apenas para lidar com variações em diferentes navegadores, mas também para afastar essas diferenças, para que não acrescentem ruído ao código. Ferramentas como GWT, Websharper e outras levam isso adiante e definitivamente têm um lugar, mas eu me pergunto se é apenas uma camada extra de indireção na maioria dos casos.
Algo que estou surpreso que ninguém mencionou é o teste de unidade. Agora é geralmente aceito que aplicativos complexos do lado do servidor devem ter testes de unidade automatizados e acho que já chegou a hora em que o JS nos aplicativos RIA é complexo o suficiente para precisar de testes de unidade - junto com a arquitetura / código que torna isso possível.
No entanto, diferentemente dos aplicativos complexos do lado do servidor, minha intuição com base no que vejo e ouço é que a grande maioria dos aplicativos complexos do lado do cliente não tem absolutamente nenhum teste de unidade (não estou falando de teste de selênio aqui, teste de unidade real).
Penso que a próxima tendência emergente será a introdução de testes de unidade (e código testável por unidade). Tendo acabado de concluir um projeto com uma quantidade moderada de JavaScript não testado em unidade, espero que seja o último.
fonte