ASP.Net vs. Front-End Architecture

All of that is one of the reasons I never tried to learn .NET and just stuck with classic ASP. I’d rather have complete control over the front end code than an easier time with the backend stuff. Of course, I’m not that extensive of a developer, so I’m probably not the target demographic for .NET.

This is why I have switched to MonoRail for all of my .Net websites and RoR everwhere else.

I had these exact problems with .NET when I was working at MySpace and they were working on their first .NET application. There are ways around the default behaviors, but most of the time developers don’t use the workarounds, because it makes it harder for them to continue using .NET the way they’re used to it.

On the upside, where I work, I am currently surrounded by very knowledgeable .NET people, and they almost always work with client-side in mind, even going so far as to write their own controls, just to maintain the initial markup that client-side created in the static mockup pages.

I’m an avid .Net user and I couldn’t agree more, it’s horrendous. The trick is to leverage the .Net framework (which really is a thing of beauty) and disavow as much of the rest of it as you possibly can. Just above the framework you have what I lovingly refer as “the miracle tier” where MS tries to “help” you. Every time they try to help, they screw it up. Every. Time. They just don’t get it. All that “help” is designed for VB6 folks who want to make a “web application” for their intranet. Typically a 1 or 2 tier kludge on top of a DB. Everyone else (read: serious web developers) are left cold.

There’s a real art to exorcising the miracle tier – and it can be highly frustrating. But it can be done. Dave Greiner, for example, does a bangup job.

Like Joshua, I still like classic ASP. The rigidity of .NET isn’t the most fun for me to work in although tools like the Visual Studio Web Developer make it easier. I’ve usually just gone with my own coding style in lieu of the built-in components. That’s worked so-so but it confused developers coming onto the project after me.

Though I’ve heard horror stories about .NET 1.0, luckily since I started .NET development I’ve been able to work exclusively with 2.0. However, I still don’t understand the need to completely steal the form element for its own devices. Not only has the semantics of my page now been completely hijacked, but it prevents me from including and having control over my own forms. Gosh, who would ever want to add a search form and have it not post back to the same page?

You’ve managed in your post to succinctly summarize what I didn’t even know was the source of my frustration with the .NET framework—

In creating a powerful framework, ASP.Net has shown either a complete disregard for or a total ignorance of front-end code that is virtually unsurpassed.

Yes, .NET exhibits a complete disregard for how excellent front-end code is architected. It shows a disregard for front-end coding patterns. It even shows a substantial ignorance of how people use websites.

I agree that the “miracle tier” is really the culprit here; the (major) company that I work for goes to great lengths to circumvent the resulting markup that is generated by it. And although it interrupts the “normal” programmer/designer workflow it eventually becomes second nature to employ all the little fixes and tricks and workarounds.

Another thing is that ASP.NET 1.1 used the HTML 4.01 DTD (sorry I don’t have a reference on that point). It wasn’t intended to generate “standards compliant XHTML,” just plain ole HTML 4.01. 2.0 is waaay better on all of these accounts. And I love working with it.

Very timely post. I had to spend this morning rewriting some custom javascript because a colleague renamed a control. If you do any serious javascript work and believe in separating it from your html, you are in for some fun with ASP.NET. Because of the automagic generation of IDs, it’s extremely difficult to keep your js in separate files since they have no way of knowing what the ids are.

I really do like may aspects of developing with .NET, but there are some major frustrations to be encountered for “front-end architects”.

Because of the automagic generation of IDs, it’s extremely difficult to keep your js in separate files since they have no way of knowing what the ids are.

The way that I used to circumvent this problem was to create all of my javascript in a separate file, and then in the head I would create a small block of script that would create local variables that I would reference in my external script using the ClientID property.

> Different Server-Side Output for Different Browsers

This can be a real annoyance (in ASP.NET 1.0 / 1.1) and is caused by the built-in browser detection (browserCaps), designed to render output that is supported by the user-agent.

http://www.codinghorror.com/blog/archives/000069.html

> Horrible Markup Decisions

Just in passing for those that haven’t already discovered, there is a project called “CSS Control Adapters” (sponsored by Microsoft) that aims to address some of the output of built-in ASP.NET 2.0 server controls (ie. replace table-based layout with CSS).

http://www.asp.net/cssadapters/

