Re: Would you take a complimentary course on HTML from a company whose website looked like this?

Den 31/03/10 20.36, Aaron Bartell skrev:

The transformations can easily be done on the server (I usually run in a

servlet container) and the XSLT's can be compiled so the transformation is
pretty cheap.

True, but then the scalability issue becomes even worse since it all resides
on the server at this point. Don't get me wrong, I think the approach can
work - I just think there are better (more CPU efficient) ways to do it.

Yes, it can, as I did it a few jobs back. In any case for a conservative web site the only way to go is to generate HTML server side - you really need to be confident in the client libraries to be certain that everything works everywhere.

I have a long time ago resigned to only ship finished HTML (in whatever

form) to the client, and only use Javascript through libraries.

What are your thoughts on only delivering JSON to the client concerning the
dynamic portion? In theory the static HTML+CSS+javascript files that
process/render the JSON would only have to be downloaded once.

I have no JSON experience, so I cannot say, sorry.

The idea of using Javascript to populate a DOM is not unreasonable, but can you simply print such a page (since many pages is expected to be reports that is not a thing to forget)?

In any case, I would be extremely cautious with choosing _which_ JSON library to use, as you need to choose something that will be maintained for as long as your _framework_ lives in order to avoid having to lift the maintainance burden yourself 10-20 years ahead. That is why our AJAX ventures go the JSF way - if JEE 6 or newer is available then so is JSF with the AJAX stuff. That is important to us.

Then you need to first define what "Efficient" means, and how to measure

it.

This isn't a scientific measurement/definition of efficient, but it is the
first thing that popped into my head when you asked.

Efficient, in one definition, is selecting a technology stack to communicate
with a UI that doesn't require you to upgrade your processing power.

For example, if a machine is at 30% utilization for CPU/memory then I
shouldn't have to upgrade machines simply because I chose to talk to a
different interface. Of course if the number of users increased
dramatically then that would be a valid reason for needing to upgrade - I am
more talking about the general user count to remain the same.

So you are thinking in terms of cpu-cycles. Not an unreasonable definition, as the AS/400 is traditionally cpu-starved by design (but modern x86 processors cannot feed the cpu fast enough).

I have not done any performance measurements on the overhead of postprocessing an XML output from "somewhere" with a _compiled_ XSLT script. Might be a good idea to do some day.