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 05:01:03 -0700 |
on October 20th of *LAST* year) On 3/4/06, M. David Peterson <xmlhacker@xxxxxxxxx> wrote: > 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/ > -- <M:D/> M. David Peterson http://www.xsltblog.com/
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: [xsl] Is letting the browser tr, M. David Peterson | Thread | Re: [xsl] Is letting the browser tr, M. David Peterson |
Re: [xsl] Is letting the browser tr, M. David Peterson | Date | Re: [xsl] Is letting the browser tr, M. David Peterson |
Month |