The server side language should be determined by your constraints. Generally, one wants to minimize cost. If you're paying (or charging) $100+ an hour for programming work, the most expensive component is not hardware, but programmer time, so you're better off using an interpreted language that's fast to deploy than a compiled language that requires more care and planning. Perl can be a good choice here.
For more complex projects, long-term maintenance issues arise. Perl code is notoriously difficult for anyone other than the author to make sense of. I recommend Java for those type of projects but there may be some rationale for using C or C++. Again, it should boil down to economics. Is it cheaper to throw more hardware at the problem or to make the code more efficient?
Cocoon 1.4 has just been released. It's a web publishing framework that uses XML, XSLT, and XSL FO to produce HTML and PDF files. Dynamic XML production is still a bit patchy, though certainly possible and is actually being used on production sites.
In my opinion, any web page generation technology that does not use XML and XSL to seperate content, design, and logic is a short-term solution at best. The benefits of using XML and XSL are too profound to ignore - seperation of content from design means that it's easy to produce views of your site tailored for the client - be it lynx, Netscape, Palm, even a Flash movie player if SVG ever achieves widespread support.
Conversly, it's a breeze to maintain multilingual sites. Using XML as both the input and output format for dynamic page creation modules means much more reusable modules and, ideally, language independence when choosing modules. Since XML/XSL aware clients are on the way, it will soon be possible to offload page rendering to intelligent clients and do the processing server-side for dumb ones. Oh, and did I mention that it's open source and uses an open source XML parser, open source XSLT processor, open source source XSL FO renderer, and optionally an open source ECMAScript interpreter?:)
Slashdot Mirror
The server side language should be determined by your constraints. Generally, one wants to minimize cost. If you're paying (or charging) $100+ an hour for programming work, the most expensive component is not hardware, but programmer time, so you're better off using an interpreted language that's fast to deploy than a compiled language that requires more care and planning. Perl can be a good choice here.
For more complex projects, long-term maintenance issues arise. Perl code is notoriously difficult for anyone other than the author to make sense of. I recommend Java for those type of projects but there may be some rationale for using C or C++. Again, it should boil down to economics. Is it cheaper to throw more hardware at the problem or to make the code more efficient?
In my opinion, any web page generation technology that does not use XML and XSL to seperate content, design, and logic is a short-term solution at best. The benefits of using XML and XSL are too profound to ignore - seperation of content from design means that it's easy to produce views of your site tailored for the client - be it lynx, Netscape, Palm, even a Flash movie player if SVG ever achieves widespread support.
Conversly, it's a breeze to maintain multilingual sites. Using XML as both the input and output format for dynamic page creation modules means much more reusable modules and, ideally, language independence when choosing modules. Since XML/XSL aware clients are on the way, it will soon be possible to offload page rendering to intelligent clients and do the processing server-side for dumb ones. Oh, and did I mention that it's open source and uses an open source XML parser, open source XSLT processor, open source source XSL FO renderer, and optionally an open source ECMAScript interpreter? :)