Comment by b_e_n_t_o_n
12 hours ago
It's making three round trips. The first is to get the original xml file, then it's to load the second xml file, then it's to load the stylesheet.
Now you can imagine with a real site, you will have many includes per page, each one perhaps using includes of it's own. You end up with a really bad waterfall where it can take a long time for a page to load because it's going back to the server constantly, whereas if you did it on the server it would be a single round trip.
Early SPA's did this, they would load a shell and then begin fetching from the client. Some still do but we know better than to do this for things that aren't web apps.
The stylistic includes and certain content (e. g. a site map) can be embedded in the XSLT itself.
It is not quite a templating engine. XSLT is a part of a semantic engine. Content is written in the way that fits the content. E. g. I write about some language and invent tags and notations that best fit what I am talking about: grammar, sounds, wrtiting. Or I write about chess and say something like (party id=abc move=15w). Then I make it available in HTML by providing a transform from my tags to HTML tags. My notation is rendered as a bunch of divs, ps and spans. This is merely a temporary rendering; other renderings may be possible.
A templating engine is the final document with placeholders for variable parts. XSLT can do that too, but this is less than its vision.
> You end up with a really bad waterfall where it can take a long time for a page to load because it's going back to the server constantly, whereas if you did it on the server it would be a single round trip.
These are all static file downloads, though. The first page load will take long, but if these are header/footer type includes, every subsequent page will use the cached file.
It's a trade-off between longer times for landing page and shorter times for every other page. The developer will decide whether or not to make the trade-off.