AJAX
Acho que sua pergunta se resume a: "Meu aplicativo Web deve gerar HTML no lado do cliente ou no servidor?" A geração do lado do cliente se comunica com o servidor usando AJAX, embora o X (XML) geralmente tenha sido substituído pelo JSON, mas a maioria das pessoas ainda o chama de AJAX porque soa melhor. No lado do servidor, o servidor apenas cria HTML no servidor.
Tenho muita experiência com XML e quase nenhuma com JSON. Tudo o que sei sobre XML me faz sugerir que você use JSON, se possível.
Profissionais do AJAX:
- Envie menos dados por HTTP (S) para que eles possam executar mais rapidamente.
- O servidor é essencialmente um serviço da web para que outras pessoas (ou você) possam escrever seus próprios clientes. Isso pode ajudar ao criar uma versão móvel do seu site. Além disso, muitas invenções se tornam populares por razões que seu criador nunca pretendeu. Os serviços são mais amigáveis para as pessoas que encontram novos usos para o seu código.
- Parece um aplicativo mais recente
Contras AJAX:
- Depurando JavaScript
- Complexidade?
- O que você pode fazer com JavaScript geralmente é completamente impossível para pessoas cegas ou deficientes usarem.
- Pode exigir mais código total (armazenamento geral maior no seu dispositivo incorporado)
Servidor cliente
Todos os aplicativos da web usam a arquitetura cliente-servidor. O protocolo HTTP força os aplicativos da web a se comportarem dessa maneira. O AJAX usa uma solução alternativa para essa limitação de design, mas o modelo básico subjacente do HTTP ainda é cliente-servidor. Eu não ficaria muito preocupado com a melhor maneira de aplicar o MVC a aplicativos da web. Se você precisa fazer o MVC por razões políticas, veja como o Ruby / Rails faz isso. Na verdade, o Rails é uma ótima arquitetura para copiar (ou usar).
Serviço versus aplicativo.
Um bom serviço é quase sempre melhor que um aplicativo. Mas fazer um bom serviço é difícil! Pode ser necessário fazer o aplicativo antes de poder escrever uma especificação projetada o suficiente para um serviço. Não faça seu trabalho mais difícil do que precisa. Para a versão 1, concentre-se em criar um ótimo aplicativo. Até que seu aplicativo seja relativamente estável e você tenha certeza de que atende aos requisitos do usuário, ter um serviço provavelmente não fará nenhum bem. Projetar o serviço errado muito cedo é um desperdício de tempo que continua desperdiçando enquanto você tenta consertar sua interface de serviço e lida com a refatoração maciça do código do servidor e do cliente a seguir.
C / Web
Uau. Trabalhei em C e Assembly por 3 anos antes de mudar para o desenvolvimento web. Não consigo pensar em uma linguagem pior para escrever um aplicativo da Web - especialmente do ponto de vista da segurança. A validação de entrada e o escape de saída são tão críticos ... O SANS libera uma lista dos erros mais comuns a cada ano. Estouros de buffer, injeções, problemas entre sites (codificação de saída incorreta) ... Todos esses erros são realmente fáceis de cometer em C ou montagem. Pelo menos uma linguagem como Java possui uma String que é imune a estouros e um mecanismo de tratamento de exceções que geralmente evita que erros um por um permitam que códigos mal-intencionados acessem a memória do sistema. Sem mencionar o manuseio de conjuntos de caracteres internacionais (use UTF-8 quando possível).
Se você precisar usar o C por motivos de memória ou firmware, é isso que você deve fazer. Seja cuidadoso!
Suporte do navegador
O primeiro passo para criar um aplicativo Web é descobrir quais navegadores serão usados pelos seus clientes? W3Schools e Wikipedia são boas fontes de estatísticas gerais, mas o YMMV.
Onde trabalho agora, atualmente validamos que nosso aplicativo apenas cria HTML de transição XHTML 1.0 válido. Também usamos o Doctype e a formatação específicos necessários para evitar o Modo Quirks no IE, o que facilita a gravação em HTML entre navegadores (consulte as dicas no meu blog ). Testamos as 3 versões mais recentes do IE, além do Firefox e Chrome no Windows e Linux (o Safari usa o mesmo mecanismo de renderização do Chrome). Com essa validação e teste, nosso aplicativo funciona praticamente em qualquer lugar (Windows, Mac, Linux, iPhone, Android, etc.), exceto o BlackBerry.
O BlackBerry nunca teve um navegador real com JavaScript, por isso não o apoiamos. Os usuários do BlackBerry estão acostumados a não ter um navegador da Web real, para não reclamarem. Talvez isso esteja mudando? Gostaria de perguntar a alguns clientes quais navegadores eles estão usando e não se esqueça de testar com esses navegadores.
Sumário
Todos os sites são criados em HTML e HTTP. Tenha uma boa referência para essas tecnologias em mãos enquanto estiver fazendo seu aplicativo. No decorrer da criação de um aplicativo, mesmo com um kit de ferramentas, você encontrará problemas que exigem um entendimento básico dessas tecnologias para resolvê-las.
Você provavelmente também precisa se sentir confortável com CSS e compactação de imagem para criar algo que pareça decente e responda rapidamente. JavaScript, servidores da web e navegadores são áreas adicionais de conhecimento que você precisará.
Se você criar seu HTML no lado do servidor, sua base de códigos provavelmente será menor e talvez você não precise aprender JavaScript. O modelo do lado do servidor significa que seus programadores escreverão um código (C?) Que gera HTML que eles podem ver diretamente antes de serem enviados ao cliente. O modelo AJAX significa que seus programadores estarão escrevendo JavaScript que gera HTML. Não conheço muitas ferramentas para validar ou mesmo exibir o código HTML gerado pelo JavaScript em um navegador, dificultando a programação correta.
Onde trabalho agora, usamos uma abordagem híbrida que ocasionalmente envolve código Java que gera JavaScript e HTML. Se vocês são novos no desenvolvimento web, esse não é o lugar para começar. Acho que devo dizer que, a menos que você tenha razões convincentes para usar um modelo AJAX, eu começaria com o modelo mais antigo de geração HTML do lado do servidor e veria até onde ele chega.