What Was Disadvantages ASP.NET Web Forms?

SagarJaybhay

•View State weight: the particular mechanism for maintaining state across requests
(known as view State) resulted in massive blocks of knowledge being transferred between
the consumer and server. This information might reach many kilobytes in even modest
web applications, and it went back and forth with each request, resulting in slower
response times and increasing the information measure demands of the server.
• Page life cycle: The mechanism for connecting client-side events with server-side
event handler code, a part of the page life cycle, might be difficult and delicate.
Few developers had success manipulating the management hierarchy at run time while not
creating read State errors or finding that some event handlers enigmatically did not
execute.
• Separation of concerns: ASP.NET net Forms’ code-behind model
provided a method to require application code out of its hypertext mark-up language markup and into a
separate code-behind category. This was done to separate logic and presentation, but,
in reality, developers were inspired to combine presentation code (for example,
manipulating the server-side management tree) with their application logic (for example,
manipulating info data) in these same monstrous code-behind categories. The end
result may well be fragile and unintelligible.
•Restricted management over hypertext markup language: Server controls rendered themselves as HTML, but not
necessarily the markup language you needed. In early versions of ASP.NET, the hypertext markup language output
failed to meet net standards or keep use of Cascading vogue Sheets (CSS), and
server controls generated unpredictable and complicated ID attributes that were exhausting
to access victimization JavaScript. These issues have improved in recent net Forms
releases, however it will still be difficult to induce the markup language you expect.
•Abstraction: net Forms tried to cover markup language and hypertext transfer protocol where doable. As
you tried to implement custom behaviors, you often fell out of the abstraction,
which forced you to reverse-engineer the post back event mechanism or perform
obtuse acts to create it generate the required markup language.
• Low test-ability: The designers of net Forms couldn't have anticipated that
automated testing would become a vital element of package development.
The tightly coupled design they designed was unsuitable for unit testing.
Integration testing may well be a challenge, too.

Jul 10 '19 #1

rollerbladegirl

ASP

ASP, Active Server Pages, have been around since before year 1999.

.NET

.NET, a version of never fully compiled when transmitted, "just in time", "your code gets sent *raw* to be compiled later (always JIT), ongoing breach of security.

Disadvantages? Go read what ".NET" really is. Not the hype. Not the flame wars between the worshipers of ".NET" and the followers of truth. If you use ".NET" then your code *is* disadvantaged. Research it yourself. Don't believe the loudest noise. Research it yourself.

That original post was like a 1,000 word essay on the effect of the smell of a wet dog. All that talk did not change the stink of ".NET". A long essay did not change the fact that ".NET" has always stunk, and still stinks, bad, really bad.

.

Jan 20 '20 #2

SmithAnchorWork

If your employer is requiring you to code on the "dark side" (as I think I read rollerbladegirl referencing somewhere else), then compile your code that you do not want stolen or changed into an external dll in C++ and use the .NET part simply as a transport.

A stinky dog (.net) can pull a cart containing clean items (dll's) and if the employer allows that, some of the stink of .net is bypassed.

Mar 23 '20 #3

Sherin

ASP.NET Web forms have got many advantages over classic ASP, but having lots of disadvantages as follows:

Undefined Application Architecture with lack of Separation of Concerns (SoC): - When we think about development of a project using ASP.NET Web Forms, there is no predefined architectural approach. Separation of Concerns (SoC) is not defined, as developers can choose their own architecture. Many developers choose code behind approach then it raises issues in complex development life cycle, as it is tightly coupled to UI and code becomes unclear with other issues around.

Complex Pages with Performance issues: - Statefulness through ViewState, Postback and Controls was great solutions for classic ASP, but later they turned out as problems. ViewState stored in the page itself, so page size becomes too large and it reduces overall performance. Developers struggle for the control hierarchy at runtime and number of events make application very complex, as developers have to struggle to implement code at right place.

Lack of abstraction with least control over HTML: - Developers have to use the traditional postback mechanism to achieve the preferred HTML, as web forms hideaway HTTP and HTML that have a spat of the abstraction. Developers have to face difficulties like integration with JQuery and JavaScript, as HTML output with Web Forms is often unclear.

Limited support for testing and SEO: - Code behind and tightly coupled architecture with a number of event handlers makes unit testing all most impossible. Even integration testing becomes difficult and complex task with web forms. Fix ASPX pages with query strings, pointed by URLs are not very friendly for users and search engine optimization.

Lack of Reusability and minimal parallel Development: - Code behind logic makes code reusability very difficult, as lots of conflicts occur if developers use same code behind logic for multiple UI and parallel development is also not possible for the particular section, because applications are tightly coupled.

Mar 27 '20 #4

SmithAnchorWork

Thank you Sherin.

Sticking with the topic of
"What Was Disadvantages ASP.NET Web Forms?"

I do not recall much considering a generally constrained "predefined architectural approach" to ASP. It was there, but I think that I took it for granted. Thank you.

"Separation of Concerns (SoC) is not defined". Again, that was taken for granted as being a given that "Separation of Concerns" would be a logical part.

"and code becomes unclear". That is as far as I feel like reading. Logic and code are not oil and water. They must, by default, mix and blend in a cohesive flow.

As I struggled with not having known of these (if they actually exist) I am reminded of why I was not aware of them. I do not use .net for any of my coding.

If I may be allowed to get maybe a little off the topic of "disadvantages asp.net web forms", to what was before it, ASP (Active Server Pages) still works (as long as .net is no part of it). ASP is fine to use today. I see nothing negative about ASP (without having any .net in it). I like to use ASP. I have no intent to use .net with it.

Back to Sherin: How do you know these things? Were you threatened to be rolled in fire ants and dragged through Arizona cactus to get you to work on developing .NET? How do you know these things? If I may be allowed to ask.

And, thank you for the information.

Apr 1 '20 #5

lewish95

Auto generated HTML does not provide full control to the developers.
HTML ID management is compromised and it makes difficult to use client side languages like Jquery.

Apr 3 '20 #6

NeoPa

I don't intend to start editing posts at this point. One reason for that is the interconnected nature of some of the less desirable comments. Stripping content out could easily lead to losing value.

What I will do is :

1. Ask everyone to refrain from any extreme language to express their disdain for products or people.
2. Remind everyone that unpleasantness tends to escalate when we stop seeing civility as a very important aspect of our interactions.
3. Continue to monitor in case intervention does become necessary at a later point.

Apr 25 '20 #7