Quelle est l'utilité de Jade ou de Handlebars lors de l'écriture d'applications AngularJs

120

Je suis nouveau (ish) à l'ensemble des applications javascript full stack, et complètement nouveau pour Angular, donc j'espérais que quelqu'un puisse mettre les choses au clair pour moi ici.

Pourquoi aurais-je besoin d'utiliser un cadre de création de modèles comme Jade ou Handlebars lors de l'écriture d'applications côté client à l'aide d'AngularJS.

Je dois dire que je n'ai jamais utilisé aucun de ces frameworks de modèles. Je ne connais donc pas complètement les avantages. Mais quand je regarde Handlebars par exemple, il fait beaucoup des mêmes choses que je le ferais dans Angular, comme la boucle, etc.

Pour autant que je sache, il serait plus logique de créer les modèles dans Angular en utilisant le code HTML approprié, puis de faire tout le modèle côté client, et de combiner cela avec une première approche API utilisant node et mongo par exemple.

La raison de cette confusion est que beaucoup d'exemples que je trouve sur GitHub utilisent Jade, et cela me semble contre-intuitif.

Veuillez m'éclairer et me redresser. J'aimerais apprendre quelques bonnes pratiques de personnes qui en savent beaucoup plus que moi.

Merci

node.js  mongodb  angularjs  handlebars.js  pug 
— Jay Pete
source

Réponses:

61

Ceux qui favorisent sans aucun doute Jade dans un environnement angulaire ne comprennent pas que la logique de vue appartient au client et la logique métier au serveur, comme l'a commenté l'OP.

Ne le faites pas à moins d'avoir une très bonne raison de le faire. En ingénierie, un système avec moins de pièces mobiles est un système plus fiable, et un système où les limites d'interface (client / serveur) sont respectées est plus maintenable sur le long terme, donc par défaut, choisissez l'architecture la plus simple et une division du travail propre si possible. Si vous avez des raisons impérieuses, faites ce que vous devez, mais mettez en garde le vide .

Récemment, j'ai passé en revue du code dans lequel la création de modèles angulaires simples aurait fait un bien meilleur travail que le mixage dans Jade, simplement en maintenant la simplicité.

Mis à part l'extension de modèle, Jade n'apporte rien de valable à la table qu'Angular ne fournit pas déjà. Soyons honnêtes: en utilisant le principe solide de "privilégier la composition par rapport à l'héritage" (c'est-à-dire les partiels), vous ne devriez jamais avoir besoin d' extensibilité de modèle. Jade n'est guère "plus facile à analyser" que HTML. Ils ne sont que trivialement différents, tandis que Jade ajoute un autre niveau d'indirection - mieux éviter.

Il existe un cas spécialisé et valide pour la création de modèles côté serveur: l'optimisation, en se souvenant que l'optimisation prématurée est généralement une mauvaise chose. Lorsque les performances sont vraiment en jeu et que vous disposez de la capacité du serveur pour gérer cela, la création de modèles côté serveur peut vous aider. Cela s'applique à des produits comme Twitter et Basecamp, où le coût de beaucoup de travail côté serveur est compensé par les gains de demandes réduites au serveur.

En ce qui concerne Handlebars, il n'est pas nécessaire de remplacer le (incroyable) modèle côté client d'AngularJS.

