A che serve Jade o Handlebars quando si scrivono app AngularJs

120

Sono nuovo (ish) a tutte le applicazioni full stack javascript e completamente nuovo ad Angular, quindi speravo che qualcuno potesse mettere le cose in chiaro per me qui.

Perché dovrei usare un framework di modelli come Jade o Handlebars quando scrivo app lato client usando AngularJS.

Devo dire che non ho mai usato nessuno di questi framework di modelli. Quindi non conosco completamente i vantaggi. Ma quando guardo il manubrio, ad esempio, fa molte delle stesse cose che farei in Angular, come il loop, ecc.

Per quanto ne so, avrebbe più senso creare i modelli in Angular utilizzando l'HTML appropriato e quindi eseguire tutti i modelli lato client e combinarli con un primo approccio API utilizzando ad esempio node e mongo.

La ragione di questa confusione è che molti degli esempi che trovo su GitHub fanno uso di Jade e mi sembra controintuitivo.

Per favore, illuminami e mettimi in ordine. Mi piacerebbe imparare alcune buone pratiche da persone che ne sanno molto di più di me.

Grazie

— Jay Pete
fonte

61

Coloro che favoriscono indiscutibilmente Jade in un ambiente angolare non riescono a capire che la logica di visualizzazione appartiene al client e la logica di business al server, proprio come ha commentato l'OP.

Non farlo a meno che tu non abbia un'ottima ragione per farlo. In ingegneria, un sistema con meno parti in movimento è un sistema più affidabile e un sistema in cui i confini dell'interfaccia (client / server) sono rispettati è più manutenibile a lungo termine, quindi utilizzare l'architettura più semplice e una divisione del lavoro pulita se possibile. Se hai ragioni imperative, fai quello che devi, ma attenzione emptor .

Recentemente ho esaminato del codice in cui la semplice creazione di modelli angolari avrebbe svolto un lavoro molto migliore rispetto al missaggio in Jade, semplicemente mantenendo la semplicità.

A parte l'estensione del modello, Jade non porta nulla di utile sul tavolo che Angular non fornisce già. Siamo onesti: usando il sano principio di "favorire la composizione sull'ereditarietà" (cioè i parziali), non dovresti mai aver bisogno dell'estensibilità del template. Jade non è "più facile da analizzare" dell'HTML. Sono solo banalmente diversi, mentre Jade aggiunge un altro livello di indirezione - meglio evitare.

C'è un caso valido e specializzato per la creazione di modelli lato server: l'ottimizzazione, ricordando che l'ottimizzazione prematura è generalmente una brutta cosa. Laddove le prestazioni sono veramente in discussione e hai la capacità del server da risparmiare per gestirlo, la creazione di modelli lato server può aiutare. Questo vale per prodotti come Twitter e Basecamp, dove il costo di fare molto lavoro lato server è compensato dai guadagni di richieste ridotte al server.

Per quanto riguarda i manubri, non è necessario sostituire i (sorprendenti) modelli lato client di AngularJS.

— Ingegnere
fonte

4

Ciao Nick, anche questa è la risposta che ho raggiunto. Non l'ho detto in modo così schietto, ma sono d'accordo!

— Jay Pete

60

@ Nick, non ho visto molte persone a cui piace scrivere / leggere XML / HTML. Sei forse il più raro che abbia mai visto che in realtà lo sostenga a favore di qualcosa di molto più secco e pulito come Jade. Ci sono tonnellate di librerie il cui unico scopo è quello di evitare che le persone scrivano / leggano XML / HTML.

— Alex K

12

Non introduco complessità dove non è necessaria. Trascorrete le vostre giornate la lettura del codice C o peggio modelli, C ++, e vi renderete conto rapidamente che l'analisi mentalmente HTML è una questione molto banale davvero .

— Ingegnere

35

"è ridicolo per qualsiasi professionista affermare questo.", "analizzare mentalmente l'HTML è davvero una cosa banale.". Trovo questi commenti molto degradanti. Preferiresti scrivere assembly perché è così facile da analizzare? Jade è fondamentalmente ciò che YAML è per XML quando usi Angular con esso.

— Philipp Gayret

7

