It seems easy for people to say things like “LOL, Web Forms” or “Web Forms is dead.”?Web Forms sometimes?gets very little respect from the .NET development community. We look forward in time, forgetting the giants on whose shoulders we stand. It was the?dominant way of making websites in .NET for many years. Is it really a remnant of a bygone era? Or does it have a vibrant existence in places oft overlooked?
Is Web Forms Really Dead?
Web Forms?has lessened in popularity, sure. But is the technology truly?dead?
I remember thinking that it would die with the advent of ASP.NET MVC. But I was naive then. I didn’t really understand the landscape, nor did I appreciate the value of a long-lived, stable technology?platform on which to build applications. I had my frustrations with Web Forms and let that color my judgment. But can we objectively say Web Forms is dead?
No, it’s not dead. Or rather, it’s complicated. Microsoft hasn’t announced any plans to stop supporting Web Forms, and in fact, they’ve released updates for it as recently as April 2018. Web Forms continues to get love and support from them. It’s shown?maturity and stability and receives?respect from many across the internet.
However, Web Forms is part of the ASP.NET full framework. And Microsft?focuses most of its attention on .NET Core, the framework’s cross-platform rewrite. So I suspect someday we’ll see the sun set on the full framework. But I don’t think that will be for many years. This is a common occurrence with Microsoft technologies, like VB.NET,?but even if one of Microsoft’s tools fades into the background, it ain’t over till it’s over!
Should I Stay or Should I Go?
But a larger question remains: should you still use Web Forms or migrate to a newer technology?
I can’t really answer this question for you. I know, disappointing. But you need to make this assessment for yourself and your team. However, I can tell you to make this assessment based on the nature of the tools you’re using. Look at what ASP.NET Core MVC or Razor Pages is going to give you over Web Forms?and vice versa. Avoid making a case based on whether the technology is “hot” or not.
Using Web Forms even today is a perfectly viable option and can be a really good fit, in some cases. In fact, there may be a larger potential talent pool to train on it than for MVC frameworks, as I will explain below.
SPAs: Web Forms in Its Newest…Form
Things in the software industry seem to come in cycles, and web technologies are no different. Many in the profession continue to look always forward to the new, leaving the old in the dust, until the old becomes new again. Web Forms falls in this boat. When you take a close look, it resembles a style of application that’s very popular at the time of this writing and shows no signs of slowing down: the single page application (SPA). The similarities between Web Forms and SPAs means that there may be more opportunity now for using it than just a few years ago.
Event Models and State
First, let me explain a little about how Web Forms works. Then I’ll move on to how popular SPA frameworks work.
Web Forms’ goal is to provide an interactive application experience like you would get on a desktop?but within a web application.
It achieves this by taking the user’s button clicks and other events and posting back to the same webpage but with different data rendered, simulating a dynamic update. It’s able to do this while consistently maintaining the “state” of the application by?using a hidden web input called a ViewState. (You can learn more about all of this here.) It then runs through a series of page lifecycle events that ensure the ViewState gets deserialized and/or updated appropriately. This all culminates in a Render() call that renders the HTML to a page and sends it to the browser.
Was It Ahead of Its Time?
Web Forms uses events to provide a stateful view of the web. It makes you ask if it was ahead of its time.
SPAs also have the goal of providing an interactive application experience through a website. It does this through asynchronous JavaScript calls (AJAX) that run on the browser. Most SPA frameworks are wired up to react to button clicks and other events. They then store and update the state directly on the browser. So we see that we have an event model that then updates some state that’s used to render the app. But it gets more interesting when we consider a particular framework: React.
React’s Model and How It Lines Up
React is an interesting beast. It looks quite similar to Web Forms:
- React and Web Forms both culminate in a Render() method that sends HTML to the browser.
- React has a State object used to render all of its components. Web Forms has a ViewState object that’s used for the same.
- Both frameworks take?advantage of their State/ViewState object through a series of lifecycle events to ensure everything gets rendered and maintained properly.
So we see that things have really come full circle. We’re at a phase in our industry where we once more value event-focused interactivity within a website. We also understand that we need an event model and way to maintain state in order to achieve this.
Interactivity With the Power of the Server
Web Forms, as mentioned above, is designed to make interactive pages within a website. And we see that tools that make interactive sites are as valuable as ever. This means that Web Forms, too, has the potential to be as valuable as ever.
We get a couple advantages with Web Forms over SPAs, though.
- We get the power of an entire web server backing up our logic processing. An SPA only gets the power of a browser, which is a constant struggle. This is the equivalent of getting a Boeing 747 to power your travel vs. a motor scooter.
- We get a typed language (C# or VB.NET) in which we can code our logic instead of untyped JavaScript. Trust me, JavaScript has its fair share of issues.
- We get a mature, long-lived framework in Web Forms as opposed to newer, ever-shifting SPA frameworks like Angular. This means even guides written 10 years ago are still applicable to our work today.
Easy Onboarding
This emergence of curiosity into event-driven, stateful interactivity on the web may have another side effect. If you’re a shop running Web Forms, your talent pool may have increased with the number of people invested in SPAs. If you spin your job descriptions right, you may see an influx of these people looking for interactive, stateful web design.
The models between SPAs and Web Forms are so similar that an SPA-experienced developer may learn Web Forms faster than they would an MVC platform. Think about it: when people were learning Web Forms back in the day, they were coming from a stateless Classic ASP world and found the stateful nature of Web Forms hard. But now many developers are used to the idea of state management on the browser and could find the page lifecycle second nature.
Niche Services Make You Money
There are many jobs out there needing Web Forms. It’s more of a niche need in software?fewer companies are turning to the technology. This means that those that need expertise will find help scarcer and, in turn, this means you can have a stronger influence over your pay.
Don’t get me wrong. There are still plenty of jobs for Web Forms. But the need is greater, and so can be your compensation.
A Place In Our Hearts and Our Toolset
Web Forms does indeed seem to be a remnant of our past. But it still has much life left. Perhaps Web Forms was before its time, but it helped pave the way for concepts like SPAs. Many companies still use Web Forms today. There is still much money to be had as it has become a niche market. And we can transpose many lessons from the?SPA community onto it, making onboarding easier. Web Forms may not be the shiniest, sharpest tool, but it still has a place?in our toolset and in our hearts.
Learn more how CodeIt.Right can automate your team standards and improve code quality.
20 Comments. Leave new
Respectfully I can’t agree with much of what you’ve written. WebForms was never in my heart – attempting to abstract the browser out of the equation was short-sighted and resulted in unnecessary complexity and 3rd party frameworks that often obscured the huge amount of data going up and down the line to the browser. Debugging in that environment was debilitating and relied on Visual Studio being able to tap into the browser, limiting options to Internet Explorer. Perhaps the most telling part of your article is “there is still much money to be had”. That’s the sort of thing COBOL developers say.
Webforms did not attempt to abstract the browser out of the picture. It did offer a way to develop that would attract Windows developers.
However you where never forced to develop that way. If you had decent knowlegde of Web technologies (HTML, JS, client-server principal) and would be prepared to dive under the hood to see what Webforms had to offer (Page Lifecycle at it’s core), there was full control over everything.
Webforms has many great things, that even today still work in any project.
The separation of mark-up and server-side code was ahead of it’s time. Building server-side controls and use them the exact same way as HTML elements was an innovative and good idea.
However the AJAX toolkit that MS released to work on top of Webforms was garbage. Some of the ideas where okay, but it was poorly build and developers where to lazy to find out what it actually did under the hood, resultating in poor performance.
But unfortunately, poor “open-sourced” frameworks and libraries have become the default for MS the last decade.
Not a fan anymore, not like I was back in the days.
Are you serious? Sure, it was hard to abstract out the equation of the web browser back in version 1 of ASP.NET and with Visual Studio 2003. However, there’s no doubt that you can abstract out pure HTML/Javascript/CSS code from C# code even with the first version of ASP.NET webforms when it first came out. When Visual Studio came out with 2010, the browser was decoupled and basically, you can use any type of browser you wanted for debugging and not tied to the Visual Studio debugger. Writing HTML/Javascript/CSS without C# code injection in the ASPX is such a godsend from the old classic ASP VBScript coding since you don’t get spaghetti coding (although time and time again, you get crappy coders who don’t follow standards and go cowboy coding). And since ASP.NET version 3 or 4, you can inter-mix SOAP with REST-ful services all within one ASP.NET Webform application solution – try that with an MVC ASP.NET or other UI Javascript framework platforms! For security, I’ve never known a webform website being hacked, unless if one was a newb and left all information wide open without securing any server-side code. Stateful server-side management, if done correctly with abstraction, is so sweet – no carrying of identifiers in the querystrings or hidden fields like you would do with all Javascript UI frameworks. You may say ViewStates are a problem? Prove it and I can prove there’s nothing to hack if you don’t generate it or if you don’t output anything important in it. I can also say that with Webforms development time, over any other type of web technologies, is faster and can provide similar or richer functionalities for users in a third or half the time. In the world of business, a rich application developed with less money and time trumps everything. We’re not talking some kid building some sort of SPA with their favorite Javascript UI framework in their own basement, we’re talking large scale business web applications. Where so many web application developments have failed due to complexity, budget, and maintainability over the years, WebForms have been around for over 20 years. Where is Backbone now? Angular 1 (and now v2), React, Vu.js are all fads that are like the soup-de-jour. These will disappear within 5 years and be replaced with yet another web technology. Sadly enough, people will flock to the latest and greatest to keep themselves happy and their resumes updated to get jobs. HTML/Javascript/CSS are the fundamentals of web development. Regardless of what technology you use, it’s fundamentally those 3 things that make a web page inside the browser and it hasn’t change all that much for the last 30 years. Businesses dictate what and how things are shown and what gets rendered is technology independent since you can write all this with any text-based editor. However, there are security implications as the application gets more complex. With WebForms you can encompass everything and adapt to all facets of modern day web development. You can’t say that with any of the MVC or Javascript UI frameworks.
I support solutions using both types – WebForms and MVC. For reasons CSharp mentions above, I would not use MVC/OAuth to keep PII and PCI information that is used by the site secure. Server managed session state and viewstate are the way to go in my opinion.
Also, the Python/React MVC solution I inherited is a garbled, spaghetti-code mess. Navigating and updating 5+ artifacts for the most simple changes is not cost efficient. Can’t wait to convert it to something simpler to maintain.
Hi, David. I appreciate your feedback. Getting abstractions right in various systems continues to be a challenge across our industry.
I’ve done both MVC and Webform projects the last 18 years. Yes ASP.NET version 1 is that old 🙂
For me the MVC style was a step backwards, to the oldskool classic “spaghetti-code” ASP and PHP stuff I did in the past.
If you know what you are doing than Webforms, at least for me, is still the best framework to get the job done in a very structured and reliable way.
Most articles I read about why MVC is so much better than Webforms are mostly written by complete noobs (sorry to say).
It’s always the same, about viewstate stuff etc. We didn’t ever use viewstate or controlstate, not even on ASP.NET version 1.
I started building web applications SPA (MVC style) about 6 years ago in combination with Webforms, and even today it’s still great!
I still support and develop projects with WebForms. I have had good results with a couple MVC SPA apps using Knowckout JS, but I still find I like and am very productive with WebForms. If you know what you’re doing WebForms can handle modern features like Bootstrap and work with Routing so the URLs don’t need to display .aspx everywhere. I find WebForms very reliable and fast to develop with. I can also use entity framework if I want to. I think I will try to build a React app at some point since it sounds like it is closer to Webforms in it’s design paradigm.
Having used web forms, mvc and core, I’d say web forms has a number of advantages.
Faster development
It’s simply much quicker to work with when you know what you’re doing. You don’t need javascript to do the interface, which saves a lot of time, because javascript isn’t nice to work with. You have a load of controls that support all kinds of complex functionality. User controls seem to be far easier to modularise code, very often with MVC we find small changes in the layout of pages can affect the javascript parse to extra values or apply extra styles, etc. so it’s far easier to break stuff when making what should be cosmetic changes.
More secure
Of course, well written apps can be secure on any platform if done properly. But web forms makes it a bit harder to hack things.
Viewstate is much maligned, but since you can encrypt it, it means you can store values in hidden fields on pages and they’re simply not readable by viewing the HTML. Now there are ways to do this on MVC, but I see sites all the time that store hidden values in form fields that are trivial to read by viewing the page source. Those developers may well implement checks to stop you changing those fields and putting values in like user type or permissions that might give access to things you should not see. But i’ve tested a lot of sites that don’t do this properly. For small custom developments, web forms built in security framework just seems to handle a lot of these issues. When you view the source of a web forms page, it’s a bit of a mess (one of its drawbacks, lots of unnecessary id tags, with long names, etc.) but you don’t see hidden field values and that viewstate looks pretty much impossible to hack. Very hard to create an HTML page that will post back to a web forms handler and trick it into doing something bad.
Quicker to learn
Seeing new people coming into both, people just seem to pick up web forms more quickly, and write decent functional stuff more quickly.
I’d say from our own experience, MVC / core is better if you’re building an app with high volume traffic or a very complex javascript interface where you need total control over everything. The HTML is cleaner and smaller, which for big traffic sites makes it worthwhile. But web forms is better for custom development of more complex projects where the volume of users will be a bit lower, such as company back ends, admin panels, etc.
It’s a shame Microsoft tends to throw big ecosystems under the bus from time to time, I’d like to see them open source web forms as I suspect we’d see that developing further, and quite possibly come back into fashion as some of the drawbacks (verbose HTML) get addressed.
Regarding “ffect. If you?re a shop running Web Forms, your talent pool may have increased with the number of people invested in SPAs. If you spin your job descriptions right, you may see an influx of these people looking for interactive, stateful web design.
The models between SPAs and Web Forms are so similar that an SPA-experienced developer may learn Web Forms faster than they would an MVC platform”, I truly don’t agree on this. Any people like to work with Web form usually lacks the skills of JavaScript.
“Any people like to work with Web form usually lacks the skills of JavaScript.” – That is such a crock of bullsh!t! The reason why you don’t want to put all the logic code up front is because any heavy lifting should be done in the BL server code. Only newbs and junior guys will code a single layer to handle validations of business rules up front. With SPA’s and mobile devices that are at a disconnected state, I can understand that some Javascript logic has to be used as an initial way to validate stateless data that are kept as JSON, but the meat of the application and all business logic should be kept from the UI from:
1) being hacked
2) long-term scalability.
If you think Javascript should be coded throughout the webpage to generate HTML code and to use as a way to dynamically provide functionality, what happens when your javascript framework gets outdated and you want to replace that with another UI framework? Also, think about the maintenance aspect of a Javascript framework application – who going to maintain that app? Usually, people who write true business applications will want those to be maintainable over time – these are called legacy applications – they’re not just throw-away apps that you will replace after 1 or 2 years, These web applications – using WebForms can be maintained for 10 or even 20 years! Just because you think you’re superior in coding Javascript doesn’t mean 90% of the web development community is well versed in writing Javascript. I would say that 80% don’t even know or understand what a closure is let alone what a function pointer is. I can write a heck of a lot of Javascript in my ASP.NET WebForms as I want, but do I want to? I always keep my mind tuned to what support can handle and I usually take the safe approach and make my web applications as simple as possible but provide all the richness that business wants. To say that WebForm developers lack Javascript skills is a joke. If you have to work with 3rd party web controls that use Javascript to control HTML and CSS to allow the user control to display/funciton how you like, you have to know how to re-program some of the functionality, trust me, I can put your comment to shame in no time!
I do not understand many of the comments here. SPAs are run on the client. The state is saved on the client not on the server and that makes the whole matter completely different. It is about to make a state aware app on the browser that makes calls to the server. Webforms tried to do all this on the server loading the server badly.
I can only agree that webforms were there to attract Winforms developers while the JavaScript was given by controls out of the box including many many third party apps. Even when ASP 3 (classic ASP) was around I knew that any serious thing regarding the client needed JavaScript.
You didn’t understand the concept of ASP development in the first place! If you understood what web development was back some 20 – 30 years ago, you’d know that the server pages (and I emphasize SERVER) were meant to serve out the HTML pages from one or a farm of servers to desktop computers with browsers. Back then, the internet speed and computer processing is slow. So, web development back then is what you called thin-client. Thick clients were pretty much what you have nowadays where things are offloaded to the desktop computers like the old WinForm of MFC applications. Even nowadays where desktop computers and the Internet connection is much faster, a server-side application such as ASP.NET WebForms/MVC can perform all the data fetching and manipulations much faster and safer on the SERVER. The computer power of a personal computer/device and the connection is not always guaranteed if you don’t have the latest and greatest technologies installed remotely (eg: cellphone, 3g vs 4g vs 5g, 2mbps wifi connection using old wireless routers). Servers, on the other hand and especially a farm of servers, can process and render HTML to clients by the millions and be secure at all times. I really don’t know where you’re coming at with servers overloading badly – maybe you’re serving up the web pages out of your basement IMB 286 PC with a 1200 Baud modem? If you’re doing that, think THIN-CLIENT – the basic HTML will load up quite fast for a HELLO WORLD page – with some lightweight javascript and sprinkle it with a bit of CSS.
The only reasons for developing web forms anymore are
1) You’re maintaining legacy web forms applications
2) You’re too lazy to learn MVC or Razor Pages
1) Yes
2) Yes
3) No to both as well. I still develop in WebForms because it’s faster than anything that can build a truly rich web application for the business with security in mind. As with my previous replies, you can adapt a WebForm easily to use REST-ful services and/or MVC architecture very easily, You can do this with ASP.NET MVC. I’ve built multi-million dollar web applications (not websites) for businesses and governments and I’m still building new applications with ASP.NET WebForms.
If I have to move away from doing ASP.NET WebForms, I’d go with ASP.NET MVC with .NET Core. It’s too bad Microsoft jumped onto the fad bandwagon to provide a pattern design for the UI. MVC should not be labeled just for UI development. MVC is a pattern so talked about because people think that this pattern should be used purely for UI development to abstract out the logic for data, display, and logical functionality. However, I’ll bet you that 80% of the masses who flock to ASP.NET MVC and other UI Javascript framework have no idea what MVC is (other than the acronym represents Model-View-Controller) and how it can be implemented correctly. I’ve seen so many pretentious MVC patterns implemented on the UI where it’s made into a mess of spaghetti code because other people on the team don’t know where to place code or people are too lazy and just put code wherever they like – it’s human nature to be lazy or not to follow standards. However, if MVC is implemented as a stack with the UI being the view or presenter, it’s not hard to figure out. A lot of senior people like to whip out a bunch of patterns and implement these patterns throughout that are hard to visualize for everyday use. This is why during development, others will ignore the complexities and build their own code stack to circumvent all that complex bullsh!t! Then, when it comes to support, all that complexity and the redundancies in code takes a longer time to fix issues.
Instead of thinking of better ways to reduce code, simplification, and maintainability, people like coming out with patterns or overthink things to make things more complex. Well, the more code logic you put in, the more bugs you may introduce to the application and the harder it will be to maintain. It’s a given. Rather than make patterns that 80% of the people don’t even recognize or even care about, why not try to simplify coding by making the code more re-usable and simplifying to make code more readable and maintainable rather than throw in patterns here and there to make things seem like it’s more structured? Even with patterns, a lot of times, codes are duplicated from one layer to the next. This is where the principles of Object Oriented Programming is so fundamental in providing the foundations of full stack development. Often times, patterns come out of developing in an object oriented way without even realizing a pattern is intended.
With WebForms, the only pattern you really need to focus on is the event model/pattern. The rest of the other patterns fall into place with the full stack. You can make the full stack as complex as you want or as simple as two tiers. There’s no rigidity in how you develop in a WebForm environment. This is why it can be so fast and so adaptive to develop. From a business standpoint, ASP.NET WebForm development gets you the biggest bang for the buck short-term and long-term (for maintainability). Since I have done some ASP.NET MVC with Razor, I will say that it’ll be my second choice over any other web development frameworks out there. It’s a shame that MVC is being used as a buzzword nowadays to promote any sort of software development when it should be implemented as a full stack development process for a muti-tiered system by a team lead with one or two very senior developers. MVC, as it stands in the modern web development world, is dictated by newbies who want something new to pad their resumes so that they can go from job to job looking for something to excite their work day rather than to fulfill a business obligation.
I am handling an ASP.NET Web Form project and I got to say, its a relief not having to worry about third party tools updates, boilerplates and the rest of 10s of things you need to consider when building, compiling and publishing using the “hottest” frameworks.
The separation of front end and code behind is so refreshing as well.
ViewState is not an issue (you can disable it and experience the “stateless” web to your heart’s content).
I wish MS kept on developing ASP.NET Web Forms, imo it would have been a strong competitor to React.
It depends on what you are building and who the end user is.
MVC – Separation of concerns creates more concerns. Do u really need these concerns? Maybe u do.
Webforms – build fast, productive and as good as u are concerned.
Core – api
Nice article, our business moved across to MVC around 2012, previously all our backend logic was done using Webforms. Once I got my head round MVC I preferred it, though it has to be said it has a lot of criticisms – it certainly doesn’t make it simplier as often specified, your programming logic can go in the controller or the model or even the view. This can make it very messy. What’s interesting now is the popular use of SPA’s, which can work in a MVC enviroment as partial views, but you can’t help thinking if MS simply made one important change to Webforms and made the server controls reload independently as oppose to the whole page then Webforms would be miles ahead in this area. Come back Webforms – deep down we all miss you.
I agree with basically all the pro web forms comments. Fast development, powerful complex controls, state management, security, all addressed. Also agree that the razor technology seems a regression to classic asp techniques.
Will acknowledge that for testing of back end logic, the decoupling you get from mvc is valuable, but, if you take into consideration all the advantages of web forms, IMO web forms will enable successful building of complex systems more quickly and with easier maintenance down the road.
I also feel that, as others have alluded to, the rejection of web forms may have a lot to do with the human tendency to scoff at the old and go all in with the new…regardless of the actual evidence.
I began learning web forms in late 2019, then began using it to develop a web application in early 2020, and incredibly, I am going to be done with the development by the summer thanks to the RAD nature of web forms. I had to choose between MVC or Nodes or React or other development methods, and I chose Web forms with no regrets, absolutely none whatsoever. This is not to say that web forms is the best option for web development out there. I am only saying that it’s “the” best option in only certain limited situations.
For instance assume the following parameters:
You already know C#, ADO.NET, HTML, CSS and Javascript,
Your web application has at most a couple hundred users,
The largest table in your database has 20 fields and at most 100K records,
Your web application is used in browsers using Windows OS on PC workstations only, and with broadband connections (no ipads, no mobile phones),
The development team consists of a single developer. He/she is the architect/UI designer/developer/tester/deployer/etc.,
You want to learn and use one single mature and dependable technology, i.e., you don’t want to patch together 5 different technologies and an additional 5 third-party tools,
You are under the gun to deliver as soon as possible, or else your competitor will get the upper hand,
The life-span of your application would never reach ten years,
You are planning to retire in about ten years too.
Putting all these together, why would I bother learning MVC or React or Angular or Nodes, etc? Give me one good reason why anything could be superior to web forms? Seriously, one good reason is all I am asking.
That’s my 2 cents.
The whole point of moving too asp.net webforms was to stop javascript hell that we used to have. Our web form sites in .net run instantly and we managed to update the frame work and visual studio perfectly. Now Microsoft want us to go back to ASP and javascript hell. When you open up VS2019 these days you get a choice of 120 different ways to start a project, from angular, blazer, razor, MVC, asp.net, .net core, server, client. Too much choice, and when you look at these frameworks there is basically no difference, but for a software company with years and millions of lines of code for near perfect high end systems, this causes a problem. The new systems are easy to code, but offer little advantage because we have built our own core procedures, frameworks and objects which run perfectly. Shame on you MS for not porting asp.net. We prefer to start again only when moving to new systems i.e. Dos to Windows or windows to the web. Who cares about the 32k imprint we are running high web based systems on browsers and mobile web browsers and have no interest in windows mobile devices.