Dans notre entreprise, nous devons construire une interface Web sur une plateforme Linux embarquée. Je vois en quelque sorte 2 options: vous utilisez une technologie où le HTML et le JavaScript sont générés côté serveur (pensez JSP, Grails, mais c'est quelque chose qui utilise C ++ et génère HTML / JavaScript) ou vous créez un client HTML5 application qui communique avec un backend générateur JSON ou XML.

J'ai le sentiment que les applications Web ont actuellement tendance à aller avec ce dernier, mais quels sont les avantages de le faire (les développeurs du projet choisissent le premier, principalement en raison du fait qu'ils connaissent bien mieux le C ++ que le HTML et le Javascript)

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.

Ce dernier a l'avantage de faire de votre «back-end» un «service de données» générique (quoi que cela puisse signifier dans votre contexte).

Votre client HTML n'est alors qu'un des nombreux consommateurs possibles de ces données. Pensez à l'application iOS, à l'application Andriod, à l'application Windows 8, aux API, etc. - comme les autres consommateurs.

Un moyen de plus en plus courant d'une application Web est un mélange des deux, tendant d'un côté ou de l'autre.

La première approche est plus traditionnelle, existe depuis des années et est bien documentée (bien que le c ++ ne soit généralement pas un langage populaire pour cela).

La deuxième option est plus moderne et est présente dans les blogs et forums de développement de nos jours. L'une des raisons à cela est le besoin croissant de servir la même application à d'autres interfaces, mobiles et API de services. La seconde approche tend vers un client plus riche et plus réactif.

Dans l'ensemble, cela dépend d'autres contraintes, comme la familiarité de l'équipe et l'analyse de rentabilisation.

Quelques questions qui peuvent vous aider à évaluer vos options:

1. L'équipe a-t-elle de l'expérience dans la langue et la plateforme?
2. L'équipe est-elle disposée à apprendre de nouvelles approches et technologies?
3. L'application profite-t-elle d'être plus facilement programmable pour d'autres appareils (iPhone, Android, Windows 8, etc.)
4. Une autre application interne ou externe intégrée aux services ou aux données sera-t-elle disponible pour l'application?

Pour de telles applications "intranet", j'utilise l'approche client lourd (JavaScript / HTML5-app + JSON) avec ExtJS4.

Pour les sites Web «Internet» normaux, j'utiliserais une approche plus «classique».

Les clients doivent de toute façon rendre le site, alors pourquoi ne pas les charger de tout le processus et leur donner simplement les données à remplir. De plus, comme il y a toujours plus de clients que de serveurs, l'ensemble du système évolue beaucoup mieux si une plus grande partie du travail est effectuée par les clients.

Le code client est livré avec HTTP, vous pouvez toujours envoyer facilement de nouvelles versions aux utilisateurs sans mécanisme de mise à jour obscur. (Il suffit de remplacer le HMTL / JS / CSS)

La seule raison pour laquelle je préférerais une approche classique sur des sites Web normaux, ce sont les moteurs de recherche.