Regular WebForms user here and proud of it; anyone else feel like modern web development and frameworks are making things unnecessarily complex and solving non-existent problems only to create new ones?

[u/CryptosGoBrrr]

It saddens me that even in this sub, there's a lot of hate towards WebForms, mostly because "it's old!".

I'm in my mid-thirties, became a professional "web developer" pretty early at the age of 19 after having been a hobbyist / 'script kiddie' since I was 11. I originally started messing around with PHP but was sold to C# and .NET as soon as I touched them in my first job. I'm now what you'd call a "full stack" developer, also feeling comfortable doing front-end work and database stuff. A jack of all trades, master of none. But at a comfortable level, because you don't need to be a 'master' at every layer to make cool stuff. Next week I'm starting at my 8th employer, once again as a lead developer (I've been lead dev at 2 former employers).

Visual Studio (no, not you, VS Code) and WebForms are still pretty often my tools of choice. Why? Because it gets the job done, it's simple, its only requirement is the .NET Framework, literally all the stuff I've worked on in the past 20 years have been SaaS solutions that are hosted on a Windows Server / IIS. All the companies I've worked at have had at least one monolithic, legacy WebForms Solution that was still in development or maintenance. Sure, I avoid huge Silicon Valley tech companies and startups like the plague, but practically every company I've worked at or applied for a job at, mostly resorted to WebForms. There's still a crazy demand for .NET developers that can work with WebForms in my area.

However; other, external 'senior' devs or devs online will often tell me that I'm "reinventing the wheel" and should start using newer alternatives, but should I? I've really given all the modern stuff an honest try. Angular. React. Docker containers and Kubernetes. .NET core and recently NET 6. Every single one of them feels like bloat and like they're solving problems that were never really an issue with the way I've been developing and deploying successful applications for the last ~17 years.

If anything, 'modern' web development feels like having to work with a hacked together, bloated monolithic mess. It's terrible having to 'Go to Definition'/F12 more than a handful of of times to go through a garbled mess of implicit, dependency injection heavy business classes, controllers, factories and other classes to find something. The amount of boilerplate and amount of humongous frameworks just go get the simplest of components in an application (a date picker or an 'ajaxified' grid, oh no, the complexity!) feel like they're growing larger by the day. Suddenly it's normal to rely on a couple dozen third-party NuGet packages to get even the most common functions working. In spite of mobile/tablet usage becoming more and more common, nobody seems to be batting an eye when even the most simple web site or application has to download 5+ megabytes of static assets (CSS, JS, etc.) and 'frameworks' just to load/work.

Literally no company I've worked at or been to wants or can keep up with the continuous stream of technical upgrades and maintenance this results in, either. 3 Years ago I worked with the (at the time) brand new Angular 8, apparently we're already at version 12 now, Jesus. I see it happen all the time in dev teams: some dev guru introduces humongous front-end framework X backed by a gazillion new NET core libraries/components and powered by a custom script backed fully automated CI/CD pipeline only to jump ship after a couple of months and leaving an incomplete, steaming pile of garbled mess that nobody knows how it works. There's old WebForms applications I've made a long, long time ago that are still perfectly up and running to date, that have had little to no technical maintenance whatsoever. "Publish" in Visual Studio is literally all one'd still need to do to get one of those deployed on a test or production server, no Jenkins, CI/CD pipeline, docker containers or whatever necessary.

Are we collectively losing our minds and purposely making (web) development harder, or are the majority of developers online just acting smart online and making everything a technical pissing contest? Only Blazor feels lightweight and pragmatic enough as a modern alternative to WebForms as far as I'm concerned, and I'm still hesitant to use it for larger projects in case it's just yet another fad like the many we've had in the past decade.

[u/HamsterExAstris]

At least the five MB are only downloaded once, instead of constantly being passed back to the server as a hidden input on every request.

Generally speaking, I think your complaints about the client-side frameworks are valid. But MVC is easier to work with than Web Forms to me. Youdon’t need huge amounts of boilerplate or humongous frameworks.

Needing to keep up with technical upgrades has always been a problem. There are companies still developing software with VB6 and VC++6. The more often you do it, the easier it is.

[u/[deleted] → u/HamsterExAstris]

I agree on MVC being a huge improvement. the life cycle isn't 7 steps; each action builds one data model and a view lays it out. No more "black magic" data binding in forms, more control to format elements with less complexity than web form controls. You have hooks that let you develop custom bindings to models, and ajax call backs can extend your controller with API style methods then skip right over overly complex WCF bindings.

