Какая польза от Jade или Handlebars при написании приложений AngularJs

120

Я новичок (иш) во всех приложениях с полным стеком javascript и совершенно новичок в Angular, поэтому я надеялся, что кто-то сможет прямо здесь рассказать обо мне.

Зачем мне использовать структуру шаблонов, такую как Jade или Handlebars, при написании клиентских приложений с использованием AngularJS.

Должен сказать, что я никогда не использовал ни одну из этих шаблонов. Так что я не полностью знаком с преимуществами. Но когда я смотрю, например, на Handlebars, он делает многие из тех же вещей, что и я в Angular, например, зацикливание и т. Д.

Насколько я могу судить, было бы наиболее разумно создавать шаблоны в Angular с использованием правильного HTML, а затем делать все шаблоны на стороне клиента и комбинировать это с первым подходом API с использованием, например, node и mongo.

Причина этой путаницы в том, что многие примеры, которые я нахожу на GitHub, используют Jade, и мне это кажется нелогичным.

Пожалуйста, просвети меня и исправь. Я хотел бы узнать несколько лучших практик от людей, которые знают гораздо больше меня.

Спасибо

— Джей Пит
источник

61

Те, кто беспрекословно предпочитает Jade в среде Angular, не понимают, что логика представления принадлежит клиенту, а бизнес-логика - серверу, как и прокомментировал OP.

Не делайте этого, если у вас нет для этого очень веских причин. В инженерии система с меньшим количеством движущихся частей является более надежной, а система, в которой соблюдаются границы интерфейса (клиент / сервер), более удобна в обслуживании в долгосрочной перспективе, поэтому по умолчанию используется простейшая архитектура и, если возможно, чистое разделение труда. Если у вас есть веские причины, делайте то, что должны, но будьте осторожны. .

Недавно я просмотрел код, в котором прямые шаблоны Angular работали бы лучше, чем смешивание в Jade, просто за счет сохранения простоты.

Помимо расширения шаблона, Jade не вносит в таблицу ничего стоящего, чего еще не предлагает Angular. Давайте будем честными: используя здравый принцип «предпочтение композиции перед наследованием» (то есть частичными), вам никогда не понадобится расширяемость шаблона. Jade трудно «разобрать», чем HTML. Они просто банально отличаются друг от друга, а Джейд добавляет еще один уровень косвенности - лучше избегать.

Есть один допустимый, специализированный случай для серверных шаблонов: оптимизация, помня, что преждевременная оптимизация, как правило, плохая вещь. Где производительность действительно стоит под вопросом, и вас есть резервные ресурсы сервера, чтобы справиться с этим, может помочь создание шаблонов на стороне сервера. Это относится к таким продуктам, как Twitter и Basecamp, где затраты на выполнение большого объема работы на стороне сервера компенсируются выигрышем от уменьшения количества запросов к серверу.

Что касается Handlebars, нет необходимости заменять (потрясающие) клиентские шаблоны AngularJS.

— инженер
источник

4

Привет, Ник, я тоже получил ответ. Я не так прямо выразился, но согласен!

— Джей Пит

60

@Nick, я не видел много людей, которым нравится писать / читать XML / HTML. Вы, наверное, самый редкий из тех, кого я когда-либо видел, кто на самом деле защищает это в пользу чего-то более сухого и чистого, как Джейд. Существует масса библиотек, вся цель которых - избавить людей от написания / чтения XML / HTML.

— Alex K

12

Я не ввожу сложность там, где она не нужна. Проведите день чтения кода C или хуже шаблонов, C ++, и вы быстро поймете , что мысленно разбора HTML является очень тривиальный вопрос на самом деле .

— Инженер

35

«смехотворно для любого профессионала утверждать это», «мысленный анализ HTML - действительно очень тривиальное дело». Я считаю эти комментарии очень унизительными. Вы бы предпочли написать сборку, потому что ее так легко разбирать? Jade - это то же самое, что YAML для XML, когда вы используете с ним Angular.

— Филипп Гайрет 05

7

