How to architect a website's presentation layer?

Question

I have been going back and forth in different approaches for designing the presentation layer for websites.

Many people swear by one of the different CMS packages which is too constraining and inflexible. Many people suggest writing the HTML by hand which seems not to scale in the case of many pages.

I have a new web application I am designing and I really want to have a "correct" and "elegant" and practical approach in how I architect it.

Has anyone done this in a way in which they are happy with and can plug in various modules and libraries with no problems?

Any tips or pitfalls I should watch for?

Answer 1

If you want to ensure standards compliance, simplicity and consistency (i.e. correctness and elegance), writing your HTML and CSS by hand is the way to go. Every competent designer I have worked with does so. That level of control is necessary to get the results you want. I don't find the economy of scale to be at all limiting. Like any other scalability problem, it can be managed with the correct tools (reuse and so forth).

Answer 2

I've written HTML by hand, written JSP, used WYSIWYG editors and I've been on teams that used packages (JSF). I've actually liked any and all of them... although I frequently end up tossing WYSIWYG editors to the curb and just started editing by hand when doing straight HTML.

I think it's a factor of what you want to do:

• JSF - and presumably other comprehensive libraries - was great for very complex web data structures. After using it, I would not want to write dynamic trees, complex tables with nested form controls, pop-up menus or other high end HTML by hand. It fit nicely into my JEE MVC architecture with its myriad types of injection, and I think it saved me a lot of time in user interface widgets. The fact that we could crack the code, too, and go in and customize some things was an absolute life saver. The major drawback - when you need to speed up your server you will end up cracking the cover quite a lot and wondering how much you saved. We had a really data-heavy system, complex connections, lots of data, and a strong need for pagination and sorting. That worked in JSF, but we ended up overwriting quite a few things to make the system work efficiently.

• JSP - and presumably other dynamic presentation mechanisms (like ASP) - really great when you need a simpler dynamic presentation form. Fast and easy to code with and able to do a nice collection of dynamic things. The challenge - building in the connection between HTML display and dynamic processing is a learning curve that is different from writing in a OO language and different from straight HTML. It can get exhausting to mentally switch between HTML/CSS thinking, JSP, and Java - and you have to. JSF will let you be fairly blind to HTML and CSS unless you're doing something tricky. JSP will not. Also, it puts the burden for session continuity on you, unless you've hunted down some open source to do it for you.

• HTML/CSS - great for just getting stuff done. Obviously straight HTML will not let you get dynamic. You need something additional - even if it's just a little JavaScript. But I still write straight HTML for pages that I don't need to update very often.

I disagree that a simplistic dynamic HTML rendering solution (like JSP) can't scale. I think you need to be clever - building pages for specialized areas (like a menu JSP for navigation), using div tags for layout, etc. And I think you need to commit yourself to becoming good at refactoring.

From JSP to something more complex that does more construction for you - I think the key to happiness is finding a library that has what you need for display. Start with some screen shots and see what libraries come close to your purposes. Also, look for libraries that will play well with other mechanisms and you'll have the best of both worlds. I don't think that's beyond reach.

Answer 3

Never ever forget scalability when building web sites which has the potential for massive amounts of traffic! I have seen too many examples of sites based on some flashy CMS which may be easy to use, but eventually turns out to have serious problems with memory and performance. It ends in disaster.

So my advice is to question how well your CMS actually manages load before you jump into bed with it. Also make sure it works with whatever memory caches, load balancers, database replication and front-ends you are planning to use. In many cases, you may be better of writing your own stuff with a simple html template engine (custom made even) and carefully crafted infrastructure.