Is anyone like me?
I always use Response.Write() for everything:<BR><BR>Response.Write(<BR> '<HTML>'<BR> + '<HEAD>'<BR> + '<TITLE>My Page</TITLE>'<BR><BR>Etc. etc. etc.<BR><BR> + '</BODY>'<BR> + '</HTML>'<BR> );<BR><BR>The reasons for this is its faster for the script to execute and download. I can see perfectly spaced out and formatted HTML but my visitors can't and it puts less strain on the server. Does anyone else do this?<BR><BR>To read in more detail about my reasons for doing this, read an article by James Shaw at CYA: http://www.coveryourasp.com/DontRender.asp
James Shaw is wrong...
That *used* to be true. But in a much more limited way than James Shaw understood. And with IIS 5, the pendulum has swung the other way completely.<BR><BR>Extensive tests have shown that writing your code straightforward, using HTML when appropriate and ASP when appropriate, is more efficient. And by a moderately significant margin.<BR><BR>There are several reasons for this:<BR><BR>(1) The process of going "into and out of" ASP mode has become much less expensive. MS significantly improved the performance of Response.Write'ing of small chunks of data. Simply turning on buffering even in IIS 4 would typically produce ties between the two techniques.<BR><BR>(2) String concatenation is *NOT* free! In fact, it's pretty darned expensive. In this code:<BR>Response.Write(<BR>'<HTML> '<BR>+ '<HEAD>'<BR>+ '<TITLE>My Page</TITLE>'<BR>+ '<BODY>'<BR>+ '</BODY>'<BR>+ '</HTML>'<BR>);<BR>You have created 6 temporary strings that then have to be destroyed and garbage collected. And each string is longer than the previous one. Not really a big deal when the total length is under a couple of hundred bytes, but if you get strings up in the thousands of bytes this can be *very* time consuming.<BR><BR>(3) Letting ASP manage long strings of HTML for you is actually *obviously* better, if you stop to think about it.<BR><BR>When ASP sees this:<BR><BR><HTML><BR><BODY>< BR><HEAD><BR><TITLE>xxx</TITLE><BR></HEAD><BR><%= xyz %><BR><BR>It *actually* generates *this* code for JS (or VBS) to process:<BR><BR>Response.Write("<HTML>
");<BR>Response.Write( xxx );<BR><BR>In other words, ASP is *already* doing a better job of collecting multiple lines of HTML that *YOU* are! Because it allows you to write your HTML in "pretty" fashion and then turns *all* adjacent HTML into a *single* long block write, which is ugly JS/VBS code but produces HTML in the output that remains as pretty as your original.<BR><BR>***********************<BR><BR>In summary, I think you are dead wrong on all counts. Sorry.<BR><BR>*******************<BR>p.s.:<BR><BR> Incidentally, how come no
's in your code, so that the HTML in the browser is readable? Two points against you for that, in my debugging book. In other words, I think that, if you chose your route, you should have written:<BR>Response.Write(<BR>'<HTML� 62;
'<BR>+ '<TITLE>My Page</TITLE>
RE: James Shaw is wrong...!!
Hi Guys, I thought I ought to chime in at this point since my article was just ripped to shreds. ;-)<BR><BR>It is true that many people have written that there are no performance gains anymore from using Response.Write all the time. I've not tested it personally, but Scott Mitchell published an article recently that was persuasive.<BR><BR>But that's not the only reason I do it.<BR><BR>First, I don't concatenate code or recommend doing so. I simply Response.Write HTML strings. I don't use any of these "helpful" editors so don't lose any design speed or functionality from this. <BR><BR>Second, DO NOT use
or output HTML comments - how ridiculous that the latter even exist! Who looks at the HTML? Debugging? PAH! Who has to debug their HTML? If there's a problem a validator will find it.<BR><BR>I want pages that load at quickly as possible, as should you all. Look at most sites HTML and it sucks. The user frequently ends up downloading 3-4 times the bytes that he needs to. The rest is whitespace and comments - don't get me started on "webbots".<BR><BR>You can read other readers feedback to my original article at http://www.coveryourasp.com/RenderFeedback.asp - quite interesting...
Sorry, but I still disagree...
You ask: Who reads HTML???<BR><BR>I say: Any ASP author who doesn't have the ability to do server-side script debugging. And many who do.<BR><BR>Some ASP code generates a bunch of HTML and something goes wrong. How do you figure out what? You go do a "VIEW | SOURCE" on the HTML, of course. And if that HTML is unreadable, then it just takes you that much longer to find the problem.<BR><BR>And a validator won't do you a damned bit of good, because you never reached the end of the generated HTML in the first place, so of course the HTML is bogus.<BR><BR>If you are able to write ASP code so well that you never need to debug in this fashion...well, my hat is off to you.<BR><BR>And while I might admit your points about not wasting time sending spaces and comments (and to be fair I virtually never use HTML comments....but I use tons of ASP comments) on a busy site...well, the truth is that the typical person posting in these forums isn't working on any busy site, and debugging and maintenance are much more important than saving a few hundred bytes of data transfer. (I'll certainly concede the point of your 10-to-1 example, but I don't believe it comes close to being typical.)<BR><BR>I firmly believe that *THE* most important aspect of producing commercial software is producing *MAINTAINABLE* software. You may be the god of programming and able to debug your own code, no matter how obscure, 37 months from now. But along comes somebody who offers you more money and now some poor schmuck who learned programming two weeks ago because his job in graphic design petered out is stuck trying to read and fix or change your code. Personally, I'd fire you if you wrote unreadable code, no matter how good it is and how cleverly it was written.<BR><BR>Is there ever a time when performance is more important than maintainability? Sure. On a (relative) handful of sites for at least some of their pages. And then it's time to bring the guns to bear and find ways to eke out every last performance nanosecond you can find. But even then I'd like to see you *start* from a basis of a "clean" page and then apply some sort of mechanical filter, if possible, rather than writing obscure code to begin with. (Of course, I could also point out that if a page is that performance critical then ASP may not be the best vehicle to use in creating it. I like VBScript and JScript, but I also recognize that they are literally orders of magnitude slower than various other possible techniques. And, of course, .NET is one way of acknowledging that fact.)<BR><BR>Well, enough. Patently James Shaw and I will continue to disagree. Fair enough. <BR><BR>[Hmmm...we might agree that Webbots and program generators generate ugly and big HTML...I wasn't even thinking in that direction as I write all my ASP by hand.]<BR><BR>One last parting shot: It doesn't do a lot of good to work really hard to save bytes in your HTML by eliminating spaces, etc., if you then load up your page with (BY ACTUAL COUNT!) **FORTY IMAGES**. After all, *each* image means *another* HTTP round-trip request from browser to server. A heluva lot more overhead than a few extra spaces or newlines tucked into the HTML would add. Yes, those **FORTY IMAGES** are on http://www.coveryourasp.com/RenderFeedback.asp !!!<BR> <BR>
I can't say that I know who you are and I won't begin to berate your programming abilities but thats a far off that mark statement to make<BR><BR>>>Who looks at the HTML? Debugging? PAH! Who has to debug their HTML? <BR><BR>Even the best programmers can screw up the html when you have tables inside of tables an rowspaning and colspaning all over the page, there was one occasion that I wrote a page like that and when I opened it in NS guess what no page in the browser.<BR>and it was all because of 1 missing </table> tag<BR>and even with nice neat readable html code it took me about an hour to figure it out.<BR><BR>I probably would still be trying if I couldn't read the code through view source.
Applause for Steve...
...of course, it doesn't hurt that he agrees with me <silly-assed-grin />.<BR><BR>
You have to admit...
That was a pretty rediculous staement to make, he was looking for trouble with that.<BR><BR>And besides you have shown me the error in my way on more than 1 occasion, so hows MS treating you these days anyhow?
You guys! This is fun!<BR><BR>I do remember having to look through HTML source once. Ok, I admit it, it was hard. But regularly? No. Normally I can see from the indentation where HTML has gone wrong. I'm surprised you can't. <BR><BR>And as for the ***shock, horror!!*** 40 images argument, well that's just petty. As you well know the user doesn't have to wait for those to arrive before reading the page, and certainly doesn't negate the reason for stripping out unnecessary HTML. <BR><BR>It's obvious that Bill rules the roost here, so I'll go back over to the forums that I help on and we'll just leave it at that. <BR><BR>P.S. C# rules. ;-)
I just think that the not looking at the html code statement was a bit over the wall, I would be willing to bet that at least (I will go low) 50% of the people that develop webpages use the view source to check thier code on a daily basis and the other half at least some time during development.<BR><BR>It hit me as a bit of an of an insult to developers so you should expect soem kinda response. its kinda like walking into a gun compatition and saying <BR><BR>!well the way I see it is if you need to look down the site to hit the target you need more practice.<BR><BR>viewing the html code is just kinda standard practice to verify the results of what you are doing.<BR><BR>And as for Bill ruling the roost, well he's cool and he don't let you get away with any crap. Hell hes been developing since computers began and has never made a said anything to my knowledge that he couldn't prove out
I've often wondered...
Why people are so concerned about microseconds, but use ASP? So the user downloads a few bytes... so what? Hammering away in JScript isn't helping the matter. We use some HTML comments also... it helps when you have a 3 different graphics people trying to merge 4 different projects into one page.<BR><BR>Bottom line is, if you need nanoseconds, you go more the ISAPI route, not the ASP route. We mix both, on a busy site (last quarter, 4 billion page views), so I don't see how there is one be all, end all solution.