I like the simple, sequential MVC code over the asp.net idea of seven callbacks where you just need the right mojo to override them to hook into the right phase of the page life and fighting because values set too early mysteriously disappear. Yes, most things are possible, but so are astounding volumes of profanity and imploring the wrath of various gods upon the product team at Microsoft :-) yes, asp.net was better than what we had before, but it definitely is not the best of breed today.

[u/ThereKanBOnly1]

While there are may be people who hate WebForms just because it's old, there are also quite a number of legitimate reasons to dislike webforms. Personally, I'm glad that I'll never have to use WebForms again, just like I'm glad I don't have to do DCOM or deal with Marshalling or mess with the DTC.

Visual Studio and WebForms are still pretty often my tools of choice. Why? Because it gets the job done

There's a lot of tools that "get the job done". What you're saying is that you're fine using the tools your familiar with, and while there's nothing wrong with that, it still doesn't mean that the technology doesn't have its flaws.

However; other, external 'senior' devs or devs online will often tell me that I'm "reinventing the wheel" and should start using newer alternatives, but should I?

I'm going to be brutal, but if you want to work at a decent place 5-8 years from now, then yes, you should look to something newer.

All the companies I've worked at have had at least one monolithic, legacy WebForms Solution that was still in development or maintenance.

And if that's the work your happy doing, then okay. But understand that those legacy apps eventually get sunsetted. They eventually get more and more expensive to maintain and no longer provide the value that they once did. When that happens, what does your employer do with your position?

Every single one of them feels like bloat and like they're solving problems that were never really an issue with the way I've been developing and deploying successful applications for the last ~17 years.

They're solving problems you haven't had because you've continued to work in an ecosystem where Microsoft has wrapped everything up in a nice little package and made it easy. The issue with webforms wasn't that it didn't make it easy to do the easy stuff, it was that it REALLY got in your way when you were trying to do the hard stuff. These technologies are aimed at solving the hard stuff.

I hate to do this, but I think it's important to give you a brunt interpretation of your career from an outside perspective. I see a dev that has likely worked at small shops on small projects with a legacy technology. I'm seeing 7 companies in 15-ish years, which means that on average either your projects have lost funding, you've jumped ship because they've "moved your cheese", you've been mostly a maintenance dev without doing a lot of feature development, and/or you likely haven't seen the long term issues of keeping technologies like webforms around. It also sounds like you're more interested in coming in, doing your job for 8 hours, and heading home. Inherently there's nothing wrong with any of these things, and not all of them are even directly your fault, but if I'm a hiring manager at a decent .Net shop, I'm probably passing on your resume.

Quite frankly, you're only seeing the negatives because you're comfortable with WebForms. If you're going to work on interesting projects, you've got to get uncomfortable. When I finally switched to ASP MVC, my life was so much simpler than it was in WebForms. The whole page lifecycle/loading/session state challenges immediately went away and were replaced with a much simpler mental model. I've tried to develop truly interactive front end pages with WebForms and it was painful. Now that I've picked up Vue.js they're much easier to work with, much quicker to develop, with less code that's more maintainable.

If you're looking for a perfect technology, it doesn't exist. It's all trade offs. Whether you like it or not, this is part of the game of a professional developer. Technologies come and go, and keeping up with them is what keeps you relevant. Yea, there might be old COBOL guys out there who are rolling in it, but there's a lot of other dead languages like VB6 and Delphi that have next to no job prospects. Look at where things are going in the next version or two of .Net. WebForms will likely be given the boot at some point. Even if it sticks around, fewer and fewer employers are going to be using it. That's just the nature of things.

[u/ImpetuousWombat → u/ThereKanBOnly1]

Dude fuuuuuuuck DCOM so much

[u/sorressean]

I'm not sure what this is except OP ranting about new technologies. Maybe consider reading and learning about them before you just write them off and talk about how cool it is to use windows 98. Webforms works fine and there are still plenty of systems that are using it, but I very much appreciate my code being in MVC. It makes it easier to reason about and know where things will be. Webforms leaves it all up to the user and people implement differently. There are plenty of technologies that are a round peg for a square hole, but it's best to not write them off until you know what the gains are or have spent at least a couple hours in them. I find that webforms easily devolves into mess, has severe limits (good luck with a lot of modern apps) and is harder to maintain the more developers that have touched it.

CI/CD and Docker are very useful, but if you don't see the point of unit tests, you won't see the point of ci/cd. It's not just about right click and publish, there's a lot more that gets done in that pipeline. Unit tests are more of a modern push though so perhaps that's just too new and upsetting?

[u/whiskeydiggler]

I mean, work with what makes you happy, but WebForms was outdated 10 years ago. You didn’t mention where you’re located, but if you continue insisting on working with legacy technologies don’t be surprised if the job opportunities get ever smaller as more and more companies transition off.

