Best practices for developing simple ASP.NET sites (built in controls or JQuery + scripts)

Question

I was recently reviewing some code written by two different contractors, both were basic ASP.NET management sites. The sites allowed the user to view and edit data. Pretty much simple CRUD gateways.

One group did their best to use built in ASP + AJAX Toolkit controls and did their best to use as many built in controls as possible. It pretty much was in line with most of the asp dev i havhe seen. I found the code much easier to read and maintain.

The other used jQuery and the code is heavily marked up with script blocks which are then used to build pages from javascript files.

Example Script block:

  <script id="HRPanel" type="text/html">
   <table cellpadding='0' cellspacing='0' class="atable"><thead class="mHeader"><tr><th>Name</th><th>Description</th><th>Other</th></thead><tbody>
  <# for(var i=0; i < hrRows.length; i++) {         
      var r = HRRows[i]; #>
        <tr><td><#=r.Name#></td><td><#=r.Description#></td><td class="taRight"><#=r.Other#></td></tr>
  <#}#>
   </tbody><tfoot><th></th><th></th><th></th></tfoot></table>
    </script>

Then in a separate location (js file) you would see something like this.

 $("#HRPanel").html($("#HRPanel").parseTemplate({ HRRows: response.something.bah.bah }));

And in the js files you will just a bunch of toggling and manipulating of html code. There was no code in the aspx files except for blocks containing html markup.

Which one is more common? The one that basically leveraged embedded HTML markup in scripts controled by javascript files screams readability and maintenance issues?

Secondly what type of issues fall out of the second way? Do people really use code like that in real production environments? Are there tools that help facilitate jQuery development with visual studio, and/or is this a practice that Microsoft is going to make more streamline in the future?

Answer 1

to answer one of your questions, one tool to facilitate jQuery development with visual studio is jquery intellisense

Answer 2

<Assuming_the_Worst> The use of Javascript templates to build important portions of the site without a fallback definitely counts as an accessibility problem. (This may be a non-issue, depending on where the website was deployed).

It poses a maintenance problem too, inasmuch as any new developer who starts working on it has to learn the syntax, quirks, and problems with the Javascript templating system they used in order to work on site (I'm assuming that they're hitting web services to create, update, and delete data). </Assuming_the_Worst>

I'm afraid my work experience is not yet far-ranging enough to say if this is a common method of developing in ASP.NET with jQuery. I do hope not though.

EDIT: As Daniel points out, there are much better ways built into ASP.NET that they could be using here, so unless this was done to solve a very particular business need, they were probably suffering from a case of BWIKTBI (Best Way I Know To Build It) and you're best off assuming the worst.

Answer 3

My answer is use a mix of both. Use each where appropriate.

That has got to be one of the ugliest uses of JQuery that I have seen. In this case a standard repeater looks like a good option. It is good for adding elements to your page in a repeatable fashion.

This scenario would be handled really well with the JQGrid plugin, which allows you to update the contents of the table with JSON data or XML. It is a lot simpler than the code that you posted. My recommendation is that you spend the time to prototype both approaches. Then look at the complexity and extensibility of both. How easy is it to add a column to your table for example? How easy is it to add paging?

Microsoft have included JQuery as default scripts in its MVC templates. Why? Because JQuery is becoming recognised in the industry as game-changing. It has drastically reduced the code required to identify and work with elements in the DOM and it has almost completely removed the need for browser-specific javascripts and browser version testing.

JQuery is really good for adding behaviour to your pages on the client side, such as menus for example. It is also very useful for things like client side validation ( a lot lighter in terms of the javascript sent to the page than the standard validation controls).

JQuery works really well when you have well defined CSS. When you understand how powerful the seclectors are, you can write some very powerful JQuery behaviour with amazingly terse code. Look at some good examples here:

http://attardi.org/labels/#info

http://net.tutsplus.com/articles/web-roundups/the-20-most-practical-and-creative-uses-of-jquery/

I'll add some more after work. :)

Answer 4

As you've said ASP + AJAX Toolkit produces code that is easy to understand and maintain. However, it does restrict you to what the built-in controls offer and in some cases it may not be so effective.

jQuery and web services are widely used for production web sites. Especially for ASP.NET MVC sites, it is the endorsed way to go. I personally don't like the idea of the script blocks. This isn't the only way to go with jQuery though. You can have a regular ASP.NET web page and use jQuery widgets for rich controls. For AJAX functionality you would need AJAX enabled WCF services. These would be much more effective than using Update Panels.

Answer 5

Most ASP.NET controls produce really crappy html code, using tables with wild uninhibited abandon, it is shameful really. That poorly generated html is an accessibility concern if you are looking to making handicap friendly sites or (IMO) use css effectively. I've also run into instances where the generated html causes problems with things like the data import from web in Excel. You can use something like the CSS Friendly adapter (http://www.asp.net/cssadapters/) or even your write your own adapters if you want to alleviate much of this particular issue (most don't though). ListView is a nice addition in .NET 3.5 that gives the developer much better control over the rendered html.

I agree with others that the use of script blocks is less than ideal. My preference would be to be to use unobtrusive scripting, which would then just have the html elements as placeholders (no script tags other than the import of the js file).