Response.Write vs <%= %>

Bearing in mind this is for classic asp

Which is better, all HTML contained within Response.Write Statements or inserting variables into HTML via <%= %>.
Eg

Response.Write "<table>" & vbCrlf
Response.Write "<tr>" &vbCrLf
Response.Write "<td class=""someClass"">" & someVariable & "</td>" & vbCrLf
Response.Write "</tr>" & vbCrLf
Response.Write "</table>" & vbCrLf

VS

<table>
  <tr>
     <td class="someClass"><%= someVariable %></td>
  </tr>
</table>

I am mainly asking from a performance point of view in which will have the least server impact when there multiple variables to insert?

If there are no technical differences what are the arguments for one over the other?

From stackoverflow Jon P

• From a personal preference point of view I prefer the <%= %> method as I feel it provides a better separation variable content from static content.

  Noah Goodrich : Presentation logic should always be separated from the business logic. Keep the logic in the HTML template restricted to simple loops and conditionals and you'll find that your code will be easier to maintain.

  Jon P : Could not agree more gabriel
  From Jon P

• <%= %> and the rest get expanded to Response.Write() so it's the same in the end.

  From Mark Cidade

• There is no performance improvement switching to Response.Write, and it can be faster to read and maintain using the shortcut notation.

  From Cade Roux

• You should frame this questions in terms of code reuse and code maintainability (aka readability). There is really no performance gain either way.

  From Jason Jackson

• The response format will render HTML like so:

  <table>
  <tr>
  <td class="someClass">variable value</td>
  </tr>
  </table>
  

  As a result, not only will the means to produce your code be unreadable, but the result will also be tabbed inappropriately. Stick with the other option.

  From Russell Myers

