1. Developers cannot think ahead well enough to create the right abstractions. This may be because of the developers, or because the spec is changing too fast.
2. The presentation and the logic are bound in some manner. You can tell you have this problem when you're trying to implement a programming language in your presentation layer
3. The logic is nearly non-existant. You can tell this is happening when your web site is looking remarkably like your data model and you're doing things like taking the results of queries and dumping them straight to XML followed by a simple translation or something like that.

If you are in the rare group that is not qualified by one of these situations, THEN you need to start worrying about logic and presentation seperation.

If you recognise one of the above, GIVE UP NOW. You will save yourself a LOT of pain no matter what platform you're developing under. There are other processes to manage complexity and performance which are much more appropriate, find them and use them, seperation of display and logic is a tool, not a holy law.

Assuming that you actually need to seperate logic and presentation, sit down with a bit of paper and think about why. Let me give you a hint, if you're honest about this, and reason #1 comes down to "because j2ee and .net can do it and management thinks its good", FIND a CLUESTICK, BEAT your MANAGERS until they understand that architecture is the job of an architect, not the job of the architects manager.

If you have used a different reason for #1, it is probably some mush containing the words performance and scalability. I hear tell, in certain circles, that it makes much more sense to scale by just buying another box, that programming for performance is a waste of valuable programmer time and effort that could be better spent getting the application out the door.

Let me point out right now, that there are almost no web applications on the planet, that cannot have another box supplied, session affinity turned on at the accelerator, and simply work. There are a very few conditions you need to have in order to make this work:

1. A web accelerator that supports session affinity. They're not rare.
2. A web application that uses some kind of network-connectable database backend
3. A web application that doesn't do anything on the local filesystem or tricky stuff with shared memory.
4. An SQL database that can replicate

2 & 3 are MOST web applications in the target area (that we haven't alreayd eliminated above). If you're designing from scratch, these conditions are a piece of cake to code within. Thats it people. No J2EE, no serialized objects wandering around on the network, no XML and no remote procedure calls.

So using the circles reasoning above, why would you waste your programmers precious time on an inferior platform that supports a useless feature? You don't need it, it doesn't get you anything, and you can write the code in half the time in perl.

Are you still reading? do you have another argument in your head? then let me explain the last level of web application. This is the level whereby you have specialised acceleration requirements. Perhaps you have a low-cpu-cost logic section which needs to be tightly coupled, and a losely coupled, high CPU cost presentation end. For example, imagine that the logic section involved calculating collisions between 4000 box models, and the presentation section rendered them. The 4000 boxes, each moved by an individual client, benefit from tight coupling, being on one machine. The rendering however, is per client and CPU expensive, so we want to farm this.

Yay! we have a good solid argument for the seperation of logic and presentation using a remote invocation system.

Anyone doing the above? raise your hands...hrm, nobody? listen, I've been doing these things for years, and only ONCE did we build a logic system. You know what it was built in? C, with shared memory, and synchronisation via broadcast UDP. Because it was hellishly performance intensive. No RPC crap would have saved us there, we had a real problem, not a make-believe one.

Laziness people, one of the magic rules, don't make things more complicated than they need to be, most of the time you're just making work for yourself.