Opinion Regarding Filtering of Content using JS

开发者_C百科I'm working on a project and there is some battle between how some JS filtering should be implemented and I would like to ask you guys some input on this.

Today we have this site that displays a long list of repeated entries of data and some JS filtering would be nice for the users to navigate through. The usual stuff: keyword, order, date, price, etc. The question is not the use of JS, which is obvious, but the origin of the data. One person defends that the HTML itself should be used and that the JS should parse through it making the user's desired filtering. Another person defends that we should use a JSON generated in the server, and that JSON should be the data's origin.

What you guys think on this? What are the pros and cons?

As a final request, I would like you to be the most informative as possible since your answers will be used and referenced for all us in the company. (Yes, that is how we trust you!:)

The right action is matter of taste and system architecture as well as utility.

I would go with dynamically generated pages with JS and JSON -- These days I think you can safely assume that most browsers has Javascript enabled -- however you may need to make provisions for crawler (GoogleBot, Bing, Ask etc) as they may not fully execute all JS and hence may not index the page if you do figure out some kind of exception for supporting those.

Using JS+JSON also means that you make your code work so that support for mobile diveces is done client side, without the webserver having to create anything special.

Doing DOM manipulation as the alternative would not be my best friend, as the logic of the page control and layout is split-up in two places -- partly in the View controller on the webserver, and partly in the JavaScript -- it is in my opinion better to have it in one place and have the view controller only generate JSON and server the root pages etc.

However this is a matter of taste, and im not sure that I would be able to say that there is one correct and best solution.

I think it's a lot cleaner if the data is delivered in JSON and then the presentation HTML or view of that data is generated from that JSON with javascript.

This fits the more classic style of keeping core data structures separate from views. In this manner you can generate all types of views without having to constantly munge/revise the way you store, access and manipulate the data. You can even build classes and methods to develop a clean interface on your data that is entirely independent of how that data is displayed.

The only issue I see with that is if the browser doesn't support javascript and that browser is a desired viewer. In that case, you have to include a default HTML version from the server that will obviously not be manipulated and the JSON will be ignored.

The middle ground is that you include both JSON and the "default", initial HTML view of that data in rendered HTML. The view comes up quickly and non-JS browsers can see something useful. But, then any future manipulation of the view (sorting, for example) uses the JSON data and generates a new clean view from the JSON data. No data is then ever "parsed" from the HTML view.

In larger projects, this also can facilitate the separation of presentation from data manipulation so different people may work on creating HTML views vs. manipulate the data (like sorting).

I would make the multiple ajax calls to the server and have it return the sorted/filtered data. If you server backend is fast than it won't be very taxing and you could even cache the data between requests.

If you only have 50-100 items than it would be reasonable to send it all to the client and have javascript sort and filter it.

Some considerations to help make the decision

• Is the information sensitive and unique? (this voids and benefit to caching in my first point)
• What is the most common request that will happen and are you optimizing for that?
• How much data is there? (tens of rows, hundreds, thousands, millions)?
• Does you site have to work with JavaScript turned off? (supporting older browsers?)
• Is your development team more comfortable doing this in the front-end or back-end?

The answer is that it depends on your situation.