Sono d'accordo con @NickWiggill. L'analisi mentale di un modello JADE rispetto a HTML grezzo richiede lo stesso tempo della CPU "wetware" per me. Non mi spingerò fino a dire che non sei professionale se non sei d'accordo, ma per me è la stessa cosa. @ Philipp, la tua analogia con l'analisi di C / C ++ e assembly uguale all'analisi di JADE in HTML è scarsa, ci sono poche persone, se ce ne sono, che potrebbero persino iniziare ad analizzare l'assembly quasi in tempo reale, mentre, credo, la maggior parte del web gli sviluppatori possono analizzare l'HTML con la stessa facilità o quasi con la stessa facilità di JADE.

— nomis

63

Uso Jade per generare modelli consumati da AngularJS perché odio scrivere HTML semplice. Sembra qualcosa di simile:

.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'
    )

... che penso sia molto più pulito del semplice HTML.

— thatmarvin
fonte

12

OK, quindi lo usi solo perché non ti piace scrivere HTML normale? È questo il vantaggio principale di Jade, ci sono altre vittorie? Jade ha mai rovinato l'HTML in qualche modo, quindi devi modificarlo per ottenere un determinato output? Vedo il pericolo di aver aggiunto un altro livello di riferimento indiretto senza una reale necessità. Ma poi di nuovo, ecco perché te lo chiedo. Voglio capire il valore qui.

— Jay Pete

1

In realtà ho iniziato con Jade prima di andare con Angular, quindi è stata un'abitudine che è rimasta più che una scelta consapevole, ma finora ha funzionato bene. L'unico problema che ho con Jade è il modo in cui gestisce gli spazi bianchi (io uso pretty = false), quindi ho finito con gli spazi vuoti finali nei file di origine ogni volta che ho bisogno di aggiungere uno spazio tra i tag. Ho trovato funzionalità come include e mixin molto utili.

— thatmarvin

Fa ng-inlude, forse utilizzato insieme ng-src, differisce molto da mixins giade e e comprende?

— Jay Pete

2

Lo strato di astrazione di @JayPete Jade sull'HTML è davvero sottile. È una delle traduzioni più intuitive tra le sintassi che abbia mai usato. In Jade accade pochissima magia, tranne quando inizi a scavare con variabili e logica condizionale (come faresti con qualsiasi motore di modelli). Non è poi così diverso.

— Chev

6

Semplice è soggettivo.

— Chev

46

Onestamente non capisco perché le persone si preoccupino della differenza tra questo:

<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>

e questo:

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")

Solo che ne trovo uno leggermente più leggibile dall'uomo. Leggermente . Non capisco perché le persone siano così ferventi sull'argomento. È tutto bikehedding. La differenza è trascurabile e qualsiasi programmatore competente potrebbe facilmente tradurre l'uno nell'altro dopo cinque secondi su Google. Usa quello che vuoi e lascia che tutti gli altri litigino per nulla. Scegli le tue battaglie e partecipa a dibattiti su cose che contano davvero, come i reattori atomici;)

— Chev
fonte

2

Sono d'accordo, anche se se aggiungi solo 1 Giada ifall'equazione, tutto cambia improvvisamente. Vedi sopra sugli "utenti premium".

— TWiStErRob

15

Non sono d'accordo, una pagina html di 9 righe è completamente irrealistica. prendendo il sorgente della pagina che sto visualizzando ora converte 2320 righe in 1580 (usando html2jade ). Sono più di 700 righe di tempo sprecate per chi ha scritto tutti i modelli di

— stackoverflow

2

@TWiStErRob Se stai passando da jade a HTML, tutto ciò che devi fare è rendere il modello, lol. Se hai ifs nel tuo markup jade, allora hai già bisogno di un qualche tipo di motore di template e dovresti convertirlo in qualunque ifsintassi sia usata da quel motore. Non capisco davvero le tue critiche.

— Chev

Se tutto questo dibattito riguarda l'appartenenza della logica condizionale (server o client), allora penso che sia un dibattito ancora più sciocco di quanto non facessi inizialmente. Ci sono casi per entrambi e usi quello che funziona o se entrambi lo farebbero, a seconda di quale preferisci. Ho passato più tempo ad avere argomenti come questi di quanto non abbia mai speso maledicendo una decisione passata di mettere un po 'di logica in una vista lato server o viceversa. Se tutti vogliamo discutere sull'efficienza, dovremmo invece discutere i meriti dell'intera conversazione.

— Chev

3

@Philipp, non è lecito presumere che la maggior parte delle righe rimosse siano solo tag di chiusura? Poiché la maggior parte degli editor aggiunge automaticamente i tag di chiusura quando scrivi un tag di apertura, dubito che abbia effettivamente salvato la scrittura di 700 righe.

