Friday, May 07, 2010

On jQuery templating

.. isn't it just shifting functionality around?

Eventhough jQuery templating is a pretty interesting concept and I feel tempted to use it, I can not stop thinking that it does not help to simplify my code.

I develop in ASP.NET mainly and do construct all the controls by hand, meaning that I first decide what my HTML will look like and then let the control render exactly that markup.

All right, all right

Arguably, I can do that with jQuery templating equally well. But I will be forced to rebuild the ViewState principle of ASP.NET in order to make changes come back to the server. I must call web services to get the data. Meaning that for each form I must have a specific web service. That is quite a bit of work.

Also I would be doing a lot of coding in JavaScript and in C# and I ike to keep as much functionality as possible in my main development language. Just to avoid confusion.

Concluding

Then again, I may have missed some stuff and maybe things can be done that I do not see yet. It's still early in the jQuery templating model and things are bound to change. I will wait and see what comes up next in this area.
For now, I will stick with my MVC inspired, Mediator based framework.

In reference to: A few thoughts on jQuery templating with jQuery.tmpl | Encosia (view on Google Sidewiki)

Related articles by Zemanta
Reblog this post [with Zemanta]
Written by Unknown on 5/07/2010 11:55:00 AM
Labels: , , ,

2 comments:

  1. Dave Ward12/5/10 04:02

    Hi Roho,

    You're right that it's conceptually very similar to a chunk of templated markup on the server-side, perhaps an ASCX user control or Repeater/ListView template. The advantage is performance.

    A client-side template can be rendered and re-rendered extremely quickly, given only a bit of JSON data. Take a look at this post, for example.

    If you deploy that to a server (testing this locally is deceiving) and compare it to any server-centric rendering model, you should find that the client-side templating is at least one order of magnitude faster.

    Does that performance justify its implementation cost in every situation? Definitely not. It's just another tool to your disposal if you find yourself needing interactivity/speed that approaches a desktop application.

    ReplyDelete
  2. Unknown12/5/10 08:02

    Hi Dave,

    Thanks for the comment. I agree that speed can be a good reason to implement this technology. I have a project right now that does use an UpdatePanel and a GridView and paging ...
    I can see the benefit, but apart from just showing data the application also needs to react to clicking on columns and cells. This is easily done in the server side EventHandlers, but could be a bit trickier when calling from the client.

    It would mean exposing some of the functionality to the outside world (there has to be JavaScript call to a webservice or something) and that will have some security implications.

    So, there is definitely a speed benefit, but it could come at some security cost. Right now in the project I am involved that is not an option.

    But your comment once again has me thinking, which is always good.

    Thanks once again.

    ReplyDelete

Thanks for you comment. I will probably have to moderate it, so it could take some time to see it appear on the blog, but I am usually quite fast at that.

When I feel that you are commenting just to get some link spam to your own site,you will probably never see it appear ..

Subscribe to: Post Comments (Atom)