I decided not to publish any names - if you recognise yourself drop me a line if you want to be named!

John.Q.Public: Your article makes sense. Especially because of the tremendous ASP execution speed difference in IIS 5. However your plan does create some design issues. I use ASPedit and it would really defeat all of the color coding that makes the code easier to debug. Maybe a mixed approach would make sense with comments included in the server side asp.

John.Q.Public: When I use DontRender I lose syntax highlighting =(

James: It's true I'm afraid - up to a point. You lose your HTML highlighting, but you still have the JavaScript highlighting. No-one's pointed this out yet, but most "helpful" editors will stop auto-completing your HTML too.

John.Q.Public: Hey James, I have to disagree with you on your article about ASP render blocks. First, if you enable buffering for your pages, which is the default for IIS 5, you don't have to worry as much about the constant switching back and forth between html and server side script. Calling response.write repeatedly is what takes a huge toll on performance, unless you have buffering enabled. With buffering, your data isn't written to the text stream until the page finishes being processed by the asp dll.

I use a modified approach. When looping, say through a recordset or an array, I build a string like you propose. However, all the other html is left as text in the page. This combined with buffering seems to give me the performance I need.

Second, writing all your code & html into a string and response.writing the string makes your page very difficult to maintain; for example, I can't load this page into InterDev or any other html wysiwyg tool. If I want to change a complex table, it will take me 10 times longer to sift through all my tr and td tags to find the right cell. By leaving my html as regular text inside my asp page, I'm able to open that page up in an editor and make changes in a fraction of the time.

OK, one more thing. With web farms as easy to set up as they are, it makes much more sense to handle scalability issues by scaling out rather than making my asp apps a nightmare to modify.

James: Thanks for the feedback John. I was hoping to hear from developers with more experience like it sounds you have. It's hard finding someone to bounce ideas off.

I got to this solution by trial and error and reading code and tips from "the pros". I wasn't aware that buffering negated the issue that has been described to me almost like "context switching". I just picked up from a ms article that they caused a performance hit when mixed. They didn't mention buffering.

I see what you mean by wysiwyg editors. Something else that I haven't thought of because I don't use one. I was burned by frontpage so badly that it'll be a while before I trust them again. The html generated was horrific and extremely inefficient. My brief foray into VI (Visual Interdev) wasn't enough to convince me, so now I use an editor that helps me edit, but doesn't "help" with the html.

One of my biggest reasons for doing what I do though, and I'm not sure I'm convinced enough yet to stop, is that the html generated is *much* smaller without whitespace, and hence the pages load quicker. Isn't that a worthy goal? My thought was that the html generated was more important than the efficiency of the server, because...

I'm not sure where asp caching plays a part in all this. I've read that the asp page is effectively compiled and cached on the server - even more so in asp+. I've assumed that this process means that my server script isn't being interpreted for every user, just the "compiled" page returned.

John.Q.Public: Dear James, What you said is practically correct. But you just tell me is it possible to write entire code with functions etc - everything in response.write(). I may include html it will be easier for us and avoids ambiguity. You tell me which one is better according to a programmer...

James: I think functions are far better - hence the article. You will get better output (i.e. no whitespace) and better control because you can share functions that contain common code. Not just at the high level like Header(), Footer() but at low level like GetRedFont() - which could output CSS class or <font> for older browsers.

For me I can see no benefit to using HTML, only drawbacks. Duplicate code everywhere, and inconsistency too - programmers writing HTML differently.

John.Q.Public: Yes, I agree with you about 90% on this one - but be warned! You will encounter major problems with <pre>...</pre> blocks if all whitespace is ripped out. I would suggest in most cases an intelligent ISAPI filter would be a much better idea. In this way, you'd be able to code raw HTML and/or ASP and have the whole lot indented to your hearts content and then the output had the unnecessary rubbish 'ripped' from it. I am using a similar idea at the moment in a JavaServer Pages environment where all output is being parsed by the absolutely wonderful HTML Tidy component (follow the links from http://www.w3c.org), where I can enforce my output to be 100% HTML or even XHTML compliant. Lovely!

John.Q.Public: Great Article. I've been championing those philosophies, but no one seems to listen. Glad to hear somebody else has the same ideas.

John.Q.Public: After reading through your attack on us feeble-minded render block users, ...[another subject]

PS. I'll work to mend my ways on this render blocks issue.

John.Q.Public: The information in the article is fairly basic and most developers should already have a simple understanding of efficient coding but it does still stir the mind into efficient behaviour - and there one or two points which are good to be reminded of.

John.Q.Public: I can't disagree with your logic behind not using render blocks however I still believe that unless you're creating the next amazon most rendering is ok. Besides that a user noted that your ASP Out function was inefficient because it repeatably calls Response.Write - he suggested building up a string(variant) and passing this to Response.Write at the end of the page. Bad Idea - MS warn about this methodology - repeatably adding to a string causes HUGE processor overheads, far more than is gained in just calling Response.Write.

And my personal favorite - the obligatory "angry person" left this review on ASPcode...

John.Q.Public: Talk about exaggeration. He claims to have been able to cut off 37kb from 40kb big file just by leaving out the spaces and comments. I find it hard to believe that he has been able to create such a big file... And security reasons! Bah humbug! I thought asp was executed serverside and html on the client, I don�t see how his way would be any faster.

James: Thanks for the feedback (!!) It's true that frontpage created a 40k file that I reduced by 37k. Can't find the file of course, but it was full of html comments containing "webbots" that frontpage was using for db access. The reason my suggestion would be faster is simple. Ill be sending fewer bytes from server to client, probably at 28k baud! You see?