Я согласен с @NickWiggill. Мысленный разбор шаблона JADE и необработанного HTML требует для меня одинакового времени процессора. Я не буду заходить так далеко, чтобы сказать, что вы непрофессионален, если вы не согласны, но для меня это то же самое. @ Филипп, ваша аналогия синтаксического анализа C / C ++ на сборке, равного синтаксическому анализу JADE в HTML, неубедительна, мало людей, если таковые имеются, которые могли бы даже начать синтаксический анализ сборки почти в реальном времени, тогда как, как мне кажется, большинство веб-сайтов разработчики могли анализировать HTML так же легко или почти так же просто, как JADE.

— nomis

63

Я использую Jade для создания шаблонов, используемых AngularJS, потому что я ненавижу писать простой HTML. Это выглядит примерно так:

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

… Который, как мне кажется, намного чище, чем простой HTML.

— thatmarvin
источник

12

Хорошо, значит, вы используете его только потому, что не любите писать простой HTML? Это главное преимущество Джейд, есть ли другие победы? Джейд когда-нибудь каким-либо образом испортил HTML, поэтому вам нужно настроить его, чтобы получить определенный результат? Я вижу опасность добавления еще одного уровня косвенного обращения без реальной необходимости. Но опять же, вот почему я спрашиваю. Я хочу понять здесь ценность.

— Джей Пит,

1

На самом деле я начал с Jade до того, как перешел на Angular, так что это была привычка, а не осознанный выбор, но до сих пор он хорошо работал. Единственная проблема, с которой я сталкиваюсь с Jade, - это то, как он обрабатывает пробелы (я использую pretty = false), поэтому в исходных файлах у меня заканчивались пробелы, когда мне нужно было добавить пробел между тегами. Я нашел такие функции, как include и mixins, очень полезными.

— thatmarvin

Сильно ли отличается от миксинов и включает Jades ng-inlude, возможно, используемых вместе с ng-src?

— Джей Пит,

2

Слой абстракции @JayPete Джейд над HTML настолько тонок. Это один из самых интуитивно понятных переводов синтаксисов, которые я когда-либо использовал. В Jade происходит очень мало магии, за исключением тех случаев, когда вы начинаете копаться в переменных и условной логике (как и в любом движке шаблонов). На самом деле все не так уж и сложно.

— Chev

6

Все просто субъективно.

— Чев

46

Честно говоря, я не понимаю, почему людей волнует разница между этим:

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

и это:

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

За исключением того, что я нахожу один более понятным для человека. Слегка . Я не понимаю, почему люди так увлечены этой темой. Это все велосипеды. Разница незначительна, и любой грамотный программист может легко перевести одно в другое через пять секунд в Google. Используйте то, что хотите, и позволяйте остальным ссориться ни из чего. Выберите свои сражения и участвуйте в дебатах о действительно важных вещах, например об атомных реакторах;)

— Чев
источник

2

Я согласен, хотя если вы просто добавите ifк уравнению 1 нефрит , все внезапно изменится. См. Выше о «премиум-пользователях».

— TWiStErRob

15

Я не согласен, html-страница из 9 строк - это совершенно нереально. взятие источника просматриваемой страницы теперь преобразует 2320 строк в 1580 (с использованием html2jade ). Это более 700 строк времени, потраченных впустую для того, кто написал все шаблоны stackoverflow,

— Филипп Гайрет,

2

@TWiStErRob Если вы переходите с jade на HTML, все, что вам нужно сделать, это визуализировать шаблон, лол. Если у вас есть ifs в вашей нефритовой разметке, то вам все равно нужен какой-то механизм шаблонов, и вам придется преобразовать его в любой ifсинтаксис, используемый этим движком. Я не очень понимаю вашу критику.

— Chev

Если вся эта дискуссия о том, где принадлежит условная логика (сервер или клиент), то я думаю, что это еще более глупые дебаты, чем я первоначально. Есть случаи для обоих, и вы используете тот, который работает, или, если они оба, то в зависимости от того, что предпочитает человек. Я потратил больше времени на подобные аргументы, чем когда- либо, проклиная прошлое решение добавить логику в представление на стороне сервера или наоборот. Если мы все хотим спорить об эффективности, мы должны обсудить достоинства всего этого разговора.

— Chev

3

