Recently I was asked the following questions in an interview:
How will you do performance optimization over your jQuery in ASP.NET?
How many script managers can you have in an ASP.NET application? Why? (AJAX related)
Could someone explain the answer to these questions? I have no idea about either of them.
You can only have one ScriptManager on a page. The script manager has several responsibilities, such as loading the MS Ajax libraries, creating proxy classes for web services, and enabling partial page rendering (e.g. UpdatePanel) support. It doesn't make sense to have more than one per page, and you'll get an exception if you try to do this.
If you need to load additional scripts or references, in a user control for example, you can use the ScriptManagerProxy class.
Regarding (1)
Use tools like firebug or dynatrace to do the profiling and digging the code.
JQuery is not out of nowere its JavaScript so one has to know it well for optimization.
Adhere to good JavaScript coding practices that helps big time.
Always remember that each JS file and line of code you write is transfered to client for execution so be aware of it while writing code as this cas cause issues. So if you decide to include 4 JS file sum sized to 400 KB emans u are putting burdon on the client especially if he is on slow lines.
Yes and for (2) refer http://forums.asp.net/t/1073734.aspx link.
One page can only have one script manager.
Hope that helped :)
Watch your selectors, especially when you are working with .NET. You don't want to run the same selector multiple times. Instead you would want to define a javascript variable to hold the selector and then use that variable...that way jQuery is not having to find the same selector multiple times.
You can have 1 ScriptManager per page.
You can have only one ScriptManager per page
A page can contain only one script manager in its hierarchy according to the documentation. For jQuery optimization, it is important to use minified versions of all JS files and profiling tools such as Firebug are helpful.
This would be an normal statement for performance optimization,
Performance is an important aspect of the modern day web application development. Not only does it make a site seamless to use, but also increases the scalability of the website and makes it future proof. In this article, we will look at various aspects of improving the performance of ASP.NET web applications. We will only concentrate on the browser/web server side performance as opposed to server/app server/database server performance optimizations.
You can have only one scriptmanager per page otherwise you will get an exception when you run the application.
you can also refer this link for Interview questions and answers.
Related
This is a simple question, NikhilK answered to this question:
"Script# doesn't support ASP.NET Ajax anymore"
Does that mean that we can't use Asp.net UpdatePanels (which need a ScriptManager) in the same page where we load mscorlib.js? Even if mscorlib is manipulating DOM elements that are not inside the updatepanel?
When I mentioned asp.net ajax is not supported, it is primarily a two-fold statement:
MSAjax assemblies allowing you to program against the msajax scripts are no longer included.
There was a mode of the compiler which caused generated script to use the type system defined in msajax scripts.
Conceptually you should be able to load mscorlib.js and program using it in any page, including one using asp.net ajax (and update panels). As a heads-up you may run into one particular issue... mscorlib.js extends Array.prototype, which I don't think affects msajax scripts, but might affect some other scripts (eg. sharepoint scripts).
In the future, I plan to generate scripts differently that would not require extending Array.prototype, but that work hasn't been done yet.
So hopefully that clarifies things. If you try and run into issues, I'd love to know. I can't guarantee they'll be fixed (esp. given that even asp.net is primarily focused around jQuery rather then the old msajax scripts), but I can try helping to see if any of them have reasonable workarounds.
i have very strict requirements for performance on a large data entry application. You can imagine a single form with hundreds of fields, tabs, modal popups and similar.
The question is, what is the best Ajax architecture that i can implement to make it fast?
i was thinking about lightweight json async calls on the client, and async operations on the server. I was also considering HTML templates on the client, instead of building html on the server.
Let me know what you think.
Thanks in advance.
Use a combination of jQuery and HTML for the client and .net methods in the server-side callbacks. Async calls are good, but not always the best choice, remember that. Basically, use as few server-side components as possible because it generates much markup
there are also techinques for improving performance like caching. This can be done many places, for example on the .aspx page or on the web-server itself.
If you can, turn off the viewstate. This can generate much unnecessary markup
I would use a combination of JQuery ajax and ASP.NET MVC 3. These two combined provide an easy way to make fully async applications and due to the nature of MVC you can have HTML templates, most of which are already available through the MVC3 template.
Ok, I hate to say it.. but what you want is impossible. You cannot have a form with hudreds of elements on it, and still have it perform well. Of course "perform well" is subjective.. but the only way to get good performance over a high latency network connection with variable bandwidth (like the internet) is to work with very small sets of elements.
Using AJAX-Enabled WCF Services, JQuery and JQuery Templates can give you a good network throughput performance and a good user experience for your users.
But this comes with a price. Developing, debugging and mantaining such an application is very hard considered to a regularly developed ASP.NET application.
It's a trade-off, and if you ask me I would suggest you to go for the traditional way and make some improvements to your application interface, such as dividing forms, implementing a save-continue wizard-like type input screens. You can still use JQuery to improve user experience and caching to improve application performance. Keeping an eye on view-state and using UpdatePanel's as necessary could help even more.
I'm building a Bridge game.
The main page, where you play the game, boast some 200 controls, like buttons that represents the 52 cards, 26 others for won / lost tricks, plenty of text fields... You name it, total some 200.
Actually its been already built and runs under Winforms model, but with the unavoidable question of implementing .NET 4.0 onto user's machine that must run Windows, and installing the software.
Hence I'm considering creating an ASP version (no PHP please, since I'm fluent in VB, and ignorant in C, Java, PHP and the likes).
Is that a "real" option or am I dreaming?
Will it run smoothly for users with a 2MB DSL connection?
Oh, by the way, no MVC please, I'm too old for that sort of sh...t :->
Can it be done? Sure.
The problem for you might be that to do it effectivly you will need to use HTML, CSS, Javascript and the like.
What most likely would be a good idea for you here would be to go the route of Silverlight. It will give you a more rich UI experience and will allow you to code in VB entirely.
I don't see using ASP.BET directly as a good option here. To make it look smooth, you would have to use javascript heavily. I thing you would be better off with Flash.
If you prefer to use pure HTML/Javascript/CSS you can create rich Web UI's by modifying the Document's Object Model (DOM). With little knowledge of Javascript and the usage of some library like: scriptaculus, prototype, sarissa, jquery, you can get rich interfaces. You should take a look at some of these libraries mainly scriptaculus because the set of animations it provides. Another javascript library made for game development is gameQuery.
With that many controls on an ASP.NET page your view state will be gigantic. If you plan on only serving up a couple of games at once then it shouldn't be a problem but you have to actually start thinking about bandwidth with that large of a viewstate. You would be better off with a DOM/jQuery type interface which displayed static images for the cards. All interaction can be handled client side and validated with a server side call.
This might be the perfect opportunity to learn javascript :). Remember each language you learn is another tool in your toolbox. The engineer with the most tools usually wins :).
I've seen a few blog posts and tutorials overviewing mixing in jQuery and the UI elements for Views in a .NET MVC web app. But usually targeted at developers with a comprehensive grasp of the full dev cycle and variations of back/middle tier technologies.
As the front end developer I'm pitching a jQuery-only UI to the back-end dev - he cautions against a non-webforms interface for sake of the code maturity pov.
I'm trying to hit back with "well...it's your pattern ...isn't it elemental to MVC? No logic in the view? I'm reading that to be 'server-side stuff'. You just serialize the properties i'm asking for, or better...let me easily discover what you _can send me...i'll be able to implement the UI via jQuery UI."
So how valid is my position?
Can jQuery's grid be expected to handle at least the bottom 85% of .net's native control (low-to-moderate capacities # of rows)?
How about in-line editing? ...from the grid?
Would working exclusively in Web Services simplify his life at all? and if so, wouldn't that be logical way to build a .net-to-jQuery relationship? - ajax liaisoning twixt server (.net WS methods) and client?
mny thx
--steve...
Don't fight the platform. That way lies pain and suffering.
The MVC view objects are vastly different than asp.net webforms with server controls--you get straight up html. You get jquery and ajax basically for free, with (almost) magic server side ajax call processing.
They are designed to do what you ask. Writing your own jquery ui is reinventing the wheel.
Not only would it be a ton of extra work for no gain. You would be the only developer around trying to do that, and when you needed help, few could offer advice.
If this is an admin interface, and the client has agreed that users must have javascript enabled then I think using javascript to build widgets on the page is a better option than using the asp.net server controls. If however this is a public facing website I would argue that a pure html and css approach is much better, and then use javascript to progressively enhance the page!
Now I dont ever advocate using asp.net server controls, because they spit out poor markup and they are overly complicated to use. Instead I have been using jQuery to do the grunt work and dom querying and traversing. I also dont advocate using jQuery UI because they are missing some very essential widgets, for example no datatable, no treeview etc. I know that there are lots of plugins for jQuery but they are not componentised and therefore each plugin needs to reinvent the wheel to achieve everything it needs. Once you have included all your plugin libraries and css you often end up with a very large page footprint. Also each plugin often has a different home page and documentation that may or may not be up to scratch.
I think that the best UI library is YUI, and you can easily combine it with jQuery. Because each widget is made up from core components the overall weight of download is smaller. Also you have all the documentation in one place with 100's of working examples. Also it means working with the same set of javascript patterns across the board, so with each widget you learn more and more about the library. Hopefully jQuery UI will catch up, but personally I am looking forward to YUI 3 which for me might mean dropping jQuery altogether...
jQuery is a very mature library. It is used by thousands of people across the internet, and I dont think I have ever encountered a bug. YUI is dogfooded by YAHOO so it too is battle hardened.
One thing I did not mention to you is that I am using the default webforms view engine with asp.net mvc. I think it is still the best option as you get intellisense and also Resharper refactoring even searches your views, and the static solution anaylsis can find code errors in your views.
For building my markup I have been using MvcContrib Fluent Html but you could also checkout this article that advocated the DRY principal very well.
When designing a ASP.net WebForm application what are some important steps to take (or hacks if you like to use the term) to ensure the best possible performance (in terms of speed, stability, and scalability)?
Here's a good Best Practices written by microsoft. Chapter 6 is specific to ASP.NET, but the whole document is .NET in general.
http://msdn.microsoft.com/en-us/library/ms998530.aspx
You've got a ton of material, directly from Microsoft here.
Also a checklist is available if you want condensed information.
Just a couple, in addition to the good advice already given,
Don't put every single page in a webform, not everything needs it - The default behaviour from VS is to give you a master page that wraps a form around everything, and a lot of people seem to stick with that. In my experience, some controls can render 30% faster outside of a webform, so if you're just parsing a querystring then reading something from a database, leave the form at home if you can. Even getting your navigation out of the form will help.
Don't use a server control when plain old HTML will do - does it really require a asp:linkbutton or asp:hyperlink just to go to the FAQ page etc. Plain hyperlinks work just fine in asp.net, but some people seem to get stuck on the idea of using runat="server" for everything.
There is a phenominal book on this subject by one of the Yahoo guys, Steve Souders. It taught me a lot.
Or you can just watch this video. It's a high level overview of the same information - you can pick up a lot in 45 minutes by watching this.
NOTE: This content is not WebForms-specific. It's general best practices for the web, and it is what you need if you are trying to roll out a high performance website.
Big # 1 tip: turn off viewstate in the web.config. That should have been the default, if you need it for a control turn it on on a control by control basis.
My other piece of advice is stay the hell away from *view controls. Use repeaters and find a good 3rd party grid control. The really "magical" controls that ship with asp tend to be perf hogs, and in general just not a good idea anyways (with the possible exception of ListView)
1 - Turn on content compression on iis
2 - Cache everything you can
This will do for the majority of webapps out there.
I am not sure about content compression when the content involves html with js doing ajax stuff. Sometimes the blocks of data exchanged through ajax are small and in this case (and if that is considered content) compression often hurts instead of helping. For example, a four bytes block of data produces a compressed block of 100+ bytes.