Personally I've been working for years with Telerik's RadControls and DevExpress
ASP.NET controls. IMHO they both produce quite an impressive HTML overhead on the client side thus for that I've never been highly pleased with them.
Of course I also know about Infragistics, ComponentOne, ComponentArt, etc.
I'd assume they are not much different than those I mentioned.
Which (commercial) controls suite generates the most compact HTML on the client side?
I'm inclined to think there is no "most performant controls suite" rather a combination
of server controls and Javascript based controls (eg. jQuery UI). Would you agree with that?
What combinations did you achieve the best/most performant user experience with?
Update 27 Jan 2012
Since my original answer, I have spent a lot of time working with MVC. As I said below, you have full control over the markup generated, which is great. I have also spend some time using Telerik MVC (http://demos.telerik.com/aspnet-mvc) controls and I must say, they have done a great job of keeping the tools functional, while minimising the markup and script sizes. They have introduced a Script registrar which allows you to register which scripts to include on the page. This allows you to also register your own custom scripts, which can be combined into a single resource and compressed for low latency and bandwidth.
Original Accepted Post:
You are correct in that commercial control suites tend to generate heavy markup and script overhead. This is partly due to the fact that they have traditionally had to deal with the ASP.NET postback and viewstate page workflow, which results in long-winded control Ids and a proliferation of many small javascript downloads (adding latency for each file).
Also, many controls tend to try to add too much functionality. They try to do it all but this makes doing anything simple with them quite a chore as there is a steep learning curve for a lot of these suites, as I am sure you are finding.
If you want to improve the download size and markup generated on your page, my advice would be to use a combination of ASP.NET MVC (great control over markup, no viewstate or _doPostBack scripts everywhere) and JQuery plugins, whic you touched on in your question.
Take a look at the markup of StacOverflow. It is written in MVC. Not sure what 3rd partycontrols they use.
The worst offender for hevy markup is often Grids. Take a look at the JQGrid http://trirand.com/blog/jqgrid/jqgrid.html
Try Obout control suit. They are very effective and bring productivity with much low overheads.
http://www.obout.com/
Here we work with ComponentArt and we are really excited about it. It's really easy to implement, looks great and has a lot of functionality in it. Performance is also very good. We also use componentone controls but they aren't very good for web apps I think.
I would definately suggest to use ComponentArt
AlbumOnNet WebControl Suite
AlbumOnNet WebControl Suite is a set of ASP.NET WebControls enabling a Web designer or programmer to use RAD techniques to create great looking Image based Slide shows, Photo Albums, and Image based Ad Rotators.
The controls can be used for product image presentations, real estate photos, art gallery pictures and screenshots.
The controls are programmed to work at its best on the design surface (in the Form Designer) in Visual Studio. Drag and drop a control, like the SlideShow control, on the page, set a few properties and experiment with the Style attributes to match your page design.
WebControls included
Album WebControl
SlideShow WebControl
SlideShow InfoViewer (EXIF codes)
Slide Info Labels
Navigation Buttons
Navigation ToolBars
Numeric link navigation
Related
I'm a new comer to the asp.net world. I hear a lot about asp.net mvc and it's advantage over webforms about the ability to customize the markup and css. I also heard that asp.net is much easier to learn than asp.net mvc so I decided to go for asp.net and webforms. My question is: what's the level of customization a web developer/designer can get with webforms concerning the markup and css?
You can have as much customisation as you like in the html output! You can customise everything in web forms. However, with customisation brings time, effort and room for error. All of these things is what web forms is trying to save you.
However, since you are just starting out I wouldn't worry. Just make your web forms how you want and forget the customisation of output (it is much better with ASP.NET 4 anyway). In a few years when you are more experienced then worry.
If you were going to customise everything then you should have gone with ASP.NET MVC - it is one of its main arguments. But there is nothing wrong with web forms. Particularly if you are beginning with asp.net in general I'd say it is better.
Standard ASP.NET WebForms uses server controls that generate the markup for you, so the level of customization is limited to what the controls you are using provide. There are techniques that allow you to override what is rendered by the controls and thus customize the markup and also write your own controls but it requires some coding. It is possible to achieve almost complete customization of the markup but it IMHO requires more efforts than a web developer should need to put into something like this.
While it is definitely possible to have a SEO friendly, unit-testable, maintanable, standards compliant application using classic ASP.NET WebForms, the efforts it requires will be significant compared to ASP.NET MVC. But if you don't care about those things you will be able to pretty quickly develop web applications.
ASP.NET comes with a set of built in user controls - things like text areas, buttons etc. These mimic winforms in how they are supposed to work (events etc), however this is a rather leaky abstraction (you must always remember you are working with HTML and HTTP).
The user controls allow reuse and when a page is built they emit HTML - you have little control over the emitted HTML (unless you override the rendering, which kinda defeats the point), hence the perception that they are harder to customize. It is not easy to get right either and requires more work than I think is worth.
There are also different compromises in the way pages are rendered out (ids for example end up as a long string of concatenated container control names) which make MVC a better choice if you are looking for control over your HTML.
Microsoft suggests that you pick the technology based on your needs:
While ASP.NET offers rich controls and produces quick results without great control over the markup (as mentioned: it can be done but somehow beats the idea behind ASP.NET and creates a lot of additional code), it suffers from the flaws mentioned by the other posters.
In MVC, there is a limited set of "out-of-the-box" controls and you'll have to code more on your own (including clientside JavaScript) but you do have more control over the rendered markup of your controls. In addition to that, your project will generally have a clean separation of concerns which benefits (unit) testing and maintainance.
Another aspect that hasn't been mentioned yet: In ASP.NET a page undergoes the so-called "ASP.NET Lifecycle" every time the client communicates with the server. The Lifecycle consists of several events that are fired in a special (and sometimes confusing) order. Handling those event in the right order in complex web applications is one of the biggest difficulties in ASP.NET and often leads beginners to forfeit. In MVC you don't have to deal with that kind of problem.
Therefore I strongly recommend that you take a look at the ASP.NET architecture before you start to code. Here is a very basic start: http://www.asp.net/learn/videos/video-6558.aspx
Personally, I started with WebForms and am now moving to MVC after I worked with the similar MVVM pattern in Silverlight and WPF for my bachelor thesis. This kind of did it for me so that I now understand the benefits and ideas behind MVC a lot better. Once you are used to WebForms, switching won't be that easy though.
I have come across the ASP.NET ready made controls like grid, repeater... etc.
For example while dealing with GRID i remember following facts,
ASP.NET V1.1 has DataGrid with "virtual row count" which is heavily used for custom paging which is need of big sites to perform well.
ASP.NET V2.0 added the GridView with all sort of cool features but also split the DataSource parts as different component. Also "virtual row count" is not supported and for pagination to be done DataSource control is need to be used.
After all these thing i thought that ASP.NET control are not made to be used as is for the development.
Please let me know whether i am right or wrong? Also if you think i am wrong PLEASE provide inputs/links which can help me come out of this thinking of mine.
The mjority of the out-of-the-box asp.net controls are very simple, easy to use and they do that they claim to do, reliably. Many people have had issues with the GridView control, particularly with regard to preformance and size of ViewState. Performance issues have only partly been resolved through the use of AJAX.
I agree with #Neil Moss about the Repeater control. It is very flexible and it outputs what you tell it to. For grids, take a look at the JQuery plugin JQGrid. It has none of the performance issues and a lot of the powerful features of many thrid party custom grids. http://www.trirand.net/demoaspnet.aspx
Also, the ListView control is a very good alternative to the GridView as it provides many of the databinding, selection, paging, sorting, modifying features of the gridview (see here) but gives full control over the output template. Here is a good series of articles on the ListView
Although I am a strong advocate of using ASP.NET MVC, there is a considerable learning curve required to do this and the change in mindset required to work properly in the MVC way should not be underestimated.
I've never had a problem using these controls. I find that they have the same advantages and disadvantages as any set of controls - native or third party. If they do 100% of what you need them to do, then fantastic. If they don't give you 100%, and don't give you events or virtual methods to override, then you're stuck and you'd need to go back to more fundamental controls and do a little programming of your own. I always found the repeaters and lists to be very handy in that respect.
to be very short & direct, ASP.NET ready made controls are the best solution for most projects.
I’ll explain you in detail, but first, ASP.NET ready made controls are known as ASP.NET Controls Framework or ASP.NET Controls Library. I am insisting on the key phrases because, when you search google like search engines, you need to search by appropriate keywords to get better results.
There are many control libraries available on the internet and most are offering free tools too. Besides the question whether should I use it in my enterprise applications or not, you need to understand your requirement.
The first point is YES, you can absolutely use the controls in your enterprise applications, because there controls are more reliable and built by control development experts, tested by strong product testing team and are enriched with quality documentation. Note, you will also get good community support, human resources with controls knowledge, and compliance with industry standards. The best of all, you will be able to save your time on all the above factors. Some controls even gain you more advantages with its features & functionalities which you wouldn’t have even thought about.
The most important things you need to do when choosing a control
1. You need to go through their knowledgebase
2. Search relevant articles for the control you choose
3. Download evaluation version and DIY
Many good control libraries are available in the internet. I am using obout control libraries and I recommend you to go for obout. Besides quality control sets, these guys provide personal development support. Most time I can’t separate them from my internal team. Check www.obout.com for yourself.
On most projects I've been one, designers has produced HTML code, then developers turned it into ASP.NET, including master-pages etc that should really be a part of design.
After it has become ASP.NET, designers could not work on the code with their tools.
I know that a lot of the design of ASP.NET is made with the purpose of separating code and design, and in principle designers should be able to work on design aspects with the Visual Web Developer, but I've never seen a designer using VWD.
How is cooperation done in practice, and what is about the best one can expect from a designer?
From someone who does both:
Most of the design should be done with CSS, so this isn't a problem.
The layout of the page, therefore, comes down to elements with IDs and classes (simplistically speaking).
I try to keep these IDs and classes as is, and place ContentPlaceHolders inside them as needed, when possible, and create controls or skins with the right classes.
Optimally, designers and programmers should work together, and know each others limitations and requirements (this cannot always be done, sometimes these are done by different companies). I think most of the responsibility here lies on the developers - they need the right controls to get the expected output.
Frankly, a web designer should care about HTML and CSS, not about what server-side technology is used to deliver them. The best I would expect from a web designer is to write flexible CSS, that can take a view changes to the HTML structure without breaking (that is - extra divs or tables, as ASP.NET tends to do).
A good ASP.NET developer will intelligently use the set of controls available. For example, in most cases, the ListView will do everything the GridView can, and produce clean, SEO-friendly markup.
In the ASP.NET environment, I would encourage the use of Expression by designers. Business owners can avail of the new deal from Microsoft and obtain VS, Expression, etc., for $100 for three years.
I think both developers and designers have to embrace each others world for anything to work.
We are still stuck with the old fashioned way of the designer producing PSD documents and hopefully rendering them into HTML.
Then we take them over and convert them to .Net, then the designer requests a change and we go in circles for a while before coming to an acceptable solution.
It would be nice if the designer could integrate into the HTML of .Net easier but I don't see that happening for a while, not while Microsoft advocates using scripting in your development..
I've found that using ASP.NET MVC will make the designer's job much easier. Especially if you stay away from using things like HTML.RenderImage, and instead place an IMG tag on the page with <%= ViewData["MyImage"] %> as the src. This will allow the designer to see the html they like and understand, while giving you the flexibility to set the source(which is all the developer should be doing). The goal being to stay away from ASP.NET controls, which would confuse a designer, while still keeping their flexibility to develop quickly.
I have read several other posts here, so i get the idea on the pro vs. cons, especially having full control over the rendered html code etc. (in MVC).
My question is regarding the UI controls: In MVC, i will have to write all UI controls myself (or the html equivalent). Now is that not going to be very difficult?
The reason why these 3rd party vendors for asp.net are there is just because of the fact that it is difficult to write UI controls for ASP.NET all by ourselves, and be able to target to all web browsers, and also that we are better off concentrating our time on the business logic rather than spending the whole lot of time writing the UI controls HTML code ourselves.
I understand that this feature gets us the full control over the final html, but is it not counter-productive to do this UI bit ourselves. If it was so easy to write them ourselves, how come these 3-rd party vendors are all living now. We could have done this all by ourselves all these years of WebForms days.
I am sure i am missing something here or being a little stupid, but please enlighten me as to what i am missing in specific regard to the UI bit being written by ourselves.
Just because i get full control over the program by writing in IL code, do we go and do that? We still use C# and things like that - So that theory of "having full control over html" - i am not bought into that idea.
Please help in getting my head around this UI bit.
Other things i understand, about the separation of concern, TDD based development possible with MVC etc.
But why would i go around writing the UI controls all by myself - it is a bit a work isn't it?
The thing is:
If you want to master in web development you have to master HTML + CSS + Javascript
And with WebForms you have to learn the WebForms way to do it, but with MVC you have the power of .Net with the freedom to generate the HTML + CSS + Javascript you want.
Here's a new rant on the subject http://www.charliedigital.com/PermaLink,guid,6dcb0333-9d70-40c7-975b-0ff4011c4661.aspx
Problem is, ASP.NET MVC is much younger product than ASP.NET. For many years 3rd party companies have been developing TONS of reusable components, and I believe that it is only a matter of time before comparable set of controls will be available for ASP.NET MVC.
If you really need very rich GUI with 3rd party controls, and you can't rewrite them in acceptable time - stick with asp.net. Altough in my opinion, MVC gives you tons of power it wouldn't be wise to spend much more time rewriting controls than you can save. If you can live without controls, and like MVC concepts - use MVC, and you'll most certainly see 3rd party solutions as soon as they'll there is growing market (maybe thay've already noticed that, I don't know) for mvc extensions.
I believe that the UI and the user experience are vital to the success of a web app. Making the page intuitive and easy to use, minimizing the amount of navigation the user has to do to get the job done, and providing effective feedback and interactivity can make all the difference between a site that users want to use and one that they avoid.
If you are trying to attract users on a public website, a pleasing appearance and excellent usability are key to building repeat visits.
If you are writing an intranet app to be used by hundreds or thousands of employees all day long -- as I mostly do -- making the UI efficient and easy to use really means a lot to your users.
So, I wouldn't downplay the importance of the UI. It isn't a nuisance. It's a key part of the user experience. I suggest that a web developer should embrace whatever tools and strategies that will get the job done. That often means coding the UI controls yourself. Or working with a teammate who likes doing that part of the work.
I recently refactored a very complex website using ASP.NET + handworked javascript to MVC + jQuery. The complexity of the code was reduced by 50%-75% and became much more testable. I replaced all the complex webcontrols I had to write (with a steep learning curve I had to overcome) with very simple HtmlHelper methods.
Don't forget, when you use custom webcontrols, you are given a very static UI by the control developer. With raw HTML, you can take advantage of styles and ui developed by the whole web industry.
Increased simplicity, decreased development time, testability, flexibility in UI... I don't want to go back.
You also have to remember that ASP.NET MVC is just the first release. I don't think there is intrinsically any reason why you couldn't have the equivalent of server controls to enable certain tasks - remember, there are many server controls that don't generate any mark-up (such as the Repeater, PlaceHolder, ListView). These type of controls could be useful in a future MVC setting, I think.
I believe that ASP.net came around when lots of developers were still used to doing desktop applications and just beginning web development. AT that point in time abstracting the details of the web with controls and post backs was a great way to get people started. At that point we weren't trying to perfect the web, we just wanted to get on it!
Now that the web has matured and we've all slowly learned about html, css, javascript and the likes we want to optimize our websites for our own needs and we don't want to depend on ASP.net Forms controls to control the fine details of our websites.
In summary, I think this is about the natural evolution of many developers from the desktop to the web
I for one, am very thankful that you cannot use ASP.NET controls in MVC.
Controls, as many have already pointed out, are just server side blocks of code that render HTML and javascript on your behalf. Things like a datagrid are great, until someone asks you to make a slight modification, like having a delete confirmation alert, and then it seems impossible to do certain tasks.
The good news is that there are very powerful jQuery tools written to help you. jQgrid is a great grid replacement that does WAY more than the ASP.NET grid...
http://www.trirand.com/blog/
jsTree is a treeview that is fantastic. Again with the jQuery....
http://www.jstree.com/
And the truth is that most things you can do with razor, HTML, javascript and CSS. It's so simple that it's just stupid.
It's hard for people like myself who were web forms developers to grasp MVC and why you should use it because it's so simple. It's difficult to let go of the complexity of conventional ASP.NET. But it feels so good when you do.
And don't mix web forms with MVC. You can do it, but you will wish you hadn't.
Here is the key thing that I think you are missing. When ASP.NET is no longer the MS way of doing things...you will eventually be forced to move on and do something else. I have programmed in perl, ASP classic, then ColdFusion, then PHP, then ASP.NET web forms, then ASP.NET MVC...the only thing that they all have in common is the underlying database, design patterns, best practices for a given set of technology AND...HTML, JavaScript, CSS, and Photoshop.
No one is asking you to learn MVC. No one is telling you to not use WebForms. However, complaining that you have to write a raw UI is not going to get you very far in this industry. You should be learning something new every day...and it sounds like some time spent on HTML and CSS would be a great place to start your focus!
The biggest problem you have with relying on third party controls is when a client asks you to do something that the third party controls don't cover. If you can't replicate their complexity plus the added feature request on your own you are skirting a possible failure in your professional livelihood! You will need to know how to do it all...eventually!
I generally suggest that you embrace new technologies. You don't have to use them...but you should at least know how. This way you will know what the best tool is for any given project.
I've been wondering - what's an equivalent of 'control' from webforms in asp.net mvc? It's not a partial view for sure. What else it can be? Controller + partial views via partial requests?
Maybe i'm dumb, blind or both, but i haven't seen any 'control' for asp.net mvc. Just a lot of code snippets to accomplish one specific thing or another.
I believe that asp.net mvc is quite unfriendly with rapid development. Only way out of this problem - a lot of open source code (like MvcContrib), tutorials, sample applications & most important - slightly smarter developers.
You do not have to replace Webforms controls with something else from MVC. Just mix them - http://www.hanselman.com/blog/PlugInHybridsASPNETWebFormsAndASPMVCAndASPNETDynamicDataSideBySide.aspx
Well, I was also wondering how to use 3rd party controls in ASP.NET MVC. Obviously, and contrary to some answers here, it had to be possible.
As much time has passed since the question was asked, the industry has evolved. So I've searched and found (but havent' yet tested) solutions such as Telerik Extensions for ASP.NET MVC .
I'm posting this answer here mainly to support other MVC newbees such as myself - Just Google
"asp.net mvc" controls
Our organization has dedicated designers who design the page and cut it up in Dreamweaver. That's worked well in the past with ASP and PHP sites. Now we're trying to make it work with .NET, but are struggling because of the structure of a project in ASP.NET. How does everybody collaborate with developers? The specific points I am looking for are:
-Transferring Dreamweaver content to Visual Studio
-Changing HTML inputs to server controls
-Giving designer access to finished Visual Studio product so they can tweak layout
Thanks!
Obviously, there will be a slight learning curve for your designers. But with that said, I have worked quite often with designers (none of whom used Dreamweaver, btw, so that may be part of the problem) on asp.net sites. Usually, they will create the HTML exactly how they want it on the server like a static HTML page, then I will go in and replace form fields manually with asp.net controls.
On an aside, I have found that I have the best chance of matching the design using controls that spit out the least HTML, such as Repeaters instead of DataGrids.
Once the site is up on the server and programmed, they can go back in an tweak things if need be.
Also, just like we have to adapt to them a bit (making our server controls spit out html how they like it) they also have to adapt to us a bit and not rely as heavily on id attributes in their stylesheets as some items id attributes will be controlled by hte .net runtime since they are controls.
MOre often than not, a designer new to asp.net will feel very threatened by this new way of doing things, specially with user controls instad of include files, but its really not that different than classic asp/php development is.
The key to the solution of all your problems in this matter is quite simple, and yet so hard to fulfill: it's usually called semantic markup. If you can make sure that the designers to start with make their html semantic, and that the .Net programmers keep rendering the same markup but with their server controls where needed, the tweaking won't be a problem - the markup is the same.
So what is semantic html, then? you may ask. Well, it's not always as simple as one would like it to be. A good start is to make every page pass XHTML validation.
In my experience, designer-created HTML almost always needs to be at least refactored, if not rewritten. So, open a browser with the original HTML on the left, and try to match it as closely as possible in VS on the right screen.
Giving designers access to ASP markup is not a good idea, imho. Too much can go wrong if you only understand half of the tags you are manipulating.
How about using one of Microsoft Expressions line of products? I've heard they are to .NET what dreamweaver is to PHP/ASP.