[DaiPlusPlus]

I respect that WebForms had a decent concept for RAD, copying VB6’s “drag and drop components, write glue-logic to make them work together”, the problem is that you had to give up a lot of control over the generated HTML, which was a huge problem because the generated HTML was awful, like “1998’s HTML in 2006”-awful, to put it succinctly. WebForms supported item-templates, but using them was hard, and you still couldn’t override other HTML until Control Adapters came out, and even then it was a lot of work and very, very brittle. Oh, and so many third-party components embedded ancient versions of jQuery. It was a mess.

Other complaints about WebForms weren’t inherent to its architecture and should have been corrected early on, such as the lack of testability and over-use of [ThreadLocal] storage, and the nigh-impossibility of running WebForms outside of IIS, but these were never properly addressed by Microsoft, instead we had ugly band-aids like “BaseHttpRequest” and “HttpRequestWrapper”. Le sigh.

[aspnet_dev]

I will agree with some of your criticisms. However there are some things that aren't pertinent.

While the HTML is awful in earlier versions was IME of no concern. Most intranet apps just need to be functional not slick. I am sure it served different HTML based on the user-agent but I could be mis-remembering now as it was well over 15 years ago.

The lack of being able to run it on anything other than IIS isn't a concern. Most places using WebForms were Microsoft shops and whatever your opinion of IIS and Windows server maybe they weren't going to be running their ASP.NET app on a Linux server.

Most of the problems I've encountered was when people tried getting around the framework itself and rebuilding what already worked quite well within the framework (many people used to use large string builder objects in the code behind files in the page load event rather than using Web Components and building their custom HTML in there, I suspect it was because they didn't understand the Page/Component lifecycle).

I'm actually trying to get away from using .NET entirely (I am bored of the language, the frameworks and most importantly I don't like working with the developers who can't do anything outside of Visual Studio to save their life). But I do think the framework get unfairly maligned because of the quality of programmers that were using it. It is the same with VB.NET, the language isn't the best but the RAD aspect of it hasn't been bettered by anything IME.

[DaiPlusPlus]

> I am sure it served different HTML based on the user-agent but I could be mis-remembering now as it was well over 15 years ago.

It did - but the "different HTML" you refer to was HTML4 for IE5.5+ or HTML3 to browsers it didn't recognize. Even by 2001 that was a bad idea, and by 2004 Firefox was leagues ahead of IE6's support for HTML and CSS features yet ASP.NET WebForms defaults to rendering HTML3-era HTML to Firefox.

...and don't forget all of the problems inherent in user-agent sniffing. Users with too many third-party IE toolbars or shovelware on their computers would see things break (because said third-party software would frequently alter IE's default user-agent string to add their own product-names, which broke things).

> The lack of being able to run it on anything other than IIS isn't a concern

It was a *huge* concern because it meant that web-application code could not be run by automated testing tools! That was one of the design-objectives when OWIN was introduced: for greater testability (for unit and integration testing). Otherwise the only way to test WebForms applications was by having a dedicated web-testing farm with web-browsers open on the desktop driven by custom-written automation tools - that just wasn't an option for smaller shops. And Visual Studio didn't add built-in unit testing support until 2005 (only for Enterprise edition), and 2008 (or 2010?) for everybody else.

Another problem was that in the days of WebForms 1.x (before .NET 2.0) the only way to run ASP.NET applications, even for development, was by having IIS installed - but IIS was not available for Windows XP Home Edition (ASP.NET 2.0 introduced the "Cassini" local development web-server, but it was severely lacking and did not faithfully recreate the IIS environment, and IIS Express wasn't introduced until around 2008). People doing hobbyist development at home had to either pay to upgrade to Windows XP Professional (to use the rather limited IIS "5.1") or apply a variety of crude registry hacks to trick the Windows 2000-era IIS 5.0 to run on Windows XP Home Edition.

> Most of the problems I've encountered was when people tried getting around the framework itself and rebuilding what already worked quite well within the framework

What works "quite well" is subjective. ViewState just doesn't scale and is unsuitable for public Internet websites because it balloons the rendered page-size (e.g. if you have an <asp:DataGrid>, used as-directed such that it's only loaded on the initial page laod) then the entire data-grid's data is persisted in ViewState, which practically quadruples your rendered page-size (due to all the hidden control state) - which was unacceptable in the days when 56K modem use was still widespread (even through to ~2006+). Disabling ViewState was essential for any public web-pages, which increased the amount of work required to get things to _just work_. I could go on...

[aspnet_dev]

> It did - but the "different HTML" you refer to was HTML4 for IE5.5+ or HTML3 to browsers it didn't recognize. Even by 2001 that was a bad idea, and by 2004 Firefox was leagues ahead of IE6's support for HTML and CSS features yet ASP.NET WebForms defaults to rendering HTML3-era HTML to Firefox.

Intranet sites were run on highly locked down machines that were running IE. Don't pretend everyone was running their own browser on their machine. As I said it was intended for intranet sites, all the documentation and all the examples at the time clearly showed these user cases.

> ...and don't forget all of the problems inherent in user-agent sniffing. Users with too many third-party IE toolbars or shovelware on their computers would see things break (because said third-party software would frequently alter IE's default user-agent string to add their own product-names, which broke things).

So they were running third party things and it broke something else that had no knowledge of them. If someone runs hundreds of chrome extensions and it breaks my site, I wouldn't bother supporting them either. The situation isn't any different.

> It was a huge concern because it meant that web-application code could not be run by automated testing tools! That was one of the design-objectives when OWIN was introduced: for greater testability (for unit and integration testing). Otherwise the only way to test WebForms applications was by having a dedicated web-testing farm with web-browsers open on the desktop driven by custom-written automation tools - that just wasn't an option for smaller shops. And Visual Studio didn't add built-in unit testing support until 2005 (only for Enterprise edition), and 2008 (or 2010?) for everybody else.

Almost none of the shops were doing automated testing at the time. People barely do it now in the .NET space.

>Another problem was that in the days of WebForms 1.x (before .NET 2.0) the only way to run ASP.NET applications, even for development, was by having IIS installed - but IIS was not available for Windows XP Home Edition (ASP.NET 2.0 introduced the "Cassini" local development web-server, but it was severely lacking and did not faithfully recreate the IIS environment, and IIS Express wasn't introduced until around 2008). People doing hobbyist development at home had to either pay to upgrade to Windows XP Professional (to use the rather limited IIS "5.1") or apply a variety of crude registry hacks to trick the Windows 2000-era IIS 5.0 to run on Windows XP Home Edition.

So on an operating system that was intended for consumer use, they couldn't use advanced stuff like IIS that the home user wouldn't have any use for? Seriously?

> What works "quite well" is subjective. ViewState just doesn't scale and is unsuitable for public Internet websites because it balloons the rendered page-size (e.g. if you have an <asp:DataGrid>, used as-directed such that it's only loaded on the initial page laod) then the entire data-grid's data is persisted in ViewState, which practically quadruples your rendered page-size (due to all the hidden control state) - which was unacceptable in the days when 56K modem use was still widespread (even through to ~2006+). Disabling ViewState was essential for any public web-pages, which increased the amount of work required to get things to _just work_. I could go on...

None of this was intended for sites on the internet. I was specifically talking about the RAD tooling. Yet you seem to be talking about things it was never intended to do at the time.