¿Cuál es el uso de Jade o Handlebars al escribir aplicaciones AngularJs?

120

Soy nuevo (más o menos) en todas las aplicaciones de pila completa de JavaScript, y completamente nuevo en Angular, por lo que esperaba que alguien pudiera aclararme las cosas aquí.

¿Por qué necesitaría usar un marco de plantillas como Jade o Handlebars al escribir aplicaciones del lado del cliente usando AngularJS?

Debo decir que nunca he usado ninguno de estos marcos de plantillas. Por tanto, no conozco completamente las ventajas. Pero cuando miro a Handlebars, por ejemplo, hace muchas de las mismas cosas que haría en Angular, como hacer bucles, etc.

Por lo que puedo decir, tendría más sentido crear las plantillas en Angular usando el HTML adecuado y luego hacer todas las plantillas del lado del cliente, y combinar esto con un primer enfoque de API usando node y mongo, por ejemplo.

La razón de esta confusión es que muchos de los ejemplos que encuentro en GitHub hacen uso de Jade, y me parece contradictorio.

Por favor, ilumíname y enderezame. Me encantaría aprender algunas de las mejores prácticas de personas que saben mucho más que yo.

Gracias

— Jay Pete
fuente

61

Aquellos que incuestionablemente favorecen a Jade en un entorno Angular no comprenden que la lógica de vista pertenece al cliente y la lógica de negocios al servidor, tal como comentó el OP.

No lo haga a menos que tenga una muy buena razón para hacerlo. En ingeniería, un sistema con menos partes móviles es un sistema más confiable, y un sistema en el que se respetan los límites de la interfaz (cliente / servidor) es más fácil de mantener a largo plazo, por lo que, de ser posible, utilice la arquitectura más simple y una división del trabajo limpia. Si tiene razones imperiosas, haga lo que deba, pero advierta emptor .

Recientemente revisé un código en el que las plantillas angulares directas habrían hecho un trabajo mucho mejor que mezclar en Jade, solo manteniendo la simplicidad.

Aparte de la extensión de la plantilla, Jade no aporta nada que valga la pena a la mesa que Angular aún no proporciona. Seamos honestos: utilizando el sólido principio de "favorecer la composición sobre la herencia" (es decir, parciales), nunca debería necesitar la extensibilidad de la plantilla. Jade no es "más fácil de analizar" que HTML. Son trivialmente diferentes, mientras que Jade agrega otro nivel de indirección: es mejor evitarlas.

Existe un caso válido y especializado para las plantillas del lado del servidor: la optimización, recordando que la optimización prematura es generalmente algo malo. Cuando el rendimiento es realmente un problema y tiene la capacidad del servidor de sobra para manejar esto, las plantillas del lado del servidor pueden ayudar. Esto se aplica a productos como Twitter y Basecamp, donde el costo de hacer una gran cantidad de trabajo del lado del servidor se compensa con las ganancias de la reducción de solicitudes al servidor.

En cuanto a Handlebars, no hay necesidad de reemplazar las (increíbles) plantillas del lado del cliente de AngularJS.

— Ingeniero
fuente

4

Hola Nick, esa es la respuesta a la que también llegué. No lo dije tan francamente, ¡pero estoy de acuerdo!

— Jay Pete

60

@Nick, no he visto mucha gente a la que le guste escribir / leer XML / HTML. Posiblemente seas el más raro que he visto en mi vida que realmente defiende eso a favor de algo mucho más seco y limpio como Jade. Hay toneladas de bibliotecas cuyo propósito es evitar que la gente escriba / lea XML / HTML.

— Alex K

12

No introduzco complejidad donde no es necesaria. Pasa sus días leyendo el código C o peor plantillas, C ++, y rápidamente se dará cuenta de que el análisis de HTML mental es un asunto muy trivial, de hecho .

— Ingeniero

35

"Es ridículo para cualquier profesional afirmar esto", "analizar mentalmente HTML es un asunto muy trivial". Encuentro estos comentarios muy degradantes. ¿Preferiría escribir ensamblado porque es muy fácil de analizar? Jade es básicamente lo que YAML es para XML cuando usa Angular con él.

— Philipp Gayret

7

