javascript - What are the use cases of jsdom

Question

After reading this Micro templates are dead article. I've become curious:

1. Whether Using the DOM on the server results in cleaner more maintainable code then templating.
2. Whether it's more efficient to use jsdom instead of a templating engine.
3. How to factor jsdom into the View of a standard MVC setup.

And generally in what situations would it be better to use a server-side DOM abstraction, like jsdom rather then a templating engine, like EJS or jade.

The question is specific to node.js and other SSJS

question from:https://stackoverflow.com/questions/6101673/what-are-the-use-cases-of-jsdom

Answer 1

1. Its a nice abstraction that matches a client side engineers take on how the dom is built and modified. In that respect it is 'cleaner' because there is one mental model. Its also nice because we don't have to mix a kluge of disparate syntaxes from a templating language on top of otherwise clean declarative markup as is the case with even the 'stupidest' templating system, such as mustache.

2. I would NOT say its more efficient to use jsdom for templating. Go take a gander at google wrt to 'memory leaks with jsdom' for instance. jsdom is rad, and is super useful for tasks like weekend projects for crawling sites, doing non-server related tasks, but I think its slow as shit from a high performance web server perspective.

3. There are a billion ways to factor this. No method has emerged as a 'standard' way. One way that I've seen is to send down an empty 'template', i.e. a block of html that represents a model in some way, and then use that to bootstrap building your end view from a model. From that article, for example:

---

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

This is the 'view' in the classic respect. In the typical web application, it might look something more like:

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

To use mvc, one sets up a controller that is vaguely aware of the semantics of the above view and the model it represents. This view is parsed into the/a DOM and accessed via your favorite selector engine. Each time the model this represents changes, you might use change events or callbacks to update the view. For instance:

Lets imagine that 'model' fires a 'change' event every time a property changes.

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);
});

These are what systems like Weld and Backbone.js do for you. They all have varying degrees of assumptions about where this work is taking place (server-side, client-side), what framework you're using (jquery, mootools, etc), and how your changes are being distributed (REST, socket.io, etc).

(Edit)

Some really useful things you can do with jsdom revolve around integration testing and spidering: https://github.com/mikeal/spider - general purpose web spider that makes use of node's event based processing and gives you jsdom/jquery to help you easily access the DOM in a programatic way https://github.com/assaf/zombie - headless browser testing using jsdom/jquery for integration tests https://github.com/LearnBoost/tobi - similar headless browser testing Personally, I'd like to see a project that took tobi's approach, but mapped it on top of something like https://github.com/LearnBoost/soda such that we can do cloud based selenium testing without selenese (since imo, it sucks).