I’ve decided that treating the web like it’s made up of HTTP requests, headers, images and markup is a bad idea. That the web, in all it’s HTML and javascript glory should not be treated as such. Instead, it should be treated as a big, fat, hairy delivery mechanism. Something that needs taming and requires a high level of abstraction to build anything useful on it. It’s like writing Win32 code to run on an old Commodore (which I’m sure someone has). Your HTML will never be in a native environment.

I’ve worked on the web for a long time. Not as long as some, but a good amount of time considering that we’re only about 13 years in. I started in HTML. Then DHTML and Javascript. Then VB Script with ASP. Then finally, ASP.NET, and where I’m currently treading water, with ASP.NET + CSS. Each of these progressions brought more sophistication to the “we’re all connected” yet annoyingly disconnected web. Static moves towards scripting, then on towards compilation then towards web UI control sets and finally CSS based layouts thrown on top. And with that, I assert the following statements to be false: over the years programming for the web has really become simpler. Our standard libraries make it easy to make applications run identically across the browser “environment” and across platforms. The web experience performs akin to a cougar chasing it’s lunch. We’re caching all our images on the client with a push of a button and decreased our time-to-last-byte counters on the server. I can’t see how any of these statement can be claimed for someone, or company, with out spoonful hubris. The web is the same promise of Java….write once, run anywhere. Yet, like Java, it can run anywhere broken, slow or unusable.

How many man hours have been spent across the world of web development trying to get some HTML to render properly in Internet Explorer? What could we have done with those computing cycles? What could they have done with their time? And it’s not just IE – Firefox is just as much a culprit, because as some have pointed out, IE became something of a standard by sheer market share – so the community programmed to it.

Now, let’s move beyond the simple web page example. Everyone knows that tweaking is a fact of life to get things working in a browser. The thing is, a whole cottage industry of consultants, designers and websites thrives off of it: A List Apart, CSS Beauty, etc. They boast the beauty and elegance of shiny CSS and the taming of the shrew; a.ka. HTML. Now you can move your presentation out of your presentation. What? To me, that’s appears to be the intent. Sure, I like using CSS to style, position and provide reuse, but it’s just moving the bits over a little. Skinning? Who does that?

But it’s not that simple. I got caught up in the sordidness. In the slickness. In the elegance. In the load of horse maneur I was being fed by reading web design sites and spending time with designers whose personal sites looked so cool and made me long to be just-like-them (wow, your style sheet is so organized!). I stood up for the purity of our HTML and for simple, open javascript libraries. I crowed about div’s and easy to read CSS files. I became the one cleaning the stables; shoveling the maneur.

And it’s not easy either. Consider the classic N-tier model: data layer, data access layer, business logic layer and presentation layer. This has been the thought pattern across most business applications for the last decade. Can we separate all these layers cleanly? At the end of the day can these layers really not know anything about each other? Nothing? MVC, as old (sorry, classic) a pattern as it is, won’t help when a business rule you never saw coming shows up. Or, some performance tweak must happen at the data access layer that is really implementing a tiny bit a business rule somewhere. How has our luck been with this? Is this even OOP? I don’t know what it is, exactly, but it’s not impressive.

Now, consider the presentation layer: your application needs to look a little more blue for some customers than others. That’s the requirement. So, where is this going to occur. You could apply a whole different style sheet with a few elements with a higher blue saturation. That would do it. But then you have duplication. You could heavily modularize your CSS files and make judicious use of “@import blue.css”. But now you don’t so much have an applicable style sheet(s) as you have style modules that are pieced together on the fly by the application or composed into more style sheets by a designer or developer. That doesn’t sound to bad to me – but I’m a software developer. But how would that sound to the UI designer/developer? Or, you application can replace the style for element A with the more blue style. My point, if you’re not catching it already, is that there isn’t and can’t be a clean separation of layers. That’s just not how the world works. Even in the food chain, an ant eater may eat ants, but those ants may have been surviving off ant eater excrement. There is a connection – maybe not a pure symbiosis, but it exists. You’re stored procedures are connected to your business logic in one way or another and your CSS is in cahoots with your HTML and (gasp!) your script/compiled code. That’s life.

