I’m new to .net, though I’ve been writing in classic asp for years. I know it’s time to make the change, but I can’t stand how bloated the HTML becomes.
For example, a simple menu using a web.sitemap and adds over 100 lines of JavaScript and HTML. A simple form with server-side validation adds in masses of ugly JavaScript. And a basic table of data using GridView adds in a ViewState that makes my eyes water.
Call me a purest, though I don’t like sending data to the browser unless it’s needed. And I don’t need a form-riddled menu when a simple unordered list of links will suffice.
So, set in my ways, am I destined to forgo the benefits of the Framework entirely by insisting on writing my own, cleaner code for everything? Or am I missing the point?
As a brief aside I’m a big fan of Campaign Monitor, a newsletter distribution company. They’ve written an elegant and comprehensive user-interface in .net without a single ViewState or bizarre .net-mangeled ID reference. Even the Sign Up form on their website (/signup.aspx) is as clean as a whistle. What’s their secret?
I hope I not the only one. Any advice would be greatly appreciated.
Try ASP.NET MVC or one of the other MVC web frameworks for .NET
If your GridView doesn't need it, then turn ViewState off for it.
Also, please edit your question to say what version of .NET you're using. Some of this gets better, and some does not. You might also want to try VS2010 beta 1, and complain about anything it doesn't fix.
Another idea would be to go on treating ASP.NET like it's classic ASP. Do it exactly the way you're used to, but do it with the idea in mind that there's about 10 years of development work that's gone into solving some of the problems of classic ASP. Once you actually hit one of those problems, find out if ASP.NET has solved it, and how.
For instance, I have a hard time believing you enjoy writing FOR loops to generate table rows. If you get tired of that, learn to use a Repeater control, or a DataList control, or even the old DataGrid control. If you turn ViewState off on those, I think you may find the generated HTML to be acceptable, and you'll find it a lot easier to generate tables and other structures that repeat based on repeating data.
You can opt-out of much of that bloat by not using all the out-of-the-box controls that come with it but I prefer the MVC route that activa suggested
Here is my list:
Keep the use of asp controls to minimum
Turn off Viewstate when it's not need
If you don't want the JavaScript associated with Client Side Validation (with ASP.NET Validation) set the EnableClientScript to False
Use asp:literal instead of asp:Label
Yeah it seems to be that everyone is bashing webforms at the minute for the reasons you have outlined above. HTML heavy Controls, ViewState, no control over ClientIDs all seem to cause an issue with people.
However let is be said that you can use asp.net (webforms) and produce some decent applications.
Control of html is yours through httpModules and httpHandlers and some of the issues mentioned above are fixed in asp.net 4.0
I just listened to a great podcast comparing MVC and webforms. Its in the area you are asking about. Also check out this blogpost by a dotNetNuke regarding the good asp.net code and why people should take a breath before converting everything to mvc.
Having said that I've tried Asp.net MVC and it is awesome. I'd probably look at dotNetNukes code to as its a mature asp.net product.
Also, when you do want to use these newfangled server controls, check out the css friendly control adapters. They clean up much of the bloat.
For client IDs the key thing to remember is to let the framework handle them. If you need to get an element on the client side, remember to emit the control's ClientID property into your script.
I've been using a template system and am very happy with it. Basically write an http handler for .html files and put tokens in the html files that regex could find in one sweep and inject any stuff. (google template c# for more info).
I tried some of the supposedly cool new features of ASP.NET for a little while. I also didn't like most of them. I felt constrained to work within the limitations of the common paradigms Microsoft had dreamed, even though I new how easy it would be to produce the HTML and JavaScript myself to do specifically what I wanted to do without having to learn how to jump through the hoops of so many new Microsoft-specific idiosyncrasies.
Anyway, I stopped using the parts of ASP.NET I didn't like on new code I've been writing lately. When I first started using ASP.NET, nothing in the MSDN documentation jumped out at me about how to avoid such complications, so I posted a couple "Hello, World" at http://www.agalltyr.com/rawaspdotnet.html to help spread the heretical word. I couldn't care less if it's the latest cool technology or the recommended technique. It's a reliable and reasonably efficient tool I can use to do my work.
Oh, and I'm not in the mood to learn ASP.NET MVC either. That's just more idiosyncrasies. Give me a language (C#) and a framework (.NET), and I'll design my own abstraction, thank you.
Related
What were typical problems during developing on ASP.NET? So, would you like to describe typical problems/mistakes during developing on ASP.NET from your experience?
UPD
I have been working as ASP.NET developer for 2 monthes.
The biggest mistake in my opinion is that many people do not take the time to learn and understand the framework before they begin coding. This often leads to solutions that do not follow the intentions/paradigm of the framework.
My biggest issue was the page lifecycle. When you start adding Masterpages & user controls, it gets a bit tricker figuring out what happens and in what order
When you say ASP.NET I'm assuming you mean WebForms.
The biggest problems are related to DataBinding, event handling, viewstate and control id's. These concepts are entangled in complex ways that start to break down whenever you take even a single step outside the beaten paths.
WebForms was built to provide a similar experience to web development as to desktop UI development. After years of ASP.NET WebForms development experience I think I can safely say that WinForms does not live up to the promise. The attempt to hide web specific concepts (like the fact that HTTP is stateless) means that you as developer loose a lot of control, which makes it hard to figure out what the problem is when something does not work as you'd expect.
For anyone starting .NET-based web development I suggest you get intimate with more modern web development platforms like the ASP.NET MVC or MonoRail. The initial learning curve may be a bit steeper but when you get rolling you'll be much more productive.
Most of the asp.net web forms problem has been overcome by asp.net mvc framework. The problem in web forms were many. The biggest i feel is it has only one form. others are misuse of viewstate, which later overcome by control state. Web form has complex page life cycle specially if you are dynamically adding user controls etc.
On the other hand i see no problem in asp.net mvc framework.
I think most common mistakes on developing not only in Asp.net is that when you try to study something or just a part of it and feel like you need to stop because you think you know everything which is obviously wrong. For me Asp.net is like the world because when you know the continent of Asia,Europe,etc. it doesn't mean that you need to stop because you already know a lot of things. I think it's not that way because Asp.net have so many capabilities that every developer can explore like me who is also still studying and when you learn something, like me most of the time I say hey I never thought this exist in the map of Asp.net and again I say hey you know what I learn something new, I wonder if my previous project applies to what I learn today. Things like that, I learn in every step and the ladder never ends.
I think making a statement about your background/experience and knowledge of Http, Html etc. might help people give a better, more meaningful response.
Typical problem #1: Master pages. Coming from classic ASP, this concept was new to me so I learned how to use it properly in "the hard way". In the beginning I tried to change things defined in the master page from within content pages which is obviously wrong.
Typical problem #2: User Controls. The classic ASP does have "include" mechanism allowing the programmer to put repetitive blocks of code so I was familiar with the basic concept, but combining it with existing Page, learning the different life cycle and understanding the real power of the custom controls took long time and many bumps on the road.
From my point of view,the biggest problem in considered to the state management.
The people often get confused what to use on a particular situation.
Next one is most of don't know about the page life cycle well.which is most important during custom controls and all.
And the most important thing is new comers often don't know how to actually indulge oops concepts while software development..
I've taken over support of a legacy web app written predominantly in classic ASP. One page has a form for doing a job estimate, and consists of about 2500 lines of javascript and ASP code to achieve a "transparent edit" - i.e., the form is always in edit mode, and changes are instantly updated into the DOM.
There is also a "Print To Word Doc" button that, when clicked, goes to an entirely separate ASP file that produces (supposedly) the same view in HTML sent downloaded to a Word document.
The problem is that we have discovered inconsistencies and bugs in the two versions that are produced. My first response, applying the DRY principle, was This needs to be re-written in ASP.NET with a single code-behind file outputting the view for both the web page and the word document, so that we have one place to maintain the source.
However, upon getting into it, I'm questioning the wisdom of that approach, and I'm soliciting advice.
The problem is that, because of the integration of the view with the editing on the web page, as opposed to simply presentation on the work document, the two functions really do have two different purposes. Also, the ASP code, while ugly and hard to maintain, produces a reasonably nice-looking document. Doing the same thing in ASP.NET, at least using ASP.NET controls like FormView, is proving challenging. (One of the rewrite requirements is that the new page must function like the old page, minus bugs, of course.) The integration of the javascript to accomplish the editing functions on the client side makes for a good UX (assuming they work correctly). I can probably accomplish that same thing with AJAX and/or jQuery, but I'm wondering if I'm really gaining anything here.
How would you handle this?
You also have to take into consideration a couple of other issues:
How critical are the defects?
How
much time to do you have to get this
thing fixed?
How long will it take
you to correct the defects in classic
ASP?
How long will it take you to
convert the entire thing to ASP.NET?
At the end of the whole thing, will
anyone care which platform it's
implemented in? That is, will they
still be able to get their work done?
Because, at the end of the day,
that's all that really matters.
ASP.NET, while a wonderful thing, is not a silver bullet. If you're spinning your wheels, you're not being productive, and no one's getting a fixed product in a reasonable timeframe. It's like refactoring code just for the sake of refactoring it. It doesn't fix any defects, but darn does the code look pretty.
My advice to you: stick with classic ASP until you get the bugs out. THEN port it to ASP.NET. I'd much rather port a fixed product than a broken one.
That's a really complex question you're posing. The main issue is right there at the end:
I'm wondering if I'm really gaining
anything here.
Is the modification you need to make a small mod? or is it large? How much will you have to maintain this in the future?
You'll only realize dividends on your effort with future modifications. If you're never touching this system again, re-writing won't realize any benefits.
I have worked in projects in which we "converted" a classic ASP application into a .NET application. This is what we did:
Made a copy of the classic ASP files and then used the automated conversion feature from Visual Studio to convert this new copy into a .NET application.
Listed the .NET features we wanted to take advantage of in this new application and then found the correct places in the application to implement them.
Re-wrote code where needed to take full advantage of such features.
Refactored existing classic ASP code to avoid re-inventing the wheel where it was not needed.
Tested everything and then ran both applications in parallel until we felt comfortable that the new .NET application was running as expected.
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
For months, I've been considering downloading Microsoft's express web platform and learning ASP.NET, which I might actually enjoy, seeing as I already do web work with PHP, but am much more comfortable with C#.
However, the primary reason I don't want to do this is that I've always associated ASP.NET with useless spaghetti HTML. The link I posted is an excellent example. Would it be possible to use ASP.NET in a context more similar to PHP, using it to power my site but not leaving the HTML, CSS, and JavaScript to be done by hand for validation and semanticity reasons?
EDIT
I've decided I'm not going to learn ASP.NET and stick with PHP.
While MVC sounds nice, for me it will likely end up being a development/debugging headache.
Things get much better if you use ASP.NET MVC. I recommend you skip ASP.NET WebForms and jump to MVC directly.
If you are going to use Classic ASP.NET Web Forms, you really need to learn how it works to avoid truely ugly html. If you know what you are doing, you can get close to what you want (you can't completely get rid of ViewState & it will do some ugly thing with element IDs)
A lot of the ugliness of Classic ASP.NET occures when people write web forms like they wrote VB 6 Windows applications.
ASP.NET MVC is a good option. It may be the way to go as a starting point; I would like to switch to it myself. I guess my point is that you can get less ugly HTML using Classic ASP.NET.
you're really going to want to check out the asp.net mvc. it allows you to develop in a manner a lot more suited for the web than vanilla webforms.
First of all, ASP.Net, even using webforms, does allow you to have complete control over the markup output. Of course it's easier for some cases than others, but anywhere you find you're not getting the html you want out of a control you can always replace the render behavior with a ControlAdapter.
That said, as others have mentioned you'll probably find it's much easier to get the exact html markup you want using ASP.Net MVC.
MVC.net and WebForms are built upon ASP.net
You can get a decent amount of control with webforms by disabling viewstate and not using any controllers (or very few). Its all in how much you let it do for you
If you are looking to acquire skills in the latest and greatest, then MVC is where you should start but I would also consider whether you will ever be asked to support ASP.Net Webforms. Having an understanding of ViewState is crucial to that end.
For fine grained HTML output, you can produce this in many different ways with classic ASP.Net. There is a growing group of developers who are using a mixture of ASP.Net and microtemplating with Javascript to produce RIA's. This inevitably leads to keeping your html output cleaner so that it can be manipulated with jQuery and CSS.
Learn ASP.NET MVC as it will give you more control over the html generated. Also learning ASP.NET will increase your job opportunities significantly.
My first real development in ASP.NET was with MVC, and I must say I truly miss it now that I'm onto the next project using webforms. Each has it's place and webforms is working pretty well for what I'm doing (also using it as an opportunity to learn about TableAdapters and what not) but I really do miss being able to insert the data I need right into the HTML. That way I know the layout I've built won't get screwed up.
As a framework I enjoy ASP.NET quite a bit, but the controls on the page seems so far removed from anything resembling HTML that there is often a mental disconnect with what I'm typing with what I'm expecting to see. I was that way when I first started HTML though, so I imagine I'll get used to it. When I started with MVC it was overall a much more enjoyable experience coming from a front-end background.
There are lots of articles and discussions about the differences between ASP.NET WebForms and ASP.NET MVC that compare the relative merits of the two frameworks.
I have a different question for anyone who has experience using WebForms that has since moved to MVC:
What is the number one thing that WebForms had, that MVC doesn't, that you really miss?
Edit
No-one has mentioned the WebForms validation controls. I am now working on some code that has a few dependant validation rules and implementing client-side validation for these is proving slow.
As a PHP/Classic ASP person, I ventured into webforms world about 5 years ago. After having to handcode things like table grids, calendars, etc, in scripting languages, it seemed like webforms would be a tremendous helping-hand. It was...that is until you need even a slight bit of customization beyond alternating row colors and the like. Yeah, you could have a gridview running with a few drag-and-drop motions. But customizing even what would seem like a simple thing could turn into hours of torture and research.
I also think a lot of the examples given in .NET online are oversimplified for the effect of making webforms look "easy". Sure you can get that gridview to show only 10 records of a 100,000 record table, but do you realize that ALL of the records are being loaded into memory by default? As an example of the over-complicatedness of rectifying that problem, I spent a while creating a pageable gridview that only loads chunks of records, but it wouldn't work. After an hour of research, I found that you had to delete an extra property that the IDE inserts into the codebehind. Not fun when stupid stuff like that sets you behind.
And at every turn, it happens.
Don't even get me started on viewstate.
But then the clouds parted, and .NET MVC was handed to us. Now THAT is a framework. If you are a web developer, you should know whats happening when someone makes a request to your webserver. The abstraction and layer of cruft that webforms put on top of that is a disservice.
For the most part, I'm able to develop applications at the speed of PHP scripting and FINALLY have TOTAL control over the UI. That's what it's all about.
And as an additional note: People need to stop complaining that they are creating "tag soup" in MVC views when they find they have to use <%= %> tags and the like. Drag and drop your gridview onto the page, set all the properties, then view the crap it gives you. And your not nearly done yet, now you have to attach events and put more gridview-related code in your codefile. Talk about messing up the coding experience. I'll take a simple foreach loop anyday.
nothing :)
I really like the way ASP.NET MVC works. I want to control my HTML. I don't need controls. We can get the same functionality with HTML helpers and third party tools, e.g. jQuery and all the available plugins.
Here's an example on how to use a gridview-like with jQuery grid on ASP.NET MVC.
Although Ruby on Rails is a more mature framework, I do think that ASP.NET MVC is on the right track.
I miss the gridview, the simplicity of getting built in sorting and paging in with very little effort. I use grid functionality all the time and have still not found a good alternative in mvc
Well I do miss something :
the ability to have a pageable grid in seconds.
Although it wouldn't be very fair since I also had to create a class to feed to the ObjectDataSource to have an efficient pagination. And also the pagination would work only with the JavaScript on or I would have to write code to read the QueryString (for ex. &pag=2 etc.) and so on.
In fact... I guess there isn't much too miss.
The simplicity of having only one form on a page. I think the html form functionality is kind of awkward and not very intuitive and I guess there is a good reason why the webforms creators tried to abstract away form handling in webforms.
One difference, which I am sure will be rectified over time, is the expansive amount of reference material and examples online for web forms versus the relatively sparse amount for MVC. However, one could argue that a lot of the material on web forms covers topics such as the page life cycle which MVC no longer makes necessary (thank goodness).
Until now nothing really.
I definitely miss MVC every day at work while I look at the ugly WebForms code I want to wipe it all out and now make everything transparent, clean and beautiful.
Of course only time will show whether the new girl is really better than your old wife.
As crazy as it sounds, I miss the calendar control. Not for datepickers or that sort of thing, but for scheduling apps where you want to show a full page month-at-a-glance/outlook style events calendar with selectable or clickable links that you inject via the day render event.
If anyone knows of an MVC alternative, please share! Rolling your own in this case is doable, but kind of a pain.
Viewstate is the thing i miss - until i remember problems it causes.
Then i bend my mind and look for another approaches (smarter model binding, ajax etc.) which usually turns out to be better (but slower to find & implement).
The main thing I miss is the documentation. WebForms, because of it's relative maturity, has a lot of official documentation and also a lot of 3rd party examples and snippets available. However, this is improving all the item and, as MVC gains momentum, I hope it will be on a par.
Nothing as well.
WebForms do so much automatically but frequently I had to hack it to suit my needs.
MVC let me do what I want and I can hack it to get things done better/faster.
I love to control the output and prefer clean, lightweight style.
Output Caching is not really implemented in ASP.NET MVC (as of version 2). There are tricks to get it working, like using Web Controls with the OutputCache directive, or using WriteSubstitution, but all these tricks go against the nature of MVC in some way. Output Caching for anything other than entire action methods is really tricky to get working in ASP.NET MVC, and always induces enormous technical debt. Since Output Caching, especially in the newer versions of IIS, is incredibly performant compared to data layer caching, this is a shame.
simplicity in Dragging and dropping controls.
might be seeing some of this in the near future maybe in mvc4
Reference :- http://www.codeproject.com/Articles/808297/Things-you-will-miss-in-ASP-NET-MVC-as-an-ASP-NET
I will not say i miss because all the changes are happening for good. But yes i would miss the below
The lovely server controls who just give output in a blink.
The behind code file.Double clicking and going to the Code behind for some reason made me superior.
Viewstate magic.
Now i need to get in to headache of POST and GET.