Still in Beta stage at the moment but looks promising – and shows at least an understanding that some .NET developers care about the resultant markup.

We struggle with this on a daily basis where I work. We’re a Microsoft shop, and that’s generally a good thing, but when us CSS developers have to spend hours diagnosing bugs that get tracked down to an errant span tag, or the entire page being wrapped in a form element, it gets pretty frustrating.

Our programmers have told me that we can have any code output that we want – at the cost of doubling or even tripling programming time, because they have to write their own controls instead of using the stock ones. Still, we’re pushing hard to have the program output the same source code we write in our templates.

Garrett, you’ve just given words to the frustration I’ve been feeling more and more these days – although you don’t have postbacks on that list, which is one of my major irritations.

I have created a few controls of my own with cleaner source – to some extent mirroring a little of Rails’ ActionView form helpers – but nothing major enough to replace, say, the GridView. While Rails heightens my annoyance with ASP.NET, it also gives me some ideas for how to make it more bearable.

Agree completely. ASP.NET 2.0 is a major step-up from 1.0 though. You needed the emotional self-control of a ninja to work with that beast. It was a practice in anger-management.

Can anyone point to some resources where there are workarounds for these problems?

I’m not sure if this is still the case in ASP.NET 2.0, but previous versions also produced sites which didn’t work if JavaScript was disabled. IIRC, some of the standard controls that would be used for navigation relied on javascript: URLs, although I don’t remember ever seeing this documented by Microsoft; the architects seem to have assumed that anybody who had JS turned off wasn’t worthy of seeing an ASP.NET site. It all tied in with the “miracle tier” ViewState stuff that’s responsible for so many of the other problems you list.

Create a Filter and assign it to Response.Filter to manipulate the junk code with Regex.

Best option for working around the ASP.NET crap is to write your own HttpHandlers and Server Controls like the MonoRails project has done. The WebForm model that ASP.NET uses by default is built on top of the IHttpHandler interface. For me the important part of .NET is the base class library (BCL) which give you lots of objects not available in classic ASP.

You can actually make your HttpHandler inherit from the Page class and have all the Controls.Add() goodness that ASP.NET offers. This methodology does away with the postback capability, but in many cases I need multiple forms per page and the trade-off is worth it.

Gosh, who would ever want to add a search form and have it not post back to the same page?

Nicole: OMG. You just captured a moment of extreme bafflement between me & the IT guys (who do .Net on the intranet while I do PHP on the internet). They worked out a shiny (!) new search page for our intranet, only I can’t just drop it in as a simple search form on the home page like I do for our public site. Nor can I put in an interceptor form to allow simultaneous searching of pages and directory.

