Comment by b_e_n_t_o_n

Comment by b_e_n_t_o_n 18 hours ago

This works client side right? So when a user navigates to this page, it recursively fetches content from the server? And if you have nested includes it would waterfall?

Even single page app frameworks have mostly solved this by doing the rendering on the server instead of making multiple round trips from the client. This feels like the no-JavaScript version of Spinnergeddon.

Does the browser wait for all the includes to resolve before showing the page or does it flicker in?

dweinus 16 hours ago

If you want server-side compilation, you could just run the xslt transform in ci/cd. It would still be a simpler solution than Jekyll in some regards, but I probably wouldn't do it for more than hobby projects

Reply View 0 replies

bawolff 17 hours ago

Looking at the xslt stylesheet , it doesn't look like there are nested includes, its just one stylesheet which doesn't include anything else. So its not that different in terms of requests than how css would work.

Reply View 5 replies

magicalist 15 hours ago

> Looking at the xslt stylesheet , it doesn't look like there are nested includes, its just one stylesheet which doesn't include anything else
At least the browser has to load template.xsl before it can know it has to load the css file though, right? And this is just a simple demo page.

Reply View | 4 replies
- bawolff 11 hours ago
  
  I guess its ine extra layer, but its not like we've gone 14 layers deep or something.
  I imagine preloading the css file using the http link header would solve this problem.
  
  Reply View | 0 replies
- b_e_n_t_o_n 14 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.
  
  Reply View | 2 replies
  
  Mikhail_Edoshin 12 hours ago
  
  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.
  
  Reply View | 0 replies
  
  lelanthran 11 hours ago
  
  > 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.
  
  Reply View | 0 replies