I Hate Programming for the Web

So I have really been thinking about this for a while now. I have had the chance to work on more then one web based project. I have also had the joy of attempting to write a website for just TWO browsers (in a time when there were essentially two well known ones, IE and Mozilla). I have come to the same conclusion each time I do it, I HATE writing "applications" for the web.

State (NO, not friggin' New Jersey or Pennsylvania)

Gripe number one, the web SESSION. This little beastie is meant to turn what is normally a stateless protocol (http or https) into a stateful one. It is meant to keep track of things on behalf of the client, on the server, for the purpose of making mere html pages seem as if they are an application. This session information makes the loosely coupled html pages hang together as if they were a full blown application. Depending on your platform a programmer can store just about anything that they can dream up into the session and then call it back at whim. So you might ask - what is so wrong with the idea of storing some of this information? One - it’s a bastardization, the web was never designed to have such a construct. Some smart people made it up to solve the problem of doing more "interesting" things with web sites. Two - it can if not done correctly, completely screw up and make pointless any load balancing you may want to do to make sure your web servers can handle the load of all the people attempting to hit your site at once. Lets be blunt, if you wanted a cohesive state (engine or otherwise), why didn't you just write an actual APPLICATION?

Standards - We don't need no friggin' standards

Gripe number two - HTML/CSS. Look these things are supposed to operate the same way no matter what 'interpreter' you use to parse and present the results of the markup that is HTML. Both of these things are supposed to be standards that leave little or no room for interpretation on what it is that they are supposed to represent or what they are supposed to do when they are parsed out to make a web page. However, as any web developer will tell you, there is ambiguity in the standard that then gets interpreted by a browser programmer and as such leads to the different browsers doing different things based on the EXACT SAME markup and CSS. What a FRIGGIN' PIA. FOR REAL? What you get out of this is needing to maintain more then one CSS for the different types of browsers, or to maintain different CSS markup in the same file for similar purpose. This is all done in the name of making the ONE web page you just wrote look the same no matter which browser it is being viewed in.

Singular deploy

Gripe number three, while it is true that I get to deploy the application just once, as you can see above - I might as well have deployed the application one time for each browser type I wanted to support. My code is different essentially for each one. Granted - a lot of the logic is deployed once (i.e. the dynamic stuff I am doing behind the 'presentation' that is a web page) so I'll give anyone that one no questions asked. The other thing of interest here - will things like the Apple Application Store bring back applications on the desktop? Think about it - a super easy to use, easy to deal with installation and management mechanism that has what amounts to a micro payment to purchase in a great number of cases. VERY interesting if you could make that system work on more then just the iPhone/iPod Touch.

Security

Gripe number four. The web is a huge pain in the ass when it comes to security of what it is that you are developing. There are phishing attacks, XSS, CSRF, and god knows how many other varieties of remote type attacks. There is injection of a variety of kinds to top everything off. Add to all of this stuff that you have to defend against on the server side you also have the security vulnerabilities in the browser to contend with as they may make any of the other styles of attack that much easier. Desktop applications may have a number of the same types of problems, but at least I can count on only having to solve them in the application and not having to deal with accounting for both a browsers issues as well as problems in my own code. All this in the name of not having to deal with remote installation of code. Lets just acknowledge that installing software and managing packages has gotten a lot better then it was and consider it when new projects come around. But we don't we stick with deploying things as 'websites' because that is what EVERYONE DOES. I would still at least consider, in a closed circuit, if doing something new as a web app (i.e. internally for a company) makes the most sense before embarking down that path. Think Customer Service application and ask yourself if it makes sense to be a web application. Really?

AJAX - Flash and other ilk

SO - IN THE NAME of all this is freakin' holy, because we want things on the web to act, look and feel more like applications on the desktop WE ADD things like flash, silverlight, ajax etc. These things essentially provide a 'framework' window in which to - wait for it - WRITE AN APPLICATION! Are we all certified morons? We are all OK with this - it might as well be a java applet for cryin' out loud. All of these things break browsers in some very fundamental ways because the URL that renders the page is now a meaningless bit of fluff, the forward and back buttons which worked wonderfully when all the web was stateless are also now meaningless because they all work on the context of a page - and all the flash, ajax and silverlight items do not. Talk about ass freakin' backwards. Lets take a browser and put an APPLICATION in it rather then a web page. All these items are designed to get more control over something that was specifically designed to be so much more light weight and easy to use.

URL Shortners

Talk about compounding issues - now on top of everything else we have a class of services that shorten URLs so that emails and Twitters and other such 'social media' items don't have to deal with super extra special long urls links in text. HELLO? FOR REAL? I think Jeff Atwood put it perfectly when he pointed out that an href in html or url tag in bbcode or what have you were specifically designed to SHORTEN THE ACTUAL url so that you could use a single word as a link if you wanted. These url shortners add another level of complexity for finding things on the web, they can't be indexed, the can't easily be searched - they are not descriptive - and lets not even discuss what the hell happens when the 'site' that is doing this additional translation of short URL into the real one gets compromised. Now ALL those short urls are taking people to places that are installing malware. Awesome.

Face it - the web is a giant mess. Yet we all seem to still so enamored with it and everything must have a 'spiffy' interactive, loginable web presence. When are going to wake up and truly solve the issues of attempting to make web applications be actual APPLICATIONS? I dunno, but I do know its going to continue to be a pain in my side for a long time to come.