I just don’t understand. :(

Heh, I’ve encountered all those growing pains as well when moving from PHP to ASP.NET.

As has been said already, .NET 2 is a big step up, but it still makes some things such as clean URL’s needlessly difficult.

When you set a form to ‘runat server,’ .NET will render its ‘action’ attribute to ‘current_page_name.aspx,’ even if you have served the page without an extension (‘current_page_name’).

The workaround is to either not use the server form tag… along with any ASP.NET controls; or write your own form control that inherits from form and overrides its rendering. Such a pointless decision by Microsoft.

You can still benefit from .NET without using runat server forms though. The raw POST and GET values are accessible. E.g.

1. Inline Style Tags
Although I’m not going to advocate using inline style tags first, they do perform faster in a number of ways. CSS has to be loaded and after load, each object containing the class must be initialized—with a lot of content and data coming down the pipe, this can actually slow the user experience. I did a perf-tune project recently where images in the CSS file were increasing the page load time by enough that with a heavy load, the site took 10-20 seconds to load

2. Different Server-Side Output for Different Browsers
I’m going to guess that it wasn’t a panel tag—a panel is simply a control that wraps a bunch of child controls with a div tag that has an ID. However, there is a difference between the way IE and other browsers render CSS margins and padding. If IE were changed, many web applications would be messed up for users—and none of us wants to rewrite existing, functional apps to handle that change.

3. Horrible Markup Decisions
This is obviously your opinion. The rendered output is efficient when you take into account that it is XHTML compliant and is reliable when you consider its wide audience use. Remember, you can always inherit from the control you’re questioning and render the output the way you see best for your application.

4. No Use of Semantics
Maybe I’m wrong, but I believe some of those tags have been deprecated in the XHTML construct. In fact, those tags are what I consider “horrible markup decisions� (excluding the tag).

5. Server-Side Label vs. Client-Side Label
The client side tags are meant to handle cases where you are transitioning an application from straight HTML or another system—take PHP, for instance—to ASP.NET. It’s very simple to just put runat=�server� on tags you want to make server side and you’ll get the same result. This construct was created in the ASP.NET 1.x framework and is still supported in the ASP.NET 2.0 framework.

6. Server-Side ID’s vs. Client-Side ID’s
Client-side IDs are modified to handle different event data, such as the post-back. This is necessary not just for ASP.NET, but to comply with XHTML standards as well as maintain a usable DOM hierarchy. Furthermore, since user controls can be reused on the page, you would not want them all the have the same ID, so why would you put CSS identifiers in for IDs? Lastly, user controls are nothing like server-side includes (SSI). SSI is a process that includes items into the page before the page is processed. User controls can be added at any time. They can be inherited, extended, and instantiated on-the-fly. You can perform server-side caching on user controls which allows them to be stored in local IIS cache.

I would like to mention some of the failures of the ASP.NET 1.1 framework. The tools provided were not enough to make it easy for a front-end designer to build streamlined HTML. Also, you could not inherit from TemplateControlParser and make your own directive tags. Fortunately, we now have ASP.NET 2.0 and Visual Studio 2005, which alleviates both of those challenges. In addition, it adds in a slew of new controls and with the upcoming Atlas controls (http://atlas.asp.net) you can have AJAX functionality all by adding a simple UpdatePanel control around your ASP.NET code. I really think that with the Web 2.0 frameworks coming out and the ease of using VS 2005, productivity is substantially increased in web application development.

Most importantly, I think the ASP.NET team that developed the controls for .NET did an AWESOME job. It was a lot of work to develop these controls so they were easy and extremely usable. I don’t think it was very kind to say that they made poor design decisions or that they did a lazy job coding these controls—that work has taken years and hours upon hours of testing. Please be kind when your evaluating someone else’s hard work.

Check out my blog here: http://blogs.msdn.com/sumanc

Suman – I honestly believe that you think your response here validly addressed Garrett’s concerns. And that is precisely what scares me to death about Microsoft.

Suman, in response to your points:

1 Images included via a CSS file (background images), are (in most browsers) loaded after the page content and any normal images included via the IMG tag.

The idea being the important content is loaded before superfluous decorations.

2 I believe Garrett is correct. The PANEL control renders a DIV to ‘advanced’ browsers, and TABLE to ‘backward’ browsers, including Firefox. It was because this effect broke my styles that I even discovered browsercaps.

4 To give an example of a control that doesn’t serve semantic HTML, take the DATAGRID. It writes out a TABLE tag, yet uses TD for the column headings instead of TH. I’m sure the control knows they are headings; this is pretty basic stuff.

5/6 These two points relate to a problem I had just recently. I tried to use a REPEATER to write out a list of people’s names with a checkbox beside each. Of course, I wanted to add an HTML LABEL to associate each name with its corresponding checkbox. To do that properly though, the LABEL needs to have its FOR attribute set to the ID of the checkbox.

The whole thing proved a huge hassle. There is no ASP LABEL (of the HTML kind), and I couldn’t predict the checkbox ID’s the control was going to generate. I ended up having to use HTML checkboxes rather than the ASP control kind, and had to call a method that generated an ID based on the person’s name. I could then call that method in four places; to write the HTML checkbox ID, the checkbox NAME, the LABEL FOR value, and, in the code-behind, I had to use it as in index to fetch the posted value from Request.Form[].

All up, I would never say the developers were lazy, but I agree with Garrett’s sentiments that .NET (1.1 in particular) neglected client-side developers a bit.

P.S. A solution to point 2:

Use Placeholder instead of Panel (which renders a DIV), and Literal instead of Label (which renders a SPAN).

Sorry to triple post, but I should have been more clear on my P.S. Feel free to delete it Garrett. What I should have said is:

Use Placeholder (which doesn’t render an HTML tag) instead of Panel (which renders a DIV/TABLE) when you want to nest things inside it.

Use Literal (which doesn’t render an HTML tag) instead of Literal (which renders a SPAN) when you simply want to write out a string.

Suman’s post also scares the hell out of me. It’s an extremely defensive arguement; I don’t think any developer with half a brain would defend .NET. Version 2.0 seems to answer a lot of issues, but version < 2.0 – I wouldn’t use it if I was given an option (work demands it though).

I skimmed the comments so if I’m repeating – my apologies. :)
Garrett – pretty much every complaint you have is not directly related to the .net framework but to Visual Studio.net . That’s an IDE with a lot of dependencies. VS.net 2k5 still won’t generate code to XHTML Strict. Using it is a choice. If you don’t like the output/code rape that VS.net does to your front end then don’t use it. Do it by hand and compile from the command line or use a tool like #Develop that gives more control. To use that stupid sports analogy – “Don’t hate the game, hate the player”. I’ve been using .net since 2001 and don’t have the issues you address at all. All because I don’t use VS.net. Easy fix.

I’m realizing that no one who is negative about it has honestly built an application using .NET yet. You couldn’t have if you are pointing out things that are handled for you already.

A solution to point 5/6.
The CheckBox control already has a text Property that has the label-for construct. If you don’t like the control, create a new one that facilitates your needs and writes out the HTML the way you want it to work. Your inability to use the CheckBoxList control also daunts me—bind it to data, that’s it, you’re done. All item’s state is already managed, and you don’t have to keep track of it. From the server side, you just say MyCheckList.SelectedItems[n].Checked to get the boolean value back.

Also, you meant to write “use Literal[Control] in place of Literal” which is a good construct when you are programmatically adding text to a page. The Label control is meant to be familiar to those with WinForms development with the web site. If there are any controls that you feel are missing, you can create a System.Web.UI.HtmlControls.HtmlGenericControl which has a parameterized constructor that takes a tag name.

Software development is like government, you can’t satisfy everyone, but you have to try your best. And, this argument has turned into the age-old programmer argument “If you’re not programming in Assembler, then your code is crap.” I think we can all agree that if we coded in Assembler all the time, business applications wouldn’t exist, XBOX and PS2 would take several more years to develop, the computer age we enjoy would not exist. Maybe you agree with that and it shouldn’t, but I have a life, so I like the productivity that’s evolved to give us rich development tools.

I kinda feel like I’m being ganged up on, here. I am a developer with more than half a brain who has coded for the web in ASP.NET, ASP 3.0, PHP, JSP, and even ColdFusion. It took me a while to like .NET, but once I understood the paradigm, it just works, and I love it. I haven’t insulted any of you, but you’re attacking me personally.

Also, I want to understand what your “fear” of Microsoft is? We’re a company that makes software, not a warehouse that sells everything under the sun at half the cost and doesn’t pay its employess. Because we have such a big market, we are a target for anti-Microsoft stuff and people will double their standards to justify “taking down Microsoft.” We were sued in Europe for having Windows Media Player in Windows XP, but Apple is allowed to come with iTunes.

We empower you with the tools that make your life easier, and furthermore, many of our tools are your bread & butter.

Lastly, although everyone seems to have told me I’m stupid for liking .NET, the performance statistics are better with managed code and productivity is better with Visual Studio and .NET. Not one of you has been able to deny that, and when companies go to build their applications, what they care about is reliability, security, productivity, and go-to-market. If you think that’s a problem (which I will concede on this point), you should construct your argument at the people who are asking us to develop this software.

Anyways, take care, and be nice. I’ll respond to Garrett, but I don’t want to respond to the negative comments I’m getting.

All because I don’t use VS.net. Easy fix.

Brandon, I’ve found that in most situations using .NET for web applications without using Visual Studio is a non-starter. ASP.NET and Visual Studio are aimed at a much wider range of developers, and those developers use the tools the way Microsoft intended. I honestly believe you need a very strong argument and an expert team to diverge away from the Microsoft way when doing ASP.NET web applications in a large enterprise. There simply is too much justified resistance to not doing it the Microsoft way.

I’ve been using ASP.NET since the public betas, and I know why Microsoft made the decisions they did. In almost every way it is an improvement over what was there before. And Microsoft has innovated in the web framework space. The Provider Model is awesome, some of the best software design I’ve seen in a long time. Declaratively wiring together ASP.NET controls and my data source objects is a thing of beauty, as long as you do things the Microsoft way. But you do give up the things that Garrett stated regarding needs of a Front-End Architect. ASP.NET and VS do not adequately address this, and I’m not holding my breath for them start.

(Viva Rails!)

Suman, I’m sorry for any negative or personal comments you’ve gotten. I certainly don’t feel that way. I’ve used and loved .NET from its inception. Its a wonderful all-purpose framework that has made my life so much better the past five years. That said, I have become increasingly frustrated with ASP.NET, even as it has made tremendous progress with ASP.NET 2.0 and Atlas.

Some of the frustration that I’ve had with ASP.NET is how the controls decide to render HTML. I understand that Microsoft wants the HTML to be as backwards compatible as possible, because ASP.NET would not have been adopted if it hadn’t. So ASP.NET abstracts those decisions from the developer, but it is the Front-End Architect’s job to make those decisions. ASP.NET has not yet done a good job of allowing you to disagree with its assumptions. The CSS Adapters is a great first step, and exists because people have recognized the valid need to control the HTML rendering, but it isn’t part of core ASP.NET yet.

Your CheckBoxList example is a great one. It renders a list of [input id=”blah” name=”blah” type=”checkbox”][label for=”blah”]Whatever[/label] separated by [br /]. But what am I to do if my CSS is written in a way that I need it formatted with the label around the input tag and in a bulleted list like [li][label][input id=”blah” name=”blah” type=”checkbox”]Whatever[/label][/li]? (Please replace [] with angle brackets.) This seems like something I should be able to configure, and I have to take the time and effort to find a different solution. This has means that I no longer can use a CheckBoxList control, and I have more C# code to write, debug, and maintain. This is a simple example, but I hope you can respect how much pain (“pain” as in additional development time) decisions like this has caused me over the years.

I’ve also struggled with the Page Controller pattern. When I first started ASP.NET I expected a MVC type pattern, and I have been frustrated by its absence ever since. My feeling is that ASP.NET’s sweet spot is between the non-structured solutions of ASP/PHP, and the well structured solutions of Rails/J2EE. I feel this decision was made so Microsoft could position ASP.NET as all things for all developers. I probably would do the same thing with Microsoft’s vast user base. But when I really need a well structured solution I have to change my strategy to accommodate ASP.NET, because it isn’t as natural a solution as others.

But I continue to be paid to deliver ASP.NET solutions, and I will continue to do so in the best way I can. It isn’t perfect, but it is better than most. But it isn’t perfect either, especially for a Front-End Architect. I’m glad Garrett has gotten your attention with this post, I do agree with his sentiments.

You’re speaking my language now. Ok, the real problem is that you want future versions of controls to offer more support for styling the base controls. This is certainly possible and if I were you, I would post it as a question to Nikhil Kothari, who is the Software Architect and Program Manager for the ASP.NET controls—he’s written an awesome book on controls, too! His site can give you access to ask questions, but be patient, he’s obviously a very busy man (www.nikhilk.net).

Suman, regarding the CheckBoxList control, I wasn’t aware of it (I’m sure it’s not the only control I don’t know about either—I certainly knew about the RadioButtonList, but that’s because a lone radio button makes no sense). I also didn’t notice the CheckBox Text property writes out to an HTML LABEL. Both are useful things I’ll remember.

So if you were simply dealing with a TextBox or DropDownList instead, how would you go about creating an HTML LABEL when it is contained within a repeater? I’ve noticed this works for a control:

string labelFor = txtTextbox.NamingContainer.ID + ”_” + txtTextbox.ID;
htmlLabel.Attributes.Add(“for”, labelFor);

Anyway, I’m happy to concede points (you shouldn’t let it daunt you), and as has been mentioned a few times; most of the problems Garrett mentioned are with the ASP.Control’s rendering rather than ASP.NET itself. But they are problems, and the solution seems to be “don’t use them,” or “improve them yourself—create your own inherited controls.”

It’s a lot of extra work because you care about the client-side code. I still like working with .NET though.

After reflecting over the weekend I’d like to appologise to Suman if my comment was personally offensive. His opinions of course are completely valid – I still disagree with most of them, but not Suman.

Now i’ve gotten that off my chest, what’s everybodys most commonly used ASP.NET control? Mine – the Literal (because it doesn’t generate tag soup).

Mine is the Placeholder (like the Literal, there is no tag attached). I like to switch ‘panels’ of HTML on or off rather than populate a control from the code behind.

That’s simply because of the frequency of content changes though. :)

