3 ms·

> Debugging JS in IE6 Visual Studio (even back when it was called Visual Interdev) supported first-class script debugging with Internet Explorer going as far

> Debugging JS in IE6 Visual Studio (even back when it was called Visual Interdev) supported first-class script debugging with Internet Explorer going as far back as Internet Explorer 4. Ditto cscript/wscript. It just wasn't popular (and few people knew about it) because most people doing front-end web-work _back then_ weren't using Visual Studio, and in general most people weren't doing back-end web-work in Visual Studio either because (pre-ASP.NET MVC), ASP.NET WebForms is, was, and ever-shall-be, godawful.

bastawhiz 6y ago
This didn't really help with the DOM or CSS, though. The developer toolbar that worked with IE6 was sorely lacking.
- DaiPlusPlus 6y ago
  I think you could explore the DOM tree in the Document Outline window of VS and see node properties in the Properties window, but that could be a false-memory of mine - it's also completely undiscoverable, even today. Support for CSS "debugging" was completely absent, yes.
diegof79 6y ago
I used Visual Interdev, but the debugger experience was bad: it was slow to start, and many times it didn’t worked (when it worked it was fine). I’ll add that to the other valid reasons that you mention.
aspnet_dev 6y ago
WebForms is still one of the quickest things to actually build intranet applications with and it still does it incredibly well. If I wanted to have a editable table (datagrid) control it literally took about 20 minutes and I had something working and people could use it. The problem with it (much like Angular which btw is basically webforms for JavaScript) is that it required you learning how the event lifecycle worked properly. Whereas other things at the time were web scripts and you could just hack against. It of course had a lot of problems (like everything on the web at the time) but for what it was actually intended for, it was actually really good.
- DaiPlusPlus 6y ago
  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 6y ago
    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.

bastawhiz 6y ago

This didn't really help with the DOM or CSS, though. The developer toolbar that worked with IE6 was sorely lacking.

DaiPlusPlus 6y ago
I think you could explore the DOM tree in the Document Outline window of VS and see node properties in the Properties window, but that could be a false-memory of mine - it's also completely undiscoverable, even today. Support for CSS "debugging" was completely absent, yes.

diegof79 6y ago

I used Visual Interdev, but the debugger experience was bad: it was slow to start, and many times it didn’t worked (when it worked it was fine). I’ll add that to the other valid reasons that you mention.

aspnet_dev 6y ago

WebForms is still one of the quickest things to actually build intranet applications with and it still does it incredibly well. If I wanted to have a editable table (datagrid) control it literally took about 20 minutes and I had something working and people could use it. The problem with it (much like Angular which btw is basically webforms for JavaScript) is that it required you learning how the event lifecycle worked properly. Whereas other things at the time were web scripts and you could just hack against. It of course had a lot of problems (like everything on the web at the time) but for what it was actually intended for, it was actually really good.

DaiPlusPlus 6y ago
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 6y ago
  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.