AngularJS est-il vraiment si parfait ? Analyse détaillée de plusieurs problèmes avec Angularjs

Laissez de côté les avantages de AngularJS, au moins la plupart des travailleurs front-end ont toujours un respect fanatique pour AngularJS. Parce que cela facilite le développement. La question est donc : pourquoi de nombreux sites Web bien connus n’utilisent-ils pas Angular ? Regardons ensemble cet article

Commençons par quelques points :

1 La pire convivialité SEO

C'est sans aucun doute très fatal, c'est ça. une raison importante pour laquelle de nombreuses jeunes entreprises en démarrage n'osent pas tenter leur chance. Les robots des moteurs de recherche et les captures d'écran d'aperçu des réseaux sociaux ne peuvent pas reconnaître les pages rendues avec JavaScript, et les solutions existantes sont complexes et très lentes.

En fait, le chargement d'une page se compose généralement de cinq parties (prenons Java comme exemple) :

1. Le navigateur envoie une requête Http au serveur

2. Le serveur traite cette demande pour obtenir les données de résultat, obtient le modèle Jsp, construit les données en texte HTML reconnu par le navigateur via le modèle et l'envoie au navigateur

3. Le navigateur analyse le texte HTML et présente le contenu de la page

On peut voir que dans la dernière étape, lorsque le navigateur obtient le texte html, c'est à ce moment-là que le processus se termine, nous avons besoin Les données seront affichées. Le processus d'utilisation d'Angular est le suivant :

1. Le navigateur envoie une requête HTTP au serveur front-end

2. Le serveur front-end envoie un modèle HTML au navigateur

3. Le navigateur analyse le HTML et exécute le script js, et envoie une requête Http au serveur d'entreprise

4. Le serveur traite cette requête et obtient les données de résultat. Encapsulez-les au format Json et envoyez-les au navigateur

5. Le navigateur analyse le Json et présente les données dans la page

   .

Ces deux processus, l'un consiste à placer l'opération de création de page dans le serveur et l'autre à la placer dans le navigateur. C'est la différence la plus évidente. Sans parler du nombre supplémentaire d'interactions, du point de vue d'un moteur de recherche, il ne peut voir que le contenu statique obtenu par le navigateur et n'exécutera pas votre code js.

Le premier moteur de recherche voit un article, tandis que le second voit des accolades les unes après les autres ! C'est aussi la raison pour laquelle les pages rendues par Angular sont incluses dans la « liste noire » de Baidu. Alors comment le résoudre ?

Citation :

Il existe deux façons de permettre aux robots d'exploration d'accéder à votre site Web. Vous pouvez exécuter une instance de navigateur sur votre serveur, puis générer des pages HTML basées sur le DOM après l'exécution de JavaScript. Vous pouvez également créer un autre ensemble de pages HTML statiques pour les robots de recherche.
L'ancienne solution vous oblige à installer WebKit (et éventuellement Xvfb), puis à générer la page après son chargement (vous pouvez également utiliser la mise en cache, mais cela ajoute plus de complexité.) Cela augmentera le temps de chargement de votre page, ce qui affecte votre classement dans les moteurs de recherche. .
Cette dernière solution (créer un autre site côté serveur) peut satisfaire des sites simples, mais si vos pages sont très diverses, ce sera un cauchemar. Et si votre site Web de sauvegarde est totalement incompatible avec votre site Web principal, Google vous punira sévèrement et votre trafic chutera.

2. La pire expérience utilisateur

Après avoir utilisé AngularJS, la méthode de rendu des pages est divisée en plusieurs processus, donc si je visite une page, et la page Quand il y en a beaucoup du contenu, je ressentirai évidemment le processus de rendu du navigateur. J'ai trop de contenu à charger. Ce processus est très mauvais, surtout lorsque le processus de chargement est placé sur le client, le retard sera très important.

Dans les applications JavaScript riches, les transitions de page se produisent généralement immédiatement, puis différents éléments sont chargés depuis le serveur. Dans les applications côté serveur, la page commence à restituer les données sans attendre que le client télécharge toutes les données.

On dirait que l'application client est meilleure, mais en fait c'est une illusion.
Imaginez que lorsque l'utilisateur clique sur un lien, une animation de chargement apparaît immédiatement dans l'application JS du client, mais les données mettent 5 secondes à se charger. L'application semble rapide à première vue.
Ne discutons pas du nombre de programmeurs souhaitant ajouter des fonctions à cette page. Il est difficile pour vous d'exiger que les gens présentent le contenu rapidement de manière asynchrone. En fait, les gens ne se soucieront pas si les éléments situés sous la page sont chargés plus tard.