Definitely the placeholder. We’ve written a custom placeholder control that avoids some of the name conflicts of the asp:PlaceHolder, but it’s an indispensible control that lets me control the markup that my code generates.

Our site is driven by a state machine, and is pretty much totally MVC, so it has a much better page model than .NET out of the box.

I’ve found that it’s totally possible to produce beautiful, semantic markup in 1.1. In fact, the only stuff that doesn’t validate is the database content, which comes from a CMA that doesn’t do character encoding and allows the client to enter sometimes invalid HTML.

To do this, we’ve had to write our own controls, but C# is a great language and it’s really not that difficult to do. We render raw, semantic HTML with server controls and data, and use CSS and JavaScript to manipulate the markup.

A framework is a tool. If you use everything .NET and ESPECIALLY Visual Studio provides, you’ll produce crappy front-end code. Most people do. If you take advantage of a good framework and a great language, you can use .NET to its full potential and be a great front-end architect.

what’s everybodys most commonly used ASP.NET control? Mine – the Literal (because it doesn’t generate tag soup).

Mine is the HtmlGenericControl (of the System.Web.UI.HtmlControls persuasion) :) You can slap a runat on anything (as Suman mentioned)! Add an id, and voila! the only “tag soup” you’ll have is the tag soup you make on your own.

