Bearing in mind this is for classic asp
Which is better, all HTML contained within Response.Write Statements or inserting variables into HTML via &l
If you are required to write and maintain a Classic ASP application you should check out the free KudzuASP template engine.
It is capable of 100% code and HTML separation and allows for conditional content, variable substitution, template level control of the original asp page. If-Then-Else, Try-Catch-Finally, Switch-Case, and other structural tags are available as well as custom tags based in the asp page or in dynamically loadable libraries (asp code files) Structural tags can be embedded within other structural tags to any desired level.
Custom tags and tag libraries are easy to write and can be included at the asp page's code level or by using an include tag at the template level.
Master pages can be written by invoking a template engine at the master page level and leveraging a second child template engine for any internal content.
In KudzuASP your asp page contains only code, creates the template engine, sets up initial conditions and invokes the template. The template contains HTML layout. Once the asp page invokes the template it then becomes an event driven resource fully driven by the evaluation of the template and the structure that it contains.
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. :)
<%= %>
and the rest get expanded to Response.Write()
so it's the same in the end.
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.
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.
There is no performance improvement switching to Response.Write, and it can be faster to read and maintain using the shortcut notation.