@Philipp, разве не безопасно предположить, что большинство удаленных строк - это просто закрывающие теги? Поскольку большинство редакторов автоматически добавляют закрывающие теги, когда вы пишете открывающий тег, я сомневаюсь, что на самом деле это сэкономило 700 строк.

— Точка с запятой

14

Вам не нужно использовать Handlebars с AngularJS, поскольку у него есть собственный механизм шаблонов.
Причина, по которой они используют Jade, заключается в том, что это просто серверный рендерер, который будет скомпилирован в html и позже обслуживается angularJS во внешнем интерфейсе.

Итак, TL; DR, на сервере, вы можете использовать любой язык [jade, haml, ...] для генерации только структуры html для вашего приложения, это не имеет ничего общего с angularJS, поскольку он будет отображать и работать с HTML в время выполнения на веб-интерфейсе.

Вам не обязательно использовать Jade на сервере, и я предлагаю не использовать, так как это запутает новых разработчиков. В проектах, которые вы видите, они используют Jade только потому, что он чище и они к нему привыкли, а если он используется с angularJS, его задача - создать простой HTML без какой-либо логики.

— Джунг Нгуен
источник

2

Разве не было бы чище не использовать сгенерированный сервером html и полностью разделить логику и представление? Или что-то мне не хватает? Почему Jade - хорошая идея при написании приложения AngularJS?

— Джей Пит

Я не говорю, что это хорошая идея для использования с angularJS. Джейд не имеет ничего общего с angularJS. Чтобы прояснить это, я обновлю свой ответ.

— Джунг Нгуен

Я понимаю, что Jade не имеет ничего общего с Angular. Я просто пытаюсь понять, в чем ценность Jade, записывая фактический HTML в частичных файлах AngularJS. Я вижу, как много людей используют это, и хочу понять, почему :-)

— Джей Пит

2

Опять же, Jade не имеет ничего общего с AngularJS. AngularJS использует части HTML и обслуживается со страницы HTML. Вы можете использовать что угодно для создания HTML-страниц на стороне сервера, включая Jade или Haml. Jade / Haml на самом деле не являются фреймворками для создания шаблонов. Они скорее препроцессоры. Правильный вопрос будет: «Handlebars или Moustache или другие языки шаблонов JavaScript»

— Эдди Монж-младший,

@JayPete Преимущество использования Jade при разработке angularJS, возможно, благодаря синтаксису Jade чище. Но все же, по моему опыту, это не сильно помогает. Так что просто сделайте это с помощью html :)

— Джунг Нгуен

8

Принятый ответ является несколько односторонним и не учитывает тот факт, что любая установка прекомпилятора для HTML имеет большое применение для ЛЮБОГО типа HTML-проекта: композиция и результирующая гибкость разметки.

Работаете в одиночку над угловым приложением? Дайте Джейд попробовать.

Jade улучшает вашу способность разбивать HTML на модули, сокращает время, которое вы тратите на отладку HTML, а также поощряет создание инвентаря разметки.

Во время разработки частей HTML может быть очень много итераций. Если вывод HTML основан на наборе файлов нефрита, команде легко действовать гибко при изменении требований. Кроме того, изменение разметки путем повторного составления jade includes значительно более надежно, чем повторная запись чистого HTML.

При этом я осознаю общее отвращение к смешиванию angular с нефритом на стадии производства или разработки. Внедрение еще одного необходимого набора знаний синтаксиса - плохая идея для большинства команд, и использование нефрита может скрыть неэффективное управление проектом, абстрагируя часть работы, которая была бы запрещена принципами DRY (например, ленивость при подготовке разметки)

— Mirko
источник

2

Понятия не имею, почему это было -1, но я парировал это.

— Mark K Cowan

Это было отклонено, потому что это не совсем правда. Jade не делает ничего для модульного построения HTML. Вы могли бы буквально сказать то же самое о простом HTML, если бы его правильно использовали с прекомпилятором.

— Джастин

1

Вы правы, то же самое можно сказать обо всех прекомпиляторах. Для Jade Mixins jade-lang.com/reference/mixins может улучшить модуляризацию (особенно по сравнению с ванильным HTML). Если вас интересует модульность HTML, вам также может понравиться polymer-project.org .

— Мирко

7

Я прочитал все ответы выше и был немного удивлен, что никто не упомянул один аспект, который делает использование jade вместо создания шаблонов AngularJS очень полезной вещью.

Как уже было сказано, в производстве разница в реалистичных сценариях между вводом необработанного html и jade на самом деле заметна, но более важная вещь, о которой мы никогда не должны забывать, это то, что иногда нам нужны динамически изменяемые и повторно инициализированные шаблоны angularjs.

Проще говоря, иногда нам нужно изменить html через innerHTML, а затем заставить AngularJS перекомпилировать содержимое. И это именно тот тип задач, когда создание таких представлений с помощью jade может иметь преимущества.

Кроме того, AngularJS хорошо работает с моделями, структура которых по определению хорошо известна. На самом деле бывает, что мы действительно не знаем точной структуры (представьте себе, например, рендерер JSON). AngularJS будет здесь довольно неуклюжим (даже если мы создаем приложение angular), в то время как jade выполнит эту работу.

— shabunc
источник

2

Вы можете включать угловые шаблоны через Jade.

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

Что касается кэширования шаблонов, я считаю это гораздо менее хрупким, чем включение экранированных шаблонов в файлы javascript.

См. Https://docs.angularjs.org/api/ng/service/$templateCache

— Остин молись
источник

2

Jade определенно гораздо ближе к html, чем Haml. Таким образом, переключение контекста на самом деле очень минимальное. Однако он не отсутствует полностью. Для разработчика это может вообще не иметь значения. Но когда ваш дизайнер приходит и спрашивает вас, как заставить вложенный тег работать должным образом, вы решаете ненужную проблему, которую создали изначально.

HTML по-прежнему можно писать очень разборчиво, и можно использовать частичные слова, чтобы сделать его более понятным. 500 строк чего-либо, что трудно прочитать - будь то Jade или HTML.

Вот шаблон 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

И эквивалентный 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>

Когда написано разборчиво, я не вижу, чтобы HTML был в очень невыгодном положении, чтобы гарантировать переход. Разумеется, угловатые кронштейны - бельмо на глазу. Но я бы предпочел их иметь, чем иметь дело с сомнениями дизайнера, нарушает ли введенное мной косвенное обращение html. (Может и нет. Но доказать, что это не достойное усилие)

— suryasankar
источник

0

Прежде всего, вам всегда нужен какой-то серверный шаблон.

Чистые клиентские шаблоны имеют огромные недостатки во время загрузки, поэтому они часто смягчаются за счет отрисовки некоторых статических элементов на сервере. Таким образом, когда пользователь частично загружает страницу, он уже видит некоторые элементы на странице.

И что ж, шаблоны в этом случае удобны, хотя люди иногда вместо этого используют статический генератор html, такой как Jekyll.

Есть еще одна причина для использования Jade, о которой здесь раньше не упоминалось.

Пробелы.

Если вы пишете HTML-код, поддерживаемый человеком, с отступами и разрывами строк, каждый отдельный разрыв строки приведет к появлению пробельного текстового узла. В некоторых случаях он может сильно испортить форматирование встроенных элементов и сделать код javascript более странным.

Вы можете прочитать более подробную информацию здесь: https://developer.mozilla.org/en-US/docs/Web/Guide/API/DOM/Whitespace_in_the_DOM

Если вы пишете код Jade, он компилируется в однострочный HTML-код, в котором нет этой проблемы.

— Алекс
источник

> [FasteRender] ( meteorhacks.com/fast-render ) - это решение, которое не требует рендеринга на стороне сервера. Он отправляет данные, необходимые для рендеринга вашей первой страницы с исходным HTML, загруженным из Meteor, поэтому страница отображается сразу после загрузки JavaScript в клиент. Он дает тот же результат, что и рендеринг на стороне сервера (SSR), но по-прежнему отправляет данные по сети, не нарушая ни одного из основных принципов Meteor.

— Макс Ходжес

0

При работе в команде фронтенд, скорее всего, предпочитает оформлять свои страницы в виде статического HTML. Перевод этого статического HTML в динамические шаблоны является источником ошибок, а добавление jade добавляет такой шаг перевода.

Как и многие другие, я предпочитаю простоту!

— Арьян
источник