I ran into the same problem that many of you did. I said “What’s a label doing here if all it does is render a span? I dug and found it has a property called AssociatedControlID that, if filled in, will automagically turn it into a client label tag with the appropriate for= attribute.

Form Label:

Most of the inline styles I’ve seen applied by the IDE is when a developer tries to style it using the properties panel. I’ve instructed them to leave styling out of it and use only CSS classnames, and this has worked out well for them as well as us (design department).

AssociatedControlID was added in .NET 2 unfortunately.

I’m realizing that no one who is negative about it has honestly built an application using .NET yet. You couldn’t have if you are pointing out things that are handled for you already.

Suman, do you honestly think there is nothing in .NET that warrants criticism? I work with it daily, and have plenty of negative things to say about the markup these controls produce.

It was a lot of work to develop these controls so they were easy and extremely usable. I don’t think it was very kind to say that they made poor design decisions or that they did a lazy job coding these controls

It might not be kind, but it’s certainly a valid point of view. You’re right, .NET controls make it very easy to build websites, just like GoLive and FrontPage do. Unfortunately, the markup they use to get the job done is just terrible, and .NET’s controls are the worst of the bunch, IMO. I’m looking at the output from a DataList right now, and it’s a total train wreck.

I really hope you don’t take this as a personal attack, because that’s not my intent, but please realize that, to those of us who work the front end with a sense of craftsmanship, there is a right way to do things, and .NET flat out makes our jobs more difficult.

