i want to know is there any difference between server controls and HTML controls in speed?
for example you want to create a log in page that have two textbox and a button for submitting data,you can do this with both server controls and HTML controls(client_side controls(input) ),do you prefer to use server controls or HTML controls and which one is more efficiently?
which one is faster?
You always want to validate on the serverside, trusting anything from the client is a big mistake
Server Controls must be executed on the server and a Render method is called to generate the HTML. Therefore they cost a little bit of performance on the server. Depending on the control, they emit data in the ViewState as well, which costs a little bit of additional bandwidth (or very much depending on the control).
It depends on the type of control you want to use. As soon as there is any serverside processing involved (read a textbox, handle a button etc.), I always prefer the asp.net server controls, because they provide much more functionality. But if the control is just sent to the client (such as images, tables, divs etc.) I use HTML controls.
I think the server side processing doesn't take much, it takes a lot longer to get data from a database. Of course it depends on the number of users as well, whether you have to optimize or not. But I would rather use OutputCache instead of not using asp.net server controls.
Hope this helps.
The main advantage of server control is that its wrapping a control as a .Net object. It gives you a medium to access your control and its properties from code behind.
HTML controls are usually won't be accessible at client side. However, you can make them available to code behind by adding runat="server" attribute.
With the assumption that you want to access the control from code, you can chose any of them.
Now if you really want to see the difference between the asp.net control (I guess this is what you have referred to as server control) and html control, its the difference between the WebControl and HTMLControl (parents of asp.net and html controls). You basically get two different sets of wrappers. ASP.Net controls come with lot of customization and the control set is a long list than tha HTML controls list.
If we assume that you want to do some basic stuff and there is no need to access the control from code, best thing is the HTML controls, because it would save the rendering effort from the server side.
One more catch here is, if you want to utilize server side resources, such as images stored in server side, you can't access it with simple consistantly. The postback may lose the path. It would expect a control with runat="server". Its again your choice, html or asp.net controls!!!
Server controls are simple html or combination of html controls with capability to post data to server.
I would prefer server side controls for simple login screen, with preliminary client side validations.
Efficiency of controls depends on the No. of round trips it is making to the server and amount of javascript logic it is executing.
Related
Just a general question that I've been wondering about for a while. I write a lot of pages in ASP.NET, and so all of my controls have tags beginning <asp:, and include runat="server", meaning that they're server-side controls. What I'm wondering is whether there's any advantage to using client-side controls rather than server-side controls when they don't need to be server-side.
For example, rather than having:
<asp:Label ID="lbl" runat="server" Text="This is a label" CssClass="labelclass" />
Would it be advantageous in any way (e.g. performance-wise) to instead use:
<label class="labelclass">This is a label</label>
?
Only if there is no intent to modify or access label values on the server side. It will be slightly faster to use direct HTML as in this case ASP.NET won't have to spend time to parse server control to generate anything.
If they don't need to be server-side controls, use client side controls. This will make the rendering quicker as there is less code to convert.
I generally only use server-side controls if I'm going to be referencing the control in some way in my code behind file.
On a site note, its worth mentioning, an ASP.NET Label web control renders as a <span> element, and not a <label> unless AssociatedControlId property is used.
Definitely there is a performance boost if we use client control rather than server control as server controls are parsed by asp server and it generates html for it and so it is an overhead.
Its not about how much performance but there is definitely a performance difference.
Server controls should only be used if they have to get modified on server side.
In addition to the server having to render server side controls, they also require an associated ViewState in order to be ping ponged back and forth between client and server. This results in larger requests, heavier loads, and longer load times for your pages.
I would like to replace asp.net form validation with jQuery validation but not sure is this secure. ASP.NET validation use client side and server side validation to prevent hack post to server by disabling client side JS validation.
If I will use client side jQuery validation then it can be easily compromised, no? Maybe I am missing something?
You should not use ONLY client side validation. It can be easily avoided. People generally use client side validation for the User Experience. That way forms don't have to do a full post to catch mistakes. You want to do server side validation for security purposes.
jQuery validation is exactly the same as client side JS validation. jQuery is javascript framework.
ALWAYS use server side validation, and if you want to improve the user's experience then include your client side validation.
you should always write server-side validation code even if you validate the data on the client, otherwise your site will be unsafe and easily could be hacked. But the reason for writing client-side validation is to avoid the round-trip to the server that would otherwise be required to validate the data. In other words, if the user enters invalid data, it's much more efficient and user-friendly to trap the error before
sending the data to the server, where if the data is invalid you'll have to rebuild the page and maintain the page state as well so that the user can fix the invalid value.
Try using asp.net AJAX plus server control validators as your validation framework for the following reasons:
It's secure because your validation runs in the server side
It's easier to implement because you dont have to write the same code twice, both in the server and in the client (javascript)
Server side code it's by far much easier to maintain than client side code
Your website will look responsive, although you must take care on how to reduce the data traveling in every partial postback. Research on this.
You are tied to the asp.net sintax and your developers will love this too. You won't actually need more.
Recommendations:
focus is lost on every partial postback: the DOM portion of the form submitted inside the update panel is replaced, and the browser does nothing to set the focus for the user. So make sure to set the focus on the proper controls thinking the user is entering data using the TAB keystroke.
if you want to customize the appeareance of your server validator controls with css, try inheriting the main validators: Custom, Regex and requiredField, with your own classes, which basically set and unset the error css class and message you want every server roundtrip (set before rendering). then map those custom classes to the framework's classes in the web.config (use tagmapping), so you alway use the default markup for server side validations. You get this way the best of the two worlds.
Jquery.validate.js
https://github.com/jzaefferer/jquery-validation
You can set this up to run independently of your own client side validation/instead of/or in conjunction with.
Is there any reason use standart HTML controls (input type=text,input type=checkbox) instead of asp.net controls ( asp:TextBox, asp:CheckBox) to improve performance?
IMHO this would be a micro optimization. You will gain performance but it won't be noticeable. On the other hand you will loose much of the flexibility offered by the server controls.
You could try to reduce the size of the ViewState by disabling it for controls that don't need it. This will reduce the size of the generated pages and improve performance.
The ASP.NET user controls will all have ViewState associated with them unless you explicitly set
EnableViewState="False"
As such, you will bloat the size of the underlying page if you have a large number of controls. As a general rule, use what meets your needs and nothing more.
Do you need to access the user control in the code-behind?
Do you need the control to maintain value across post-backs etc?
In most cases, it won't make a difference, but it is good to keep your page clean if you don't need these features.
As always with performance optimizations: it depends on the situation. Test it in your project and see if it makes any difference.
Also with .net 4.0 another con of using server controls is gone, since you can set ClientIDMode to Static, which will give you full control over ID's on your controls. Previously using just a standard textbox or button (without viewstate) would still render crazy non-readable ID's because of the way Naming Containers work. Those days are over now though :)
Remember your three options are:
use regular html which can't be referenced on the server.
add runat="server" to your existing html-tags (ie. ) and you'll be able to access it as an HtmlControl.
use the asp.net tags (<asp:* runat="server" />)
The disadvantage of option 3 is that you don't always know what the rendered html-markup will be and you have less control over it. I personally only use option 3 for more advanced controls like , the button () and third party controls. For normal html-markup that I need to reference on the server I prefer option 2.
Regarding performance I would mainly look at the rendered output, how much extra bloat is rendered to the client and such. CPU-time on the server using one or the other approach I would say is secondary compared to the different caching techniques ASP.Net has already.
Why do I need script on an aspx page?
Javascript will allow you to perfrorm client side coding, so to avoid having to post back to the server.
From Using JavaScript Along with ASP.NET
Working logic and application
processes on the client-side allows
browser based applications to seem
more responsive and to have more
"snappiness" to them.
For client scripting, i.e. validation. There are many scenarios where you need to execute certain logic on the browser's end.
Javascript runs on the client side. So if you want anything to happen or change without refreshing the whole page you use javascript.
There are a lot of things the server can't really do that well. For example if you want to manipulate the page. You could post the whole thing back to the server with some sort of action and get the server to give you a new page. Or you could just use javascript to change it for you and avoid the trip to the server. It is faster for the client and takes the load off of your server.
It helps in doing things on the client side, which essentially means you can :
reduce burden on your server
by doing less postbacks.
do a round of validations on the client
side itself if they are non critical.
Do some fancy stuff like animations etc with out contacting the server
There are a lot more implications/uses of using JavaScript.
For knowing more, remember google is your friend!
Thanks
I'm not sure if you mean why ASP.NET pages requires Javascript, or if you mean additional scripts on the page.
ASP.NET uses Javascript for several types of postbacks. If you for example have a LinkButton, a script is making a postback instead of the default action of the link.
You can use additional scripts on the page for visual effects and to verify data before doing a postback to prevent unneccessary postbacks. (Of course you should also verify the data on the server side to protect against malicious actions.)
For example,
If I have a textbox with runat=server on a page, The value will be posted back to the server so I can access the properties in the code-behind.
However, under the following situations, does it still hold true?
A textbox with runat=server but does not appear in the function that is post back to. For example, a button is also on the page, when clicked a post back occurs and within the method that is raised, this textbox was not used.
Within a MasterPage, will a textbox residing on the Masterpage itself be posted back?
Because just thinking, isn't this mechanism bloated in nature?
If all input controls and its value are posted back on every single button click (even when the input control is not needed), doesn't this deteriorate performance?
Having just one Form Tag on the page really restricts us to using this mechanism?
Truly Understanding ViewState is a must read article on the subject of ASP.NET ViewState
There are several options to cut down on the bloat (and yes, there's a lot of it when dealing with lots of controls):
Use AJAX to post only the items required - although be careful to allow clients that don't have JavaScript enabled to still use the page/ site.
The MVC framework allows multiple form tags to be used so you can group sections if needs be.
Set the EnableViewState to false on pages/ controls.
Break up your pages into smaller ones.
Additionally, check out this brilliant graphical representation of the Page Life Cycle in ASP.NET.
Every input on the page is posted back fully unless you use ajax, because of the single form tag. Welcome to asp.net...
As long as the method that you're hitting on the server-side is a non-static member of the page's class, it'll have access to the textbox and all other controls on the page.
And yes, all controls rendered to the browser (whether in the MasterPage, user control, etc.) will be available on post-back.
You may want to look into Understanding ASP.NET View State.
There surely are performance hits with this architecture, but (depending on complexity of the page) it's usually not an issue from the server load perspective, because hardware upgrades are typically cheaper than additional programming hours spend on optimizing application performance.
With that said, (and as others have pointed out) look into using AJAX if you want to avoid whole page-level postbacks to the server.
Yes, it's all posted back, and yes it can cause bloat. I'm sure if you search for ViewState you will find plenty of people ranting about it and how to minimise it :)
Yes your text box will be available in both cases, yes it is bloated. This is where AJAX comes into play. Using AJAX you can send just the data you need.
If you want to send a minimal ammount of data, you could use a Page Method (static method on page decorated so the script manager builds javascript to call it or you could call it using jquery or other methods), or a script enabled web service works nice as well.
You also have viewstate which can get very large. ASP.Net MVC is a new paradigm instead of using WebForms which doesn't have view state, or post backs. It embraces HTTP instead of hidding it giving developers more control.
The textbox data would be posted back as noted. In addition to using Ajax, disabling view state greatly imporoves your page's performance though even then data in properties critical to the functioning of controls (Control state) would still be posted back.
If you didn't have postback for every control on the form, you wouldn't be able to access it in code-behind. I.e. if in your button press you wanted to modify the property of the text control you couldn't do that because ASP.Net would know nothing about the text control.
Since the communication between the server and the client is stateless and every time a page is server the server forgets all about it Postbacks are important if you want to work with the same page again. No matter what programming language you use, this or similar mechanism exists for processing server side code.
If you wish to minimize postback (viewstate size), do this.
Set enableviewstate=false on all controls that you don't want posted back.
Use AJAX and web services wherever possible (and don't use UpdatePanel).
Use HTML control as much as possible instead of ASP.Net controls.
Hmm.. There are some excellent suggestion in other answers and good links too.
You've pretty much hit the nail on the head with vanilla ASP.NET - it's not very good! In both the instances you describe the answer is yes - the textbox will be sent with the form.
The whole postback/ViewState problem is a bit of a pain, one of the first things any competent ASP.NET developer learns to do is avoid them!