3 ms·

Not trying to pick on this particular project because it seems cool enough, but, I don't get all this html templating. With ajax and websockets on the way, why

Not trying to pick on this particular project because it seems cool enough, but, I don't get all this html templating. With ajax and websockets on the way, why are we still generating html in the application? This all seems like a solution to a problem we should be leaving behind.

sgrove 16y ago
You're definitely right, actually. I've been working a lot in clojure, node.js, and html5 <canvas> recently on various projects (more posts later), and there's a definitely feeling of reinventing the wheel, and doing it poorly. That said, there are a ton of different approaches - At the oak.js meetup, I saw a sammy.js app embedded into couchdb. Definitely not my style, but a cool idea anyway. I'm very eager to get this into several html5 apps that are currently node.js or rails backends and for particular reasons would be well suited for a lisp backend. The goal is to tie in very closely with the html5 landscape, and drop a lot of the legacy stuff that other frameworks care about.
lemming 16y ago
on the way You said it - websockets aren't here yet. Plus I think there are still plenty of good applications for static HTML. For starters, even full AJAX apps should work without JS enabled if you care about accessibility.
- ekidd 16y ago
  For starters, even full AJAX apps should work without JS enabled if you care about accessibility. This should be just about possible using Node.js these days: You can run your entire client-side templating system—and even the <canvas>—on the server, and then server static HTML and PNGs to the browser. Unfortunately, quite a bit of elbow grease is still required.
  - lemming 16y ago
    But my point is - you're still templating. The only thing you're gaining is using the same language on the client and the server. I'm not saying that's a small thing, but the OP could have achieved the same using parenscript. The GP seemed to be implying that we should only generate our HTML programatically on the client. Thinking about it more, I don't agree with this. I don't write webapps these days, but in our platform we do a lot of code generation. We use a programmatic method to do this because we have to manipulate the intermediate representation a lot - add or remove fields added by earlier phases in the generation etc. This is much more flexible but it's much harder to maintain, and looking at the code generation code it's very hard to see what the end result will be. If we were simply generating code in a single pass I'd definitely use templating, it's just much simpler, easier to develop, and easier to see what the end result will be. Add in the need with HTML to work with designers and I think templating will be with us for some time to come.
_dan 16y ago
Because you have to hit the server initially. While you could totally serve some JS, JSON data and a small HTML wrapper to kickstart the client-side code, just generating the page is a lot simpler and typically more efficient. Then you have all the problems of a purely client-side application (dealing with deep-linking, bookmarks, back buttons, users with exotic browsers, search engines, etc). That stuff can all be dealt with, but all dramatically increases the complexity. Your "Hello World" quickly becomes complex and unwieldy. I personally think the right way is probably a templating engine that can work either client- or server-side so you can generate whatever you need wherever you are.
_delirium 16y ago
I guess I don't see a reason not to generate it on the server. I have a section of my website with some essays, for example, which are formatted from Markdown source plus a bit of HTML templating. The essays don't frequently change, and neither does the template. Why would I want to regenerate the page on the client side every time someone reads it instead of just generating it once and serving up static HTML?
Raphael 16y ago
So the AJAX request goes out, and what comes back? HTML or data? It will have to be turned into HTML either by the server or the client. And you need some logic for that. So there's really no escaping this.

sgrove 16y ago

You're definitely right, actually. I've been working a lot in clojure, node.js, and html5 <canvas> recently on various projects (more posts later), and there's a definitely feeling of reinventing the wheel, and doing it poorly. That said, there are a ton of different approaches - At the oak.js meetup, I saw a sammy.js app embedded into couchdb. Definitely not my style, but a cool idea anyway. I'm very eager to get this into several html5 apps that are currently node.js or rails backends and for particular reasons would be well suited for a lisp backend. The goal is to tie in very closely with the html5 landscape, and drop a lot of the legacy stuff that other frameworks care about.

lemming 16y ago

on the way You said it - websockets aren't here yet. Plus I think there are still plenty of good applications for static HTML. For starters, even full AJAX apps should work without JS enabled if you care about accessibility.

ekidd 16y ago
For starters, even full AJAX apps should work without JS enabled if you care about accessibility. This should be just about possible using Node.js these days: You can run your entire client-side templating system—and even the <canvas>—on the server, and then server static HTML and PNGs to the browser. Unfortunately, quite a bit of elbow grease is still required.
- lemming 16y ago
  But my point is - you're still templating. The only thing you're gaining is using the same language on the client and the server. I'm not saying that's a small thing, but the OP could have achieved the same using parenscript. The GP seemed to be implying that we should only generate our HTML programatically on the client. Thinking about it more, I don't agree with this. I don't write webapps these days, but in our platform we do a lot of code generation. We use a programmatic method to do this because we have to manipulate the intermediate representation a lot - add or remove fields added by earlier phases in the generation etc. This is much more flexible but it's much harder to maintain, and looking at the code generation code it's very hard to see what the end result will be. If we were simply generating code in a single pass I'd definitely use templating, it's just much simpler, easier to develop, and easier to see what the end result will be. Add in the need with HTML to work with designers and I think templating will be with us for some time to come.

_dan 16y ago

Because you have to hit the server initially. While you could totally serve some JS, JSON data and a small HTML wrapper to kickstart the client-side code, just generating the page is a lot simpler and typically more efficient. Then you have all the problems of a purely client-side application (dealing with deep-linking, bookmarks, back buttons, users with exotic browsers, search engines, etc). That stuff can all be dealt with, but all dramatically increases the complexity. Your "Hello World" quickly becomes complex and unwieldy. I personally think the right way is probably a templating engine that can work either client- or server-side so you can generate whatever you need wherever you are.

_delirium 16y ago

I guess I don't see a reason not to generate it on the server. I have a section of my website with some essays, for example, which are formatted from Markdown source plus a bit of HTML templating. The essays don't frequently change, and neither does the template. Why would I want to regenerate the page on the client side every time someone reads it instead of just generating it once and serving up static HTML?

Raphael 16y ago

So the AJAX request goes out, and what comes back? HTML or data? It will have to be turned into HTML either by the server or the client. And you need some logic for that. So there's really no escaping this.