Did everyone skip over the link to the CSS Friendly ASP.net control adapters?

http://www.asp.net/cssadapters/

Control adapters seem to fix all the problems everyone is having.

Yeah, I just realized that today, Johann. It’s funny that it got passed over, because it’s definitely the answer to all the gripe.

Pretty much sums up my issues with .NET as well, Garrett.

There’s a lot of hype, and marketing around .NET. Sure, it’s an awesome framework, with support for several languages and you can build executables as well as web applications from within the same framework. Still, there’s a lot of odd choices. It promotes a lot of drag and drop features. More or less locked to the Microsoft platform, and I’m pretty sure Mono won’t be an enterprise level solution either.

The glorification of compilation and the general misconception that .NET would be a better framework simply because it’s a programming network. There are plenty of web frameworks, CakePHP, Ruby on Rails, Django, etc, etc that makes it a lot easier to output good, and controlled client-code.

CSS Adapters isn’t the solution either, IMHO. Not if you want total control over your controls. Then it’s back to writing your own, and at least doubling production time. So while writing a custom datagrid control, a Ruby developer can run his scaffold command and get cleaner code ASAP.

I am relatively new to ASP .NET, and I must say I share a lot of frustrations described here. As a seasoned web developer (I worked in ASP and ColdFusion for many years), I developed my own programming style over the years – a framework for tying it all together: client and server side logic. Now that I moved to .NET I’m finding I have to trash it all and start from scratch, I feel like years of experience wiped out of my job history.

