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.
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.