I have been doing web design and development for a few years now. It's been interesting. I have seen a lot of different designs and been part of putting together a good many web applications for different companies. Each of which is done in at least a slightly different way, even if they're using the same technologies. Though I have primarily seen these things done in Java and a few open source technologies, I have an insight to share that seems to be pretty obvious to me, but not so much to others. This, from the perspective of a front end designer, after being part of several great teams.
It seems that the most successful web user interfaces are completely divorced from their back end counterparts. This is somewhat anti-intuitive from traditional web design. In Javaland you have JSPs that are directly included as part of the project. It seems to make sense that they would become integrated with the middle tier because it's so closely linked. It creates a false sense of "togetherness" that really doesn't exist. Static HTML (the way most JSPs are used) and Servlets couldn't be more different if they tried. It's something that has been apparent to me since the first day that I found out JSPs were compiled in to Servlets. I immediately asked "Why? That sounds like a lot of wasted CPU cycles." My comment still holds true today. Sometimes the marriage between JSP and Servlet is useful, where it's going to be a completely dynamic response. However, it's been my experience that using JSPs in a way that utilizes their dynamic nature (and not just for excess complexity purposes), is very rare. Most of the time, even if a few tag libraries are used, ninety percent of the page in question is just static html that has no need to pass through all the extra cycles that JSPs do.
So, am I proposing totally static HTML? Definitely not. There are just too many reasons that the server should do some view logic work. Browsers just aren't built powerfully enough to take care of everything that a modern webpage needs to.
Ideally, I would love to see a "front end project" consisting of a standard *AMP set up. Pick your poison for that P (PHP, Perl, Python.. or Ruby, etc), and a separate Java (or ASP) project for doing the heavy lifting. Compiled code is much more efficient with CPU than interpreted code, and makes a lot more sense to write powerful algorithms in. The interpreted code can easily connect to the compiled code to get the data that it needs on the server side. The static code that the client ends up with is capable of getting access to the back end as well using JavaScript with JSON (or whatever your preferred client side technology stack is) for getting the data from the client side.
I have a feeling this is just one of those separation of concerns design patterns that has not caught on yet. My guess is that at some point in the future we'll start seeing this sort of separation become more common. It adds a bit of complexity in connecting things together, but it relieves front end designers of trying to do a back end designers work. People like me that truly live on the web tier, and not the middle tier, would find great joy in seeing this sort of change in mentality.
*AMP = Fast, immediate delivery of data to the client.
Java/ASP = Powerful, heavy lifter for back end processes.
It only makes sense.