Further, my career path was taking me higher up the ladder – I was finding myself concentrating more on business side of things, serving as a team lead, since I’ve mastered the technical details completely. Now I’m thrown years back debugging Javascript and CSS trying to get it to do something that took me minutes before – now is taking me hours. I am farther than ever from the team lead or project lead role, having to concentrate on technical details rather than business. Perhaps, it’s just my learning curve, but I’m having my doubts now whether I want to be thrown back like this… One definite advantage of .NET I see so far is the powerful backend framework for implementing your business layer in a true object-oriented way – a huge step forward from mishmash of UI, database and business logic all mixed in script pages before. But that’s it. This is huge, but other than this – don’t tell me about improving programmer productivity – I wonder if anyone measured how much more it costs companies to develop software in .NET. Thank god for project managers not understanding technical details – otherwise, we’d all be still doing ASP and ColdFusion, because no budget-sensitive manager would allow for tasks to take hours that can take minutes.

Having recently just moved from ASP to .Net 2.0 and painfully converted a not insubstantial amount of code (for a one man shop so to speak) I have to admit that .Net 2.0 is an extremely steep learning, especially isf accessibility is a concern. Previously I was generating all my front end code via XML/XSL, but with .Net’s controls it is too tempting not to use them. However the output is not great and does produce needless tags.

Suman, I am still far down the learning curve and no expert, but I can’t help feeling ASP.Net 2.0 could really have made a massive impact (on the scale of RoR) in the Web 2.0 world if it’s controls would have been defaulted to produce semantic and accessible output. Instead most of what you read about ASP.Net 2.0 is “don’t use it if you need accessible markup”. Is this what Microsoft intended? I don’t want to have to re-configure the controls, the output should be semantic out of the box.

.Net is a great framework and the ability to bind your dataobjects to user controls is great and saves me a huge amount of time. But I sometimes feel I then waste an equal amount of time trying to solve really simply things like linking the asp:label control to a form field. Why does this control change the tag it outputs from span to label when you specify the AssociatedControlID. I do not have an intimate knowledge of all the in built asp.net controls and when I saw the output of asp:label was a span I initially gave up on trying to use this control to link text to form fields. But then I thought (as with most of my problems!) that I’m probably not the only one who’s had this problem and landed on this blog post with the solution – after 1 hour of looking. If the asp:label always produced a label I would have checked its properties more thoroughly initialy. It is this kind of inconsistency that can be really mind boggling for “experienced” .Net 2.0 newbies.

I never seriously considered using ASP.NET just because of the mess in the front-end.
Drag-and-drop design and default controls might be great for WinForms, but I don’t think it is possible to adapt them for HTML+CSS without losing flexibility. I personally want control over my code, therefore I use XSLT for templates.
Imitation of event-driven programming on the web is also not an elegant solution because it tries to go against the request-response nature of HTTP.

Totally agree! It is a really poor decision to ignore the client side.

One example I am working on is to move items between two listboxes and move items inside the list. Yes, we could use all server side event to make it work. But think about the overhead it put on server when the user only move some Option items inside the list box. If one item is to be moved from index 10 to the top and the user clicks 9 times a “move up” button, then 9 times postback to server at least! WHY? the design logic is wrong! To me, all these moves should be client-side’s job and should not cause post-back and the page should not go through the whole life cycle 9 times!. Of course, some callback technique can be used to save some postback. But that also need some work.

Because of the unnessary postback when when it is supossed to be just client-side work, I do not use the server-side’s onClick event. I have made some javascript to move items on client side (using onClientClick event). Everything looks great on the browser. But when you create OK button and think to let the server to get the values you have seen in the browser, you cannot get it!. This is against WYSIWYG.

Then a new issue is to share information between client and server. I have to create a hidden variable ….

It is supposed to be very simple logic. If it is server’s job, leave to setrver. But if it is supposed to be client-side job (like moves option items around before the value in the list is actually to be used), leave it to client to handle it! Give a simple way to pass the values back the server when the client is done!

It is really a stupid Microsoft design for this missing communication between client and server. It is either too lazy to think what the real world is, or not responsible, or … I just feel that it really damage the name of “Microsoft”.