News for hackers. Stuff that matters.
Re:Quarto by Tomte on Wednesday February 14, 2024 @04:36AM (#39368140)
Is there a way (a common template/theme or so) to get small, fast-loading web pages from quarto?

Obviously, as soon as you‘re using math, you‘ll get MathJax or KaTex, all the reactive stuff needs JavaScript libraries, but is there a small baseline for just „heading paragraph paragraph image paragraph“ type pages?

Re:Quarto by bluish29 on Wednesday February 14, 2024 @05:42AM (#39368452)
All major browsers supports Mathml now, which means you can type latex and math equations without any need for JS libraries like KaTeX.

And for your request, I would suggest bearblog template [1] (it is inspired by bearblog itself). It doesn't use any JS and provide minimal way to have a blog (website) and quarto supports hugo specific format that can help. [2]

[1] https://github.com/janraasch/hugo-bearblog

[2] https://quarto.org/docs/output-formats/hugo.html

Re:Quarto by fredguth on Wednesday February 14, 2024 @05:42AM (#39368449)
Is the default template not small and fast enough for you?

It generates html in a folder and afaik it the file is self-contained, i.e. it includes in the html all 200-ish lines of js it uses, no external dependencies.

Re:Quarto by Tomte on Wednesday February 14, 2024 @05:47AM (#39368485)
I don't know. Both the Quarto web site and the Quarto-generated sites I have looked at seem to be rather fat.

Let's look at Lighthouse (I know it's not the be-all and end-all) for https://quarto.org/docs/websites/website-blog.html: performance score 68 with a FCP time of 2.7 seconds, and earlier today it was 4.something.

That seems to be a lot.

Re:Quarto by Etheryte on Wednesday February 14, 2024 @06:32AM (#39368687)
I think the gallery might be a better comparison point for what you're looking for as it shows the actual output of Quatro. E.g. https://quarto-dev.github.io/quarto-gallery/articles/html/ht... which matches your description of heading-paragraph-image type of page yields performance 99 and FCP 0.8s.
Re:Quarto by cscheid on Wednesday February 14, 2024 @10:06AM (#39370594)
(Disclosure: I'm a Quarto dev)

This is an area we want to improve in the future. Most of the JS libraries can be disabled in the project configuration. We find that our typical user prefers to have access to the features those libraries provide, but I agree with you that we should be doing better. This is a place where some guided documentation would help. We're working on it.

With that said, we dogfood Quarto pretty seriously, and consume the content from mobile devices. I admit that we use devices that are likely in the 90% percentile of speed, but website performance is something we do take into account.

Re:Quarto by WillAdams on Wednesday February 14, 2024 @11:00AM (#39371452)
Wouldn't it be possible to parse the list of commands used and only enable the JS libraries which are actually required?
Re:Quarto by dragonstyle on Wednesday February 14, 2024 @11:44AM (#39371950)
We do generally attempt to only include JS dependencies in the HTML output if they are used. We share those dependencies across pages in a website, so if a single page uses a dependency they all will pick it up, but if you have a minimal world view and disable the various interactive goodies, you should get a _relatively_ more thin set of dependencies.

For HTML output, using `minimal: true` in document front matter will give you very minimal HTML that should be ready to style with CSS (and pretty much no dependencies)

Re:Quarto by cscheid on Wednesday February 14, 2024 @11:25AM (#39371752)
Frankly, that's easier said than done.

The complication is from the implied dependencies. If you've designed from zero to be able to track the requirements everywhere in the code base, then that's (in principle, though still not trivial) possible. But if you're looking to ship fast with a small team on the large feature set that we do have, then it's actually a better call to work on a system that has a fixed set of dependencies known in advance, and quickly iterate to solve other customer problems.

tl;dr: tradeoffs. We chose one that still serves us well, but it does come with consequences.