Avantages et inconvénients de la création d'une application Web d'une seule page [fermé]

J'arrive à la fin d'une phase de prototypage / de validation de concept pour un projet parallèle sur lequel je travaille et j'essaie de prendre des décisions concernant la conception d'applications à plus grande échelle. L'application est un système de gestion de projet plus adapté au processus de développement agile. L'une des décisions que je dois prendre consiste à choisir entre une application traditionnelle à plusieurs pages ou une application à une seule page.

Actuellement, mon prototype est une configuration traditionnelle de plusieurs pages. Cependant, je me suis penché sur backbone.js pour nettoyer et appliquer une structure à mon code Javascript (jQuery). Il semble que si backbone.js peut être utilisé dans des applications de plusieurs pages, il brille davantage avec les applications d'une seule page. J'essaie de proposer une liste d'avantages et d'inconvénients à l'utilisation d'une approche de conception d'application d'une seule page. Jusqu'à présent j'ai:

Avantages

• Toutes les données doivent être disponibles via une sorte d’API - c’est un gros avantage pour mon cas d’utilisation, car je souhaite quand même avoir une API pour mon application. Actuellement, environ 60 à 70% de mes appels pour obtenir / mettre à jour des données se font via une API REST. Faire une application d'une seule page me permettra de mieux tester mon API REST puisque l'application l'utilisera elle-même. Cela signifie également que, à mesure que l'application grandit, l'API grandira elle-même, car c'est ce que l'application utilise. pas besoin de maintenir l'API en tant que complément à l'application.

• Application plus réactive - puisque toutes les données chargées après la page initiale sont réduites au minimum et transmises dans un format compact (comme JSON), les demandes de données devraient généralement être plus rapides et le serveur effectuera un traitement légèrement moins.

Désavantages

• Duplication de code - par exemple, code de modèle. Je vais devoir créer des modèles à la fois côté serveur (PHP dans ce cas) et côté client en Javascript.
• La logique métier en Javascript - Je ne peux pas donner d'exemples concrets sur la raison pour laquelle cela serait mauvais, mais cela ne me semble pas correct de disposer d'une logique métier en Javascript que tout le monde peut lire.
• Fuites de mémoire Javascript - la page ne se rechargeant jamais, des fuites de mémoire Javascript peuvent se produire et je ne sais même pas par où commencer pour les déboguer.

Il y a aussi d'autres choses qui sont une sorte d'épée à double tranchant. Par exemple, avec des applications à une seule page, les données traitées pour chaque demande peuvent être beaucoup moins importantes, car l'application demandera le minimum de données dont elle a besoin pour la demande particulière. Toutefois, cela signifie également qu'il pourrait y avoir beaucoup plus de petites demandes à le serveur. Je ne suis pas sûr que ce soit une bonne ou une mauvaise chose.

Quels sont certains des avantages et des inconvénients des applications Web à page unique que je devrais garder à l’esprit lors du choix de la voie à suivre pour mon projet?

Le plus gros inconvénient est que JavaScript doit être activé sur le client et qu'il doit être suffisamment puissant pour en exécuter une bonne partie. Il est également plus difficile de répondre aux préoccupations en matière d'accessibilité ou à tout ce qui repose sur l'analyse de code HTML statique (bien que connaître votre API puisse probablement faire mieux que le nettoyage de code HTML). Enfin, il est plus facile d’avoir des fuites de mémoire importantes.

En ce qui concerne la duplication de code ou l'application de la logique métier sur le client, je ne sais pas trop combien il vous reste à faire. Si le modèle sur le client est un modèle View (un modèle qui correspond au monde tel que l’interface utilisateur le voit, et non un modèle commercial), la logique correspondant au modèle ViewModel jusqu'au modèle commercial peut résider sur le client. serveur, ou un peu des deux. Cela dépend de ce que vous pensez que votre API contienne une façade spécifique au client et de ce que le client traduise les entrées de l'interface utilisateur en appels d'API.

Vous voudrez peut-être aussi regarder knockout.js. Je ne peux pas dire si c'est mieux que l'épine dorsale, mais cela conviendra mieux à votre projet.

Les inconvénients que je vois souvent avec les applications Web à page unique:

• Incapable de créer un lien vers une partie spécifique du site, il n’ya souvent qu’un seul point d’entrée.
• Boutons arrière et avant dysfonctionnels.
• L'utilisation des onglets est limitée ou inexistante.

(surtout mobile :)

• Prendre très longtemps à charger.
• Ne fonctionne pas du tout.
• Impossible de recharger une page, une perte soudaine de réseau vous ramène au début du site.

Tout cela peut être corrigé, mais d'après ce que j'ai vu, la plupart des constructeurs de sites ne le savent pas.

Il y a un client très important qui n'exécute jamais Javascript: Google Crawler (à partir de 2012) . (Bing's ne fonctionne pas non plus avec JS, je suppose.)

Vous devrez fournir une version raisonnable non-AJAX de chaque page à indexer ou des liens vers une page à indexer.

Si votre site est petit, vous pouvez fournir des versions très basiques des quelques pages uniquement pour l’indexation des robots.

Si la majeure partie du contenu du site ne concerne que les utilisateurs enregistrés, ou n'a pas besoin d'être indexée pour d'autres raisons, vous pouvez créer tout l'espace non indexé en tant qu'application d'une page, avec votre propre recherche, blackjack, etc.

Si vous ne faites ni l'un ni l'autre, il est probablement préférable de développer dès le départ un site de plusieurs pages et de ne fournir que des mises à jour AJAX où cela ne change pas le "but général" de la page.

-Duplication de code - Par exemple, code de modèle. Je vais devoir créer des modèles à la fois du côté serveur (PHP dans le cas) et du côté serveur en javascript.

Vous êtes dans le monde PHP, mais il existe des stratégies de génération de code dans le monde .NET pour créer automatiquement des proxies JavaScript WCF. Voir ici

Je ne sais pas quelles options pourraient être disponibles pour ne pas avoir à créer vos objets distants vous-même en JavaScript dans une application PHP, mais c'est une option pour ceux qui écrivent des applications à une seule page dans .NET.

Le choix ne doit pas nécessairement être l'un ou l'autre. JWt est par exemple une boîte à outils Web qui implémente l’illusion parfaite d’une page Web de plusieurs pages, mais c’est une seule page. De plus, il reconnaîtra les robots Google et les navigateurs dépourvus de javascript (essayez-le), et basculera vers le modèle traditionnel à plusieurs pages lorsqu'il les détectera.

En bref:

• pas besoin d'écrire une API (mais vous le pouvez quand même)
• application responsive: chaque clic utilisateur nécessite au maximum un aller-retour serveur (plus la récupération d'images)
• pas de duplication de code
• pas de logique métier côté client
• complexité minimale côté client
• les robots de recherche peuvent l'indexer