Qual é a utilidade do Jade ou do guidão ao escrever aplicativos AngularJs

120

Eu sou novo (ish) em todos os aplicativos de pilha cheia de javascript e completamente novo no Angular, então esperava que alguém pudesse colocar o registro diretamente para mim aqui.

Por que eu precisaria usar uma estrutura de modelos, como Jade ou Guidão, ao escrever aplicativos do lado do cliente usando o AngularJS.

Devo dizer que também nunca usei nenhuma dessas estruturas de modelos. Portanto, não estou familiarizado com as vantagens completamente. Mas quando olho para o guidão, por exemplo, ele faz muitas das mesmas coisas que faria no Angular, como looping etc.

Tanto quanto posso dizer, faria mais sentido criar os modelos no Angular usando HTML adequado e, em seguida, fazer todo o modelo do lado do cliente, e combinar isso com uma primeira abordagem da API usando o node e o mongo, por exemplo.

O motivo dessa confusão é que muitos dos exemplos que encontro no GitHub fazem uso do Jade, e isso me parece contra-intuitivo.

Por favor, me esclareça e me conserte. Gostaria muito de aprender algumas práticas recomendadas de pessoas que sabem muito mais do que eu.

obrigado

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

Respostas:

61

Aqueles que inquestionavelmente apóiam o Jade em um ambiente Angular falham em entender que a lógica de exibição pertence ao cliente e a lógica de negócios no servidor, exatamente como o OP comentou.

Não faça isso a menos que você tenha um bom motivo para fazê-lo. Na engenharia, um sistema com menos partes móveis é um sistema mais confiável e um sistema em que os limites da interface (cliente / servidor) são respeitados é mais sustentável a longo prazo, portanto, é possível adotar a arquitetura mais simples e a divisão de trabalho limpa, se possível. Se você tiver razões imperiosas, faça o que deve, mas faça uma ressalva ao emptor .

Recentemente, revi alguns códigos em que a modelagem angular direta teria feito um trabalho muito melhor do que misturar Jade, apenas mantendo a simplicidade.

Além da extensão do modelo, o Jade não traz nada de valor à tabela que o Angular ainda não fornece. Sejamos honestos: usando o princípio sólido de "favorecer a composição sobre a herança" (isto é, parciais), você nunca deve precisar de extensibilidade de modelo. Jade é dificilmente "mais fácil de analisar" do que HTML. Eles são trivialmente diferentes, enquanto Jade acrescenta outro nível de indireção - melhor evitar.

Há um caso válido e especializado para modelagem do lado do servidor: Otimização, lembrando que a otimização prematura geralmente é uma coisa ruim. Onde o desempenho está realmente em questão, e você tem a capacidade de poupar do servidor para lidar com isso, o modelo do lado do servidor pode ajudar. Isso se aplica a produtos como o Twitter e o Basecamp, onde o custo de realizar muito trabalho no servidor é compensado pelos ganhos de solicitações reduzidas ao servidor.

Quanto ao guidão, não há necessidade de substituir o modelo do AngularJS (incrível) no lado do cliente.

— Engenheiro
fonte
4
Oi Nick, essa é a resposta que cheguei também. Não falei tão francamente, mas concordo!
— Jay Pete
60
@ Nick, eu não vi muitas pessoas que gostam de escrever / ler XML / HTML. Você é possivelmente o mais raro que eu já vi que realmente defende isso em favor de algo muito mais seco e limpo como Jade. Existem inúmeras bibliotecas cujo objetivo é poupar as pessoas de escrever / ler XML / HTML.
— Alex K
12
Não introduzo complexidade onde não é necessária. Passe os seus dias lendo o código C ou pior modelos, C ++, e você vai logo perceber que HTML mentalmente analisar é um assunto muito trivial fato .
— coordenador
35
"risível para qualquer profissional reivindicar isso.", "analisar mentalmente o HTML é realmente uma questão muito trivial". Acho esses comentários muito degradantes. Você prefere escrever montagem porque é tão fácil de analisar? Jade é basicamente o que YAML é para XML quando você está usando Angular.
— Philipp Gayret
7
Eu concordo com @NickWiggill. Analisar mentalmente um modelo JADE vs. HTML bruto requer um tempo de CPU 'wetware' igual para mim. Não vou tão longe a ponto de dizer que você não é profissional se discordar, mas para mim é a mesma coisa. @ Philipp, sua analogia de analisar C / C ++ para assembly igual a analisar JADE para HTML é ruim, existem poucas pessoas, se houver, que poderiam começar a analisar assembly quase em tempo real, enquanto, na minha opinião, os desenvolvedores poderiam analisar o HTML tão facilmente ou quase tão facilmente quanto o JADE.
— Nomis 29/09/14
63

