在编写 AngularJs 应用程序时，使用 Jade 或 Handlebar 有什么用

我对整个 javascript 完整堆栈应用程序还是新手，对 Angular 也是全新的，所以我希望有人可以在这里为我直接记录。

在使用 AngularJS 编写客户端应用程序时，为什么需要使用类似 Jade 或 Handlebar 的模板框架呢。

我应该说，我也从未使用过这些模板框架中的任何一个。所以我并不完全熟悉其中的优势。但是，当我看着把手，例如，它做了很多相同的事情，我会在角度，如循环等。

据我所知，最有意义的做法是使用适当的 HTML 创建 Angular 模板，然后在客户端完成所有模板工作，并将其与使用 node 和 mongo 的 API 优先方法结合起来。

The reason for this confusion is that a lot of the examples I find on GitHub make use of Jade, and it seems counter intuitive for me.

Please enlighten me, and set me straight. I would love to learn some best practices from people who know much more than I do.

Thanks

47687 次浏览
小开
  1. AngularJS 不需要使用 Handlebar，因为它有自己的模板引擎。
  2. 他们之所以使用 Jade，是因为它只是一个服务器渲染器，将被编译成 html，稍后在前端由 angularJS 提供服务。

所以 TL; DR，在服务器上，你可以使用任何语言[ Jade，haml，... ]为你的应用程序生成 HTML 结构，它与 angularJS 没有任何关系，因为它会在运行时在前端渲染和处理 HTML。

您不必在服务器上使用 Jade，我建议不要使用它，因为它会让新开发人员感到困惑。在你看到的项目中，他们使用 Jade 仅仅是因为它更干净，而且他们已经习惯了，如果它使用 angularJS，它的唯一工作就是生成没有任何逻辑的纯 HTML。

小开

我使用 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 要干净得多。

小开
最佳答案

那些在角环境中偏爱 Jade 的 毫无疑问用户不能理解视图逻辑属于客户机，业务逻辑属于服务器，就像 OP 所说的那样。

除非你有很好的理由，否则不要做这件事。在工程中，一个运动部件较少的系统是一个更可靠的系统，一个界面边界(客户机/服务器)受到尊重的系统在长期内更容易维护，所以如果可能的话，默认使用最简单的架构和干净的分工。如果你有压倒一切的理由，做你必须做的，但 买者自负。

最近我回顾了一些代码，在这些代码中，直角模板比在 Jade 中混合要好得多，只需要保持简单。

除了模板扩展，Jade 没有为 Angular 提供任何有价值的东西。让我们诚实地说: 使用“偏爱组合优于继承”(即部分)的合理原则，您永远不应该使用 需要模板扩展性。Jade 很难比 HTML“更容易解析”。他们只是 小事一桩不同，而杰德增加了另一个层次的间接-最好避免。

There is one valid, specialised case for server-side templating: Optimisation, remembering that premature optimisation is generally a Bad Thing. Where performance is truly at issue, 还有 you have the server capacity to spare to handle this, server side templating can assist. This applies to products like Twitter and Basecamp, where the cost of doing a lot of server side work is offset by the gains of reduced requests to the server.

至于 Handlebars，没有必要替换 AngularJS 的(惊人的)客户端模板。

小开

我真的不明白为什么人们关心这两者之间的区别:

<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 上花5秒钟把一个翻译成另一个。利用你想要的，让其他人无谓地争吵。选择你的战斗，参与到关于真正重要的事情的辩论中，比如 原子反应堆;)

小开

我读了上面所有的答案，有点惊讶没有人提到一个方面，使用翡翠在生成 AngularJS 模板非常有用的事情。

正如我们已经说过的，在生产环境中，输入原始 html 和 Jade 之间的现实场景差异实际上是显著的，但更重要的是，我们永远不应该忘记的是，有时我们需要动态 changed and reinitialized angularjs 模板。

简单地说，有时候需要通过 innerHTML 修改 html，然后强制 AngularJS 重新编译内容。而这正是通过玉产生这种观点的任务类型，可以有它的好处。

此外，AngularJS 可以很好地处理模型，根据定义，模型的结构是众所周知的。实际上，我们并不知道确切的结构(想象一下，比如说 JSON 渲染器)。AngularJS 在这里会相当笨拙(即使我们正在建立一个有棱角的应用程序) ，而翡翠将做这项工作。

小开

首先，您总是需要某种服务器端模板。

纯客户端模板在加载时有很大的缺点，因此通常可以通过在服务器上呈现一些静态元素来减轻这种缺点。这样，当用户部分加载页面时，他将已经看到页面上的一些元素。

在这种情况下，模板非常方便，尽管人们有时会使用像 Jekyll 这样的静态 html 生成器。

使用 Jade 还有一个前面没有提到的原因。

空格。

如果您使用缩进和换行符编写人类可维护的 HTML，那么每个换行符都将生成一个空格文本节点。在某些情况下，它可以很好地改变内联元素的格式，使 javascript 代码更加怪异。

你可以在这里阅读更多的细节: https://developer.mozilla.org/en-US/docs/Web/Guide/API/DOM/Whitespace_in_the_DOM

如果您正在编写 Jade 代码，它将被编译成一行 HTML，这样就不存在这个问题。

小开

你可以包括角模板通过翡翠。

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

对于缓存模板，我认为这比在 javascript 文件中包含转义模板要容易得多。

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

小开

公认的答案有点片面，忽略了这样一个事实，即任何 HTML 预编译器的设置对任何类型的 HTML 项目都有很大的用处: 组合和由此产生的标记灵活性。

独自开发一个棱角分明的应用程序? 给杰德一个机会

Jade 提高了模块化 HTML 的能力，减少了调试 HTML 所花费的时间，还鼓励构建标记清单。

在设计阶段，可能会对 HTML 部分进行大量的迭代。如果 HTML 输出基于一组翡翠文件，那么团队就很容易灵活地处理变更的需求。此外，通过重新组合 Jade 包含来更改标记要比重新编写纯 HTML 健壮得多。

尽管如此，我认识到在生产或开发阶段，人们普遍反对将玉石与棱角混合。对于大多数团队来说，引入另一套所需的语法知识是一个糟糕的主意，而且翡翠的使用可能会通过抽象出一些 DRY 原则禁止的工作(例如在标记准备上懒惰)来掩盖低效的项目管理

小开

Jade 绝对比 Haml 更接近 html。所以上下文切换实际上是非常小的。然而，它并非完全不存在。对于开发人员来说，这可能根本无关紧要。但是，当您的设计师来问您如何使嵌套标记正常工作时，您正在解决一个您最初创建的不必要的问题。

HTML 仍然可以写得非常清晰，可以使用部分内容使其更易于理解。500行任何东西都很难读懂——无论是 Jade 还是 HTML。

这是翡翠模板

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

When written legibly I dont see HTML to be very particularly disadvantaged so as to warrant a switch. Sure enough, the angular brackets are an eyesore. But I would rather have them, than having to deal with the designer's doubts whether the indirection I introduced is breaking the html. ( It may not. But proving it is not a worthy effort )

小开

在团队中工作时，前端可能更喜欢将页面设计为静态 html。将静态 html 翻译成动态模板是一个错误的来源，添加翡翠添加了这样的翻译步骤。

和其他人一样，我喜欢简单！


提交答案