Comment by mattmanser

Yeah, and as soon as soon as they tried doing that, they found out it was all superficial and the fact that there was HTTP calls inbetween meant everything started falling over and they saw weird behaviour. And instead of learning how to work with state management in general, they learnt how to work with WebForm's state management instead.

I'm working on one of those webforms projects right now, a legacy project that they need some fairly trivial tweaks to and it's an absolute nightmare of bad code. And I've done this before, it's become an accidental skill that I can still fix these awful messes.

One of the (many) reasons why webforms and the new Razor Pages are bad is because the code gets split up according to the UI instead of by function. So it gets scattered all over the place and is incredibly hard to do maintenance work on it.

The page-centric code layout that Webforms/Razor Pages/all the old PHP/Perl/etc. encourage is also extremely conducive in encouraging copy-and-pasta code for programmers trying to get stuff done asap.

So not only is it a nightmare to pick apart the code, you can often fine 2 or 3 copies of the same code that you only discover when one page is working as expected, but the same functionality is used somewhere else but someone just copied the page/control instead of actually splitting the page up into controls and re-using functionality.

I've seen this happen over and over and over. A single developer can avoid these pitfalls, a team cannot.