编写 AngularJs 应用程序时 Jade 或 Handlebars 有什么用 [英] What's the use of Jade or Handlebars when writing AngularJs apps

问题描述

我是整个 javascript 全栈应用程序的新手，对 Angular 完全陌生，所以我希望有人能在这里为我直截了当地记录.

I am new(ish) to the whole javascript full stack applications, and completely new to Angular, so I was hoping somebody can put the record straight for me here.

在使用 AngularJS 编写客户端应用程序时，为什么我需要使用像 Jade 或 Handlebars 这样的模板框架.

Why would I need to use a templating framework like Jade or Handlebars when writing client side apps using AngularJS.

我应该说我也从未使用过任何这些模板框架.所以我完全不熟悉这些优点.但是，当我查看 Handlebars 时，它会执行许多与我在 Angular 中所做的相同的事情，例如循环等.

I should say that I have never used any of these templating frameworks either. So I am not familiar with the advantages completely. But when I look at Handlebars for example, it does many of the same things as I would do in Angular, such as looping etc.

据我所知，最有意义的是使用适当的 HTML 在 Angular 中创建模板，然后在客户端进行所有模板化，并将其与使用 node 和 mongo 的 API 优先方法相结合.

As far as I can tell, it would make most sense to create the templates in Angular using proper HTML and then do all templating client side, and combine this with an API first approach using node and mongo for example.

造成这种混乱的原因是我在 GitHub 上找到的很多示例都使用了 Jade，这对我来说似乎违反直觉.

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.

谢谢

推荐答案

那些在 Angular 环境中毫无疑问偏爱 Jade 的人无法理解视图逻辑属于客户端，而业务逻辑属于服务器，正如 OP 评论的那样.

Those who unquestioningly favour Jade in an Angular environment fail to understand that view logic belongs on the client, and business logic on the server, just as the OP commented.

除非您有充分的理由，否则不要这样做.在工程中，移动部件较少的系统是更可靠的系统，并且系统具有接口边界(客户端/server) 更易于长期维护，因此如果可能，默认为最简单的架构和清晰的分工.如果您有压倒一切的理由，请做您必须做的事情，但警告空手.

Don't do it unless you have a very good reason to do it. In engineering, a system with fewer moving parts is a more reliable system, and a system where interface boundaries (client/server) are respected is more maintainable over the long term, so default to the simplest architecture and clean division of labour if possible. If you have overriding reasons, do what you must, but caveat emptor.

最近我审查了一些代码，其中直接 Angular 模板会比在 Jade 中混合做得更好，只是通过保持简单性.

Recently I reviewed some code where straight Angular templating would have done a far better job than mixing in Jade, just through maintaining simplicity.

除了模板扩展之外，Jade 没有带来任何 Angular 尚未提供的有价值的东西.老实说:使用优先组合而不是继承"(即部分)的合理原则，您不应该需要模板可扩展性.Jade 并不比 HTML更容易解析".它们只是微不足道不同，而 Jade 增加了另一个间接级别 - 最好避免.

Aside from template extension, Jade brings nothing worthwhile to the table that Angular doesn't already supply. Let's be honest: Using the sound principle of "favour composition over inheritance" (i.e. partials), you shouldn't ever need template extensibility. Jade is hardly "easier to parse" than HTML. They are but trivially different, while Jade adds another level of indirection - best avoided.

服务器端模板有一个有效的特殊情况:优化，记住过早优化通常是一件坏事.如果性能确实存在问题，并且您有足够的服务器容量来处理这个问题，服务器端模板可以提供帮助.这适用于 Twitter 和 Basecamp 等产品，在这些产品中，执行大量服务器端工作的成本被减少对服务器的请求所带来的收益所抵消.

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, and 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 的(惊人的)客户端模板.

As for Handlebars, there is no need to replace AngularJS's (amazing) client-side templating.

这篇关于编写 AngularJs 应用程序时 Jade 或 Handlebars 有什么用的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！