

Simplify templating with node.js, jsdom 0.2.0 and weld - indexzero
http://blog.nodejitsu.com/micro-templates-are-dead

======
simonw
DOM-based templating is a horrible idea, at least for the majority of projects
I've ever worked on.

The whole point of using templates is to separate your presentation logic from
the rest of your application - ideally, you can hand the templates over to a
client-side developer/designer and they can re-jiggle everything on their own.

If your templating code works by performing manipulations against a DOM, even
minor changes to your page structure require to to completely rewrite both the
templates and the code that manipulates them. I'd much rather leave my "view"
code alone and just alter the template.

~~~
piranha
Also it's probably worth to mention that manipulation of DOM is not that fast.
Every performance optimization article starts with "don't manipulate DOM
directly, make a batch of your changes and then inject them in one step".

~~~
prodigal_erik
I don't see any reason for JSDOM in the server to be slow, the object tree
being manipulated isn't all that complicated. They aren't suggesting the
typical mess of putting useless markup on the wire and then conducting massive
repairs to it in the browser's DOM, all while a rendering engine tries to
repaint each change.

~~~
dmethvin
Seems like the complexity of the client-side code comes from rendering the DOM
tree based on the CSS and constraints of the drawing area, hardware, etc. So
yeah, just manipulating the tree would seem to be pretty fast.

Of course, it's being compared to spitting out an arbitrary stream of
characters to the client without the need to parse HTML on the server side,
which is probably faster. Years of experience with the string rendering
approach tells us it's definitely more error prone. For example it's
impossible to tell whether the character stream is well formed HTML without
traversing all the code paths.

------
georgecalm
The fact that it's all std-based, and back/front-end rendered is beautiful,
but what seriously bothers me is how much weld.js is tied to jQuery.

The README states "Use with whatever library you want, jQuery for example".
Let's analyze that for a second.

Weld.js uses the following jQuery methods: \- Sizzle selector ($) \- first()
\- is() \- val() \- attr() \- text() \- map() \- extend() \- clone() \- data()
\- remove()

These methods are used throughout the 249 lines of code.

This makes weld.js completely dependent on jQuery. Thus, you _can't_ just use
whatever library you want. And that would be allright, if the README would say
that; but it didn't, and so it isn't.

~~~
hij1nx
meh, we might remove jQuery next version.

------
soljin2000
<http://www.yuiblog.com/blog/2010/09/29/video-glass-node/> This video from
David Glass shows why this can be very powerful when code on the front end and
the backend. It's pretty straight forward. Check for content. If not generate
content. Attach behavior (skipped on the server). render out put (the branch
between the server and the front end).

There is an example using express and all kinds of cool business.

------
gcv
The Enlive system (for Clojure, see <https://github.com/cgrand/enlive>) does
something very similar.

~~~
draegtun
Yes its nothing new. You can find lots of modules/libraries that have been
around for quite that do same/similar things.

Here is a list which was put together & called "Push style template systems"
which covers some of these modules/libraries (in different languages):
<http://www.perlmonks.org/?node_id=674225>

------
jlsync
My attempt at the same idea using jquery:
<https://github.com/jlsync/jlt/blob/master/jlt.js>

Anyone have any pointers to other/better similar solutions?

------
meikeric
Good stuff!