— Ingénieur
source
4
Salut Nick, c'est aussi la réponse que j'ai trouvée. Je ne l'ai pas dit aussi brutalement, mais je suis d'accord!
— Jay Pete
60
@Nick, je n'ai pas vu beaucoup de gens qui aiment écrire / lire du XML / HTML. Vous êtes peut-être le plus rare que j'aie jamais vu qui prône cela en faveur de quelque chose de beaucoup plus sec et plus propre comme Jade. Il existe des tonnes de bibliothèques dont le seul but est d'éviter aux gens d'écrire / lire du XML / HTML.
— Alex K
12
Je n'introduis pas de complexité là où elle n'est pas nécessaire. Passez vos journées à la lecture du code C ou pire, C ++ modèles, et vous vous rendrez vite compte que l' analyse mentalement HTML est une question très trivial en effet .
— Ingénieur
35
"risible pour tout professionnel de prétendre cela.", "l'analyse mentale du HTML est une question très triviale.". Je trouve ces commentaires très dégradants. Préférez-vous écrire l'assembly car il est si facile à analyser? Jade est essentiellement ce que YAML est pour XML lorsque vous utilisez Angular avec lui.
— Philipp Gayret
7
Je suis d'accord avec @NickWiggill. L'analyse mentale d'un modèle JADE par rapport au HTML brut nécessite pour moi le même temps processeur «wetware». Je n'irai pas jusqu'à dire que vous n'êtes pas professionnel si vous n'êtes pas d'accord, mais pour moi, c'est la même chose. @ Philipp, votre analogie entre l'analyse C / C ++ et l'assembly étant égale à l'analyse JADE en HTML est médiocre, il y a peu de gens, voire aucun, qui pourraient même commencer à analyser l'assembly en temps quasi réel, alors que, je pense, la plupart des sites Web les développeurs peuvent analyser le HTML aussi facilement ou presque aussi facilement que JADE.
— nomis
63

J'utilise Jade pour générer des modèles consommés par AngularJS parce que je déteste écrire du HTML brut. Cela ressemble à quelque chose comme:

.control-group(
  ng-form
  name='emailGroup'
  ng-class='{"ng-error": emailGroup.$invalid}'
)
  label.control-label Email
  .controls
    input(
      type='email'
      ng-model='user.email'
      required
      placeholder='you@example.com'
      focus-on='focusEmail'
    )

… Ce qui, à mon avis, est beaucoup plus propre que le simple HTML.

