Question

阅读此Micro templates are dead文章后。我变得很好奇：

在服务器上使用DOM是否会产生更清晰，更易于维护的代码，然后进行模板化。
使用jsdom而不是模板引擎是否更有效。
如何将jsdom纳入标准MVC设置的视图中。

通常在什么情况下使用服务器端DOM抽象会更好，比如jsdom而不是模板引擎，比如EJS或jade。

该问题特定于node.js和其他SSJS

Answer 1

好吧，我实际上需要JSDom用于我在node.js上周末建立的一个小项目。因此，在我的服务器上，我必须接受一个URL来获取，从给定的URL中获取所有HTML，解析它，并向用户显示图像，以便用户可以从该URL中选择一个缩略图。（当你把链接放到Facebook输入框时有点像）所以，我使用了一个名为Request的模块，它允许我在服务器端获取HTML。但是，当HTML到达我的程序时，我无法像使用客户端javascript那样遍历它。因为没有实际的DOM，所以我不能说document.getElementById('someId')。因此，通过给我一个“临时”DOM允许我遍历返回的HTML，JSDom派上了用场。现在，即使我还在服务器端，JSDOM创建了一个与浏览器中的窗口对象非常相似的window对象，并从返回的HTML中创建了一个DOM。现在，即使在服务器上，我也可以通过调用window.$('img')来获取所有图像。我可以像平常那样定位和解析元素。所以，这只是JSDom成为解决方案的一个问题，但它的效果非常好。希望这有助于一些人！

Answer 2

它是一个很好的抽象，可以与客户端工程师一起研究如何构建和修改dom。在这方面它是“更清洁”，因为有一个心理模型。它也很好，因为我们不需要在其他干净的声明性标记之上混合使用模板化语言的大量不同语法，就像“愚蠢的”模板系统一样，例如小胡子。
我不会说使用jsdom进行模板更有效率。例如，去google wrt以“与jsdom进行内存泄漏”为例。 jsdom是rad，对于爬行站点的周末项目，执行非服务器相关任务等任务非常有用，但我认为从高性能Web服务器角度看它很慢。
有十亿种方法可以将其考虑在内。没有任何方法作为“标准”方式出现。我看到的一种方法是发送一个空的“模板”，即以某种方式表示模型的html块，然后使用它来引导从模型构建终端视图。从那篇文章中可以看出：

<li class="contact" id="contact-template">
    <span class="name"></span>
    <p class="title"></p>
</li>

这是经典方面的'观点'。在典型的Web应用程序中，它可能看起来更像：

<li class="contact">
    <span class="name"><?= $name ?></span>
    <p class="title"><?= $title ?></p>
</li>

要使用mvc，可以设置一个控制器，该控制器模糊地了解上述视图的语义及其所代表的模型。该视图被解析为/ a DOM并通过您喜欢的选择器引擎访问。每次代表更改的模型时，您可以使用更改事件或回调来更新视图。例如：

让我们想象一下，每当一个属性改变时，'model'就会触发'change'事件。

controller = new Controller({ 
    view: $('#contact-template').clone(), // Assume jquery or whatever
    model: aContact 
});

// Assume some initialization that sets the view up for the first time
// and appends it to the appropriate place. A la:
// this.view.find('.name').text(model.name);
// this.view.find('.title').text(model.title);
// this.view.appendTo('#contacts')

controller.on('model.name.change', function(name){
    this.view.find('.name').text(name);
});

这些是像Weld和Backbone.js这样的系统为您做的。他们对这项工作的发生位置（服务器端，客户端），您正在使用的框架（jquery，mootools等），以及如何分配您的更改（REST，套接字等）都有不同程度的假设。 io等。）

修改

使用jsdom可以做的一些非常有用的事情围绕集成测试和抓取：

https://github.com/mikeal/spider - 使用节点基于事件的处理的通用网络蜘蛛，并为您提供jsdom / jquery以帮助您以编程方式轻松访问DOM
https://github.com/assaf/zombie - 使用jsdom / jquery进行集成测试的无头浏览器测试
https://github.com/LearnBoost/tobi - 类似的无头浏览器测试

就个人而言，我希望看到一个采用tobi方法的项目，但是将其映射到像https://github.com/LearnBoost/soda这样的东西，这样我们就可以在没有selenese的情况下进行基于云的硒测试（因为imo，它很糟糕）。

Answer 3

有些人想到：

在服务器和浏览器之间共享视图/控制器
数据挖掘/抓取/处理
转换AJAX /实时内容中使用的HTML片段
通过避免模板标签绝对分离逻辑和内容

并回答你的问题：

也许。很多事情会影响代码质量，但这是朝着正确方向迈出的一步
nope，模板引擎总是会更快，因为它们可以预编译模板
这可能需要一个新问题吗？

Answer 4

你的问题的第2点可以通过这个模板测试用例来回答：

去http://jsperf.com/dom-vs-innerhtml-based-templating/300

点击“运行测试”按钮。
耐心等待，它比较了其他模板引擎的焊接与很多，并为您提供了当前的基准......

jsdom的用例是什么？

4 个答案: