5 ms·

Simplify templating with node.js, jsdom 0.2.0 and weld

47 points by indexzero 16y ago

meikeric 16y ago
Good stuff!
gcv 16y ago
The Enlive system (for Clojure, see https://github.com/cgrand/enlive https://github.com/cgrand/enlive) does something very similar.
- draegtun 16y ago
  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 http://www.perlmonks.org/?node_id=674225
- gregwebs 16y ago
  There is also PURE for javascript already. http://beebole.com/pure/ http://beebole.com/pure/
simonw 16y ago
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.
- boucher 16y ago
  I'd argue that this isn't really that dissimilar from most simple template engines. It's basically substituting class names for placeholder syntax, though with a bit less flexibility for things like repetitions or conditionals. Though I'd agree that I'd rather just use something like Mustache than this.
- tmpvar 16y ago
  How do you rationalize including logic in the markup?
  - simonw 16y ago
    Presentation logic requires logic. If a designer decides to display a bunch of items as three columns rather than two columns, or to switch the display for a single item vs a number of different items, that's presentation logic. Ideally it should go in the template, if that's where you've chosen to keep it. With Django, I often find myself writing view logic to support specific presentation tasks (regrouping items in a manner more complicated than Django's {% regroup %} template tag allows, for example). This used to bother me, but then I decided that pragmatism beats purity if you actually want to ship anything.
- webXL 16y ago
  I think he just wants to separate the presentation from the logic, which might be good when you don't trust designers re-jiggling things, and you want clean code. Plus, if you're working with a lot of AJAX, it's nice to be able to reproduce the presentation on the server the same way you do it on the client. I suppose keeping the two in sync can be difficult, which is why you probably would only want to render on the server on the initial page request.
- reddittor 16y ago
  I'd have to agree with you, for most traditional web applications. When you start to build single page applications with lots and lots of states ( that are bound to a DOM ), this approach actually can become favorable since your "presentation logic" is browser-side JavaScript. To my understanding, the server-side rendering aspect of this approach is really just an after-thought. You have your single page application, but you can still render a server-side snapshot of various UI states without requiring a browser. While I wouldn't necessarily dive straight into DOM-based templating, I think there is a lot of room for interesting improvements in this area. I'm glad to see JSDOM maturing.
soljin2000 16y ago
http://www.yuiblog.com/blog/2010/09/29/video-glass-node/ 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.
soljin2000 16y ago
http://www.yuiblog.com/blog/2010/09/29/video-glass-node/ 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.
jlsync 16y ago
My attempt at the same idea using jquery: https://github.com/jlsync/jlt/blob/master/jlt.js https://github.com/jlsync/jlt/blob/master/jlt.js Anyone have any pointers to other/better similar solutions?
georgecalm 16y ago
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 16y ago
  meh, we might remove jQuery next version.

47 points by indexzero 16y ago

Good stuff!

gcv 16y ago

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

draegtun 16y ago
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 http://www.perlmonks.org/?node_id=674225
gregwebs 16y ago
There is also PURE for javascript already. http://beebole.com/pure/ http://beebole.com/pure/

simonw 16y ago

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.

boucher 16y ago
I'd argue that this isn't really that dissimilar from most simple template engines. It's basically substituting class names for placeholder syntax, though with a bit less flexibility for things like repetitions or conditionals. Though I'd agree that I'd rather just use something like Mustache than this.
tmpvar 16y ago
How do you rationalize including logic in the markup?
- simonw 16y ago
  Presentation logic requires logic. If a designer decides to display a bunch of items as three columns rather than two columns, or to switch the display for a single item vs a number of different items, that's presentation logic. Ideally it should go in the template, if that's where you've chosen to keep it. With Django, I often find myself writing view logic to support specific presentation tasks (regrouping items in a manner more complicated than Django's {% regroup %} template tag allows, for example). This used to bother me, but then I decided that pragmatism beats purity if you actually want to ship anything.
webXL 16y ago
I think he just wants to separate the presentation from the logic, which might be good when you don't trust designers re-jiggling things, and you want clean code. Plus, if you're working with a lot of AJAX, it's nice to be able to reproduce the presentation on the server the same way you do it on the client. I suppose keeping the two in sync can be difficult, which is why you probably would only want to render on the server on the initial page request.
reddittor 16y ago
I'd have to agree with you, for most traditional web applications. When you start to build single page applications with lots and lots of states ( that are bound to a DOM ), this approach actually can become favorable since your "presentation logic" is browser-side JavaScript. To my understanding, the server-side rendering aspect of this approach is really just an after-thought. You have your single page application, but you can still render a server-side snapshot of various UI states without requiring a browser. While I wouldn't necessarily dive straight into DOM-based templating, I think there is a lot of room for interesting improvements in this area. I'm glad to see JSDOM maturing.

soljin2000 16y ago

http://www.yuiblog.com/blog/2010/09/29/video-glass-node/ 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.

soljin2000 16y ago

jlsync 16y ago

My attempt at the same idea using jquery: https://github.com/jlsync/jlt/blob/master/jlt.js https://github.com/jlsync/jlt/blob/master/jlt.js Anyone have any pointers to other/better similar solutions?

georgecalm 16y ago

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 16y ago
meh, we might remove jQuery next version.