Hacker News new | past | comments | ask | show | jobs | submit login

The Globalization sounds like a good idea. However the template library scares me. There are so many different template use cases in JS that having one ordained jquery one seems like it might have to be too many things to too many people.



JavaScript templating may sound scary, but if done properly they can be so ridiculously powerful that at this point I think it's inevitable that server-side generation of HTML will eventually be obsolete.

Imagine being able to throw away all the hideous and incompatible JSP, eRuby, PHP (smarty etc), and Django templates with a universal template language.


With respect, I think it's naive to think that the lastest templating language will be the "universal" one. No, this is just one more JS templating language.

http://yehudakatz.com/2010/09/09/announcing-handlebars-js/ http://code.google.com/p/trimpath/wiki/JavaScriptTemplates http://code.google.com/p/jstal/ http://github.com/janl/mustache.js


Technically there's nothing preventing universal server-side templating language (e.g. XSLT & TAL are available for all languages you've mentioned). It's just a matter of everyone agreeing on syntax — and that's the hard part.


You can't just agree on syntax, IMHO the reason for that is the best template languages have the full language available. You need a full-language for a great template language. Smarty, for instance, sucks. HAML, which is terse, but has access to the full syntax of ruby rocks. You can do things like:

  = @users.map {|u| sprintf("%04d: %s",u.id, u.status.capitalize)}.join(', ')
Sure there's some special operator is smarty to do this, but I don't want to have to learn it, and they're always more clunky.

Additionally, I always hit complex, weird situations where I need a full-language, and migrating that logic out of the view makes no sense. For instance, I was working on a site where I had repeating content, with ads at predetermined offsets. I rendered it something like:

  ads_positions = Set.new(2,8,10,12)
  content.each_with_index do |content,i|
    if ad_positions.include?(i)
      content
      ad
    else
      content
    end
  end
I hate expressing that stuff server-side or in half-baked templating languages.


Though we've got nigh-universal bidirectional communication: JSON. That makes JS templating systems server-agnostic, where server-side templates need the server to run more software to render your templates.


Javascript templating isn't really scary. I've used two different engines in the last few months. That's not my concern. More it's that the syntax needed for a small template is going to be very different from a full js application. And both of those are going to be different from a server side node.js template.

Having options is a good thing, and I worry that jQuery with it's dominate position could become the defacto standard even if it is not the best choice for all projects.


How exactly are Django templates hideous?


I didn't single Django out, I think all server-side template languages are hideos and largely unnecessary. JavaScript templates, with some work, can be better in a lot of ways.


Well I can understand why you think some templating languages are hideous, because they definitely are. Many are overly verbose.

I've definitely enjoyed a few though, Django's being one of them.

I think Javascript templating is great, and it's certainly helpful in many ways, but it could never flat-out replace server-side template engines for me. In Django for example, you almost always pass whole ORM objects to the template. On someone's page of a list of friends, I'd loop through a collection of User objects and generate an html list of usernames and permalinks to their profile pages. If I passed the whole collection of User objects to the client they'd get access to a lot of sensitive information. Which would require me to white-list at the ORM level exactly what fields I might need ahead of time. That might work, but I'd always be worried that I didn't clean the objects sent to the client's JS template enough for every page I'm writing.

Unless of course you were going for the idea that we'll be using one universal templating language both for the front-end JS as well as on the back-end in something like node. In which case disregard everything I just wrote.


It won't degrade gracefully for those who turn off javascript or don't have it. Putting more and more things into javascript may be in vogue but it doesn't seem any better than the solutions we already have.


Yep, definitely another reason not to leave the entire template render to Javascript.


Have you used HAML? Not hideous at all - in fact, less work and more elegance than straight-up HTML (not that that ought to be hard!)




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: