--- title: "Asynchronous ASP.Net actions suck?" url: "https://osherove.com/blog/2003/9/1/asynchronous-aspnet-actions-suck.md" canonical: "https://osherove.com/blog/2003/9/1/asynchronous-aspnet-actions-suck.html" published: "2003-09-01T02:55:00" updated: "2003-09-01T02:55:00" tags: [".Net Original"] author: "Roy Osherove" description: "Every once in a while you get to do dev work in an area you know nothing about. That’s me and ASP.Net. Well, I do know some things but it’s all theoretical. I never really got to do asp.net development in a “real”…" usage: "Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page)." license: "https://creativecommons.org/licenses/by/4.0/" --- # Asynchronous ASP.Net actions suck? By Roy Osherove September 1, 2003 In [.Net Original](https://osherove.com/blog/category/net-original) **Historical article** · Originally published September 1, 2003; technical details may be outdated. Every once in a while you get to do dev work in an area you know nothing about. That’s me and ASP.Net. Well, I **do** know some things but it’s all theoretical. I never really got to do asp.net development in a “real” situation. Yesterday, however, I got to do just that. I needed to integrate a library I wrote in .Net to be used in asp.net. Mind you, this wasn’t just any “get my data” kinda lib. It does some work asynchronously, throws events when it finds some stuff and takes a long time. Having some from a strong background on win forms and VB, with no web experience what so ever, I’m used to easily enable my apps with progress bars, asynchronous status updates via events and so on, all in a rich UI. Moving over to “stateless” mode pretty much throws much of what I know and love to the garbage can, leaving me to find out how the hell am I supposed to this with an object that is destroyed in the next call. I still haven’t figured out a way to do it. The closest thing I found was actually quite a complicated piece of work. It looks like the infrastructure required to do this entails public or protected properties in the code behind class, HIDDEN fields that reflect those properties in the web form, and a JavaScript function that occurs in the “OnLoad” event of the page (in the BODY tag) that checks if it should call “submit” on the form itself. That’s not real asynchronous. It’s plain old procedural programming, with the scripting function acting as the good old message pump. (how difficult would it be in regular ASP??) If you have any web experience you might be laughing,   but I’ll still ask : **Why the hell is it so much more difficult?** The answer is, of course, that the browser was never meant to be a real application platform. Therefore, it will never provide the power we expect in today’s rich applications. Dev wise, it means we’ll always have to “work around” problems instead of focusing on the business value of our web applications. Example – instead of wondering “what’s the best way to show the user the progress”, I’m actually wondering if **there is** a good way that’s actually feasible without it taking a week to implement. Smart clients (auto deployed) provide an answer for this problem. They still do not provide an answer for not having the .net framework installed on a user’s machine (which people are **still(!)** afraid of) which is the main reason I’m working on an ASP.Net project right now, instead of an auto-deployed smart winform GUI. Hopefully, this will change soon. ## More in .Net Original [All posts in .Net Original](https://osherove.com/blog/category/net-original) - Sep 1, 2003 ### [Hosting the CLR - the native approach](https://osherove.com/blog/2003/9/1/hosting-the-clr-the-native-approach.html) - Sep 1, 2003 ### [The \[Conditional\] Attribute](https://osherove.com/blog/2003/9/1/the-conditional-attribute.html) - Aug 25, 2003 ### [Loading Winform UI controls from a different AppDomain is problematic](https://osherove.com/blog/2003/8/25/loading-winform-ui-controls-from-a-different-appdomain-is-pr.html) - Aug 25, 2003 ### [The ultimate connection string reference](https://osherove.com/blog/2003/8/25/the-ultimate-connection-string-reference.html) --- ## About the author **Roy Osherove**: Senior Solutions Architect at AWS working on AI for production and AI-driven development; author of The Art of Unit Testing and Elastic Leadership, with about 20 years of consulting and training on unit testing, TDD, team leadership and continuous delivery. ### Sites - [RobotPaper](https://robotpaper.ai/): This blog: AI patterns and anti-patterns, AI and coding agents, and engineering leadership. - [osherove.com](https://osherove.com): Roy's personal site. Author of The Art of Unit Testing and Elastic Leadership; consulting and training on unit testing, TDD, team leadership and continuous delivery, plus about 20 years of blog posts. - [The Art of Unit Testing](https://www.artofunittesting.com): The Art of Unit Testing, 3rd Edition (Manning): readable, maintainable, trustworthy unit tests, plus TDD workshops in C#, JavaScript, Java and Kotlin. - [5whys.com](https://www.5whys.com): Roy's writing on software team leadership: self-organizing teams, surviving chaos, learning mode and the Elastic Leadership model. - [Pipeline Driven](https://pipelinedriven.org): Continuous delivery and DevOps practices: build patterns, pipeline-friendly testing, DevOps metrics and enterprise DevOps. - [Elastic Leadership](https://www.elasticleadership.com): Elastic Leadership, Roy's framework for software team leaders (survival, learning and self-organizing modes). ### Social - X: https://x.com/royosherove - LinkedIn: https://www.linkedin.com/in/osherove/ ### Contact - Contact form: https://forms.gle/jQSx5KoXvrVA1JCK7 ### License Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page). License: https://creativecommons.org/licenses/by/4.0/