AJAX
Je pense que votre question se résume à: "Mon application Web doit-elle générer du HTML côté client ou côté serveur?" La génération côté client communique avec le serveur à l'aide d'AJAX, bien que le X (XML) ait généralement été remplacé par JSON, mais la plupart des gens l'appellent encore AJAX car il sonne mieux. Côté serveur, le serveur fait juste du HTML sur le serveur.
J'ai beaucoup d'expérience avec XML et presque aucune avec JSON. Tout ce que je sais sur XML me fait suggérer d'utiliser JSON si possible.
AJAX Pros:
- Envoyez moins de données via HTTP (S) afin qu'elles puissent s'exécuter plus rapidement.
- Le serveur est essentiellement un service Web afin que d'autres personnes (ou vous) puissent écrire leurs propres clients. Cela peut être utile lors de la création d'une version mobile de votre site. De plus, de nombreuses inventions deviennent populaires pour des raisons que leur créateur n'a jamais voulues. Les services sont plus conviviaux pour les personnes qui trouvent de nouvelles utilisations pour votre code.
- Ressemble à une application plus récente
AJAX Contre:
- Débogage de JavaScript
- Complexité?
- Les choses que vous pouvez faire avec JavaScript sont souvent totalement impossibles à utiliser pour les personnes aveugles ou handicapées.
- Peut nécessiter plus de code au total (plus de stockage global sur votre appareil intégré)
Serveur client
Toutes les applications Web utilisent une architecture client-serveur. Le protocole HTTP oblige les applications Web à se comporter de cette façon. AJAX utilise une solution de contournement pour cette limitation de conception, mais le modèle sous-jacent de base de HTTP est toujours client-serveur. Je ne m'attarderais pas sur la meilleure façon d'appliquer MVC aux applications Web. Si vous devez faire du MVC pour des raisons politiques, regardez comment Ruby / Rails le fait. En fait, Rails est une excellente architecture à copier (ou à utiliser).
Service vs App.
Un bon service est presque toujours meilleur qu'une application. Mais rendre un bon service est difficile! Vous devrez peut-être faire la demande avant de pouvoir écrire une spécification suffisamment bien conçue pour un service. Ne rendez pas votre travail plus difficile qu'il ne devrait l'être. Pour la version 1, concentrez-vous sur la création d'une excellente application. Jusqu'à ce que votre application soit relativement stable et que vous soyez sûr qu'elle répond aux exigences de votre utilisateur, avoir un service ne vous sera probablement pas utile de toute façon. Concevoir le mauvais service trop tôt est une perte de temps qui continue de se perdre pendant que vous essayez de réparer votre interface de service et de faire face à la refactorisation massive du code serveur et client qui va suivre.
C / Web
Sensationnel. J'ai travaillé en C et Assembly pendant 3 ans avant de passer au développement web. Je ne peux pas penser à une langue pire pour écrire une application Web - en particulier du point de vue de la sécurité. La validation des entrées et l'échappement des sorties sont si critiques ... SANS publie chaque année une liste des erreurs les plus courantes. Débordements de tampon, injections, problèmes intersites (encodage de sortie incorrect) ... Toutes ces erreurs sont vraiment faciles à faire en C ou en assemblage. Au moins un langage comme Java a une chaîne qui est immunisée contre les débordements et un mécanisme de gestion des exceptions qui empêche généralement les erreurs ponctuelles de permettre au code malveillant d'accéder à la mémoire système. Sans parler de la gestion des jeux de caractères internationaux (utilisez UTF-8 si possible).
Si vous devez utiliser C pour des raisons de mémoire ou de micrologiciel, c'est ce que vous devez faire. Fais attention!
Prise en charge du navigateur
La première étape pour créer une application Web est de découvrir quels navigateurs seront utilisés par vos clients? W3Schools et Wikipedia sont tous deux de bonnes sources de statistiques générales, mais YMMV.
Là où je travaille maintenant, nous validons actuellement que notre application crée uniquement du HTML de transition XHTML 1.0 valide. Nous utilisons également le Doctype et le formatage spécifiques nécessaires pour éviter le mode Quirks dans IE, ce qui facilite l'écriture HTML entre navigateurs (voir les conseils sur mon blog ). Nous testons sur les 3 dernières versions d'IE, plus Firefox et Chrome sur Windows et Linux (Safari utilise le même moteur de rendu que Chrome). Avec cette validation et ces tests, notre application fonctionne à peu près partout (Windows, Mac, Linux, iPhone, Android, etc.) à l'exception du BlackBerry.
Le BlackBerry n'a jamais eu de véritable navigateur avec JavaScript, nous ne le prenons donc pas en charge. Les utilisateurs de BlackBerry sont habitués à ne pas avoir de véritable navigateur Web, ils ne se plaignent donc pas. Peut-être que ça change? J'essaierais de demander à quelques clients quels navigateurs ils utilisent et je m'assurerais de tester avec ces navigateurs.
Sommaire
Tous les sites Web sont construits sur HTML et HTTP. Ayez une bonne référence pour ces technologies sous la main pendant que vous faites votre demande. Au cours de la création d'une application, même avec une boîte à outils, vous rencontrerez des problèmes qui nécessitent une compréhension de base de ces technologies pour les résoudre.
Vous devez probablement également être à l'aise avec CSS et la compression d'image afin de créer quelque chose qui semble décent et qui réagisse rapidement. JavaScript, les serveurs Web et les navigateurs sont des domaines de connaissances supplémentaires dont vous aurez finalement besoin.
Si vous construisez votre code HTML côté serveur, votre base de code sera probablement plus petite et vous n'aurez peut-être pas besoin d'apprendre JavaScript. Le modèle côté serveur signifie que vos programmeurs écriront du code (C?) Qui génère du code HTML qu'ils peuvent consulter directement avant de l'envoyer au client. Le modèle AJAX signifie que vos programmeurs écriront du JavaScript qui génère du HTML. Je ne connais pas beaucoup d'outils pour valider ou même afficher le code HTML généré par JavaScript dans un navigateur, ce qui rend plus difficile la programmation correcte.
Là où je travaille maintenant, nous utilisons une approche hybride qui implique parfois du code Java qui génère du JavaScript qui génère du HTML. Si vous êtes nouveau dans le développement Web, ce n'est pas le bon point de départ. Je suppose que je devrais dire qu'à moins d'avoir des raisons impérieuses d'utiliser un modèle AJAX, je commencerais par l'ancien modèle de génération HTML côté serveur et voir jusqu'où cela vous mène.