Dans les applications côté serveur, si un appel API est lent, la page entière se chargera lentement. Vous ne pouvez pas ignorer la lenteur côté serveur car elle affecte tout le monde. Mais la lenteur du client passe facilement inaperçue.

Vous pouvez facilement résoudre la lenteur du serveur, car le serveur est contrôlable et fonctionne sur la machine que vous configurez. Vous pouvez clairement savoir ce qui se passe sur cette machine. De plus, la plupart des serveurs se trouvent dans un réseau de cluster interne, ce qui rend le transfert d'informations entre eux très rapide. Même si une action nécessite plusieurs transferts d'informations, elle peut être réalisée en un instant. Mais confier ces transferts au client le ralentira pour de nombreux facteurs.
Nous ne pouvons pas contrôler strictement le navigateur utilisé par les utilisateurs, ni la configuration des machines des utilisateurs, mais nous pouvons tout contrôler sur nos propres serveurs.

3. Le plus important est trop insipide

Insipide ? Certaines personnes diront qu'AngularJS présente divers avantages, tels que « facile à maintenir », « codage pratique », etc. Mais cela repose sur un sacrifice des performances et de l’expérience utilisateur. Et ce que l'on appelle « l'injection de dépendances » et d'autres idées back-end sont introduites de force dans le front-end. Cela semble noble, mais qu'est-ce qui ne va pas ? Le back-end est divisé en architectures, services et divers frameworks sont utilisés pour un développement plus simple. Le front-end Web lui-même est simplement du texte HTML qui apparaît dans le navigateur. Il est statique et n'implique aucune activité, je ne pense pas. cela lui serait d'une réelle aide.

D'après ces commodités, on ne peut pas dire que cela soit inutile, mais Dans tous les scénarios, il existe presque une solution qui peut parfaitement remplacer AngularJS et le faire mieux qu'elle. ce. . . C'est embarrassant ! Par exemple freemaker.

Freemaker est familier à tout le monde. Il peut appeler directement la fonction freemakerApi fournie par Java au lieu d'exécuter une requête http via ajax pour obtenir des données de manière asynchrone. De même, ses performances battent également AngularJSC'est peut-être un peu intimidant par rapport à ses performances, mais en tant que moteur de template, freemaker est en effet qualifié pour écraser AngularJS en termes de performances.

En termes de facilité d'utilisation, en plus d'appeler directement les fonctions Java, freemaker peut également obtenir des données via http, mais il construira les données obtenues en texte HTML, puis les transmettra au navigateur pour analyse. le plus important est qu'il prend également en charge l'injection de dépendances et d'autres fonctionnalités associées, et qu'il est parfaitement intégré au programme back-end. Combiné avec les points ci-dessus, il est excellent en termes d'évolutivité, de maintenabilité, de performances globales, d'expérience utilisateur, etc. . AngularJS écrasé. La seule chose qui n'est pas aussi bonne qu'AngularJS est la phase de développement. Comparé à Angular, le développement freemaker est plus compliqué, ou en d'autres termes, Angular est beaucoup plus simple dans le processus de développement. Si c'est simplement parce que le développement devient agréable et qu'un grand nombre de facteurs de performance sont ignorés, c'est très effrayant pour certaines personnes. optimisent constamment à la recherche de mécanismes de performance, tandis que certaines personnes optimisent pour un développement plus simple. Je ne peux pas dire qui a raison ou tort, mais je préfère le premier.

Laissez de côté freemaker, il existe également un grand nombre de solutions remplaçables dans nodejs et un grand nombre de frameworks mvc, je n'entrerai donc pas dans les détails ici.

Je pense que le rôle de js dans le navigateur devrait être davantage dans l'interaction que dans la présentation du contenu. Ce n'est pas la bonne solution.

4. Problèmes liés au scénario d'application

AngularJS semble être un bon choix dans le scénario où le front et le back end sont séparés, mais comme mentionné ci-dessus, AngularJS prend trop en compte lorsque les extrémités avant et arrière sont trop étroites, après notre séparation, le développement est devenu plus pratique, mais les performances et l'expérience d'origine ont été perdues, ce qui est sans aucun doute un échec. En combinant ces raisons, il peut y avoir très peu de scénarios dans lesquels AngularJS peut être. utilisé, mais il semble être en arrière-plan (il peut être utilisé dans deux scénarios : panneau de contrôle de gestion backend) et WEBApp.