Estoy de acuerdo con @NickWiggill. Analizar mentalmente una plantilla JADE frente a HTML sin procesar requiere el mismo tiempo de CPU de 'wetware' para mí. No iré tan lejos como para decir que no eres profesional si no estás de acuerdo, pero para mí es lo mismo. @ Philipp, su analogía de analizar C / C ++ con ensamblado es igual a analizar JADE en HTML es deficiente, hay pocas personas, si es que hay alguna, que podría incluso comenzar a analizar ensamblado casi en tiempo real, mientras que, creo, la mayoría de la web los desarrolladores pueden analizar HTML con la misma facilidad o casi tan fácil como JADE.

— nomis

63

Utilizo Jade para generar plantillas consumidas por AngularJS porque odio escribir HTML simple. Se parece a 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 creo que es mucho más limpio que HTML simple.

— thatmarvin
fuente

12

De acuerdo, ¿solo lo usa porque no le gusta escribir HTML sin formato? ¿Es ese el principal beneficio para Jade, hay otras victorias? ¿Jade alguna vez estropea el HTML de alguna manera, por lo que tienes que modificarlo para obtener un resultado determinado? Veo el peligro de haber agregado otra capa de indirecta sin una necesidad real. Pero, de nuevo, es por eso que estoy preguntando. Quiero entender el valor aquí.

— Jay Pete

1

De hecho, comencé con Jade antes de ir con Angular, por lo que fue un hábito que se mantuvo en lugar de una elección consciente, pero ha funcionado bien hasta ahora. El único problema que tengo con Jade es la forma en que maneja los espacios en blanco (uso pretty = false), así que terminé con espacios en blanco finales en los archivos de origen cada vez que necesito agregar un espacio entre las etiquetas. Encontré características como include y mixins muy útiles.

— thatmarvin

¿Se diferencia mucho ng-inlude, posiblemente usado junto con ng-src, de los mixins e incluye de Jades?

— Jay Pete

2

@JayPete La capa de abstracción de Jade sobre HTML es muuuy delgada. Es una de las traducciones más intuitivas entre sintaxis que he usado. Muy poca magia ocurre en Jade, excepto cuando comienzas a profundizar con variables y lógica condicional (como lo harías con cualquier motor de plantilla). Realmente no es tan diferente.

— Chev

6

Lo simple es subjetivo.

— Chev

46

Sinceramente, no entiendo por qué a la gente le importa la diferencia entre esto:

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

y esto:

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

Excepto que encuentro uno un poco más legible por humanos. Ligeramente . No entiendo por qué la gente es tan ferviente con el tema. Todo es derramamiento de bicicletas. La diferencia es insignificante y cualquier programador competente podría traducir fácilmente uno al otro después de cinco segundos en Google. Usa lo que quieras y deja que todos los demás peleen por nada. Elija sus batallas y participe en debates sobre cosas que realmente importan, como los reactores atómicos;)

— Chev
fuente

2

Estoy de acuerdo, aunque si agregas 1 jade ifa la ecuación, todo cambia de repente. Consulte más arriba sobre los "usuarios premium".

— TWiStErRob

15

No estoy de acuerdo, una página html de 9 líneas es completamente irreal. tomar la fuente de la página que estoy viendo ahora convierte 2320 líneas en 1580 (usando html2jade ). Eso es más de 700 líneas de tiempo perdidas para quien haya escrito todas las plantillas de stackoverflow

— Philipp Gayret

2

@TWiStErRob Si vas de jade a HTML, todo lo que necesitas hacer es renderizar la plantilla, jejeje. Si tiene ifs en su marcado de jade, entonces ya necesita algún tipo de motor de plantillas de todos modos y tendría que convertirlo a cualquier ifsintaxis que utilice ese motor. Realmente no entiendo tu crítica.

— Chev

Si todo este debate se trata de dónde pertenece la lógica condicional (servidor o cliente), entonces creo que es un debate aún más tonto que el que hice originalmente. Hay casos para ambos y usted usa el que funcione o si ambos lo harían, entonces el que prefiera el individuo. He pasado más tiempo teniendo argumentos como estos de lo que he pasado maldiciendo una decisión pasada para poner algo de lógica en una vista del lado del servidor o viceversa. Si todos queremos discutir sobre la eficiencia, entonces deberíamos discutir los méritos de toda esta conversación.

— Chev

3