• First, The most important factor you should be looking at is ease of maintenance. You could buy a server farm with the money and time you would otherwise waste by having to decipher a messy web site to maintain it.

  In any case, it doesn't matter. At the end of the day, all ASP does is just execute a script! The ASP parser takes the page, and transforms <%= expression %> into direct script calls, and every contiguous block of HTML becomes one giant call to Response.Write. The resulting script is cached and reused unless the page changes on disk, which causes the cached script to be recalculated.

  Now, too much use of <%= %> leads to the modern version of "spaghetti code": the dreaded "Tag soup". You won't be able to make heads or tails of the logic. On the other hand, too much use of Response.Write means you will never be able to see the page at all until it renders. Use <%= %> when appropriate to get the best of both worlds.

  My first rule is to pay attention at the proportion of "variable text" to "static text".

  If you have just a few places with variable text to replace, the <%= %> syntax is very compact and readable. However, as the <%= %> start to accumulate, they obscure more and more of the HTML and at the same time the HTML obscures more and more of your logic. As a general rule, once you start taking about loops, you need to stop and switch to Response.Write`.

  There aren't many other hard and fast rules. You need to decide for your particular page (or section of the page) which one is more important, or naturally harder to understand, or easier to break: your logic or your HTML? It's usually one or the other (I've seen hundreds of cases of both)

  If you logic is more critical, you should weight more towards Response.Write; it will make the logic stand out. If you HTML is more critical, favor <%= %>, which will make the page structure more visible.

  Sometimes I've had to write both versions and compare them side-by-side to decide which one is more readable; it's a last resort, but do it while the code is fresh in your mind and you will be glad three months later when you have to make changes.

  From Euro Micelli

• <%=Bazify()%> is useful when you are generating HTML from a short expression inline with some HTML.

  Response.Write "foo" is better when you need to do some HTML inline with a lot of code.

  Technically, they are the same.

  Speaking about your example, though, the Response.Write code does a lot of string concatenation with &, which is very slow in VBScript. Also, like Russell Myers said, it's not tabbed the same way as your other code, which might be unintentional.

  From Jacob

• I prefer the <%= %> method in most situations for several reasons.

  1. The HTML is exposed to the IDE so that it can be processed giving you tooltips, tag closing, etc.
  2. Maintaining indentation in the output HTML is easier which can be very helpful with reworking layout.
  3. New lines without appending vbCrLf on everything and again for reviewing output source.
  From ManiacZX

• I prefer <%= %> solely because it makes Javascript development easier. You can write code that references your controls like this

  var myControl = document.getElementById('<%= myControl.ClientID %>');
  

  I can then use that control any way I'd like in my javascript code without having to worry about the hard coded IDs.

  Response.Write can break some ASP.NET AJAX code on some occasions so I try to avoid it unless using it for rendering specific things in custom controls.

  From Dan Herbert

• Leaving aside issues of code readibility/maintainibility which others have addressed, your question was specifically about performance when you have multiple variables to insert - so I assume you're going to be repeating something like your code fragment multiple times. In that case, you should get the best performance by using a single Response.Write without concatenating all of the newlines:

  Response.Write "<table><tr><td class=""someClass"">" & someVar & "</td></tr></table>"
  

  The browser doesn't need the newlines or the tabs or any other pretty formatting to parse the HTML. If you're going for performance, you can remove all of these. You'll also make your HTML output smaller, which will give you faster page load times.

  In the case of a single variable, it doesn't really make a lot of difference. But for multiple variables, you want to minimise the context switching between HTML and ASP - you'll take a hit for every jump from one to the other.

  To help with readibility when building a longer statement, you can use the VBScript line continuation charcter and tabs in your source code (but not the output) to represent the structure without hitting your performance:

  Response.Write "<table>" _
          & "<tr>" _
              & "<td class=""someClass"">" & someVar & "</td>" _
          & "</tr>" _
          & "<tr>" _
              & "<td class=""anotherClass"">" & anotherVar & "</td>" _
          & "</tr>" _
          & "<tr>" _
              & "<td class=""etc"">" & andSoOn & "</td>" _
          & "</tr>" _
      & "</table>"
  

  It's not as legible as the HTML version but if you're dropping a lot of variables into the output (ie a lot of context switching between HTML and ASP), you'll see better performance.

  Whether the performance gains are worth it or whether you would be better off scaling your hardware is a separate question - and, of course, it's not always an option.

  Update: see tips 14 and 15 in this MSDN article by Len Cardinal for information on improving performance with Response.Buffer and avoiding context switching: http://msdn.microsoft.com/en-us/library/ms972335.aspx#asptips_topic15.

  From Simon Forrest

• I try to use the MVC paradigm when doing ASP/PHP. It makes things easiest to maintain, re-architect, expand upon. In that regard, I tend to have a page that represents the model. It's mostly VB/PHP and sets vars for later use in the view. It also generates hunks of HTML when looping for later inclusion in the view. Then I have a page that represents the view. That's mostly HTML peppered with <%= %> tags. The model is #include -d in the view and away you go. Controller logic is typically done in JavaScript in a third page or server-side.

  From Jason Dufair

• Many of the answers here indicate that the two approaches produce the same output and that the choice is one of coding style and performance. Its seems its believed that static content outside of <% %> becomes a single Response.Write.

  However it would be more accurate to say the code outside <% %> gets sent with BinaryWrite.

  Response.Write takes a Unicode string and encodes it to the current Response.CodePage before placing it in the buffer. No such encoding takes place for the static content in an ASP file. The characters outside <% %> are dumped verbatim byte for byte into the buffer.

  Hence where the Response.CodePage is different than the CodePage that was used to save the ASP file the results of the two approaches may differ.

  For example lets say I have this content saved in a standard 1252 code page:-

  <%
       Response.CodePage = 65001
       Response.CharSet = "UTF-8"
   %>
  <p> The British £</p>
  <%Response.Write("<p> The British £</p>")%>
  

  The first paragraph is garbled, since the £ will not be sent using UTF-8 encoding, the second is fine because the Unicode string supplied is encoded to UTF-8.

  Hence from a perfomance point of view using static content is preferable since it doesn't need encoding but care is needed if the saved code page differs from the output codepage. For this reason I prefer to save as UTF-8, include <%@ codepage=65001 and set Response.Charset = "UTF-8".

  From AnthonyWJones

• I agree with Jason, more so now that .NET is offering an MVC framework as an alternative to that awful Web Form/Postback/ViewState .NET started out with.

  Maybe it's because I was old-school classic ASP/HTML/JavaScript and not a VB desktop application programmer that caused me to just not grokk "The Way of the Web Form?" but I'm so pleased we seem to be going full circle and back to a methodology like Jason refers to.

  With that in mind, I'd always choose an included page containing your model/logic and <%= %> tokens within your, effectively template HTML "view." Your HTML will be more "readable" and your logic separated as much as classic ASP allows; you're killing a couple of birds with that stone.

  From Sprogz

• My classic ASP is rusty, but:

  Response.Write "<table>" & vbCrlf
  Response.Write "<tr>" &vbCrLf
  Response.Write "<tdclass=""someClass"">" & someVariable & "</td>" & vbCrLf 
  Response.Write "</tr>" & vbCrLf 
  Response.Write "</table>" & vbCrLf
  

  this is run as-is. This, however:

  <table>
    <tr>
       <td class="someClass"><%= someVariable %></td>
    </tr>
  </table>
  

  results in:

  Response.Write"<table>\r\n<tr>\r\n<td class="someClass">"
  Response.Write someVariable
  Response.Write "</td>\r\n</tr>\r\n</table>"
  

  Where \r\n is a vbCrLf

  So technically, the second one is quicker. HOWEVER, the difference would be measured in single milliseconds, so I wouldn't worry about it. I'd be more concerned that the top one is pretty much unmaintainable (esp by a HTML-UI developer), where as the second one is trivial to maintain.

  props to @Euro Micelli - maintenance is the key (which is also why languages like Ruby, Python, and in the past (tho still....) C# and Java kicked butt over C, C++ and Assembly- humans could maintain the code, which is way more important than shaving a few ms off a page load.

  Of course, C/C++ etc have their place.... but this isn't it. :)

  From Nic Wise