Ensuite, la question est que le développement de la page de la console de gestion n'a pas besoin de trop tenir compte des performances, ni d'être optimisée pour le référencement, mais le point médian dans ce scénario est l'interaction, pas l'affichage supérieur du contenu. . En tant que moteur de template front-end, AngularJS a perdu son positionnement. Son rôle était minime, ce qui était embarrassant.

Lors du développement d'une WebApp, elle n'a peut-être pas besoin de prendre en compte le référencement. En termes de performances, le framework App peut optimiser les performances car je peux contrôler strictement la version client utilisée par les utilisateurs. Je peux choisir le framework d'application, mais comme je peux choisir le framework de développement d'application par moi-même, presque tous les frameworks d'application ont une solution qui surpasse AngularJS, à la fois en termes de performances et de facilité d'utilisation. Cela semble donc pire que de développer la page de la console d'administration.

Sur la base de ces points, je pense que la position d'AngularJS est très embarrassante.

Le seul scénario sans conflit pourrait être celui du développement d'applications internes à l'entreprise.

C'est peut-être pour cela qu'AngularJS semble génial, mais peu d'entreprises le choisissent. La recherche de la performance est ce que tout programmeur devrait avoir, en particulier ceux engagés dans le développement back-end. Ils réfléchiront davantage et ne pourront pas renoncer à l'expérience au profit d'un développement apparemment pratique. Si vous abandonnez vraiment, quelle distinction ferez-vous entre le collège et le lycée ? D'où vient l'architecte ? Commencez simplement un tas de consultations sur le code.

De même, cela a également causé de l'embarras lors des entretiens pour certains ingénieurs front-end :

Q : Savez-vous comment utiliser AngularJs ?
Réponse : Oui ! Bien. . Mais pas beaucoup utilisé. . Mais je le fais vraiment. . Euh

Ne parlons pas des avantages d'AngularJS. Au moins, la plupart des travailleurs front-end ont toujours un respect fanatique pour AngularJS. Parce que cela facilite le développement. La question est donc : pourquoi de nombreux sites Web bien connus n’utilisent-ils pas Angular ?
Permettez-moi de commencer par quelques points :

1. La pire convivialité du référencement

C'est sans aucun doute très fatal, ce qui a fait échouer facilement de nombreuses jeunes startups. essayer. Les robots des moteurs de recherche et les captures d'écran d'aperçu des réseaux sociaux ne peuvent pas reconnaître les pages rendues avec JavaScript, et les solutions existantes sont complexes et très lentes.

En fait, le chargement d'une page se compose généralement de cinq parties (prenons Java comme exemple) :

1. Le navigateur envoie une requête Http au serveur

2. Le serveur traite cette demande pour obtenir les données de résultat, obtient le modèle Jsp, construit les données en texte HTML reconnu par le navigateur via le modèle et l'envoie au navigateur

3. Le navigateur analyse le texte HTML et présente le contenu de la page

On peut voir que dans la dernière étape, lorsque le navigateur obtient le texte html, c'est à ce moment-là que le processus se termine, nous avons besoin Les données seront affichées. Le processus d'utilisation d'Angular est le suivant :

1. Le navigateur envoie une requête HTTP au serveur front-end

2. Le serveur front-end envoie un modèle HTML au navigateur

3. Le navigateur analyse le HTML et exécute le script js, et envoie une requête Http au serveur d'entreprise

4. Le serveur traite cette requête et obtient les données de résultat. Encapsulez-les au format Json et envoyez-les au navigateur

5. Le navigateur analyse le Json et présente les données dans la page

   .

Ces deux processus, l'un consiste à placer l'opération de création de page dans le serveur et l'autre à la placer dans le navigateur. C'est la différence la plus évidente. Sans parler du nombre supplémentaire d'interactions, du point de vue d'un moteur de recherche, il ne peut voir que le contenu statique obtenu par le navigateur et n'exécutera pas votre code js.

Le premier moteur de recherche voit un article, tandis que le second voit des accolades les unes après les autres ! C'est aussi la raison pour laquelle les pages rendues par Angular sont incluses dans la « liste noire » de Baidu. Alors comment le résoudre ?