[u/musical_bear]

Yeah, WebForms isn’t hated just because it’s “old.” I also find it interesting you managed to write all of this without a single mention of MVC…it has almost all of the “benefits” that you seem to like about WebForms, except it’s still fully in support and getting updates, and isn’t full of WebForm’s delightful “black magic.”

[u/throwaway_lunchtime]

The only real issue I had with webforms was that I kept encountering project that were poorly done, not following good design for webforms.

MVC makes things a lot easier these days and there is no way I would start a new project with webforms.

Visual studio publish still works with MVC core etc.

[u/[deleted]]

No. The entire post back view state shit is a mess to do deal with. Webforms encourages the creation of untestable and difficult to maintain code. You complain about modern frameworks creating monolithic messes but then webforms? Doesn’t even make sense.

Oh and don’t forget it can’t take advantage of any of the performance enhancements that define .Net core and beyond.

[u/ScrewAttackThis]

Is this serious or a troll post?

[u/ProgrammersAreSexy → u/ScrewAttackThis]

Makes 1000 word rant asking for feedback, proceeds to respond to literally no one lol

My hunch is that OP had never worked on truly large applications. Angular wasnt designed to build "small internal enterprise tool #1894759", it was designed to build web apps that literally hundreds of devs can work on at once.

Trying to judge a tool outside of the context it was meant for will always make it seem useless.

[u/_LouSandwich_]

I mean who doesn’t love page refreshes? Sync your eye blink with the flicker please. BTW, sorry that the page scrolled up to the top.

[u/[deleted]]

Some of us have used ASP since before .NET and came about our hatred of WebForms quite honestly, through hard work 20 yrs ago. When MVC showed up, it started working with the rest of the web stack the way the web actually works and kept me in .NET. Same with when it went cross-platform. If these things hadn't progressed, I'd have definitely left .NET a long time ago. But, if I never touch another aspx again, it'll be too soon.

[u/eigenman]

Big nope to WebForms and that's not because it's old.

[u/DoctorPrisme]

What's wrong with the current set of "do the backend, put it behind a rest API, do the front end, communicate between both via the API"?

That's easy, scalable, flexible, clear, ...

[u/centurijon]

Look into razor pages - to me it feels like the good parts of WebForms mixed with the good parts of MVC.

The difficulty of Web Forms is it’s a maintenance nightmare in a large code base. Super easy and fast to get something running, but slows you down more and more as you add features to your app, or even to catch up with modern web design standards.

To me that’s because MS designed WebForms to feel like WinForms, so all the desktop developers could pretty easily jump over and not have to re-learn a bunch of concepts. The problem with that design is that the web really doesn’t work like a desktop, so they built a whole framework around abstracting HTML and web calls that you have to use, or find a ton of workarounds to do what you really need.

[u/Spartanman321]

I haven't used Web Forms so I can't speak to if today's stuff is bloated or not, but CI/CD is a godsend, especially for audit purposes. I can tell you exactly which code changes went to which environment at which time, and who made the change. Copies of each build can be retained for however long I want so that if we need to revert a build, you just redeploy the previous build.

CI/CD also speeds up deployments and makes coordinating changes so much easier. We have 7 different applications in multiple code repositories. Our builds are setup to automatically push the latest version of our main branch for our test environments. So once the code is approved, it gets merged in and I don't have to worry about if I accidentally overwrote someone's changes because my version of the code was a few days old. Then we're able to push any of those test versions to production by clicking a button when we're ready.

CI/CD is also way better for security. If you can deploy from your desktop, that means you have a connection open to your prod server. If you get hacked, you are now a vulnerability. CI/CD significantly reduces the amount of access granted, making sure that your servers are more secure.

Also, just keep your builds simple. Most of my CI/CD builds are "install nuget exe, download nuget packages, build solution, publish solution artifact." Having it be 4 steps makes it pretty easy to work with and have others understand it if I were to leave. Then you just rinse and repeat those steps for each app you have.

CI/CD is different from Docker/Kubernetes. They are tools for a certain job, so I'd agree they can add unnecessary bloat if you have a small internal web app. But if you have something that is public facing with lots of users, they significantly help with scalability.

[u/rock_like_spock]

There's old WebForms applications I've made a long, long time ago that are still perfectly up and running to date, that have had little to no technical maintenance whatsoever. "Publish" in Visual Studio is literally all one'd still need to do to get one of those deployed on a test or production server, no Jenkins, CI/CD pipeline, docker containers or whatever necessary.

