Why is XSLT so rarely used in Web?

Clash Royale CLAN TAG#URR8PPP
up vote
1
down vote
favorite
XSLT is mature, widely accepted standard.
It can be used in browsers (even in old IE) and on server side (nginx has XSLT module, it can be used from programming laguages, of course). Its implementations are compiled and, therefore, should be much faster than Python or JS. JS implementation Saxon JS can be used, at least, as fallback. Jinja, Angular, Ruby's Slim, ASP and PHP templating are not even close.
XSL template can be easily validated in IDE. How many IDEs can help with Jinja or Angular?
Looks like it's perfect idea to decompose UI and data with XSLT.
Admittedly, implementations can give different results in some corner cases, but it's a problem only with templating on client side. And it's same with HTML, CSS and everything else that is done on client side.
So, why not XSLT?
web-development web-applications web front-end xslt
add a comment |Â
up vote
1
down vote
favorite
XSLT is mature, widely accepted standard.
It can be used in browsers (even in old IE) and on server side (nginx has XSLT module, it can be used from programming laguages, of course). Its implementations are compiled and, therefore, should be much faster than Python or JS. JS implementation Saxon JS can be used, at least, as fallback. Jinja, Angular, Ruby's Slim, ASP and PHP templating are not even close.
XSL template can be easily validated in IDE. How many IDEs can help with Jinja or Angular?
Looks like it's perfect idea to decompose UI and data with XSLT.
Admittedly, implementations can give different results in some corner cases, but it's a problem only with templating on client side. And it's same with HTML, CSS and everything else that is done on client side.
So, why not XSLT?
web-development web-applications web front-end xslt
JSON is easier than XML. I kid you not, just last night I heard developers saying how grateful they were that they never had to use XSLT again. See: stackoverflow.com/questions/4862310/json-and-xml-comparison
â Dan Wilson
3 hours ago
add a comment |Â
up vote
1
down vote
favorite
up vote
1
down vote
favorite
XSLT is mature, widely accepted standard.
It can be used in browsers (even in old IE) and on server side (nginx has XSLT module, it can be used from programming laguages, of course). Its implementations are compiled and, therefore, should be much faster than Python or JS. JS implementation Saxon JS can be used, at least, as fallback. Jinja, Angular, Ruby's Slim, ASP and PHP templating are not even close.
XSL template can be easily validated in IDE. How many IDEs can help with Jinja or Angular?
Looks like it's perfect idea to decompose UI and data with XSLT.
Admittedly, implementations can give different results in some corner cases, but it's a problem only with templating on client side. And it's same with HTML, CSS and everything else that is done on client side.
So, why not XSLT?
web-development web-applications web front-end xslt
XSLT is mature, widely accepted standard.
It can be used in browsers (even in old IE) and on server side (nginx has XSLT module, it can be used from programming laguages, of course). Its implementations are compiled and, therefore, should be much faster than Python or JS. JS implementation Saxon JS can be used, at least, as fallback. Jinja, Angular, Ruby's Slim, ASP and PHP templating are not even close.
XSL template can be easily validated in IDE. How many IDEs can help with Jinja or Angular?
Looks like it's perfect idea to decompose UI and data with XSLT.
Admittedly, implementations can give different results in some corner cases, but it's a problem only with templating on client side. And it's same with HTML, CSS and everything else that is done on client side.
So, why not XSLT?
web-development web-applications web front-end xslt
web-development web-applications web front-end xslt
asked 4 hours ago
George Sovetov
1224
1224
JSON is easier than XML. I kid you not, just last night I heard developers saying how grateful they were that they never had to use XSLT again. See: stackoverflow.com/questions/4862310/json-and-xml-comparison
â Dan Wilson
3 hours ago
add a comment |Â
JSON is easier than XML. I kid you not, just last night I heard developers saying how grateful they were that they never had to use XSLT again. See: stackoverflow.com/questions/4862310/json-and-xml-comparison
â Dan Wilson
3 hours ago
JSON is easier than XML. I kid you not, just last night I heard developers saying how grateful they were that they never had to use XSLT again. See: stackoverflow.com/questions/4862310/json-and-xml-comparison
â Dan Wilson
3 hours ago
JSON is easier than XML. I kid you not, just last night I heard developers saying how grateful they were that they never had to use XSLT again. See: stackoverflow.com/questions/4862310/json-and-xml-comparison
â Dan Wilson
3 hours ago
add a comment |Â
3 Answers
3
active
oldest
votes
up vote
3
down vote
I am flip-flopping back and forth between answering this question and closing it as primarily-opinion-based. So, here's my flip:
In short, because XML makes a crappy programming language. Something with the semantics of XSLT but much better syntax would be a whole different matter, I think. There are some really cool Lisp-based XML-transformation languages, for example.
XSLT can't decide whether it wants to be a tree-rewriting language, a functional language, or a procedural language. It has features of all of those, but it isn't really good at any of them. For any of the three aspects, there are better languages out there.
XML Syntax indeed may look verbose. But, what are some other languages that are supported everywhere?
â George Sovetov
4 hours ago
XSLT is an excellent functional language IMO. Where it falls down is in the way it mixes view w/ transformation logic.
â RubberDuck
3 hours ago
1
@GeorgeSoverov why is it important to be supported everywhere? It only needs to be supported on your server.
â Esben Skov Pedersen
3 hours ago
@EsbenSkovPedersen to work with services that speak HTTP/XML from browser and, at the same time, avoid templating in JS.
â George Sovetov
2 hours ago
I think the ugliness of a language is irrelevant if it serves a relevant use case. Just witness the success of JavaScript. The problem with XSLT is the use case just isn't there.
â JacquesB
3 mins ago
add a comment |Â
up vote
1
down vote
XSLT does not really have a useful role in the modern interactive web. The purpose of XSLT is to transform from one XML language into another - but you actually never need to do that in the first place. How powerful, fast and well supported a technology is is irrelevant if you don't have problem which the technology is deigned to solve.
There are several reasons why the use case for XSLT has gone away:
- HTML has won. XSLT was supposed to be useful for transforming "rich text" content in some semantic markup format into HTML "for presentation". But HTML is in itself a perfectly fine format for semantic markup, so why not just use that for rich-text content and skip the transformation?
- CSS has become much more powerful. One of the promises of XSLT was that you could keep the source markup clean and semantic and then transform it into "presentational HTML" which worked cross browser and where you could rearrange elements and so on. But you don't really need presentational HTML these days, you can use semantic HTML and CSS can perform the necessary styling and layout.
- XML has not become the ubiquitous format for data. When fetching SQL data from a database it is much simpler to just directly merge it into a template, rather than first transform it into XML and then transform it via XSLT. And JSON has all but replaced XML for structured data on the client side.
- XSLT is designed for transforming a whole document at a time. But in modern interactive web pages, small snippets of data are downloaded piecemeal all the time and merged into the page.
- Data is just not so complex. For the majority of use cases, simpler template formats with placeholders and repeaters solve the task fine. XSLT is more much more powerful, but you rarely need that extra power, and it has a steep cost in complexity and uglyness.
XSLT is IMHO a pretty cool and powerful technology when you actually need it. It just isn't very often these days.
add a comment |Â
up vote
0
down vote
Depends what you mean by "in Web".
XSLT is very widely used. As far as we can judge from metrics like the number of StackOverflow questions, it is in the top 30 programming languages, which probably makes it the top data-model-specific programming language after SQL.
But XSLT isn't widely used client-side, that is, in the browser. It's usually used either server-side to deliver content on demand in response to HTTP requests, or it's used in batch mode as part of a publishing workflow. It's also used, of course, in many applications that have very little to do with the web, e.g. in print publishing.
There are a number of reasons XSLT isn't extensively used in the browser. The main reason is that good conformant XSLT support was very slow coming from the browser vendors; no-one wanted to use it until it was available on every browser, and by the time it was available on every browser, the things people wanted to do in the browser had moved on (remember "Web 2.0"?) and the XSLT implementations in the browser didn't help you build interactive applications or fetch data using AJAX.
Saxonica (disclaimer, this is my product) has attempted to plug these gaps with Saxon-JS, but the product is a latecomer to the party, and client-side web development is very fashion-driven, so it's not enough just to have a product that ticks all the technical boxes. Part of being fashion driven is that most data-oriented sites (as distinct from document-oriented) have moved towards JSON rather than XML, largely because JSON is much easier to manipulate from Javascript.
The other issue is that XSLT is a love-it-or-hate-it language. Its declarative, rule-based, functionally-oriented paradigm appeals to many because of its high-level nature, but can be off-putting to those whose only experience of programming is to write imperative code that tells the computer exactly what to do and in what order.
add a comment |Â
3 Answers
3
active
oldest
votes
3 Answers
3
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
3
down vote
I am flip-flopping back and forth between answering this question and closing it as primarily-opinion-based. So, here's my flip:
In short, because XML makes a crappy programming language. Something with the semantics of XSLT but much better syntax would be a whole different matter, I think. There are some really cool Lisp-based XML-transformation languages, for example.
XSLT can't decide whether it wants to be a tree-rewriting language, a functional language, or a procedural language. It has features of all of those, but it isn't really good at any of them. For any of the three aspects, there are better languages out there.
XML Syntax indeed may look verbose. But, what are some other languages that are supported everywhere?
â George Sovetov
4 hours ago
XSLT is an excellent functional language IMO. Where it falls down is in the way it mixes view w/ transformation logic.
â RubberDuck
3 hours ago
1
@GeorgeSoverov why is it important to be supported everywhere? It only needs to be supported on your server.
â Esben Skov Pedersen
3 hours ago
@EsbenSkovPedersen to work with services that speak HTTP/XML from browser and, at the same time, avoid templating in JS.
â George Sovetov
2 hours ago
I think the ugliness of a language is irrelevant if it serves a relevant use case. Just witness the success of JavaScript. The problem with XSLT is the use case just isn't there.
â JacquesB
3 mins ago
add a comment |Â
up vote
3
down vote
I am flip-flopping back and forth between answering this question and closing it as primarily-opinion-based. So, here's my flip:
In short, because XML makes a crappy programming language. Something with the semantics of XSLT but much better syntax would be a whole different matter, I think. There are some really cool Lisp-based XML-transformation languages, for example.
XSLT can't decide whether it wants to be a tree-rewriting language, a functional language, or a procedural language. It has features of all of those, but it isn't really good at any of them. For any of the three aspects, there are better languages out there.
XML Syntax indeed may look verbose. But, what are some other languages that are supported everywhere?
â George Sovetov
4 hours ago
XSLT is an excellent functional language IMO. Where it falls down is in the way it mixes view w/ transformation logic.
â RubberDuck
3 hours ago
1
@GeorgeSoverov why is it important to be supported everywhere? It only needs to be supported on your server.
â Esben Skov Pedersen
3 hours ago
@EsbenSkovPedersen to work with services that speak HTTP/XML from browser and, at the same time, avoid templating in JS.
â George Sovetov
2 hours ago
I think the ugliness of a language is irrelevant if it serves a relevant use case. Just witness the success of JavaScript. The problem with XSLT is the use case just isn't there.
â JacquesB
3 mins ago
add a comment |Â
up vote
3
down vote
up vote
3
down vote
I am flip-flopping back and forth between answering this question and closing it as primarily-opinion-based. So, here's my flip:
In short, because XML makes a crappy programming language. Something with the semantics of XSLT but much better syntax would be a whole different matter, I think. There are some really cool Lisp-based XML-transformation languages, for example.
XSLT can't decide whether it wants to be a tree-rewriting language, a functional language, or a procedural language. It has features of all of those, but it isn't really good at any of them. For any of the three aspects, there are better languages out there.
I am flip-flopping back and forth between answering this question and closing it as primarily-opinion-based. So, here's my flip:
In short, because XML makes a crappy programming language. Something with the semantics of XSLT but much better syntax would be a whole different matter, I think. There are some really cool Lisp-based XML-transformation languages, for example.
XSLT can't decide whether it wants to be a tree-rewriting language, a functional language, or a procedural language. It has features of all of those, but it isn't really good at any of them. For any of the three aspects, there are better languages out there.
answered 4 hours ago
Jörg W Mittag
66.2k14138217
66.2k14138217
XML Syntax indeed may look verbose. But, what are some other languages that are supported everywhere?
â George Sovetov
4 hours ago
XSLT is an excellent functional language IMO. Where it falls down is in the way it mixes view w/ transformation logic.
â RubberDuck
3 hours ago
1
@GeorgeSoverov why is it important to be supported everywhere? It only needs to be supported on your server.
â Esben Skov Pedersen
3 hours ago
@EsbenSkovPedersen to work with services that speak HTTP/XML from browser and, at the same time, avoid templating in JS.
â George Sovetov
2 hours ago
I think the ugliness of a language is irrelevant if it serves a relevant use case. Just witness the success of JavaScript. The problem with XSLT is the use case just isn't there.
â JacquesB
3 mins ago
add a comment |Â
XML Syntax indeed may look verbose. But, what are some other languages that are supported everywhere?
â George Sovetov
4 hours ago
XSLT is an excellent functional language IMO. Where it falls down is in the way it mixes view w/ transformation logic.
â RubberDuck
3 hours ago
1
@GeorgeSoverov why is it important to be supported everywhere? It only needs to be supported on your server.
â Esben Skov Pedersen
3 hours ago
@EsbenSkovPedersen to work with services that speak HTTP/XML from browser and, at the same time, avoid templating in JS.
â George Sovetov
2 hours ago
I think the ugliness of a language is irrelevant if it serves a relevant use case. Just witness the success of JavaScript. The problem with XSLT is the use case just isn't there.
â JacquesB
3 mins ago
XML Syntax indeed may look verbose. But, what are some other languages that are supported everywhere?
â George Sovetov
4 hours ago
XML Syntax indeed may look verbose. But, what are some other languages that are supported everywhere?
â George Sovetov
4 hours ago
XSLT is an excellent functional language IMO. Where it falls down is in the way it mixes view w/ transformation logic.
â RubberDuck
3 hours ago
XSLT is an excellent functional language IMO. Where it falls down is in the way it mixes view w/ transformation logic.
â RubberDuck
3 hours ago
1
1
@GeorgeSoverov why is it important to be supported everywhere? It only needs to be supported on your server.
â Esben Skov Pedersen
3 hours ago
@GeorgeSoverov why is it important to be supported everywhere? It only needs to be supported on your server.
â Esben Skov Pedersen
3 hours ago
@EsbenSkovPedersen to work with services that speak HTTP/XML from browser and, at the same time, avoid templating in JS.
â George Sovetov
2 hours ago
@EsbenSkovPedersen to work with services that speak HTTP/XML from browser and, at the same time, avoid templating in JS.
â George Sovetov
2 hours ago
I think the ugliness of a language is irrelevant if it serves a relevant use case. Just witness the success of JavaScript. The problem with XSLT is the use case just isn't there.
â JacquesB
3 mins ago
I think the ugliness of a language is irrelevant if it serves a relevant use case. Just witness the success of JavaScript. The problem with XSLT is the use case just isn't there.
â JacquesB
3 mins ago
add a comment |Â
up vote
1
down vote
XSLT does not really have a useful role in the modern interactive web. The purpose of XSLT is to transform from one XML language into another - but you actually never need to do that in the first place. How powerful, fast and well supported a technology is is irrelevant if you don't have problem which the technology is deigned to solve.
There are several reasons why the use case for XSLT has gone away:
- HTML has won. XSLT was supposed to be useful for transforming "rich text" content in some semantic markup format into HTML "for presentation". But HTML is in itself a perfectly fine format for semantic markup, so why not just use that for rich-text content and skip the transformation?
- CSS has become much more powerful. One of the promises of XSLT was that you could keep the source markup clean and semantic and then transform it into "presentational HTML" which worked cross browser and where you could rearrange elements and so on. But you don't really need presentational HTML these days, you can use semantic HTML and CSS can perform the necessary styling and layout.
- XML has not become the ubiquitous format for data. When fetching SQL data from a database it is much simpler to just directly merge it into a template, rather than first transform it into XML and then transform it via XSLT. And JSON has all but replaced XML for structured data on the client side.
- XSLT is designed for transforming a whole document at a time. But in modern interactive web pages, small snippets of data are downloaded piecemeal all the time and merged into the page.
- Data is just not so complex. For the majority of use cases, simpler template formats with placeholders and repeaters solve the task fine. XSLT is more much more powerful, but you rarely need that extra power, and it has a steep cost in complexity and uglyness.
XSLT is IMHO a pretty cool and powerful technology when you actually need it. It just isn't very often these days.
add a comment |Â
up vote
1
down vote
XSLT does not really have a useful role in the modern interactive web. The purpose of XSLT is to transform from one XML language into another - but you actually never need to do that in the first place. How powerful, fast and well supported a technology is is irrelevant if you don't have problem which the technology is deigned to solve.
There are several reasons why the use case for XSLT has gone away:
- HTML has won. XSLT was supposed to be useful for transforming "rich text" content in some semantic markup format into HTML "for presentation". But HTML is in itself a perfectly fine format for semantic markup, so why not just use that for rich-text content and skip the transformation?
- CSS has become much more powerful. One of the promises of XSLT was that you could keep the source markup clean and semantic and then transform it into "presentational HTML" which worked cross browser and where you could rearrange elements and so on. But you don't really need presentational HTML these days, you can use semantic HTML and CSS can perform the necessary styling and layout.
- XML has not become the ubiquitous format for data. When fetching SQL data from a database it is much simpler to just directly merge it into a template, rather than first transform it into XML and then transform it via XSLT. And JSON has all but replaced XML for structured data on the client side.
- XSLT is designed for transforming a whole document at a time. But in modern interactive web pages, small snippets of data are downloaded piecemeal all the time and merged into the page.
- Data is just not so complex. For the majority of use cases, simpler template formats with placeholders and repeaters solve the task fine. XSLT is more much more powerful, but you rarely need that extra power, and it has a steep cost in complexity and uglyness.
XSLT is IMHO a pretty cool and powerful technology when you actually need it. It just isn't very often these days.
add a comment |Â
up vote
1
down vote
up vote
1
down vote
XSLT does not really have a useful role in the modern interactive web. The purpose of XSLT is to transform from one XML language into another - but you actually never need to do that in the first place. How powerful, fast and well supported a technology is is irrelevant if you don't have problem which the technology is deigned to solve.
There are several reasons why the use case for XSLT has gone away:
- HTML has won. XSLT was supposed to be useful for transforming "rich text" content in some semantic markup format into HTML "for presentation". But HTML is in itself a perfectly fine format for semantic markup, so why not just use that for rich-text content and skip the transformation?
- CSS has become much more powerful. One of the promises of XSLT was that you could keep the source markup clean and semantic and then transform it into "presentational HTML" which worked cross browser and where you could rearrange elements and so on. But you don't really need presentational HTML these days, you can use semantic HTML and CSS can perform the necessary styling and layout.
- XML has not become the ubiquitous format for data. When fetching SQL data from a database it is much simpler to just directly merge it into a template, rather than first transform it into XML and then transform it via XSLT. And JSON has all but replaced XML for structured data on the client side.
- XSLT is designed for transforming a whole document at a time. But in modern interactive web pages, small snippets of data are downloaded piecemeal all the time and merged into the page.
- Data is just not so complex. For the majority of use cases, simpler template formats with placeholders and repeaters solve the task fine. XSLT is more much more powerful, but you rarely need that extra power, and it has a steep cost in complexity and uglyness.
XSLT is IMHO a pretty cool and powerful technology when you actually need it. It just isn't very often these days.
XSLT does not really have a useful role in the modern interactive web. The purpose of XSLT is to transform from one XML language into another - but you actually never need to do that in the first place. How powerful, fast and well supported a technology is is irrelevant if you don't have problem which the technology is deigned to solve.
There are several reasons why the use case for XSLT has gone away:
- HTML has won. XSLT was supposed to be useful for transforming "rich text" content in some semantic markup format into HTML "for presentation". But HTML is in itself a perfectly fine format for semantic markup, so why not just use that for rich-text content and skip the transformation?
- CSS has become much more powerful. One of the promises of XSLT was that you could keep the source markup clean and semantic and then transform it into "presentational HTML" which worked cross browser and where you could rearrange elements and so on. But you don't really need presentational HTML these days, you can use semantic HTML and CSS can perform the necessary styling and layout.
- XML has not become the ubiquitous format for data. When fetching SQL data from a database it is much simpler to just directly merge it into a template, rather than first transform it into XML and then transform it via XSLT. And JSON has all but replaced XML for structured data on the client side.
- XSLT is designed for transforming a whole document at a time. But in modern interactive web pages, small snippets of data are downloaded piecemeal all the time and merged into the page.
- Data is just not so complex. For the majority of use cases, simpler template formats with placeholders and repeaters solve the task fine. XSLT is more much more powerful, but you rarely need that extra power, and it has a steep cost in complexity and uglyness.
XSLT is IMHO a pretty cool and powerful technology when you actually need it. It just isn't very often these days.
edited 7 mins ago
answered 13 mins ago
JacquesB
40k1682116
40k1682116
add a comment |Â
add a comment |Â
up vote
0
down vote
Depends what you mean by "in Web".
XSLT is very widely used. As far as we can judge from metrics like the number of StackOverflow questions, it is in the top 30 programming languages, which probably makes it the top data-model-specific programming language after SQL.
But XSLT isn't widely used client-side, that is, in the browser. It's usually used either server-side to deliver content on demand in response to HTTP requests, or it's used in batch mode as part of a publishing workflow. It's also used, of course, in many applications that have very little to do with the web, e.g. in print publishing.
There are a number of reasons XSLT isn't extensively used in the browser. The main reason is that good conformant XSLT support was very slow coming from the browser vendors; no-one wanted to use it until it was available on every browser, and by the time it was available on every browser, the things people wanted to do in the browser had moved on (remember "Web 2.0"?) and the XSLT implementations in the browser didn't help you build interactive applications or fetch data using AJAX.
Saxonica (disclaimer, this is my product) has attempted to plug these gaps with Saxon-JS, but the product is a latecomer to the party, and client-side web development is very fashion-driven, so it's not enough just to have a product that ticks all the technical boxes. Part of being fashion driven is that most data-oriented sites (as distinct from document-oriented) have moved towards JSON rather than XML, largely because JSON is much easier to manipulate from Javascript.
The other issue is that XSLT is a love-it-or-hate-it language. Its declarative, rule-based, functionally-oriented paradigm appeals to many because of its high-level nature, but can be off-putting to those whose only experience of programming is to write imperative code that tells the computer exactly what to do and in what order.
add a comment |Â
up vote
0
down vote
Depends what you mean by "in Web".
XSLT is very widely used. As far as we can judge from metrics like the number of StackOverflow questions, it is in the top 30 programming languages, which probably makes it the top data-model-specific programming language after SQL.
But XSLT isn't widely used client-side, that is, in the browser. It's usually used either server-side to deliver content on demand in response to HTTP requests, or it's used in batch mode as part of a publishing workflow. It's also used, of course, in many applications that have very little to do with the web, e.g. in print publishing.
There are a number of reasons XSLT isn't extensively used in the browser. The main reason is that good conformant XSLT support was very slow coming from the browser vendors; no-one wanted to use it until it was available on every browser, and by the time it was available on every browser, the things people wanted to do in the browser had moved on (remember "Web 2.0"?) and the XSLT implementations in the browser didn't help you build interactive applications or fetch data using AJAX.
Saxonica (disclaimer, this is my product) has attempted to plug these gaps with Saxon-JS, but the product is a latecomer to the party, and client-side web development is very fashion-driven, so it's not enough just to have a product that ticks all the technical boxes. Part of being fashion driven is that most data-oriented sites (as distinct from document-oriented) have moved towards JSON rather than XML, largely because JSON is much easier to manipulate from Javascript.
The other issue is that XSLT is a love-it-or-hate-it language. Its declarative, rule-based, functionally-oriented paradigm appeals to many because of its high-level nature, but can be off-putting to those whose only experience of programming is to write imperative code that tells the computer exactly what to do and in what order.
add a comment |Â
up vote
0
down vote
up vote
0
down vote
Depends what you mean by "in Web".
XSLT is very widely used. As far as we can judge from metrics like the number of StackOverflow questions, it is in the top 30 programming languages, which probably makes it the top data-model-specific programming language after SQL.
But XSLT isn't widely used client-side, that is, in the browser. It's usually used either server-side to deliver content on demand in response to HTTP requests, or it's used in batch mode as part of a publishing workflow. It's also used, of course, in many applications that have very little to do with the web, e.g. in print publishing.
There are a number of reasons XSLT isn't extensively used in the browser. The main reason is that good conformant XSLT support was very slow coming from the browser vendors; no-one wanted to use it until it was available on every browser, and by the time it was available on every browser, the things people wanted to do in the browser had moved on (remember "Web 2.0"?) and the XSLT implementations in the browser didn't help you build interactive applications or fetch data using AJAX.
Saxonica (disclaimer, this is my product) has attempted to plug these gaps with Saxon-JS, but the product is a latecomer to the party, and client-side web development is very fashion-driven, so it's not enough just to have a product that ticks all the technical boxes. Part of being fashion driven is that most data-oriented sites (as distinct from document-oriented) have moved towards JSON rather than XML, largely because JSON is much easier to manipulate from Javascript.
The other issue is that XSLT is a love-it-or-hate-it language. Its declarative, rule-based, functionally-oriented paradigm appeals to many because of its high-level nature, but can be off-putting to those whose only experience of programming is to write imperative code that tells the computer exactly what to do and in what order.
Depends what you mean by "in Web".
XSLT is very widely used. As far as we can judge from metrics like the number of StackOverflow questions, it is in the top 30 programming languages, which probably makes it the top data-model-specific programming language after SQL.
But XSLT isn't widely used client-side, that is, in the browser. It's usually used either server-side to deliver content on demand in response to HTTP requests, or it's used in batch mode as part of a publishing workflow. It's also used, of course, in many applications that have very little to do with the web, e.g. in print publishing.
There are a number of reasons XSLT isn't extensively used in the browser. The main reason is that good conformant XSLT support was very slow coming from the browser vendors; no-one wanted to use it until it was available on every browser, and by the time it was available on every browser, the things people wanted to do in the browser had moved on (remember "Web 2.0"?) and the XSLT implementations in the browser didn't help you build interactive applications or fetch data using AJAX.
Saxonica (disclaimer, this is my product) has attempted to plug these gaps with Saxon-JS, but the product is a latecomer to the party, and client-side web development is very fashion-driven, so it's not enough just to have a product that ticks all the technical boxes. Part of being fashion driven is that most data-oriented sites (as distinct from document-oriented) have moved towards JSON rather than XML, largely because JSON is much easier to manipulate from Javascript.
The other issue is that XSLT is a love-it-or-hate-it language. Its declarative, rule-based, functionally-oriented paradigm appeals to many because of its high-level nature, but can be off-putting to those whose only experience of programming is to write imperative code that tells the computer exactly what to do and in what order.
answered 20 mins ago
Michael Kay
2,47711010
2,47711010
add a comment |Â
add a comment |Â
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsoftwareengineering.stackexchange.com%2fquestions%2f380344%2fwhy-is-xslt-so-rarely-used-in-web%23new-answer', 'question_page');
);
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password

JSON is easier than XML. I kid you not, just last night I heard developers saying how grateful they were that they never had to use XSLT again. See: stackoverflow.com/questions/4862310/json-and-xml-comparison
â Dan Wilson
3 hours ago