Citation :

Il existe deux façons de permettre aux robots d'exploration d'accéder à votre site Web. Vous pouvez exécuter une instance de navigateur sur votre serveur, puis générer des pages HTML basées sur le DOM après l'exécution de JavaScript. Vous pouvez également créer un autre ensemble de pages HTML statiques pour les robots de recherche.
L'ancienne solution vous oblige à installer WebKit (et éventuellement Xvfb), puis à générer la page après son chargement (vous pouvez également utiliser la mise en cache, mais cela ajoute plus de complexité.) Cela augmentera le temps de chargement de votre page, ce qui affecte votre classement dans les moteurs de recherche. .
Cette dernière solution (créer un autre site côté serveur) peut satisfaire des sites simples, mais si vos pages sont très diverses, ce sera un cauchemar. Et si votre site Web de sauvegarde est totalement incompatible avec votre site Web principal, Google vous punira sévèrement et votre trafic chutera.

2. La pire expérience utilisateur

Après avoir utilisé AngularJS, la méthode de rendu des pages est divisée en plusieurs processus, donc si je visite une page, et la page Quand il y en a beaucoup du contenu, je ressentirai évidemment le processus de rendu du navigateur. J'ai trop de contenu à charger. Ce processus est très mauvais, surtout lorsque le processus de chargement est placé sur le client, le retard sera très important.

Dans les applications JavaScript riches, les transitions de page se produisent généralement immédiatement, puis différents éléments sont chargés depuis le serveur. Dans les applications côté serveur, la page commence à restituer les données sans attendre que le client télécharge toutes les données.

On dirait que l'application client est meilleure, mais en fait c'est une illusion.
Imaginez que lorsque l'utilisateur clique sur un lien, une animation de chargement apparaît immédiatement dans l'application JS du client, mais les données mettent 5 secondes à se charger. L'application semble rapide à première vue.
Ne discutons pas du nombre de programmeurs souhaitant ajouter des fonctions à cette page. Il est difficile pour vous d'exiger que les gens présentent le contenu rapidement de manière asynchrone. En fait, les gens ne se soucieront pas si les éléments situés sous la page sont chargés plus tard.

Dans les applications côté serveur, si un appel API est lent, la page entière se chargera lentement. Vous ne pouvez pas ignorer la lenteur côté serveur car elle affecte tout le monde. Mais la lenteur du client passe facilement inaperçue.

Vous pouvez facilement résoudre la lenteur du serveur, car le serveur est contrôlable et fonctionne sur la machine que vous configurez. Vous pouvez clairement savoir ce qui se passe sur cette machine. De plus, la plupart des serveurs se trouvent dans un réseau de cluster interne, ce qui rend le transfert d'informations entre eux très rapide. Même si une action nécessite plusieurs transferts d'informations, elle peut être réalisée en un instant. Mais confier ces transferts au client le ralentira pour de nombreux facteurs.
Nous ne pouvons pas contrôler strictement le navigateur utilisé par les utilisateurs, ni la configuration des machines des utilisateurs, mais nous pouvons tout contrôler sur nos propres serveurs. (Si vous voulez en savoir plus, rendez-vous sur le site PHP chinois Manuel de développement AngularJS pour apprendre)

3. Le plus important est trop insipide

insipide ? Certaines personnes diront qu'AngularJS présente divers avantages, tels que « facile à maintenir », « codage pratique », etc. Mais cela repose sur un sacrifice des performances et de l’expérience utilisateur. Et ce que l'on appelle « l'injection de dépendances » et d'autres idées back-end sont introduites de force dans le front-end. Cela semble noble, mais qu'est-ce qui ne va pas ? Le back-end est divisé en architectures, services et divers frameworks sont utilisés pour un développement plus simple. Le front-end Web lui-même est simplement du texte HTML qui apparaît dans le navigateur. Il est statique et n'implique aucune activité, je ne pense pas. cela lui serait d'une réelle aide.

D'après ces commodités, on ne peut pas dire que cela soit inutile, mais Dans tous les scénarios, il existe presque une solution qui peut parfaitement remplacer AngularJS et le faire mieux qu'elle. ce. . . C'est embarrassant ! Par exemple freemaker.

