What's the Best Web Site Builder

I don't think it exists yet.

There is a parallel between Web Site Frameworks (and friends) and Operating Systems and I think we can build better web site development systems if we're aware of it.

About OS's (at a really light level)

Operating systems really stated out as Monitor programs which allowed a 1950s and '60s 'programmer' to load and run one program at a time on the monster sized, minuscule capable early machines. They sucked, but it was better than programming in machine code.

The big advantage Monitors gave was that if you upgraded the hardware, you reflected the change in the Monitor and your old programs still ran. MS-DOS and CP-M were really Monitors, not operating systems.

Then smart people developed the idea of an Operating System. One problem with Monitors is that they didn't have any way to recover control of the hardware when the application program went into a infinite loop or some other destructive mode. OS's had an executive module which allowed the program to run. It regained control periodically and decided whether or not to kill the program or let it run. In other words, you had to get permission from the OS to run your program. It sat there like a despot, completely controlling what you could and couldn't do and how long you could do it.

To get Back to Web development, I think we're at the 'early-ish OS stage'.

We've already gone through the Machine Code and Assembler Language stage with raw HTML and doing everything with Tables. Monitors roughly correspond to writing everything by hand - with or without a tool like Dreamweaver - one site at a time.

Drupal, Rails, Joomla!, and friends look very much to me like early OS's. When a request goes to the server, it is caught by the framework's machinery. The framework (read OS executive/sultan/king) then decides what to do with it.

So What's the Point?

What's the most successful OS model of all time? UNIX!

Why?

UNIX gave Choice to the Programmers and took it away from the OS Designers.

UNIX was a fundamentally different from the other OS's. IBM and everybody else put everything that a good police state needs to control it's citizens inside the operating system where nobody could get at it except the privileged few. UNIX didn't.

The UNIX system consisted of two parts: the kernel, which provides services for it's citizens and userspace, where things are done.

The kernel supports and enables. For the most part, it doesn't control. All the Executive stuff is in userspace which means: it can be replaced by the people Using the machine if it doesn't do what they want.

This is really important so I'll repeat it. The kernel supplies services, but doesn't do anything. It just sits and waits - like a good robot. All the action is in userspace and it can be replaced if you want something different.

All the web frameworks I've looked at over the past year and half have the Executive function embedded in the framework. That is, when a request comes it, it's received and processed by the framework. Right now in Web Development, if you want to do something which is not directly supported by your framework, you have three choices:

• hack together some lame work-around
• don't do what you want
• get another framework

It's just like the pre-UNIX days.

When UNIX came in, it became possible for the Programming Community to build lots of alternate Executive function implementations as drop in replacements for the stuff which shipped with the system. Free Market!!! That's why UNIX is a great development environment and why it makes such a great server environment. The Programming Community developed a lot of stuff and kept the stuff which works.

That couldn't have happened if we'd had to change kernels for every alternative design - or it would have taken a gazillion years longer.

The Pitch

I think we need Web Development kernel. I'm working at spec'ing one out. I call it uWeb (pronounced 'you Web')

Me and the Leopard

I installed Mac OS X 10.5 - aka Leopard - last Saturday (or was it Sunday) and just now finished reverting to 10.4.10. Boy oh Boy, has it been non-Fun.

Well, it was really my own fault. I know better than to install the initial release of anything, but, I'll admit it, I got lulled into wanting it - salivating even - by listening to Steve the Jobs extol Leopard's features. He's really right: they are really neat, look great, and will make using the machine so much easier. So when Leopard came out, I pounced.

Anyway, skippin’ the boring details:

• Printing to my HP All-in-one died dramatically
• Time machine doesn't work across a LAN w/o OS X Server - for another $500
• 'admin' accounts spontaneously became 'standard - Twice
  

So I got scared and spent the next three days reverting back to Tiger. (I finally did an Erase and Install and reinstalled/rebuilt everything)

I'm waiting for 10.5.1, and then I'll try it again - maybe.

Design Patterns?

I was asleep in the country when Design Patterns became popular. It seems now that unless you've had a 'pattern implant' you're not qualified to solve problems.

This came as a shock to me because I've been analyzing and solving problems for a long time: I escaped Engineering school in '68, '70, and, finally for good, in '72. We didn't have 'design patterns' then. We had principles, experience, and knowledge.

So what are these things? Are they a good thing or not?

According to the Wikipedia article on Design Pattern (computer science), a design pattern "... is a description or template for how to solve a problem that can be used in many different situations."

So far that sounds good, but then I start getting confused:

• design patterns are not algorithms because "algorithms solve computational problems." I didn't know that. I thought algorithms were systematic, iterative procedures which did something - like copy a buffer from one place to another or to find something.
  
• design patterns are not "architectural patterns" because they have a "different scope."
  

Then I read some stuff by Martin Fowler describing the Active Record pattern. The thing that came across most strongly is vagueness. Everything is so indefinite and "could also be ...".

It all became crystal clear!

Design Patterns are the current Holy Grail of the Software Methodology Guru.

As long as I've been beating on computers, there have been Great Gods of Software Design. I used to read their stuff and think I was doing everything wrong because I wasn't doing it their way. So I'd try it and it didn't work very well for me (why later).

The Software Methodology Gods are really OK guys, but you have to judge their gospel within its context. In other words: what do these guys really do?

One thing the don't do is actually build the kinds of systems they tell you how to build. Why? Well, they don't have time. They spend their time watching other teams build things and writing and preaching about what they've observed. At least that's what they are supposed to be doing. [And the reason it didn't work for me is that I've never worked on a team. All my stuff was in-house, solo or with a partner, limited scope, and very limited user base. Their experience did *not* apply! see Joel on Software, chapter twelve "Five Worlds"]

So these guys' main business is giving advice.

I'm sure a lot of the advice is pretty good - it has to be if they get from watching teams that do good work. But that doesn't mean it's right 100% of the time and in all cases. Anyway you can't really tell if it works, because there's no way you can compile and execute vagueness.

OK, I'm a little harsh. It's just that if the advice is vague, then it's usually pretty easy to win the postmortum no matter how things work out - success or failure. If it worked, it's because you followed my advice. If it failed, it's because you didn't. Vaguness covers or excludes a whole range of implementations.

Anyway, what happens is this: These guys sound so confident that I used to get lulled into thinking that they're right and I was wrong.

What's the result?

I'd read their stuff and instead of trying to figure out if it is worth doing in my situation, I'd spend all my time trying to figure out what they're talking about and how to change what I was doing to be right - according to them.

I was working my brain, but not on the right problem. (By the way, would you be interested in this really great vacuum cleaner we have on special today?)

So, here's what I think Design Patterns are good for:

• ideas - look them over and see how somebody else does it
  
• obfuscation - if you know enough of them, you've got a great cryptic language you can use to blow smoke in the other guy's face
  
• writing books and articles - "Design Patterns for ________". Just fill in the blank and you're all set for fame and fortune
  
• getting consulting gigs from non-technical managers
  
• giving courses to programming teams
  

One thing they won't do is make mediocre and poor programmers productive.

So what am I going to do now? Well, I'll read the book. There must be something useful in there. But I'm not going to shut off my brain when I design something.

Why MVC is Wrong

First of all: MVC is Right because the model separates problems into three relatively independent functions.

But, MVC is wrong because it's being used as though it is the Only way to do things.

It's Not.

The problem is that Presupposing or Requiring an MVC model interfers with the Design Process.

Here's the best way we've found to design and construct systems:

1. figure out what is to be done and define it precisely and succinctly

2. define a collection of tasks which can be performed in series or parallel where the results can be either combined or fed to successive tasks which produce the desired result. Ideally, these tasks can be defined as 'black boxes' - to use the term I was taught back in Engineering school.

3. Build the boxes, test, deploy and celebrate.

In my experience, every field - Engineering, Computer Science, Economics, etc etc - has rediscovered the same method and principles - but uses different terminology.

In CS, black boxes were 'objects'. Now they are Design Patterns. We used to talk about Heirarchic Decomposition, Information Hiding and Structured Programming. In client-server designs, we talk about clients, servers, and protocols.

It's all the same stuff.

1. We figure out what we want to do.

2. Then we chop it into pieces small enough to build.

3. Then we define some protocol to get inputs into and outputs out of each piece and use them to wire the whole thing together.

MVC Screws this up mostly because it puts the Chopping before the Analysis. This Adds complexity to the solution rather than taking it away.

For Example:

Suppose I have a semi-static web site. By that I mean, nothing changes all that much, but the owner would like to modify something on a couple of pages every once in a while.

I can Make this MVC, but why bother? There's nothing to Control. All I have are Views. The only 'model' I have is a chunk of Text. Most of my pages can look like:

<html>
etc
<?php include('owner-content'); ?>
etc
</html>

If I have a way for the site owner to update 'owner-content' - possibly a simple update page so she can edit the page on her home machine and then download it to the site - then I'm done.

I don't need MVC partitioning of this problem unless I want to use a prepackaged system.

The obvious answer is there isn't any need for all that machinery to solve simple problems.