At my previous job, our team architect was strongly against including any server side code in the markup, even simple ID's, so this code would not be allowed to get checked in:
<script>
var el = document.getElementByID('<% SomeElement.ClientID %>')
</script>
instead you had to inject it into javascript via Page.ClientScript.Register...
His reason was that asp.net has to recompile a page every time if it has those server code includes.
That didn't sound right for me but I couldn't find any proof of either.
Any ideas? Does that change performance or not? I know that server side code in markup is not good because of difficulties in debugging and readability and the whole idea of separatin gcode form markup, but I am only interested in performance differences.
Thanks!
Your architect is wrong.
ASP.NET compiles a page once, regardless of whether or not it contains any C# code. It will recompile the page only if it detects that the ASPX file was changed since last compilation.
Use a profiling tool (like dotTrace from JetBrains) to definitively tell you the performance metrics. Write 2 pages...one with and one without server-side stuff...and test.
Related
While working on an ASP.NET project, I really liked the concept of a class for each page or webform, where I could write all the method and actions I want, and more importantly, the Page Load method.
Everyone says that we should avoid using scriplets, either in ASP or JSP.
And I suppose that the Page Load existed for us so that we don't use scriplets anymore.
Because I heard and read many times that we can't know when these scriplets will run, but in the Page Load method, we know exactly how the codes will run and how the page will be rendered.
But in JSP, as far as I know, we don't have this type of server-side class for each page.
Instead we have something called servelts, which everyone encourages to use.
But technically servlets are independent from the normal JSP pages.
So still, I'm using scriplets in my JSP pages, even though I'm trying to make them less as much as I could, but I still use some scriplets to check the Session and some URL parameters.
Isn't there a similar idea or approach to the Page Load (ASP) in JSP?
BalusC was right in saying you are comparing apples to oranges. JSF was created in response to asp.net. (source # 47 minutes) It has grown independently and you might do well to look into all the different frameworks and paradigms out there. While JSF will work similar to asp.net there are plenty of alternatives worth exploring. In .NET you might want to look into MVC4. In Java there is Tapestry, Spring MVC, Seams, etc.
I would start with wiki comparison and go from there. At your stage in the game I would pick one and try to get familiar with it, than try 2 more to do that same thing.
http://en.wikipedia.org/wiki/Comparison_of_web_application_frameworks#Java_2
I am currently rewriting a large website with the goal of replacing a large number of page/form submittals - with AJAX calls. The goal is to reduce the amount of server roundtrips - and all the state handling on pages that are rich with client .
Having spent some time considering the best way forward with regards to performance - my question is now the following.
Will it lead to better performance to have just one single aspx page that are used for all AJAX calls - or will it be better to have a aspx page for every use of AJAX on a given webage?
Thank you very much for any insights
Lars Kjeldsen
Performancewise either approach can be made to work on a similar order of magnitude.
Maintanancewise, I prefer to have separate pages for each logical part of your site. Again, either can work, but I've seen more people make a mess of things with "monolithic" type approaches. Single page you'll need a good amount of skill structuring your scripts and client side logic. Well done there isn't a problem, however, I just see more people getting it right when they use separate pages for separate parts of the site.
If you take a look at the site http://battlelog.battlefield.com/ (you'll have to create an account) you'll notice a few things about this it.
It never refreshes the page as you navigate the website. (Using JSON to transmit new data)
It updates the URL and keeps track of where you are.
You can use the updated URL and immediately navigate to that portion of the web-application. (In this case it returns the HTML page)
Here's a full write up on the website.
Personally, I like this approach from a technology/performance perspective, but I don't know what the impact it will have on SEO since this design relies on the HTML5 History state mechanism in JavaScript.
Here's an article on SEO and JavaScript, but you'll have to do more research.
NOTE: History.js provides graceful degradation for Browsers that do not support History state.
This might be a pretty strange question in the eyes of some of you out here, but I really wonder if comments in my code will slow down the execution time of the pages I make.
I have some Classes / WebControls that required alot of comments to make everything clear and quickly readable to other people that will have to deal with my code and now wonder how ASP.Net deals with my comments. Will comments be stripped from my code at compile time or how is this all done?
I should be more specific: I mean comments in my code-behind in C#.
Comments serverside in C# won't do anything but a slight increase in compiletime.
Comments in javascript of course increase the downloadsize. But since you usually minify javascript on production systems, and thus strip out the comments and whitespace it doesn't matter in practice.
Since html minification on dynamically generated pages isn't that common, comments in html slow you down a bit, but they typically are so few that it doesn't matter in practice either.
Comments on the aspx pages (like in javascript etc.) are slowing down the page because it is content that needs to be downloaded. For JavaScript you might use a minimizer and have a minimized version of the javascript on the production system.
For c# code... it does not make a difference since the comments are not compiled into the assembly.
No. Only exception is when you have an exorbitant amount of HTML (<!--) comments because this will require extra time to transfer your HTML over the internet. All C# comments will be striped when compiled.
If the comments are in the .aspx page, it will depend on whether they're HTML comments or server-side comments. As Pieter points out, HTML (!<--) comments have an impact because they get transferred over the network.
Generally speaking, the more that gets sent to the browser, the longer it will take your pages to load. (It also puts additional load on your server - increased bandwidth usage, and most likely a small increase in CPU load simply because the server has to work harder to send more data.)
That's why ASP.NET supports server-side comments. If you use the !<%-- ... --%> syntax instead, the contents of the comment will not be sent to client. The best way to know for certain what's actually being transferred is to View Source in the browser to see what came across.
Scott Guthrie posted about this back in 2006: http://weblogs.asp.net/scottgu/archive/2006/07/09/Tip_2F00_Trick_3A00_-Using-Server-Side-Comments-with-ASP.NET-2.0-.aspx
I know the question is a bit subjective, but often there is a consensus as to a whether a style should be avoided or is considered harmless.
I have elements of actual HTML mixed in with a lot of my ASP.NET markup. I don't know enough about what goes on in the background to determine whether this should be avoided or if it is harmless.
I recently read that all styling elements should be left out of ASPX files and relegated to CSS; this seems wise for a variety of reasons.
I'm wondering if HTML code should be replaced by corresponding ASP as it is harder to control from the code behind, or if it is perhaps recommended to put actual HTML code as it is less do to when the page is rendered.
When the asp.net compiler parses your .aspx files, it converts everything that's not already a runat="server" control into an <asp:literal> control so that it can construct code (be it c# or vb.net) from your markup that generates the page.
Ultimately there's probably very little difference, performance wise, but if you have no reason to manipulate a particular element from your codebehind it probably makes sense to leave it as "pure" HTML, for readability if nothing else.
I think it's nothing wrong to put HTML in ASPX page if this part is actually static, for example I often to use HTML tables in ASPX. Page will be rendering faster if you don't use server controls where it's not necessary.
I like to keep my HTML just HTML so that it is clear to anyone else looking at my code in the future what elements are potentially referenced in server side logic without having to compare code behind files to .aspx pages to see what is used in server side code or not.
That way someone can easily tell from looking at the "design" of the page what elements are processed on the back end. Either way, like noted probably not a major performance difference, but more a good practice IMO.
I'm looking at converting a web site from classic ASP to ASP.NET. I'm thinking of doing an agile style approach and providing deliverables as quickly as possible and so am thinking of doing a line by line conversion and creating "bad" ASP.NET and have it all in the ASPX file for phase 1 and get that working. That, I figure, will be the fastest and safest (i.e. preserving identical functionality). The next phase would be to split the code out into codebehind and multi-tiers.
I plan on replacing the VBScript in the ASP files with C# in the ASPX files.
So apart from general comments about what I'm planning on doing (which I welcome) the specific question that I have is: Are there any helper functions out there that wrap the VBScript functions from ASP to a C# equivalent that someone's already done?
So I'd be looking for a C# file (library) that has wrappers like:
string Mid(string txt,int start,int length)
{
return txt.SubString(start, length); // or is it start - 1?
}
double Abs(double num)
{
return Math.Abs(num);
}
Look in the Microsoft.VisualBasic namespace to get access to the old VBScript/VB6 functions. You can use them directly from C#.
Additionally, you're in for a shock. ASP.Net uses a different compiler model, and so some of the things you did in Classic ASP aren't allowed at all in ASP.Net. Include files is the big one that comes to mind-- all of your supporting code (code outside of the *.asp file for the page itself) must be re-thought to support the new model.
I don't think a line-by-line approach is a good idea - you'll just end up with a bunch of bad code that you'll still have to refactor. That doesn't sound very Agile to me either.
I'd try breaking the site up logically into modules, and then try rewriting specific pages or modules as ASPX. For example, if the site has an admin section, maybe you could just rewrite the admin portion. Then repeat for the next section. This could be done iteratively for each section until you're done.
I agree with the comment by Jason, and would like to also point out a higher level issue that you'd have to address, if you haven't thought about it already.
Does your classic ASP site make use of session variables to manage state between pages? If so, have you thought about how you're going to share session state between ASP and ASP.NET? Classic ASP and ASP.NET implement session state in different ways, so you will need methods to transfer between the two.
Smaller applications may be easier to "convert", but if you've got a large app that makes heavy use of session variables, you may want to think about other options.
If using ASP.NET MVC is an option for you, I'd take a look at that first. I would think it would be a much easier translation than trying to go from a scripting language to WebForms.
I don't think you gain anything by redoing the site as-is in .Net. Implementing it properly will be so radically different than what you'll start with in .Net that it just seems like wasted effort. Furthermore, it will be very difficult to write unit tests if you implement everything in .aspx pages without even code-behind.
I would aim for an MVC conversion. If you do port it over as-is, at least investigate master pages, that should save you some headaches.