@Philipp, ¿no es seguro asumir que la mayoría de las líneas eliminadas son solo etiquetas de cierre? Dado que la mayoría de los editores agregan automáticamente etiquetas de cierre cuando escribes una etiqueta de apertura, dudo que realmente haya ahorrado la escritura de 700 líneas.

— Punto

14

No es necesario utilizar Handlebars con AngularJS, ya que tiene su propio motor de plantillas.
La razón por la que usan Jade, porque es solo un renderizador de servidor que será compilado en html y servido por angularJS más adelante en la interfaz.

Entonces TL; DR, en el servidor, puede usar cualquier lenguaje [jade, haml, ...] para generar solo la estructura html para su aplicación, no tiene nada que ver con angularJS ya que se renderizará y funcionará con HTML en tiempo de ejecución en la interfaz.

No tiene que usar Jade en el servidor, y sugiero que no lo use, ya que confundirá a los nuevos desarrolladores. En los proyectos que ve, usan Jade solo porque es más limpio y están acostumbrados, y si lo usa con angularJS, su único trabajo es generar html simple sin ninguna lógica.

— Dzung Nguyen
fuente

2

¿No sería más limpio no usar el html generado por el servidor y separar completamente la lógica y la vista? ¿O hay algo que me estoy perdiendo? ¿Por qué Jade es una buena idea al escribir una aplicación AngularJS?

— Jay Pete

No digo que sea una buena idea usar con angularJS. Jade no tiene nada que ver con angularJS. Para dejar esto en claro, actualizaré mi respuesta.

— Dzung Nguyen

Entiendo que Jade no tiene nada que ver con Angular. Solo estoy tratando de averiguar cuál es el valor de Jade, sobre escribir el HTML real en parciales de AngularJS. Veo a mucha gente usándolo y quiero entender por qué :-)

— Jay Pete

2

Nuevamente, Jade no tiene nada que ver con AngularJS. AngularJS consume parciales HTML y se sirve desde una página HTML. Puede usar lo que sea para crear las páginas HTML en el lado del servidor, incluidos Jade o Haml. Jade / Haml no son marcos de plantillas. Son más preprocesadores. La pregunta correcta sería "Manillar o Moustache u otros lenguajes de plantillas JavaScript"

— Eddie Monge Jr

@JayPete El beneficio de usar Jade al desarrollar angularJS tal vez debido a que la sintaxis de Jade es más limpio. Pero aún así, debido a mi experiencia, no es de mucha ayuda. Así que hazlo con html :)

— Dzung Nguyen

8

La respuesta aceptada es algo unilateral y descuida el hecho de que cualquier configuración de precompilador para HTML tiene un gran uso para CUALQUIER tipo de proyecto HTML: la composición y la flexibilidad de marcado resultante.

¿Trabaja solo en una aplicación angular? Dale una oportunidad a Jade.

Jade mejora su capacidad para modularizar HTML, reduce la cantidad de tiempo que dedica a depurar HTML y también fomenta la creación de inventarios de marcado.

Durante el tiempo de diseño, puede haber una gran cantidad de iteraciones en partes HTML. Si la salida HTML se basa en un conjunto de archivos jade, es fácil para el equipo actuar con flexibilidad ante los requisitos cambiantes. Además, cambiar el marcado mediante la recomposición de las inclusiones de jade es significativamente más sólido que volver a escribir HTML puro.

Dicho esto, reconozco la aversión general a mezclar angular con jade en la etapa de producción o desarrollo. Introducir otro conjunto requerido de conocimiento de sintaxis es una mala idea para la mayoría de los equipos y el uso de jade podría ocultar una gestión de proyectos ineficiente al abstraerse de algunos trabajos que estarían prohibidos por los principios de DRY (por ejemplo, ser perezoso en la preparación del marcado)

— Mirko
fuente

2

No tengo idea de por qué esto tenía un -1, pero lo he contrarrestado.

— Mark K Cowan

Se votó en contra porque no es completamente cierto. Jade no hace nada para modularizar HTML. Literalmente, podría decir lo mismo sobre HTML simple si se usa de la manera correcta con un precompilador.

— Justin

1