Uso o Jade para gerar modelos consumidos pelo AngularJS porque odeio escrever HTML simples. Parece algo como:

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

... que eu acho muito mais limpo que o HTML simples.

— thatmarvin
fonte
12
OK, então você só o usa porque não gosta de escrever HTML simples? Esse é o principal benefício para Jade, existem outras vitórias? O Jade atrapalha o HTML de alguma forma, então você precisa ajustá-lo para obter uma determinada saída? Eu vejo o perigo de ter adicionado outra camada de indireção sem uma necessidade real. Mas, novamente, é por isso que estou perguntando. Eu quero entender o valor aqui.
— Jay Pete
1
Na verdade, eu comecei com Jade antes de ir para a Angular, por isso era um hábito que ficou mais do que uma escolha consciente, mas funcionou bem até agora. O único problema que tenho com o Jade é a maneira como ele lida com espaços em branco (eu uso pretty = false); portanto, acabei com espaços em branco nos arquivos de origem sempre que preciso adicionar um espaço entre as tags. Achei recursos como inclusões e mixins muito úteis.
— thatmarvin
Será que ng-inlude, possivelmente, utilizado em conjunto com ng-src, difere muito do mixins Jades e e inclui?
— Jay Pete
2
A camada de abstração do @JayPete Jade sobre HTML é muuuuito fina. É uma das traduções mais intuitivas entre sintaxes que já usei. Muito pouca mágica acontece no Jade, exceto onde você começa a pesquisar com variáveis ​​e lógica condicional (como faria com qualquer mecanismo de modelo). Realmente não é tão diferente assim.
— Chev
6
Simples é subjetivo.
— Chev
46

Sinceramente, não entendo por que as pessoas se preocupam com a diferença entre isso:

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

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

Só que eu acho um pouco mais legível por humanos. Ligeiramente . Não entendo por que as pessoas são tão fervorosas sobre o assunto. É tudo ciclismo. A diferença é insignificante e qualquer programador competente pode facilmente traduzir um para o outro após cinco segundos no Google. Use o que quiser e deixe que todos briguem por nada. Escolha suas batalhas e participe de debates sobre coisas que realmente importam, como reatores atômicos;)

— Chev
fonte
2
Concordo que, se você adicionar 1 Jade ifà equação, tudo muda repentinamente. Veja acima sobre "usuários premium".
— TWIStErRob
15
Eu discordo, uma página html de 9 linhas é completamente irrealista. pegar a fonte da página que estou vendo agora converte 2320 linhas em 1580 (usando html2jade ). Aquela é mais de 700 linhas de tempo perdido para quem escreveu todos os modelos stackoverflow
— Philipp Gayret
2
@TWiStErRob Se você está indo de jade para HTML, tudo que você precisa fazer é renderizar o modelo, lol. Se você possui ifs na sua marcação jade, já precisa de algum tipo de mecanismo de modelagem e precisará convertê-lo para qualquer ifsintaxe usada por esse mecanismo. Eu realmente não entendo suas críticas.
— Chev
Se todo esse debate é sobre onde a lógica condicional pertence (servidor ou cliente), acho que é um debate ainda mais tolo do que originalmente. Existem casos para ambos e você usa o que funciona ou se os dois prefeririam o que o indivíduo preferir. Passei mais tempo discutindo argumentos do que nunca, amaldiçoando uma decisão passada de colocar alguma lógica em uma visão do servidor ou vice-versa. Se todos nós queremos discutir sobre eficiência, devemos discutir os méritos de toda essa conversa.
— Chev
3
@ Philipp, não é seguro assumir que a maioria das linhas removidas está apenas fechando as tags? Como a maioria dos editores adiciona automaticamente as tags de fechamento quando você escreve uma tag de abertura, duvido que tenha economizado 700 linhas.
— Ponto-
14
  1. Você não precisa usar o guidão com o AngularJS, pois ele possui seu próprio mecanismo de modelo.
  2. O motivo pelo qual eles usam o Jade, porque é apenas um renderizador de servidor que será compilado em html e servido pelo angularJS posteriormente no frontend.

