Events + Web = hell

This title is there to reflect the hell I live when you push the boundaries of event management, web and a little bit of client-side scripting.

I will launch in few days a new website about science in Irish schools for Secondary pupils, ScienceUnleashed.

Check yourself if you want to have a look, but be aware the site is still in debugging mode, and I can say it's hard, very hard to debug a web application with so many things happening on a screen.

I curse actually the Postback system, and I wish Whidbey improve the system.

An example. I build a dynamic Quiz working well alone. But I also have a popup control triggering a Postback, so I have to redraw the Quiz after the window show up, otherwise my Quiz controls will be empty.

But I have 4 different states for the Quiz, so every time a postback happen, I have to test which state I am before redrawing the Quiz. Pain in the ass!
Also reading the values from a form is basic stuff, but because you can have another event somewhere on the page I have to store (State bag) each value of my form. Pain in the ass!

And I have at least 10 cases happening like that !

I don't want to be too negative, the overall .Net experience is good for me, but I dream about some future improvements in a .Net web application like:

- Truly multithread events including Postback. Doing so,  each event will have his own execution without the necessity to worry about refreshing the page.
- Better implementation (well surely in VB) of the events themselves. I would like to see something like a button click from my code. Maybe I am wrong but I couldn't find something simple to fire a button through my code.
- Less bloated viewstate. The source of the default page on my site look like the Champollion tablet, overloaded with strange hieroglyphs.

OK maybe it's my bad day, but I have to post this rant. Nothing is perfect in .Net kingdom.