XSLT vs Client Side Templates
188 views
Skip to first unread message
Justin Meyer
Oct 28, 2008, 2:52:02 AM10/28/08
to SOFEA
The following is my response to someone arguing for XSLT vs Client
side templates. They have numbered their points. My response is in
between. I think people might find the end of the conversation #7+#8
interesting.
1) Parsing XML input on the server is actually quite fast. Built a
quick test: DOM parse: 8/10,000th of a second, JSON, 4.5/10,000th of a
second, Expat 1/10,000th of a second. Expat is actually 4 times
faster than JSON. In fact, over 10k iterations, Expat is 10x quicker.
But in reality, the performance on the server side will not impact the
request much since we're talking about 10,000ths of a second.
How are you doing this test? How are you parsing JSON? But with
these speeds, I agree that it's really non-issue.
2) XML/XSLT handling on the browser is not as bad as it is commonly
thought. In terms of raw speed, JSON is clearly faster, but when it
comes to manipulating the DOM that speed advantage is blown completely
away. I found an article by a guy who did some benchmarking between a
popular JSON template engine and XSLT, and despite JSON's raw speed
being faster, the JSON template engine ended up being 4 times slower
than XSLT. Also, there is no clear answer to templated DOM
manipulation in JSON.
I would like to see the benchmark results. Which JSON template
engine? I can almost guarantee that processed EJS templates run
faster than XSLT. Processed EJS templates simply add strings
together. They do not use eval or have a processing step which is why
typical templates run slow.
Also, XSLT is loaded from another file while EJS can be packaged with
the JavaScript payload. This necessitates an extra request by the
client.
3) JSON is not a WC3 standard. It's an implied standard in that many
JavaScript developers use it, but it is not a standard as dictated by
the group that has developed the HTML standard, the DOM standard, the
XHTML standard, the CSS standard, the HTTP standard, etc. I'm not
necessarily a stickler for standards, but our customers might be, so
that needs to be a consideration. Also, we should be careful about
assuming that our customers will have the necessary JavaScript
experience to do DOM manipulation.
JSON is a standard because it is implied by EMCAScript. As long as
there is EMCAScript there will be JSON.
4) DOM manipulation using JSON can be quite code-intensive. The more
complex the manipulation, the more complex the code. XSLT allows for
complex DOM manipulation to be done with virtually no code, only some
additional markup.
I'll respond to this comparison #8.
5) Using JSON typically requires the use of eval(), which we typically
tell people not to use in PHP because of security issues that can
occur. Those same security issues can exist in JSON. Since XSLT
processing is done outside of the JavaScript engine itself, that
exposure is minimized.
If you are using the numerous JSON client side parsing libraries, eval
does not need to be used. Furthermore, eval is only dangerous if you
are not sanitizing output. But if you aren't doing that, there are
many other possible attack vectors that don't require eval. For
example, injecting script tags.
6) XSLT is supported by virtually all browsers. Safari since 1.3
supports page-level XSLT and 3 supports script-level. Firefox >=
1.0.2, Netscape >= 8, Opera >= 9, IE >= 5 (limited support, full
support in 6). In fact, if we include page-level XSLT, I think that
it has stronger support than JSON instead of being on par.
JSON is part of JavaScript which has been around since the dark ages
of the web. I find it highly unlikely that there are more browsers
that understand XSLT than {a: 'b'}. However, this, like performance,
is really a non-issue.
7) using XSLT translations would allow for applications to include a
JavaScript and non-JavaScript version, with either browser or server-
side transformation. About 5% of the Internet has JavaScript turned
off. If a customer so desires, using XSLT makes it much easier to
build an architecture that can optionally be run without JavaScript on
either the server side or the client side.
This is typically the best argument for putting logic on the server.
But this is balanced by a few factors:
Precedent: Big companies are starting to require JavaScipt for their
core applications.
Numbers: Though 5%, if you are quoting (http://www.w3schools.com/
browsers/browsers_stats.asp), is high. In Ajaxian, I remember it
being reported that this included search engine spiders, but they were
unable to account for what % of traffic this accounted for. I can't
find this article, so this might have been in my head. Finally, W3C is
a site where people know a great deal more than average, making it
much more likely that they have JavaScript disabled.
Need: User experience is everything, and if you want a modern
application, this forces you to program for the client.
Tools: HTMLUnit have been used to automatically create non-JavaScript
versions of JavaScript sites.
This technique was used by Kris Zyp to make http://www.xucia.com/.
Turn off JavaScript and it still works.
But we are really talking about the choice of template. You can frame
the argument differently for rich web applications vs applications
that are little more than static websites.
For mostly static apps, non-JS versions can be very easily supported.
You can have something like HTMLUnit render the HTML for you (XSLT not
supported directly), or you could have XSLT be handled by the server.
Both are about equal. XSLT will be faster, but performance probably
isn't a huge issue for a small group of people and spiders.
For the case of rich web applications, XSLT or HTMLUnit are not going
to cut it. The UIs are often so radically different than what would
be acceptable in a non JS version that a re-write is most likely
called for. Neither XSLT or HTMLUnit+templates are going to make
things better.
In the end, this is another non-issue. If you are making something
simple, you can do both easily. If you are modifying a rich
application, there is going to be pain no matter what.
8) there is a common misconception that XSLT is complex. I don't
believe this to be accurate. XSLT is basically like writing XHTML
with a few extra tags. Basic XSLT is extremely easy and requires
virtually no JavaScript expertise. Complex XSLT is virtually the same
as writing the XHTML code to render it.
In my opinion, it is impossible to escape JavaScript in an RIA.
RIA development is much more than getting data, transforming it, then
inserting it into the dom. If that was all it was, why even learn
XSLT? I would have the server return HTML and insert it directly into
the page.
RIA development is hugely complex. The project we are working on
right now has more than 120 different files that run on the client.
They do much more than updating the dom outside of a simple Ajax
request. This level of complexity requires that we look at client
side development differently.
This starts at the service layer. The service layer needs to supply
raw data that can be wrapped by a client model. This is the
difference between raw PHP scripts that did SQL in the page and models
that frameworks like Zend encourage.
Supporting service models a big argument against using XML/XSLT. Why
use a data transport that JavaScript doesn't understand as easy. One
that is more unwieldy. In our applications, we have complex models
that abstract data. This is not possible with XSLT. This is best
illustrated with an example:
Our F->IT application (fit.jupiterit.com) is an FTP application. It
requests all the different files in a folder and creates File and
Folder objects out of them. When it drags one file or folder to
another, it does code like the following before doing the Ajax
request:
if(drag_file.can_move_to(drop_folder) == true){
drag_file.move_to(drop_folder) // does the ajax request
}else{
alert("Unable to move");
}
This little bit of code checks that one folder can't move into a sub
folder folder or itself. More importantly, it illustrates the
importance of the model layer. ** In this case the code should also
be present on the server **
This ajax request comes back with data that is converted into a File
instance. The new file's html is generated with a template and put in
its new place. However, the file data returns something like:
{
path: '/this/is/a/long/path/to/file.txt'
}
After being put in a model, we can render the file in a template like:
<div id="file_<%= file.path %>"><%= file.pretty_name() %></div>
Pretty name is a function that returns "file.txt".
How would you add these model functions to be used by XSLT? Adding
layers of abstraction to your data is impossible with XSLT.
But more importantly, it is impossible to escape JavaScipt in any
moderately complex RIA. People have to learn it to do anything
interesting. But choosing XSLT will only limit your code's
expressiveness.
On the complexity of XSLT. Compare the wikipedia example:
<?xml version="1.0" ?>
<persons>
<person username="JS1">
<name>John</name>
<family-name>Smith</family-name>
</person>
<person username="MI1">
<name>Morka</name>
<family-name>Ismincius</family-name>
</person>
</persons>
<?xml version="1.0" ?>
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
version="1.0">
<xsl:output method="xml" indent="yes"/>
<xsl:template match="/persons">
<root> <xsl:apply-templates select="person"/> </root>
</xsl:template>
<xsl:template match="person">
<name username="{@username}">
<xsl:value-of select="name" />
</name>
</xsl:template>
</xsl:stylesheet>
With:
people = [{username: 'JS1', name: "John", family-name: "Smith"},
{ username: "MI1", name: "Morka", family-name: "Ismincius"}]
<root>
<% people.each(person){ %>
<name username='<%=person.username%>'><%=person.name%></name>
<%}%>
</root>
I think it's pretty clear which one is easier to understand.
side templates. They have numbered their points. My response is in
between. I think people might find the end of the conversation #7+#8
interesting.
1) Parsing XML input on the server is actually quite fast. Built a
quick test: DOM parse: 8/10,000th of a second, JSON, 4.5/10,000th of a
second, Expat 1/10,000th of a second. Expat is actually 4 times
faster than JSON. In fact, over 10k iterations, Expat is 10x quicker.
But in reality, the performance on the server side will not impact the
request much since we're talking about 10,000ths of a second.
How are you doing this test? How are you parsing JSON? But with
these speeds, I agree that it's really non-issue.
2) XML/XSLT handling on the browser is not as bad as it is commonly
thought. In terms of raw speed, JSON is clearly faster, but when it
comes to manipulating the DOM that speed advantage is blown completely
away. I found an article by a guy who did some benchmarking between a
popular JSON template engine and XSLT, and despite JSON's raw speed
being faster, the JSON template engine ended up being 4 times slower
than XSLT. Also, there is no clear answer to templated DOM
manipulation in JSON.
I would like to see the benchmark results. Which JSON template
engine? I can almost guarantee that processed EJS templates run
faster than XSLT. Processed EJS templates simply add strings
together. They do not use eval or have a processing step which is why
typical templates run slow.
Also, XSLT is loaded from another file while EJS can be packaged with
the JavaScript payload. This necessitates an extra request by the
client.
3) JSON is not a WC3 standard. It's an implied standard in that many
JavaScript developers use it, but it is not a standard as dictated by
the group that has developed the HTML standard, the DOM standard, the
XHTML standard, the CSS standard, the HTTP standard, etc. I'm not
necessarily a stickler for standards, but our customers might be, so
that needs to be a consideration. Also, we should be careful about
assuming that our customers will have the necessary JavaScript
experience to do DOM manipulation.
JSON is a standard because it is implied by EMCAScript. As long as
there is EMCAScript there will be JSON.
4) DOM manipulation using JSON can be quite code-intensive. The more
complex the manipulation, the more complex the code. XSLT allows for
complex DOM manipulation to be done with virtually no code, only some
additional markup.
I'll respond to this comparison #8.
5) Using JSON typically requires the use of eval(), which we typically
tell people not to use in PHP because of security issues that can
occur. Those same security issues can exist in JSON. Since XSLT
processing is done outside of the JavaScript engine itself, that
exposure is minimized.
If you are using the numerous JSON client side parsing libraries, eval
does not need to be used. Furthermore, eval is only dangerous if you
are not sanitizing output. But if you aren't doing that, there are
many other possible attack vectors that don't require eval. For
example, injecting script tags.
6) XSLT is supported by virtually all browsers. Safari since 1.3
supports page-level XSLT and 3 supports script-level. Firefox >=
1.0.2, Netscape >= 8, Opera >= 9, IE >= 5 (limited support, full
support in 6). In fact, if we include page-level XSLT, I think that
it has stronger support than JSON instead of being on par.
JSON is part of JavaScript which has been around since the dark ages
of the web. I find it highly unlikely that there are more browsers
that understand XSLT than {a: 'b'}. However, this, like performance,
is really a non-issue.
7) using XSLT translations would allow for applications to include a
JavaScript and non-JavaScript version, with either browser or server-
side transformation. About 5% of the Internet has JavaScript turned
off. If a customer so desires, using XSLT makes it much easier to
build an architecture that can optionally be run without JavaScript on
either the server side or the client side.
This is typically the best argument for putting logic on the server.
But this is balanced by a few factors:
Precedent: Big companies are starting to require JavaScipt for their
core applications.
Numbers: Though 5%, if you are quoting (http://www.w3schools.com/
browsers/browsers_stats.asp), is high. In Ajaxian, I remember it
being reported that this included search engine spiders, but they were
unable to account for what % of traffic this accounted for. I can't
find this article, so this might have been in my head. Finally, W3C is
a site where people know a great deal more than average, making it
much more likely that they have JavaScript disabled.
Need: User experience is everything, and if you want a modern
application, this forces you to program for the client.
Tools: HTMLUnit have been used to automatically create non-JavaScript
versions of JavaScript sites.
This technique was used by Kris Zyp to make http://www.xucia.com/.
Turn off JavaScript and it still works.
But we are really talking about the choice of template. You can frame
the argument differently for rich web applications vs applications
that are little more than static websites.
For mostly static apps, non-JS versions can be very easily supported.
You can have something like HTMLUnit render the HTML for you (XSLT not
supported directly), or you could have XSLT be handled by the server.
Both are about equal. XSLT will be faster, but performance probably
isn't a huge issue for a small group of people and spiders.
For the case of rich web applications, XSLT or HTMLUnit are not going
to cut it. The UIs are often so radically different than what would
be acceptable in a non JS version that a re-write is most likely
called for. Neither XSLT or HTMLUnit+templates are going to make
things better.
In the end, this is another non-issue. If you are making something
simple, you can do both easily. If you are modifying a rich
application, there is going to be pain no matter what.
8) there is a common misconception that XSLT is complex. I don't
believe this to be accurate. XSLT is basically like writing XHTML
with a few extra tags. Basic XSLT is extremely easy and requires
virtually no JavaScript expertise. Complex XSLT is virtually the same
as writing the XHTML code to render it.
In my opinion, it is impossible to escape JavaScript in an RIA.
RIA development is much more than getting data, transforming it, then
inserting it into the dom. If that was all it was, why even learn
XSLT? I would have the server return HTML and insert it directly into
the page.
RIA development is hugely complex. The project we are working on
right now has more than 120 different files that run on the client.
They do much more than updating the dom outside of a simple Ajax
request. This level of complexity requires that we look at client
side development differently.
This starts at the service layer. The service layer needs to supply
raw data that can be wrapped by a client model. This is the
difference between raw PHP scripts that did SQL in the page and models
that frameworks like Zend encourage.
Supporting service models a big argument against using XML/XSLT. Why
use a data transport that JavaScript doesn't understand as easy. One
that is more unwieldy. In our applications, we have complex models
that abstract data. This is not possible with XSLT. This is best
illustrated with an example:
Our F->IT application (fit.jupiterit.com) is an FTP application. It
requests all the different files in a folder and creates File and
Folder objects out of them. When it drags one file or folder to
another, it does code like the following before doing the Ajax
request:
if(drag_file.can_move_to(drop_folder) == true){
drag_file.move_to(drop_folder) // does the ajax request
}else{
alert("Unable to move");
}
This little bit of code checks that one folder can't move into a sub
folder folder or itself. More importantly, it illustrates the
importance of the model layer. ** In this case the code should also
be present on the server **
This ajax request comes back with data that is converted into a File
instance. The new file's html is generated with a template and put in
its new place. However, the file data returns something like:
{
path: '/this/is/a/long/path/to/file.txt'
}
After being put in a model, we can render the file in a template like:
<div id="file_<%= file.path %>"><%= file.pretty_name() %></div>
Pretty name is a function that returns "file.txt".
How would you add these model functions to be used by XSLT? Adding
layers of abstraction to your data is impossible with XSLT.
But more importantly, it is impossible to escape JavaScipt in any
moderately complex RIA. People have to learn it to do anything
interesting. But choosing XSLT will only limit your code's
expressiveness.
On the complexity of XSLT. Compare the wikipedia example:
<?xml version="1.0" ?>
<persons>
<person username="JS1">
<name>John</name>
<family-name>Smith</family-name>
</person>
<person username="MI1">
<name>Morka</name>
<family-name>Ismincius</family-name>
</person>
</persons>
<?xml version="1.0" ?>
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
version="1.0">
<xsl:output method="xml" indent="yes"/>
<xsl:template match="/persons">
<root> <xsl:apply-templates select="person"/> </root>
</xsl:template>
<xsl:template match="person">
<name username="{@username}">
<xsl:value-of select="name" />
</name>
</xsl:template>
</xsl:stylesheet>
With:
people = [{username: 'JS1', name: "John", family-name: "Smith"},
{ username: "MI1", name: "Morka", family-name: "Ismincius"}]
<root>
<% people.each(person){ %>
<name username='<%=person.username%>'><%=person.name%></name>
<%}%>
</root>
I think it's pretty clear which one is easier to understand.
Peter Svensson
Oct 28, 2008, 3:35:31 AM10/28/08
to so...@googlegroups.com
Justin, your argumentation is brilliant! :) This would make an excellent blog-post to draw down the ire of dzone server-huggers, I think.
Also, it would be interesting to hear what answers (if any) you get to the post.
Cheers,
PS
Also, it would be interesting to hear what answers (if any) you get to the post.
Cheers,
PS
Ganesh and Sashi Prasad
Oct 28, 2008, 5:51:47 AM10/28/08
to so...@googlegroups.com
I'm intrigued by the comment about *browser-side* XSLT being universally supported. Can anyone give me more details?
Ganesh
Ganesh
2008/10/28 Peter Svensson <psve...@gmail.com>
Kris Zyp
Oct 28, 2008, 9:55:19 AM10/28/08
to so...@googlegroups.com
Wow, what a thorough response. A couple of thoughts (to back your
arguments). First, I am not exactly sure what makes something a
standard, but I believe JSON is an accepted media type by the Internet
Engineering Task Force: http://www.ietf.org/rfc/rfc4627.txt. On other
hand, it is my understanding that the W3C is not actually an official
standards body, they can only make recommendations, whereas the IETF
(where the JSON spec lives) is an official standards body. Consequently,
I believe JSON is just as much of a standard as anything else you find
in the web page. And of course JSON is a subset of ECMA-262 which is
officially blessed by the ECMA standards body.
arguments). First, I am not exactly sure what makes something a
standard, but I believe JSON is an accepted media type by the Internet
Engineering Task Force: http://www.ietf.org/rfc/rfc4627.txt. On other
hand, it is my understanding that the W3C is not actually an official
standards body, they can only make recommendations, whereas the IETF
(where the JSON spec lives) is an official standards body. Consequently,
I believe JSON is just as much of a standard as anything else you find
in the web page. And of course JSON is a subset of ECMA-262 which is
officially blessed by the ECMA standards body.
In the realm of the XML vs JSON debate, I think one really simple way of
looking at the difference is simply choose the tool that was designed
for your application. eXtensible Markup Language, is a markup language,
intended for giving semantic meaning to text documents, exemplified in
HTML. JavaScript Object Notation is designed for describing
object-oriented data structures. Unfortunately the last decade has seen
XML be such a buzzword that vast amounts structured data has been
inappropriately stuffed in XML, but going forward developers can use the
correct tool for their application, and hopefully will be less
restricted by such antiquated approaches. Of course, SOFEA applications
are usually going to be transferring structured data, at least at the
top level (one can always include XML in JSON strings).
Kris
Mic Cvilic
Nov 6, 2008, 7:30:18 AM11/6/08
to so...@googlegroups.com
hi Justin,
On 28 Oct 2008, at 07:52, Justin Meyer wrote:
2) XML/XSLT handling on the browser is not as bad as it is commonly
thought.
The IE msxml.dll in charge of XML/XSLT is incredibly fast.
As IE is by far the most popular, if not exclusive, browser in big corporations, he's right to say it's not as bad.
But for the growing others:
In FF2 the JS engine was faster than the XML/XSLT one.
I thought XSLT was neglected in Safari? It was one of the reasons to switch to JSON.
I found an article by a guy who did some benchmarking between a
popular JSON template engine and XSLT
Did you get some more information about this benchmark?
Hey! I found you! You are behind EJS too ;)
4) DOM manipulation using JSON can be quite code-intensive. The more
complex the manipulation, the more complex the code. XSLT allows for
complex DOM manipulation to be done with virtually no code, only some
additional markup.
Intriguing. Again because of IE and its messy DOM, I don't think it's as easy to recycle some DOM fragments
and process them through XSLT.
Did they say something more about it?
8) there is a common misconception that XSLT is complex. I don't
believe this to be accurate.
Nobody from the street knows XSLT.
We had to train all the people we were hiring.
And pattern programming takes a long time to master in general.
There is no comparison with HTML and Javascript, that anybody out of school knows today.
Although functional JS may take a while too.
With:
people = [{username: 'JS1', name: "John", family-name: "Smith"},
{ username: "MI1", name: "Morka", family-name: "Ismincius"}]
<root>
<% people.each(person){ %>
<name username='<%=person.username%>'><%=person.name%></name>
<%}%>
</root>
I think it's pretty clear which one is easier to understand.
With the autoRender version of PURE :-P
{people: [
{username: 'JS1', name: "John", familyName: "Smith"},
{username: "MI1", name: "Morka", familyName: "Ismincius"}]}
<root>
<name class="people username@username name"></name>
</root>
Cheers,
Mic
--
BeeBuzz, the voice of BeeBole : http://beebole.com/blog
BeeBuzz, the voice of BeeBole : http://beebole.com/blog
Reply all
Reply to author
Forward
0 new messages