Web Programming is a Hack

I'm surely not the first person to make this observation, but I don't understand why it's rare.

I've spent most of my career so far doing either non-web apps or things like web services that are cohesive programs. Now I'm doing web development full time, so it's in my face.

HTML/HTTP was (as we all know) not intended to be a systems development platform. Nowadays, darn near every system must run over it. That's a fallacy, of course; many web apps don't need to be so (how many corporate internal web apps are there that could be much simpler as desktop apps), but most people think it's true.

Everything is so fragmented in web development - you may have:

• Code on the client for validation or whatever.
• Different code on the client that has nothing to do with the other code (AJAX).
• Code constructs in your CSS.
• Code on the server.
• Code directly on the page (sometimes necessary).

That's just the code; the process itself is enormously complicated - and I don't know the half of it. As I've said before, complex ain't cool. It's certainly possible to make some things clean in web development, but the whole process isn't.

Consider what I had to do recently in order to make a simple animated gif run while a lengthy process takes place. I fully realize there are other ways to do it (queuing the process and just returning a simple message seems the best candidate), and I'm constrained in this case by slightly older technology (.net 1.1), but still:

• Client submits a batch of email messages. (Note: IE locks animated gifs while waiting for the return of a post).
  
• Server receives request, needs to return quickly so it starts an asynchronous process to send the messages, sends down a javascript handler to the page to receive the results of the asynchronous process, and turns on the gif.
  
• The page receives the result so it starts animating the gif.
• The asynch process starts sending email messages maintaining a collection of those that may have failed.
• When it finishes, it can return text to the client, but that handler can't receive complex results (JSON not avail, can't use a web service here), so all it receives is the number of successful email messages. It stuffs the failed collection in cache on the server.
• Now the client receives the result, knows how many messages were successfully sent, but it doesn't have the data on the failure collection. It builds a url to post back to the server with a query string sending the number of successful email messages back.
• The server detects the successful email query string, checks for a failure collection in cache, binds that to a grid (and turns it on) if it exists, writes out the successful number (couldn't have done that on the client because the state would be lost on the second trip to the server) and returns. Whew!

That's a hack. But I have to do what I have to do. The web constrained me. It's still fun, but it always feels kludgey.