— thatmarvin
source
12
OK, vous ne l'utilisez que parce que vous n'aimez pas écrire du HTML brut? Est-ce le principal avantage de Jade, y a-t-il d'autres victoires? Jade gâche-t-il jamais le HTML de quelque manière que ce soit, vous devez donc le modifier pour obtenir une certaine sortie? Je vois un danger d'avoir ajouté une autre couche d'indirection sans un besoin réel. Mais là encore, c'est pourquoi je demande. Je veux comprendre la valeur ici.
— Jay Pete du
1
En fait, j'ai commencé avec Jade avant de partir avec Angular, donc c'était une habitude qui restait plutôt qu'un choix conscient, mais cela a bien fonctionné jusqu'à présent. Le seul problème que j'ai avec Jade est la façon dont il gère les espaces blancs (j'utilise pretty = false) donc je me suis retrouvé avec des espaces de fin dans les fichiers source chaque fois que j'ai besoin d'ajouter un espace entre les balises. J'ai trouvé des fonctionnalités comme les inclusions et les mixins très utiles.
— thatmarvin
Est ng-inlude- ce que , éventuellement utilisé avec ng-src, diffère beaucoup des mixins et et comprend Jades?
— Jay Pete
2
La couche d'abstraction de @JayPete Jade sur HTML est tellement mince. C'est l'une des traductions les plus intuitives entre les syntaxes que j'ai jamais utilisées. Très peu de magie se produit dans Jade, sauf lorsque vous commencez à creuser avec des variables et une logique conditionnelle (comme vous le feriez avec n'importe quel moteur de modèle). Ce n'est vraiment pas si différent.
— Chev
6
Le simple est subjectif.
— Chev
46

Honnêtement, je ne comprends pas pourquoi les gens se soucient de la différence entre ceci:

<html ng-app>
 <!-- Body tag augmented with ngController directive  -->
 <body ng-controller="MyController">
   <input ng-model="foo" value="bar">
   <!-- Button tag with ng-click directive, and string expression 'buttonText' wrapped in "{{ }}" markup -->
   <button ng-click="changeFoo()">{{buttonText}}</button>
   <script src="angular.js">
 </body>
</html>

et ça:

html(ng-app="ng-app")
  // Body tag augmented with ngController directive  
  body(ng-controller="MyController")
    input(ng-model="foo", value="bar")
    // Button tag with ng-click directive, and string expression 'buttonText' wrapped in "{{ }}" markup
    button(ng-click="changeFoo()") {{buttonText}}
    script(src="angular.js")

Sauf que j'en trouve un un peu plus lisible par l'homme. Un peu . Je ne comprends pas pourquoi les gens sont si fervents sur le sujet. Ce n'est que du vélo. La différence est négligeable et tout programmeur compétent pourrait facilement traduire l'un dans l'autre après cinq secondes sur Google. Utilisez ce que vous voulez et laissez tout le monde se quereller pour rien. Choisissez vos batailles et engagez-vous dans des débats sur des choses qui comptent vraiment, comme les réacteurs atomiques;)

— Chev
source
2
Je suis d'accord, mais si vous ajoutez simplement 1 Jade ifà l'équation, tout change soudainement. Voir ci-dessus à propos des "utilisateurs premium".
— TWiStErRob
15
Je ne suis pas d'accord, une page html de 9 lignes est complètement irréaliste. prendre la source de la page que je regarde maintenant convertit 2320 lignes en 1580 (en utilisant html2jade ). C'est plus de 700 lignes de temps perdu pour celui qui a écrit tous les modèles de stackoverflow
— Philipp Gayret
2
@TWiStErRob Si vous passez du jade au HTML, tout ce que vous avez à faire est de rendre le modèle, lol. Si vous avez des ifs dans votre balisage jade, vous avez de toute façon déjà besoin d'un moteur de création de modèles et vous devrez le convertir en n'importe quelle ifsyntaxe utilisée par ce moteur. Je ne comprends pas vraiment vos critiques.
— Chev
Si tout ce débat porte sur la place de la logique conditionnelle (serveur ou client), je pense que c'est un débat encore plus ridicule que je ne le faisais à l'origine. Il y a des cas pour les deux et vous utilisez celui qui fonctionne ou si les deux le feraient, ce que l'individu préfère. J'ai passé plus de temps à avoir des arguments comme ceux-ci que je n'ai jamais passé à maudire une décision passée de mettre un peu de logique dans une vue côté serveur ou vice versa. Si nous voulons tous discuter de l'efficacité, nous devrions plutôt discuter des mérites de toute cette conversation.
— Chev
3
@Philipp, n'est-il pas prudent de supposer que la plupart des lignes supprimées ne font que fermer des balises? Étant donné que la plupart des éditeurs ajoutent automatiquement des balises de fermeture lorsque vous écrivez une balise d'ouverture, je doute que cela ait réellement économisé 700 lignes.
— Point
14
  1. Vous n'avez pas besoin d'utiliser Handlebars avec AngularJS car il possède son propre moteur de modèle.
  2. La raison pour laquelle ils utilisent Jade, car c'est juste un moteur de rendu de serveur qui sera compilé en html et servi par angularJS plus tard sur le frontend.

Donc TL; DR, sur le serveur, vous pouvez utiliser n'importe quel langage [jade, haml, ...] pour générer uniquement une structure html pour votre application, cela n'a rien à voir avec angularJS car il rendra et fonctionnera avec HTML à runtime sur le frontend.

Vous n'êtes pas obligé d'utiliser Jade sur le serveur, et je suggère de ne pas l'utiliser car cela déroutera les nouveaux développeurs. Dans les projets que vous voyez, ils utilisent Jade uniquement parce qu'il est plus propre et qu'ils y sont habitués, et s'il l'utilise avec angularJS, le seul travail est de générer du HTML sans aucune logique.

— Dzung Nguyen
source
2
Ne serait-il pas plus propre de ne pas utiliser le html généré par le serveur et de séparer complètement la logique et la vue? Ou y a-t-il quelque chose qui me manque? Pourquoi Jade est-il une bonne idée lors de l'écriture d'une application AngularJS?
— Jay Pete
Je ne dis pas que c'est une bonne idée à utiliser avec angularJS. Jade n'a rien à voir avec angularJS. Pour que cela soit clair, je mettrai à jour ma réponse.
— Dzung Nguyen
Je comprends que Jade n'a rien à voir avec Angular. J'essaie juste de comprendre quelle est la valeur de Jade, en écrivant le HTML réel dans les partiels AngularJS. Je vois beaucoup de gens l'utiliser et je veux comprendre pourquoi :-)
— Jay Pete
2
Encore une fois, Jade n'a rien à voir avec AngularJS. AngularJS contient des partiels HTML et est servi à partir d'une page HTML. Vous pouvez utiliser n'importe quoi pour créer les pages HTML côté serveur, y compris Jade ou Haml. Jade / Haml ne sont pas vraiment des frameworks de modèles. Ce sont davantage des préprocesseurs. La bonne question serait "Guidon ou Moustache ou autres langages de création de modèles JavaScript"
— Eddie Monge Jr
@JayPete L'avantage d'utiliser Jade lors du développement d'angularJS peut-être à cause de la syntaxe de Jade est plus propre. Mais encore, en raison de mon expérience, cela n'aide pas beaucoup. Alors faites-le avec html :)
— Dzung Nguyen
8