Tiene razón, se puede decir lo mismo de todos los precompiladores. Para Jade, Mixins jade-lang.com/reference/mixins puede mejorar la modularización (especialmente en comparación con HTML vanilla). Si está interesado en la modularización de HTML, también puede que le guste polímero-project.org .

— Mirko

7

Leí todas las respuestas anteriores y me sorprendió un poco que nadie hubiera mencionado un aspecto que hace que usar jade sobre la generación de plantillas AngularJS sea algo muy útil.

Como ya se dijo, en producción, la diferencia de escenarios realistas entre escribir html crudo y jade es realmente notable, pero lo más importante que nunca debemos olvidar es que a veces necesitamos plantillas de angularjs reiniciadas y cambiadas dinámicamente .

En pocas palabras, a veces necesitamos cambiar html a través de innerHTML y luego forzar a AngularJS a recompilar el contenido. Y este es exactamente el tipo de tarea cuando la generación de tales vistas a través de jade puede tener sus beneficios.

Además, AngularJS funciona bien con modelos, cuya estructura es bien conocida por definición. En realidad, sucede que en realidad no conocemos la estructura exacta (imagina, digamos, el renderizador JSON). AngularJS será bastante torpe aquí (incluso si estamos construyendo una aplicación angular), mientras que jade hará el trabajo.

— shabunc
fuente

2

Puede incluir plantillas angulares a través de Jade.

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

Para las plantillas de almacenamiento en caché, percibo esto como mucho menos frágil que incluir las plantillas de escape en los archivos javascript.

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

— Austin reza
fuente

2

Jade definitivamente está mucho más cerca de html que decir Haml. Entonces, el cambio de contexto es realmente mínimo. Sin embargo, no está completamente ausente. Puede que no le importe en absoluto a un desarrollador. Pero cuando su diseñador llega y le pregunta cómo hacer que una etiqueta anidada funcione correctamente, está resolviendo un problema innecesario que creó en primer lugar.

HTML aún se puede escribir de manera muy legible y se pueden usar parciales para hacerlo más comprensible. 500 líneas de cualquier cosa son difíciles de leer, ya sea Jade o HTML.

Aquí hay una plantilla 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

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

Cuando se escribe de manera legible, no veo que HTML esté particularmente en desventaja para justificar un cambio. Efectivamente, los corchetes angulares son una monstruosidad. Pero preferiría tenerlos, que tener que lidiar con las dudas del diseñador sobre si la indirecta que introduje está rompiendo el html. (Puede que no. Pero demostrar que no es un esfuerzo digno)

— suryasankar
fuente

0

En primer lugar, siempre necesitas algún tipo de plantilla del lado del servidor.

Las plantillas del lado del cliente puro tienen enormes desventajas en el tiempo de carga, por lo que a menudo se mitiga al representar algunos elementos estáticos en el servidor. De esta manera, cuando el usuario carga parcialmente una página, ya verá algunos elementos en la página.

Y bueno, las plantillas son útiles en este caso, aunque la gente a veces usa un generador de html estático como Jekyll.

Hay otra razón para usar Jade que no se mencionó aquí antes.

Espacio en blanco.

Si está escribiendo HTML mantenible por humanos con sangrías y saltos de línea, cada salto de línea resultará en un nodo de texto de espacio en blanco. En algunos casos, puede arruinar el formato de elementos en línea y hacer que el código javascript sea más extraño.

Puede leer más detalles aquí: https://developer.mozilla.org/en-US/docs/Web/Guide/API/DOM/Whitespace_in_the_DOM

Si está escribiendo código Jade, se compila en HTML de una línea que no tiene este problema.

— alex
fuente

> [FasteRender] ( meteorhacks.com/fast-render ) es una solución que no implica la renderización del lado del servidor. Envía los datos necesarios para representar su primera página con el HTML inicial cargado desde Meteor, por lo que la página se representa justo después de que se cargue el JavaScript en el cliente. Ofrece un resultado idéntico al de la representación del lado del servidor (SSR), pero sigue enviando datos a través del cable sin romper uno de los principios básicos de Meteor.

— Max Hodges

0

Cuando se trabaja en equipo, el front-end probablemente prefiere diseñar sus páginas como html estático. Traducir ese html estático en plantillas dinámicas es una fuente de errores, y agregar jade agrega ese paso de traducción.

¡Como muchos otros, prefiero la sencillez!

— Arjan
fuente