views:

111

answers:

2

Should a browser based Feed Reader always use something on the client side, like Javascript?

UPDATE: I mean, specifically, for the Parsing of RSS. If you can offload it to the browser, it seems almost irresponsible to make your server do the work. Still, there are plenty of advantages in my particular situation to doing it server side. So I'm just wondering: is it blasphemy, do you think, to make your server do the parsing instead of jquery or the like?

A: 

meh, it depends :-P There's nothing wrong with a pure navigation/post based system that uses plain html and forms. There's also nothing wrong with sprinkling a little bit of ajax and other client-side features where appropriate. It all depends on what you need to support in terms of client.

Joel Martinez
Thanks. Let me clarify. I mean, specifically, for the Parsing of RSS. If you can offload it to the browser, it seems almost irresponsible to make your server do the work. Still, there are plenty of advantages in my particular situation to doing it server side. So I'm just wondering: is it blasphemy, do you think, to make your server do the parsing instead of jquery or the like?
oh, in that case, yes, I wholeheartedly support the parsing and querying of remote RSS data on the server. *my* main reason for doing so would actually be so I can cache the results for X amount of time so I don't have to hit the remote source quite so often :-)
Joel Martinez
Thanks. I thought it was standard to do in on the client, for performance reasons. Gareth pointed out that the standard actually is doing it on the server.
+1  A: 

Google Reader is one example of an RSS reader that parses the RSS on the server. I can't see any reason why you'd have to do that processing on the client

Gareth
That's great to know. Because of http://code.google.com/apis/ajaxfeeds/ I was under the impression that Google Reader also parsed on the client side.