— Punto

14

Non è necessario utilizzare Manubri con AngularJS poiché ha il proprio motore di modelli.
Il motivo per cui usano Jade, perché è solo un renderer di server che verrà compilato in html e servito da angularJS in seguito sul frontend.

Quindi TL; DR, sul server, puoi usare qualsiasi linguaggio [jade, haml, ...] per generare solo una struttura html per la tua applicazione, non ha nulla a che fare con angularJS poiché renderà e funzionerà con HTML a runtime sul frontend.

Non è necessario utilizzare Jade sul server e suggerisco di non utilizzarlo poiché confonderà i nuovi sviluppatori. Nei progetti che vedi usano Jade solo perché è più pulito e ci sono abituati, e se lo usa con angularJS, l'unico compito è generare html semplice senza alcuna logica.

— Dzung Nguyen
fonte

2

Non sarebbe più pulito non utilizzare l'html generato dal server e separare completamente la logica e la vista? O c'è qualcosa che mi manca? Perché Jade è una buona idea quando si scrive un'app AngularJS?

— Jay Pete

Non dico che sia una buona idea da usare con angularJS. Jade non ha niente a che fare con angularJS. Per renderlo più chiaro, aggiornerò la mia risposta.

— Dzung Nguyen

Capisco che Jade non abbia niente a che fare con Angular. Sto solo cercando di capire qual è il valore di Jade, scrivendo l'effettivo HTML in parziali AngularJS. Vedo molte persone che lo usano e voglio capire perché :-)

— Jay Pete

2

Ancora una volta, Jade non ha nulla a che fare con AngularJS. AngularJS utilizza parziali HTML ed è servito da una pagina HTML. Puoi usare qualsiasi cosa per creare le pagine HTML sul lato server, inclusi Jade o Haml. Jade / Haml non stanno realmente creando modelli di framework. Sono più preprocessori. La domanda corretta sarebbe "Manubri o baffi o altri linguaggi di template JavaScript"

— Eddie Monge Jr

@JayPete Il vantaggio di utilizzare Jade durante lo sviluppo di angularJS, forse a causa della sintassi di Jade, è più pulito. Tuttavia, a causa della mia esperienza, non è di grande aiuto. Quindi fallo con html :)

— Dzung Nguyen

8

La risposta accettata è in qualche modo unilaterale e trascura il fatto che qualsiasi configurazione di pre-compilatore per HTML ha un grande uso per QUALSIASI tipo di progetto HTML: composizione e flessibilità di markup risultante.

Lavori da solo su un'app angolare? Prova Jade.

Jade migliora la tua capacità di modularizzare l'HTML, riduce la quantità di tempo speso per il debug dell'HTML e incoraggia anche la creazione di inventari di markup.

Durante la fase di progettazione può esserci un'enorme quantità di iterazione sulle parti HTML. Se l'output HTML si basa su un set di file jade, è facile per il team agire in modo flessibile al variare dei requisiti. Inoltre, la modifica del markup tramite la ricomposizione degli include jade è significativamente più robusta rispetto alla riscrittura dell'HTML puro.

Detto questo, riconosco la generale avversione verso la miscelazione angolare con giada in fase di produzione o sviluppo. L'introduzione di un altro set richiesto di conoscenza della sintassi è una cattiva idea per la maggior parte dei team e l'uso di jade potrebbe nascondere una gestione inefficiente del progetto astraendo del lavoro che sarebbe proibito dai principi DRY (ad esempio essere pigri nella preparazione del markup)

— mirko
fonte

2

Non ho idea del motivo per cui questo avesse un -1, ma l'ho contrastato.

— Mark K Cowan

È stato downvoted perché non è completamente vero. Jade non fa nulla per modulare l'HTML. Potresti letteralmente dire le stesse cose del semplice HTML se viene usato nel modo giusto con un pre-compilatore.

— Justin

1

Hai ragione, lo stesso si può dire di tutti i pre-compilatori. Per Jade, Mixins jade-lang.com/reference/mixins può migliorare la modularizzazione (soprattutto rispetto al vanilla HTML). Se sei interessato alla modularizzazione dell'HTML, ti potrebbe piacere anche polymer-project.org .

— Mirko

7

Ho letto tutte le risposte sopra e sono rimasto un po 'sorpreso che nessuno avesse menzionato un aspetto che rende l'uso di giada sulla generazione di modelli AngularJS una cosa molto utile.

Come è già stato detto, in produzione, la differenza di scenari realistici tra la digitazione di html grezzo e jade è effettivamente notevole, ma la cosa più importante che non dovremmo mai dimenticare è che a volte abbiamo bisogno di modelli angularjs cambiati e reinizializzati dinamicamente.

Per semplificare, a volte abbiamo bisogno di cambiare html tramite innerHTML e quindi forzare AngularJS a ricompilare i contenuti. E questo è esattamente il tipo di attività in cui la generazione di tali visualizzazioni tramite jade può avere dei vantaggi.

Inoltre, AngularJS funziona bene con i modelli, la cui struttura è per definizione ben nota. In realtà, accade che in realtà non conosciamo la struttura esatta (immagina, diciamo, renderer JSON). AngularJS sarà piuttosto goffo qui (anche se sta costruendo un'app angolare), mentre jade farà il lavoro.

— shabunc
fonte

2

Puoi includere modelli angolari tramite Jade.

script(type="text/ng-template", id="admin")
  include partials/admin

Per i modelli di memorizzazione nella cache lo percepisco come molto meno fragile rispetto all'inclusione dei modelli con escape nei file javascript.

Vedi: https://docs.angularjs.org/api/ng/service/$templateCache

— Austin Pray
fonte

2

Jade è decisamente molto più vicino a html di quanto dicono Haml. Quindi il cambio di contesto è in realtà molto minimo. Eppure non è del tutto assente. Potrebbe non essere affatto importante per uno sviluppatore. Ma quando il tuo designer arriva e ti chiede come far funzionare correttamente un tag nidificato, stai risolvendo un problema non necessario che hai creato in primo luogo.

L'HTML può ancora essere scritto in modo molto leggibile e le parziali possono essere utilizzate per renderlo più comprensibile. 500 righe di qualsiasi cosa sono difficili da leggere, che si tratti di Jade o HTML.

Ecco un modello di giada

.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

E l'equivalente HTML

<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>

Quando scritto in modo leggibile, non vedo che l'HTML sia particolarmente svantaggiato in modo da giustificare un passaggio. Abbastanza sicuro, le parentesi angolari sono un pugno nell'occhio. Ma preferirei averli, piuttosto che dover affrontare i dubbi del designer sul fatto che l'indirizzamento che ho introdotto stia rompendo l'html. (Potrebbe non esserlo. Ma provare che non è uno sforzo degno)

— suryasankar
fonte

0

Prima di tutto, hai sempre bisogno di una sorta di template lato server.

I modelli puri lato client presentano enormi svantaggi in un tempo di caricamento, quindi sono spesso mitigati dal rendering di alcuni elementi statici sul server. In questo modo quando l'utente carica parzialmente una pagina, vedrà già alcuni elementi sulla pagina.

E beh, i modelli sono utili in questo caso, anche se a volte le persone usano invece un generatore di html statico come Jekyll.

C'è un altro motivo per usare Jade che non è stato menzionato qui prima.

Lo spazio bianco.

Se stai scrivendo HTML gestibile dall'uomo con rientri e interruzioni di riga, ogni singola interruzione di riga risulterà in un nodo di testo con spazi vuoti. In alcuni casi può praticamente rovinare la formattazione degli elementi inline e rendere il codice javascript più strano.

Puoi leggere maggiori dettagli qui: https://developer.mozilla.org/en-US/docs/Web/Guide/API/DOM/Whitespace_in_the_DOM

Se stai scrivendo codice Jade, viene compilato in HTML a una riga che non presenta questo problema.

— alex
fonte

> [FasteRender] ( meteorhacks.com/fast-render ) è una soluzione che non prevede il rendering lato server. Invia i dati necessari per eseguire il rendering della prima pagina con l'HTML iniziale caricato da Meteor, quindi la pagina viene visualizzata subito dopo che JavaScript è stato caricato sul client. Fornisce risultati identici a Server Side Rendering (SSR), ma invia comunque i dati in rete senza rompere uno dei principi fondamentali di Meteor.

— Max Hodges

0

Quando si lavora in un team, il front-end preferisce probabilmente progettare le proprie pagine come HTML statico. Tradurre quell'html statico in modelli dinamici è una fonte di errori e l'aggiunta di jade aggiunge tale passaggio di traduzione.

Come molti altri, prediligo la semplicità!

— Arjan
fonte