La réponse acceptée est quelque peu unilatérale et néglige le fait que toute configuration de pré-compilateur pour HTML a une grande utilité pour TOUT type de projet HTML: composition et flexibilité de balisage qui en résulte.

Travailler seul sur une application angulaire? Essayez Jade.

Jade améliore votre capacité à modulariser le HTML, réduit le temps que vous passez à déboguer le HTML et encourage également la création d'inventaires de balisage.

Au moment de la conception, il peut y avoir une quantité énorme d'itérations sur les parties HTML. Si la sortie HTML est basée sur un ensemble de fichiers jade, il est facile pour l'équipe de faire preuve de souplesse face à l'évolution des besoins. De plus, changer le balisage via la recomposition des inclut jade est beaucoup plus robuste que la réécriture de HTML pur.

Cela étant dit, je reconnais l'aversion générale pour le mélange angulaire et jade au stade de la production ou du développement. L'introduction d'un autre ensemble requis de connaissances syntaxiques est une mauvaise idée pour la plupart des équipes et l'utilisation du jade pourrait masquer une gestion de projet inefficace en faisant abstraction de certains travaux qui seraient interdits par les principes de DRY (par exemple, être paresseux lors de la préparation du balisage)

— Mirko
source
2
Je ne sais pas pourquoi cela avait un -1, mais je l'ai contré.
— Mark K Cowan
Il a été critiqué parce que ce n'est pas tout à fait vrai. Jade ne fait rien pour modulariser le HTML. Vous pourriez littéralement dire les mêmes choses à propos du HTML brut s'il est utilisé de la bonne manière avec un précompilateur.
— Justin
1
Vous avez raison, la même chose peut être dite de tous les pré-compilateurs. Pour Jade, Mixins jade-lang.com/reference/mixins peut améliorer la modularisation (surtout par rapport au HTML vanilla). Si vous êtes intéressé par la modularisation du HTML, vous aimerez peut-être aussi polymer-project.org .
— Mirko
7

J'ai lu toutes les réponses ci-dessus et j'ai été un peu surpris que personne n'ait mentionné un aspect qui rend l'utilisation de jade sur la génération de modèles AngularJS une chose très utile.

Comme il a déjà été dit, en production, la différence de scénarios réalistes entre la saisie de html brut et de jade est en fait notable, mais la chose la plus importante que nous ne devons jamais oublier est que parfois nous avons besoin de manière dynamique modèles angularjs modifiés et réinitialisés dynamiquement.

Pour faire simple, nous devons parfois changer le code HTML via innerHTML, puis forcer AngularJS à recompiler le contenu. Et c'est exactement le type de tâche lorsque la génération de telles vues via jade peut avoir des avantages.

De plus, AngularJS fonctionne bien avec les modèles, dont la structure est par définition bien connue. En fait, il arrive que nous ne connaissions pas la structure exacte (imaginez, disons, le rendu JSON). AngularJS sera assez maladroit ici (même si nous construisons une application angulaire), tandis que jade fera le travail.

— shabunc
source
2

Jade est certainement beaucoup plus proche du html que de dire Haml. Le changement de contexte est donc en fait très minime. Pourtant, ce n'est pas complètement absent. Cela n'a peut-être pas d'importance pour un développeur. Mais lorsque votre concepteur vient et vous demande comment faire fonctionner correctement une balise imbriquée, vous résolvez un problème inutile que vous avez créé en premier lieu.

Le HTML peut toujours être écrit de manière très lisible et les partiels peuvent être utilisés pour le rendre plus compréhensible. 500 lignes de tout est difficile à lire - que ce soit Jade ou HTML.

Voici un modèle Jade