On the flip side are the folks at all the web design shops whose biggest output is “sweet” CSS with mirrored background images that they show off to other designers and brag how it works in Safari. These are the marketing, branding and product sites. They aren’t concerned with reuse. They aren’t concerned about skinning. To them, CSS is a very flexible way for them to think and build web pages. It let’s them focus on making their site look as slick, as gentle, as in your face or as required by their client as possible. That is the non application side of using CSS. And it’s very different than what I, or the folks I associate with deal with.

Now, if we accept the hypothesis that clean separation of concerns is not attainable, if even just for arguments sake, then what is the course of action? That’s simple: don’t worry about it. This is probably enough to make the most staid of personalities somewhat indignant. But yes, the simplest answer is to not worry about it, or better stated, don’t worry about the details. Build your applications at such a level that your developers can worry about concepts not rendering. So that they don’t constantly have to make decisions on whether to use a span, a div, or a list (in horizontal mode none-the-less). Build libraries that render exactly the HTML you want and not what the web design community says you should have. It’s a different application of CSS or HTML or the web in general really. One of the reasons you shouldn’t have to worry about every detail of HTML and CSS as you create a new page in a web application is because the page doesn’t exist anyway.

I’m not saying there “is no spoon” (i.e. the Matrix), in that you can wish the page away. Instead, look back towards the origins of the web and our good friend Tim Berners-Lee. The original intent was for document navigation. Link from document A to document B. Not a generated on the fly document B, but a real document whose bits are on disk somewhere. Where if you were sitting at the console of said server, you could type “vi documentB” and be presented with the same thing that someone using browser would receive.

So, the page doesn’t exist. A representation of a page, generated in memory and streamed over HTTP via TCP/IP exists and then disappears. In that payload are a bunch of bits. These bits are then pulled together, parsed and rendered. A page isn’t sent to a browser – but the notion of one is. In the same way, you should write code and develop web applications towards the notion of a page. Once the page is considered an abstract concept it can be created as an abstract type with a modicum of work. And thus begins the business of abstracting the web away from the web application.

If you call a method on a business object to retrieve a list of widgets must you absolutely know that it’s talking to MySQL on the back end of the transaction? No. Not if it’s built even close to correct. Again, so why must we pay such attention if we’re receiving a POST or a GET. Heck, it seems a wasted effort to handle both (I know there are camps that don’t use POST) since it’s your software that dictates the communication request to your server. Your application receives a request. Plain and simple. Another example is web platforms that have a one to one mapping of a file to a URL. That just doesn’t make sense since that file (page) isn’t going to be sent back in the state it is on disk anyway.

Continue moving down the stack and we’re back at CSS. Ebay figured out a way to handle their CSS and images. Through some really slick Eclipse customization and use of software factories they compile all CSS and images with their source code; they’ve integrated instead of separating. It’s more complicated than I make it sound, but the idea is that the reuse of these assets is identifiable through their source control and build procedures. It’s not a secondary asset that is applied on top of all the engineering. It’s been sucked into the process. At the end of the day, the browser receives a bunch of CSS, but maybe some of it’s on the page and some of it’s in external files. It doesn’t matter that much. It’s more aesthetic than anything that all CSS should be tightly contained and able to be opened at any point in time in Dreamweaver. It’s trying to be separate when really you want it contained. You don’t want it to really exist. Just like the page, the notion of CSS files is great. And the rendering and positioning it provides is very helpful (plus it renders faster) but you don’t need to be explicit and draw lines in the sand of your application to make it so. A web application is software that delivers the notion of a document. The document should work extremely well in the requested browser. But the programming and design of a web application should be at a higher level of abstraction. The web, browsers and buzzword technology will outpace your development and features. This provides a way to either match that pace or ignore it.

From forward to Structure and Interpretation of Computer Programs; Abelso, Sussman and Sussman
“After a short time we forget about syntactic details of the language (because there are none) and get on with the real issues — figuring out what we want to compute, how we will decompose problems into manageable parts, and how we will work on the parts.”

Advertisements