|My apologies for not replying sooner to the people who commented on my post. However, I have been involved in quite a bit of in-depth testing of the newer web development tools on offer by Microsoft, which includes ASP.NET MVC, Blazor, and Razor pages.
I have a standard that I always go by when it comes to software tools... If it can't be figured out in 20 minutes it is not worth the effort. I use this standard as a basis for how well the corresponding documentation to the tools presents itself to the developer while allowing the developer to quickly set up scenarios that he or she would require for their projected endeavor.
What I found in my testing is that the web development environments now being offered by Microsoft are almost schizophrenic in nature while being accompanied by such erratic documentation from a wide range of sources as to be almost incomprehensible. So much of the documentation provides for so many differing implementations of the same thing that a developer would be more than confused as to which one is best for his or her circumstances in addition to which implementation actually works consistently.
As it regards ASP.NET WebForms being merely a prototyping software tool. This is completely false. WebForms was designed to be similar to current desktop development endeavors with an event driven environment. However, it did not fully encapsulate the concept of the thin-client, which was a radical departure from desktop applications where such clients were usually quite heavy.
The thin-client model became popular in the late 1990s and early 2000s as a result of the n-tiered client-server architecture then being promoted. In my view, the thin-client concept was and still is far superior to the now thick-client emphasis in development. The thin-client was there to promote only code on the front-end that dealt with the display and retrieval aspects of the interface, leaving the rest to various tiers in the overall application\system. Such a distributed nature of this type of development was and still is the primary factor in making distributed systems that could scale with very high levels of concurrency.
Having worked on one of the largest MVC projects in the United States in 2010, I saw first hand how inept this paradigm was for complex database project development. The work required to implement such a basic framework was completely out of line with the requirements and deadlines the project had been based upon as I and my colleagues had to work far harder and longer to accomplish the same things that would have been required by the more sophisticated WebForms construct. The fact that WebForms may have not been as efficient as the MVC environment really made little sense to worry about given the huge complexities dinvolved.
Though my colleagues were highly capable software engineers and I admired them for such capabilities, it made little sense to me why they would put themselves in such a position that required them to work far longer hours with far more complexity than that which would have been required had the project been developed with WebForms.
The reason for all this was that my colleagues were of the opinion that this new MVC paradigm was the correct way to build new Internet applications.
They were abjectly wrong since there is no correct way to build such applications. The Internet is based upon a very old technology that was primarily designed to simply support basic messaging, not the complexities that are being sent over it now. In the end, the Internet's primary request and response methods are still the only two communication factors that are available to us at a general level, with lower level forms of communication being more recently implemented.
The idea that was promoted in one of the replies here that developers should have a greater understanding of how the Internet works in order to develop better applications is complete nonsense. That is not our job as software engineers and developers. Our job is to develop quality applications; not worry about what is going on underneath the hood as they say. That job is for network and hardware specialists.
And even if one knows how the Internet works, so what? You are still going to be bound with how any one software tool works to develop your applications.
Recently Microsoft has produced the Blazor environment and the new Razor Pages development paradigm; neither of which appear to work very comfortably considering that attempting to mix the two under certain circumstances yields unworkable conflicts. And yet one has a hard time attempting to figure out just where one environment ends and another picks up based on a lot of the documentation I have gone through.
Razor started off as a more efficient view-engine for MVC and now it is being touted as an alternative development environment on top of the ASP.NET MVC foundation. In fact, Microsoft is touting Razor Pages as the new WebForms. However, trying such an implementation out in its various formats had its own issues demonstrating that it was hardly ready for prime time development. The biggest one I found was the arcane techniques required to extract data when posted from the front-end. I imagine this will be corrected over time but it brings up the question as to why Microsoft would even tout such a development as a new form of a now denigrated technology. I suggest that it is most likely that Microsoft, very late in the game, realized their mistake by dropping the WebForms paradigm in the first place as ASP.NET MVC simply cannot compete with its sophistication and simpler style in the development of quality applications. And for all its inefficiencies, WebForms development, when done correctly, yielded far fewer defects that any other overly complex technology such as MVC would do so under stressful conditions.
In fact, Microsoft did attempt to port WebForms to its new ASP.NET Core environment but found that doing so was causing all sort of issues. As a result, they have been working their way back to it with their latest implemntation of Razor Pages. Nonetheless, the current mechanism in Razor Pages that appears to work consistently is a complete throw-back to Classic ASP, whereby C# code is inherently mixed with HTML markup in a single file. What is this? And now we are supposed to believe that after years of denigrating such a mixture of code it is supposed to be the "new thing"?
There are developments in Razor Pages with a new form of Code-Behind modular structure as was with the WebForms Aspx construct but I have not found it to work very consistently... At least not yet...
I am finding that people who promote the ASP.NET MVC style of development appear not to have been exposed to its drastic limitations when under stress with the development large-scale, complex, database, intensive applications. No one in their right mind would promote such a bare-bones framework as ASP.NET MVC under such circumstances that relies on so many auxiliary technologies to make it work with the complex interfaces involved.
I saw this first hand and ASP.NET MVC has not evolved to a point that would make such implementations easier. In fact, it is getting even more complex than its earlier incarnations. And complexity is the bane of quality software development...
Sr. Software Engineer
Black Falcon Software, Inc.