Subject: Re: [xsl] Is letting the browser transform XML to XHTML using XSLT a good choice? From: "M. David Peterson" <xmlhacker@xxxxxxxxx> Date: Sat, 4 Mar 2006 04:58:38 -0700 |
Actually, my studies shown in the article linked to before prove that, in fact, you can develop solutions faster when you single out each client, take the base solution that works for a majority of the cases, and then spend your time debugging each browser, instead of trying to write one solution that fits all. I have quite literally watched a project take 6 months longer than it should have because they were dead set on making one code base work on all browsers. If they had stood back and found the common ground the could rely on, to then fine tune for each of the supporting browsers (there are only four major browser engines (although in the case of Mozilla there are several implementations -- but they still use the same engine) - IE, Mozilla, Safari/Konqueror, and Opera 9.0 PR1/2, and eventually the final - that support client side XSLT -- but this constitutes well over 99% of all browsers in use. Of course there are versions as well, but this in fact is one of the primary problems with creating a one size fits all solutuion -- browser versions introduce an entirely new layer of developer hello that i, generally speaking the biggest problem in regards to time consumption. Take a look at both my own article on this: http://www.xsltblog.com/archives/2005/12/finally_someone_1.html And more importantly, the newly "Browser Grading" guide published study by Yahoo!: http://developer.yahoo.net/yui/articles/gbs/gbs.html Coming from someone who has just spent the last year of his life studying the intimate details of each and every browser on the market, I have come to the absolute conclusion that the notion of developing a one size fits all (or most) simply does not make sense any more. The cost of attempting such efforts is so disproportionate to the cost of fine tuning the standard base on a per browser basis, its not even funny. In many cases (speaking at the corporate development level) we're speaking in terms of several million dollars in additional cost, and a range of between 3-9 extra months of development. I have personally been able to develop individualized solutions that use a common core code base, that is then tweaked for each browser, in less than a weeks time on my own. It just doesn't make sense any more. I will admit that this has been a recent change (Safari gains XSLT support last January, Opera 9.0 PR1 on October 20th of this year) -- but recent or not, its still a change, and a necessary one to maintain any sort of competitive advantage. In my mind, the day this all became a true reality was October 20th. Opera has had significant political resistance to implementing an XSLT solution within their browser. The fact that they now have I believe speaks volumes in and of itself. Why go to that expense, and give up the politics, if its not seen as crucial to their ongoing competitive success? On 3/4/06, Michael Kay <mike@xxxxxxxxxxxx> wrote: > > I am, today, very very surprised that this basic > > functionality is still not > > there, is it because: > > > > a) Actual players have vested interests in a mainframe like > > architecture? > > b) People lack imagination with XSLT based technologies and > > nobody thought > > about this simple feature? > > c) software producers are sleeping on the switch? > > d) XSLT is unpopular > > e) an asteroid felt on earth and anybody with the will to do it was > > destroyed? > > It's none of the above: it's because of costs and risks. > > I think most of us can see that doing transformation on the client makes > sense in principle. But the problem is that you have much more control over > the server than you have over the client. As soon as you do things on the > client you have to cope with a bewildering variety of versions and variants, > and this is a nightmare for quality assurance and potentially for support > costs. Also, it means you have to put up with using highest-common-factor > technology: you can't use technologies like XSLT 2.0 until five years after > they emerge, despite the huge productivity gains they bring. (XForms and SVG > suffer from the same issues.) > > So it's not an easy choice, and there's no single answer that's right for > every project. > > The option of doing both - client side when possible and server side > otherwise - is one way forward, but it adds to your overall system > complexity and cost. > > Michael Kay > http://www.saxonica.com/ > > -- <M:D/> M. David Peterson http://www.xsltblog.com/
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
RE: [xsl] Is letting the browser tr, Michael Kay | Thread | Re: [xsl] Is letting the browser tr, M. David Peterson |
RE: [xsl] Is letting the browser tr, Michael Kay | Date | Re: [xsl] Is letting the browser tr, M. David Peterson |
Month |