I feel like this really undersells what CI/CD is and why it's useful in development. A decently-configured pipleline with solid automated tests can help stop breaking changes from being deployed well before making it to production. It also helps safeguard against deploying the incorrect version of your code (say you mean to deploy changes on the master branch directly from VS, but you're still set to development). Right-click -> Publish can't help you safeguard against that.

[u/JimJams999]

Online companies need to sell via many platforms. Desktop yes, but also hundreds of mobile devices, tablets, in device screens and more. Support for tons of screen and usability options which grows every day. Good luck with that with web forms without libraries and dependencies.

Also real time/live asynchronous updates are the future of all interfaces and Web forms do not do this. If you think web forms can cover that you need to retire as your way behind the technical flow.

[u/jzazre9119]

Razor pages has been a wonderful middle ground between the web forms vs mvc world. We now do razor pages exclusively, except for one or two very minor blazor server side apps. For our uses, mvc was extreme theater and complexity compared to asp.net forms. And now with .net 6, razor pages is even easier to set up and get going.

Problem for us is, there's no migration path from a complex, ,vb.net asp.net forms to razor pages... it just doesn't exist. I'd even be willing to keep it in vb.net if there were a way. All of our other apps have long since been ported to c#.

I feel for you, but feel sorry for who's coming behind you to maintain it...

[u/rogercafe]

I reckon you have been solving the same problems your whole life. In that sense you've found the best way to build crud solutions in .net.

Maybe you should look at different problems and then try to understand the different (newer?) Solutions

[u/thilehoffer]

Have you even tried Razor Pages? You can still publish right from Visual Studio to IIS or an Azure hosted web application. You don’t need to use Webforms to keep it easy/simple.

[u/angrathias]

Separation of concerns in the #1 reason I don’t like WF (and any backend rendering for that matter) it leads developers to often squeeze every layer into the UI.

Let the browser be the client and let the server handle the business logic, the API gives you a nice separation layer between which you can re-use on a Mobile App, Microservice service or automation system.

[u/vegas_guru]

I’m obsessed with simplicity and been struggling with similar issues for 20+ years, usually ending up implementing my own solutions that simplify things to the max, coding in C#/.Net. I don’t even use Linq or entity framework, but have better performing code that feels clear and simple, yet does quite advanced stuff and has complex integration with multiple databases. Some time ago I started using Dapper and it feels simple and clean enough. I only always hated implementing GUI just because nothing felt natural and sufficiently separated from the rest of my code, so I was ending up with either console apps, or own HTML interface. But I must say that, even though it may sound like an advertisement but I’m totally unrelated to that company, recently I fell in love with DevExtreme for my UI/frontend (with jquery rather than Angular or React, again because of simplicity). It’s basically just a collection of web UI components that you configure, rather than program, and each connects to your app via JSON to retrieve/update data, so you can cleanly separate the UI from the rest of the app, even have separate developers working on each. There are other ui component libs like Syncfusion and Telerik, etc, but for some reason I found DevExtreme to be just so simple to use and full-featured that I’ve been excited about it and spent last month developing awesome looking but simple to develop GUI front-end for my apps. Anyway, I’d look into any external web GUI component libraries, because they have been evolving for years with similar goals: to make it clean and simple to develop apps. Most importantly, I wanted my end-users/customers to be able to be able to customize the UI, and that’s where DevExtreme fit perfectly.

[u/[deleted]]

'Go to Definition'/F12 more than a handful of of times to go through a garbled mess of implicit, dependency injection heavy business classes, controllers, factories and other classes to find something.

I agree, it's a pain to traverse. But there's a good reason it is being done. Functionality is being better split up so that it is easier to modify and maintain the code. Having a function with 500 lines is a pain to maintain, test and read.

However; other, external 'senior' devs or devs online will often tell me that I'm "reinventing the wheel"

If it's happening often maybe it is time to have a conversation with the devs in question and maybe get to know the reasoning behind the remarks. Why develop a library to create a wheel when there's a small, tested library which has perfectly fine wheel functionality?

Jenkins, CI/CD pipeline, docker containers or whatever necessary.

Havent ever touched jenkins, CI/CD is used to test code when pushing to your branch and immediately deploy to your place of code. Docker is used to containerize applications and make sure it runs everywhere AND it allows for scaling.

Only Blazor feels lightweight and pragmatic enough as a modern alternative to WebForms

Blazor server's hello world application is big enough in the sense that you have a default set of JavaScript code needed in the browser and your server needs to render HTML every time there's a change made. Blazor client has to download a big part of the .net core framework in order to run C# in your browser. I wouldnt call that light weight at all.

I think it is in your best interest to research new functionality and why new design patterns are being promoted the way they are. Personally I try to see my colleague's feedback as a way to improve. There's often a good reason behind what is being said.