Hi,
Interesting but what worrries me is that with this approach one is just moving the view generation to the client, so the server will still be using lots of CPU cycles for the business logic.
On the other hand, you now need to send the XML + XSLT to the client, in some cases increasing the bandwith, and then processing it there with sometimes incompatible results between broswers and difficult debugging. Moreover, processing it in the server gives you the benefit or caching pre-processed XSLTs and that increases the performance of the transformation greatly. You also don't have to depend on the client having a good CPU to get good performance, you can control that on the server.
As you say, you can solve that with helper classes on the server for those problematic browsers / CPU-constrained clients, but then the complexity increases and you back to square one for some of your clients.
I believe that if you want to use the browser, go for a thin client, wtih small extras if you want; but if you want a fat client, use something else as base plattform.
Maybe if the JavaScript was more reliable across browsers, easier to develop wtih and debug...
Anyway, just my 2ec. |
java.net RSS Feeds
