One of the cool things about ASP.NET is how many different ways there are to get things done. There is a ton of stuff in there, and you can pick and choose the bits that make sense for your project.
In the old days, that meant you could toss out all silly drag/drop, faux-stateful garbage they put in to make it so you could build webapps like they were VB6. Thus, leaving behind a really good compact MVC framework for building webapps (long before they came out with something actually called MVC that wasn't as good at it). Now it means that I can read this list and not see a single technology I've touched at all in my 18 years of build stuff on this stack.
Personally, I tend to disagree with the author's approach of pushing routine stuff out to the realm of "magically happens behind the scenes", in favor of having common base classes for my page handlers that can be explicitly told to do those things with a little Initialize() method at the top of the handler. That way, when something goes wrong I get a breakpoint looking at my own code.
I like control, so the idea of voluntarily putting something in place that could magically shove its way in front of my code and whisk the user off to an error page just smells wrong.
But again, it's cool that the stack gives us the option to do so if it fits our style.
In the old days, that meant you could toss out all silly drag/drop, faux-stateful garbage they put in to make it so you could build webapps like they were VB6. Thus, leaving behind a really good compact MVC framework for building webapps (long before they came out with something actually called MVC that wasn't as good at it). Now it means that I can read this list and not see a single technology I've touched at all in my 18 years of build stuff on this stack.
Personally, I tend to disagree with the author's approach of pushing routine stuff out to the realm of "magically happens behind the scenes", in favor of having common base classes for my page handlers that can be explicitly told to do those things with a little Initialize() method at the top of the handler. That way, when something goes wrong I get a breakpoint looking at my own code.
I like control, so the idea of voluntarily putting something in place that could magically shove its way in front of my code and whisk the user off to an error page just smells wrong.
But again, it's cool that the stack gives us the option to do so if it fits our style.