Portanto, TL; DR, no servidor, você pode usar qualquer linguagem [jade, haml, ...] para gerar apenas uma estrutura html para seu aplicativo, ele não tem nada a ver com angularJS, pois renderizará e funcionará com HTML em tempo de execução no frontend.

Você não precisa usar o Jade no servidor, e eu sugiro que não o use, pois isso confundirá novos desenvolvedores. Nos projetos em que você vê, eles usam o Jade apenas porque é mais limpo e estão acostumados, e se ele usa com o angularJS, o único trabalho é gerar html simples sem lógica.

— Dzung Nguyen
fonte
2
Não seria mais limpo não usar o html gerado pelo servidor e separar completamente a lógica e a exibição? Ou há algo que estou perdendo? Por que Jade é uma boa ideia ao escrever um aplicativo AngularJS?
— Jay Pete
Não digo que seja uma boa ideia usar com angularJS. Jade não tem nada a ver com angularJS. Para deixar isso claro, atualizarei minha resposta.
— Dzung Nguyen
Entendo que Jade não tem nada a ver com Angular. Estou apenas tentando descobrir qual é o valor do Jade, escrevendo o HTML real nas parciais do AngularJS. Eu vejo um monte de pessoas a usá-lo, e quer entender porque :-)
— Jay Pete
2
Novamente, Jade não tem nada a ver com AngularJS. AngularJS consome parciais HTML e é veiculado em uma página HTML. Você pode usar o que quer que seja para criar as páginas HTML no lado do servidor, incluindo Jade ou Haml. Jade / Haml não são realmente estruturas de templates. Eles são mais pré-processadores. A pergunta correta seria "guiador ou bigode ou outras linguagens de templates JavaScript"
— Eddie Monge Jr
@JayPete O benefício de usar o Jade no desenvolvimento de angularJS talvez por causa da sintaxe do Jade seja mais limpo. Mas ainda assim, devido à minha experiência, não ajuda muito. Então, basta fazê-lo com html :)
— Dzung Nguyen
8

A resposta aceita é um pouco unilateral e negligencia o fato de que qualquer configuração do pré-compilador para HTML tem uma grande utilidade para QUALQUER tipo de projeto HTML: Composição e flexibilidade de marcação resultante.

Trabalhando sozinho em um aplicativo angular? Experimente Jade.

O Jade melhora sua capacidade de modularizar HTML, diminui a quantidade de tempo gasto na depuração de HTML e também incentiva a criação de inventários de marcação.

Durante o tempo de design, pode haver uma quantidade enorme de iteração nas partes HTML. Se a saída HTML for baseada em um conjunto de arquivos jade, é fácil para a equipe agir de maneira flexível em relação à alteração de requisitos. Além disso, alterar a marcação via re-composição de jade inclui significativamente mais robusto do que reescrever HTML puro.

Dito isto, reconheço a aversão geral à mistura de angular com jade na fase de produção ou desenvolvimento. A introdução de outro conjunto necessário de conhecimento de sintaxe é uma péssima idéia para a maioria das equipes, e o uso do jade pode ocultar o gerenciamento ineficiente do projeto, abstraindo algum trabalho que seria proibido pelos princípios DRY (por exemplo, ser preguiçoso na preparação da marcação)

— Mirko
fonte
2
Não faço ideia por que isso teve um -1, mas eu o contrariei.
— Mark K Cowan
Foi rebaixado porque não é completamente verdade. O Jade não faz nada para modularizar o HTML. Você poderia literalmente dizer as mesmas coisas sobre HTML simples, se ele for usado da maneira certa com um pré-compilador.
— 277 Justin
1
Você está certo, o mesmo pode ser dito de todos os pré-compiladores. Para o Jade, o Mixins jade-lang.com/reference/mixins pode melhorar a modularização (especialmente em comparação com o HTML de baunilha). Se você estiver interessado na modularização de HTML, também poderá gostar de polymer-project.org .
— Mirko
7