.product-container

    .input-group.msB.col-md-5.no-padding
        .fnt-light-navyblue.mtB(for='name')
            strong Name the sticker
        input.full-input(type='text', placeholder='Awesome Batman Sticker')
    .clear

    .form-group.mmT
        label.form-label.fnt-light-navyblue
            strong Choose size
        .selector-group(ng-repeat="size in sizes", ng-class="{ 'msT': !$first}")
            - raw
            span.radio
                input.radio(name='choose_sticker_size',
                            ng-model="selectedSize",
                            type='radio',
                            value='{{size}}',
                            id="sticker-{{size}}")
                span.fake-radio
            label(for='sticker-{{size}}') {{size}} inch
            - endraw
    // end form-group
    .clear

Et le HTML équivalent

<div class="product-container">

    <div class="input-group msB col-md-5 no-padding">
        <div for="name" class="fnt-light-navyblue mtB">
            <strong>Name the product</strong>
        </div>
        <input type="text" placeholder="Awesome Batman Sticker" class="full-input" />
    </div>
    <div class="clear"></div>

    <div class="form-group mmT">
        <label class="form-label fnt-light-navyblue">
            <strong>Choose size</strong>
        </label>
        <div
            class="selector-group"
            ng-class="{ 'msT': !$first}"
            ng-repeat="size in sizes">
                {% raw %}
                <span class="radio">
                    <input
                        id="sticker-{{size}}"
                        class="radio"
                        name="choose_sticker_size"
                        ng-model="selectedSize"
                        type="radio"
                        value="{{ size }}" />
                    <span class="fake-radio"></span>
                </span>
                <label for="sticker-{{size}}">{{size}}</label>
                {% endraw %}
        </div>
    </div><!-- end form-group -->
    <div class="clear"></div>
</div>

Lorsqu'il est écrit lisiblement, je ne vois pas le HTML comme étant très particulièrement désavantagé pour justifier un changement. Effectivement, les crochets angulaires sont une horreur. Mais je préfère les avoir, plutôt que d'avoir à gérer les doutes du concepteur si l'indirection que j'ai introduite brise le html. (Ce n'est peut-être pas le cas. Mais prouver que ce n'est pas un effort louable)

— suryasankar
source
0

Tout d'abord, vous avez toujours besoin d'une sorte de modèle côté serveur.

Les modèles purs côté client ont d'énormes inconvénients en termes de temps de chargement, ils sont donc souvent atténués par le rendu de certains éléments statiques sur le serveur. De cette façon, lorsque l'utilisateur charge partiellement une page, il verra déjà certains éléments sur la page.

Et bien, les modèles sont pratiques dans ce cas, bien que les gens utilisent parfois un générateur html statique comme Jekyll à la place.

Il y a une autre raison d'utiliser Jade qui n'a pas été mentionnée auparavant.

Espace blanc.

Si vous écrivez du HTML maintenable par l'homme avec des indentations et des sauts de ligne, chaque saut de ligne se traduira par un nœud de texte en espace blanc. Il peut à peu près visser le formatage des éléments en ligne dans certains cas et rendre le code javascript plus étrange.

Vous pouvez lire plus de détails ici: https://developer.mozilla.org/en-US/docs/Web/Guide/API/DOM/Whitespace_in_the_DOM

Si vous écrivez du code Jade, il est compilé en HTML d'une ligne qui ne présente pas ce problème.

— Alex
source
> [FasteRender] ( meteorhacks.com/fast-render ) est une solution qui n'implique pas de rendu côté serveur. Il envoie les données nécessaires pour rendre votre première page avec le HTML initial chargé à partir de Meteor, de sorte que la page est rendue juste après le chargement du JavaScript sur le client. Il donne un résultat identique à celui du rendu côté serveur (SSR), mais envoie toujours des données sur le fil sans rompre l'un des principes fondamentaux de Meteor.
— Max Hodges
0

Lorsqu'il travaille en équipe, le front-end préfère probablement concevoir ses pages au format HTML statique. Traduire ce HTML statique en modèles dynamiques est une source d'erreurs, et l'ajout de jade ajoute une telle étape de traduction.

Comme beaucoup d'autres, je privilégie la simplicité!

— Arjan
source
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.