where's the beef (web design)

I've got some personal problems with internet technologies. The central problem is that, as a game programmer, I've never really respected web tech. The web is static and unresponsive. Most of the code is bad. Most of the languages used are (dynamically typed?) and unresponsive.

But as I keep pushing forward anyway, it seems to me that my central problem has been that I don't even understand where the work happens. Where's the beef, as it were.

A game, for example, is written in one programming language, and is tightly bound to itself, and to a single machine. It's easy, in principle, to follow the path of execution from user input, to simulation, to display. And in between there's a mass of c++ or what-have-you that makes everything go. To me, that makes sense.

But on the web, I face a daunting situation. The user sits on machine A, in browser B, makes a request to server C, which hits database D, and when the server gets the data, it renders a page, and returns it to the client. The browser then renders the page, and then the client side code takes over and manages some of the interaction going forward, talking to the server as necessary.

Just to take one example, count the number of languages, or distinct syntaxes, involved in this chain of events:

  1. URI/URL, (HTTP)
  2. ASP*
  3. C#
  4. SQL
  5. HTML
  6. CSS
  7. Javascript
  8. XML (webservices, optional)
  9. Flash (optional, special purpose)

So, as a newcomer to the field I say, great, where do I put my application? Where does the code go? And the sad answer is, it has to go everywhere. In order to make a high performance site (the only kind I can even bear to contemplate), you need spend time with each of these technologies and syntaxes. The connections between most of the different languages are very loose. There aren't a lot of good tools for looking at more than one or three of the languages at a time. And they all matter.

So my essential personal problem with web development, is that I find it absolutely disgusting. It literally triggers my "unclean" emotional response. And then I shut my brain off and try to hold my nose as I program, and it's not very easy to work one-handed.

Well anyway I have these websites that I want to build. So, I need to get over it. I need to get over my tightly-bound, completely-integrated elitism. And so part of what I've been learning lately, is that I've been looking at the stack in the wrong way.

Now that I've figured out that nobody designs websites in html and css (they design in photoshop or illustrator), things are starting to make a lot more sense. I can redraw my big list like this:

how does it look?
1. Photoshop/Illustrator
3. CSS
4. ASP (optional)

what does it do?
1. SQL
2. C#
3. ASP

how does it feel?
1. Javascript
2. XML (webservices, optional)
3. Flash (optional, special purpose)

So, there are three distinct jobs here. (Four, if you count the job of drawing the lines in between the categories.) Each job has good tools associated with it. Each job covers a small enough group of technologies that it's possible to work effectively. The trick, I think, is to only work on one job at a time. Put on your architect hat and draw the divisions. Put on your UI art hat and render the page. Put on yous system engineer hat and define the services. Put on your game programmer hat and write some javascript.

Do not, under any circumstances, try to design your page layout with C#. That sort of procedural art is technically possible, but it's incredibly time consuming, and the tools for it are terrible or nonexistent.

I know this isn't novel, but I feel so much better for writing it down.

*I'll use the ASP.NET C# stack because that's what I've been using for my personal projects. I strongly suspect that it's not much better or worse than anything else. I know I personally like it better than Ruby on Rails. I've never really tried PHP.

No comments:

Post a Comment