什么是写AngularJs应用程序时使用玉或车把 [英] What's the use of Jade or Handlebars when writing AngularJs apps
问题描述
我是新的（ISH）整个JavaScript的全栈的应用程序，并且完全新的角度，所以我希望有人可以把打抱不平，我在这里。
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客户端应用程序时。
Why would I need to use a templating framework like Jade or Handlebars when writing client side apps using AngularJS.
我应该说，我从来没有使用这些模板框架任。所以我不熟悉完全的优势。但是，当我看着车把为例，它做了很多的同样的事情，我会做的角，如循环等。
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创建在角模板，然后做所有的模板客户端，并使用节点与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上的例子都使用玉，似乎直觉我。
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.
感谢
推荐答案
这些谁毫无疑问地的青睐玉在角环境不明白，视图逻辑所属的客户端和业务逻辑在服务器上，就像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.
的除非你有一个很好的理由这样做不这样做。的在工程上，用更少的运动部件的系统是一个更可靠的系统，以及一个系统，其中的接口边界（客户机/服务器）受到尊重是长期更容易维护，所以默认为最简单的结构和劳动力如果可能的清洁师。如果你有压倒一切的原因，做你必须的，但的买者自负的
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.
最近，我回顾了一些code其中直角模板会做一个更好的工作比在翡翠混合，刚刚经历保持简洁性。
Recently I reviewed some code where straight Angular templating would have done a far better job than mixing in Jade, just through maintaining simplicity.
除了模板扩展，玉带来没什么值得的角度已经不供应表。坦率地说：使用偏袒继承组成（即谐音）的发声原理，你不应该永远的需求的模板可扩展性。翡翠是很难更易于解析比HTML。他们是但的平凡的不同，而翡翠增加了间接的另一个层面 - 最好避免
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.
有一个有效的，服务器端模板专门的案例：优化，记住，premature优化通常是一件坏事。表现在哪里是真正的问题，和的你有服务器容量以备用来处理这个问题，服务器端模板可以帮助。本产品适用于Twitter和大本营，在那里做了很多服务器端工作的成本是由减少请求到服务器的收益所抵消。
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.
至于把手，也没有必要更换AngularJS的（惊人）客户端模板。
As for Handlebars, there is no need to replace AngularJS's (amazing) client-side templating.
这篇关于什么是写AngularJs应用程序时使用玉或车把的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