Eu li todas as respostas acima e fiquei um pouco surpreso por ninguém ter mencionado um aspecto que torna o uso do jade sobre a geração de modelos AngularJS uma coisa muito útil.

Como já foi dito, na produção, a diferença de cenários realistas entre a digitação de html bruto e jade é realmente notável, mas a coisa mais importante que nunca devemos esquecer é que às vezes precisamos mudar dinamicamente e reinicializar modelos angularjs .

Para simplificar, às vezes precisamos alterar o html via innerHTML e forçar o AngularJS a recompilar o conteúdo. E esse é exatamente o tipo de tarefa ao gerar tais visualizações via jade, podendo ter benefícios.

Além disso, o AngularJS funciona bem com modelos, cuja estrutura é por definição bem conhecida. Na verdade, acontece que realmente não sabemos a estrutura exata (imagine, digamos, renderizador JSON). O AngularJS será bastante desajeitado aqui (mesmo que esteja criando um aplicativo angular), enquanto o jade fará o trabalho.

— shabunc
fonte
2

Jade é definitivamente muito mais próximo do html do que Haml. Portanto, a troca de contexto é realmente muito mínima. No entanto, não está completamente ausente. Pode não ser importante para um desenvolvedor. Mas quando o designer vem e pergunta como fazer com que uma tag aninhada funcione corretamente, você está resolvendo um problema desnecessário criado em primeiro lugar.

O HTML ainda pode ser escrito de maneira muito legível e parciais podem ser usadas para torná-lo mais compreensível. É difícil ler 500 linhas de qualquer coisa - seja Jade ou HTML.

Aqui está um modelo de 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

E o HTML equivalente

<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 escrito de forma legível, não vejo o HTML muito particularmente desfavorecido, a fim de justificar uma troca. Com certeza, os colchetes angulares são uma desgraça. Mas prefiro tê-los do que ter que lidar com as dúvidas do designer se o indireto que apresentei está quebrando o html. (Pode não. Mas provar que não é um esforço digno)

— suryasankar
fonte
0

Primeiro de tudo, você sempre precisa de algum tipo de modelo do servidor.

A modelagem pura do lado do cliente tem enormes desvantagens no tempo de carregamento, por isso é frequentemente atenuada ao renderizar alguns elementos estáticos no servidor. Dessa forma, quando o usuário carregar parcialmente uma página, ele já verá alguns elementos na página.

E bem, os modelos são úteis nesse caso, embora às vezes as pessoas usem um gerador de html estático como o Jekyll.

Há outra razão para usar o Jade que não foi mencionada aqui antes.

Espaço em branco.

Se você estiver escrevendo HTML de manutenção humana com recuos e quebras de linha, cada quebra de linha resultará em um nó de texto em espaço em branco. Ele pode estragar a formatação dos elementos embutidos em alguns casos e tornar o código javascript mais estranho.

Você pode ler mais detalhes aqui: https://developer.mozilla.org/en-US/docs/Web/Guide/API/DOM/Whitespace_in_the_DOM

Se você estiver escrevendo código Jade, ele é compilado em HTML de uma linha que não possui esse problema.

— alex
fonte
> [FasteRender] ( meteorhacks.com/fast-render ) é uma solução que não envolve renderização no servidor. Ele envia os dados necessários para renderizar sua primeira página com o HTML inicial carregado do Meteor, para que a página seja renderizada logo após o JavaScript ser carregado no cliente. Ele fornece resultados idênticos aos da SSR (Server Side Rendering), mas ainda envia dados por fio sem quebrar um dos princípios básicos do Meteor.
— Max Hodges
0

Ao trabalhar em equipe, o front-end provavelmente prefere projetar suas páginas como html estático. A tradução desse html estático em modelos dinâmicos é uma fonte de erros e a adição de jade adiciona essa etapa de tradução.

Como muitos outros, sou a favor da simplicidade!

— Arjan
fonte
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.