Avantages et inconvénients de la création d'une application Web à page unique
J'approche de la fin d'une phase de prototypage/preuve de concept pour un projet parallèle sur lequel je travaille et j'essaie de prendre des décisions de conception d'applications à plus grande échelle. L'application est un système de gestion de projet davantage adapté au processus de développement agile. L'une des décisions que je dois prendre est de choisir ou non une application multipage traditionnelle ou une application monopage.
Actuellement, mon prototype est une configuration multi-pages traditionnelle, mais j'ai étudié backbone.js pour nettoyer et appliquer une structure à mon code Javascript (jQuery). Il semble que si backbone.js peut être utilisé dans des applications multipages, il brille davantage avec les applications monopages. J'essaie de dresser une liste des avantages et des inconvénients de l'utilisation d'une approche de conception d'application sur 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 veux de toute façon avoir une API pour mon application. À l'heure actuelle, 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 REST API puisque l'application elle-même l'utilisera. Cela signifie également que, au fur et à mesure que l'application se développe, l'API elle-même se développera 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 fera un traitement légèrement moins.
Inconvénients
- 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.
- Logique d'entreprise en Javascript - Je ne peux pas donner d'exemples concrets sur la raison pour laquelle cela serait mauvais, mais cela ne me semble pas juste d'avoir une logique d'entreprise en Javascript que tout le monde puisse lire.
- Fuites de mémoire Javascript - puisque la page ne se recharge jamais, des fuites de mémoire Javascript peuvent se produire, et je ne saurais même pas par où commencer pour les déboguer.
Il y a aussi d'autres choses qui sont des sortes d'épées à double tranchant. Par exemple, avec des applications d'une seule page, les données traitées pour chaque demande peuvent être beaucoup moins puisque l'application demandera le minimum de données dont elle a besoin pour la demande particulière, mais cela signifie également qu'il pourrait y avoir beaucoup plus de petites demandes à le serveur. Je ne sais pas si c'est une bonne ou une mauvaise chose.
Quels sont les avantages et les inconvénients des applications Web à page unique que je dois garder à l'esprit lorsque je décide de la direction à suivre pour mon projet?
Le plus gros inconvénient est que le client doit avoir JavaScript activé et être suffisamment puissant pour en exécuter une bonne quantité. Il est également plus difficile de répondre aux problèmes d'accessibilité ou à tout autre élément qui repose sur l'analyse du HTML statique (bien que quelque chose connaissant votre API spécifique puisse probablement faire mieux que le scraping HTML). Enfin, il est plus facile d'avoir des fuites de mémoire importantes.
En ce qui concerne la duplication de code ou la mise en logique métier sur le client - je ne sais pas combien de cela vous devez faire. Si le modèle sur le client est un View-Model (un modèle qui correspond au monde tel que l'interface utilisateur le voit, pas un modèle commercial), la logique qui correspond au ViewModel jusqu'au modèle commercial peut résider sur le client, le 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 par rapport au fait que le client traduise les entrées de l'interface utilisateur en appels d'API.
Vous pouvez également consulter knockout.js. Je ne peux pas dire si c'est mieux que l'épine dorsale mais cela peut mieux convenir à votre projet.
Inconvénients que je constate souvent avec les applications Web à page unique:
- Impossible de créer un lien vers une partie spécifique du site, il n'y a souvent qu'un seul point d'entrée.
- Boutons arrière et avant dysfonctionnels.
- L'utilisation des onglets est limitée ou inexistante.
(particulièrement mobile :)
- Prenez 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.
Tous ces éléments peuvent être contournés, mais d'après ce que j'ai vu, la plupart des constructeurs de sites ne le font pas.
Il existe un client très important qui n'exécute jamais Javascript: le robot Google (à partir de 2012). (Bing ne lance pas JS non plus, je suppose.)
Vous devrez fournir une version non AJAX raisonnable de chaque page qui doit être indexée, ou des liens vers une page qui doit être indexée.
Si votre site est petit, vous pouvez fournir des versions très basiques des quelques pages uniquement pour l'indexation des bots.
Si la plupart du contenu du site est uniquement destiné aux utilisateurs enregistrés, ou n'a pas besoin d'être indexé pour d'autres raisons, vous pouvez créer l'intégralité de l'espace non indexé en tant qu'application d'une page, avec votre propre recherche, blackjack, etc.
Si aucun de ceux-ci, vous feriez probablement mieux de développer un site de plusieurs pages dès le début, 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 côté serveur (PHP dans le cas) et 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 proxys WCF JavaScript. Voir ici
Je ne sais pas quelles options pourraient être disponibles pour ne pas avoir à créer vous-même vos objets distants en JavaScript dans une application PHP, mais c'est une option pour ceux qui écrivent des applications d'une seule page dans .NET.
Le choix n'a pas à ê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 il s'agit d'une seule page. De plus, il reconnaîtra les robots Google et les navigateurs qui ne disposent pas de javascript (essayez-le), et basculera vers le modèle multipage traditionnel lorsqu'il les détectera.
En bref:
- pas besoin d'écrire une API (mais vous pouvez toujours le faire si vous le souhaitez)
- application réactive: chaque clic utilisateur nécessite au plus un aller-retour de 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