Freemaker est familier à tout le monde. Il peut appeler directement la fonction freemakerApi fournie par Java au lieu d'exécuter une requête http via ajax pour obtenir des données de manière asynchrone. De même, ses performances battent également AngularJSC'est peut-être un peu intimidant par rapport à ses performances, mais en tant que moteur de template, freemaker est en effet qualifié pour écraser AngularJS en termes de performances.

En termes de facilité d'utilisation, en plus d'appeler directement les fonctions Java, freemaker peut également obtenir des données via http, mais il construira les données obtenues en texte HTML, puis les transmettra au navigateur pour analyse. le plus important est qu'il prend également en charge l'injection de dépendances et d'autres fonctionnalités associées, et qu'il est parfaitement intégré au programme back-end. Combiné avec les points ci-dessus, il est excellent en termes d'évolutivité, de maintenabilité, de performances globales, d'expérience utilisateur, etc. . AngularJS écrasé. La seule chose qui n'est pas aussi bonne qu'AngularJS est la phase de développement. Comparé à Angular, le développement freemaker est plus compliqué, ou en d'autres termes, Angular est beaucoup plus simple dans le processus de développement. Si c'est simplement parce que le développement devient agréable et qu'un grand nombre de facteurs de performance sont ignorés, c'est très effrayant pour certaines personnes. optimisent constamment à la recherche de mécanismes de performance, tandis que certaines personnes optimisent pour un développement plus simple. Je ne peux pas dire qui a raison ou tort, mais je préfère le premier.

Laissez de côté freemaker, il existe également un grand nombre de solutions remplaçables dans nodejs et un grand nombre de frameworks mvc, je n'entrerai donc pas dans les détails ici.

Je pense que le rôle de js dans le navigateur devrait être davantage dans l'interaction que dans la présentation du contenu. Ce n'est pas la bonne solution.

4. Problèmes liés au scénario d'application

AngularJS semble être un bon choix dans le scénario où le front et le back end sont séparés, mais comme mentionné ci-dessus, AngularJS prend trop en compte lorsque les extrémités avant et arrière sont trop étroites, après notre séparation, le développement est devenu plus pratique, mais les performances et l'expérience d'origine ont été perdues, ce qui est sans aucun doute un échec. En combinant ces raisons, il peut y avoir très peu de scénarios dans lesquels AngularJS peut être. utilisé, mais il semble être en arrière-plan (il peut être utilisé dans deux scénarios : panneau de contrôle de gestion backend) et WEBApp.

Ensuite, la question est que le développement de la page de la console de gestion n'a pas besoin de trop tenir compte des performances, ni d'être optimisée pour le référencement, mais le point médian dans ce scénario est l'interaction, pas l'affichage supérieur du contenu. . En tant que moteur de template front-end, AngularJS a perdu son positionnement. Son rôle était minime, ce qui était embarrassant.

Lors du développement d'une WebApp, elle n'a peut-être pas besoin de prendre en compte le référencement. En termes de performances, le framework App peut optimiser les performances car je peux contrôler strictement la version client utilisée par les utilisateurs. Je peux choisir le framework d'application, mais comme je peux choisir le framework de développement d'application par moi-même, presque tous les frameworks d'application ont une solution qui surpasse AngularJS, à la fois en termes de performances et de facilité d'utilisation. Cela semble donc pire que de développer la page de la console d'administration.

Sur la base de ces points, je pense que la position d'AngularJS est très embarrassante.

Le seul scénario sans conflit pourrait être celui du développement d'applications internes à l'entreprise.

C'est peut-être pour cela qu'AngularJS semble génial, mais peu d'entreprises le choisissent. La recherche de la performance est ce que tout programmeur devrait avoir, en particulier ceux engagés dans le développement back-end. Ils réfléchiront davantage et ne pourront pas renoncer à l'expérience au profit d'un développement apparemment pratique. Si vous abandonnez vraiment, quelle distinction ferez-vous entre le collège et le lycée ? D'où vient l'architecte ? Commencez simplement un tas de consultations sur le code.

De même, cela a également causé de l'embarras lors des entretiens avec certains ingénieurs front-end :

Q : Savez-vous comment utiliser AngularJs ?

Réponse : Oui ! Bien. . Mais pas beaucoup utilisé. . Mais je le fais vraiment. . Euh

Cet article se termine ici (si vous voulez en voir plus, rendez-vous sur le site Web PHP chinois Manuel d'utilisation d'AngularJS pour en savoir plus. Si vous avez des questions, vous pouvez partir). un message ci-dessous.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!