Quarto
quarto.org
quarto.org
https://shiny.posit.co/py/docs/overview.html
Some other great quarto features:
- Write Python Package documentation with Quarto Doc: https://github.com/machow/quartodoc
- Make static dashboards with Quarto Dashboard https://quarto.org/docs/dashboards/
- Fully integrates Typst: https://quarto.org/docs/blog/posts/2024-01-24-1.4-release/#t...
- Render to a ton of formats including PDF, HTML, Reveal JS, Word, and PowerPoint
- Allows you to use GitHub with a Jupyter Notebook workflow
[1] See profile
If y'all haven't seen the kind of magic that Tyler does with ray tracers in R (yes, you read it right), you're missing out. Go click on that link!
Generating website, epub and pdf from markdown is an attractive option. I did it with pandoc/mdbook, but would've likely gone with Quarto if it had been available at that time.
Publishing Documents with Quarto - https://news.ycombinator.com/item?id=38358214 - Nov 2023 (1 comment)
Quarto: A scientific and technical publishing system built on Pandoc - https://news.ycombinator.com/item?id=30042831 - Jan 2022 (33 comments)
We added support recently and have some nice features like password protection: https://docs.cloud.ploomber.io/en/latest/apps/quarto.html
My understanding is that Pluto has its own execution engine outside of Jupyter, and so would require the creation of a new "engine" in our codebase. We are a pretty lean team that has other priorities for 2024, but we would very much love to see Pluto running in Quarto.
There is an open PR right now (https://github.com/quarto-dev/quarto-cli/pull/8645) to add a Julia-native engine to Quarto, from the developers of Makie which we hope to merge soon. I don't think that will provide instant Pluto support, but it will certainly make it easier for other Julia-native folks to build on.
1. Has scoping rules that make it difficult to debug 2. Has low latency, making it frustrating for debugging.
The scoping rules are by design and match .ipynb workflows in the case of multiple documents, so we're unlikely to change it.
The render latency of quarto is definitely higher than we'd love, but we have a plan and have been steadily improving it. Quarto 1.4 is generally about 20% faster than 1.3, and we have performance regression infrastructure to not let us slip on it.
For my personal workflow (others may differ), compiling to html is only done once at the end of a session, and the latency wouldn't matter if it could execute like a script. Weave.jl^[1] has a great feature called `include_weave` which has the features I like.
But take my feedback with a grain of salt. I generally just save things in folders and compile a pdf separately with many tables and figures.
[1] https://weavejl.mpastell.com/stable/usage/#include_weave
How well does this work w/ a TeX-oriented editor? Say TeXshop?
I don't know what forum you're referring to. We monitor our GitHub discussions very closely, though: https://github.com/quarto-dev/quarto-cli/discussions/
> How well does this work w/ a TeX-oriented editor? Say TeXshop?
Quarto can produce .tex output from .ipynb or .qmd inputs, which can then be further edited directly in your text editor of choice (TeXshop, or even something like overleaf) should you want to.
My question was whether one could use a TeX-oriented editor in lieu of VS Code --- would this be a reasonable option, or, do the advantages/capabilities conferred by VS Code make it something which pretty much require its use?
I'm trying to work up an environment for a largish project which I'm currently doing on Gitbook:
https://willadams.gitbook.io/design-into-3d/
and I'm just not finding any tools which are a good fit yet, and when I move, I'd like to have a bit of familiarity to begin, and TeXshop is one tool in this space which I am familiar with.
That said, the Quarto VS.Code extension has some very nice features that I think would be awfully useful in a big project:
- A visual editor to allow a simpler editing experience (could be a pro or con ;-)).
- Completions for document centric things like cross references and bibliographies, completions for yaml configuration options.
- Live preview of LaTeX math, Mermaid and Graphviz diagrams
- Syntax highlight for the markdown and embedded languages
- A nice preview workflow
I'm not sure if those are enough to overcome the lack of familiarity, but thought I'd highlight some of the benefits. Neovim and Rstudio both have very strong features with most or all of the above. Our JuptyerLab extension is more minimal, really only helping with markdown rendering.
Downloading VS Code now.
I want to write a detailed tutorial (as HTML page) and a condensed version of it (as Reveal JS slides) from a single document.
I have found this suggestion[1] to specify the separate output file name for the slides in the header, and `quarto render myfile.qmd` will generate both.
Is there a way to include content (long form text, code, or images) that will only be exported in the HTML page but not in the slides (where space is more limited)?
[1] https://github.com/quarto-dev/quarto-cli/discussions/1751
You'll want to use something like {.content-visible unless-format="revealjs"}
We're for profit, but here's the relevant paragraph: "Together, RStudio’s open-source software and commercial software form a virtuous cycle: The adoption of open-source data science software at scale in organizations creates demand for RStudio’s commercial software; and the revenue from commercial software, in turn, enables deeper investment in open-source software, which benefits everyone."
I greatly enjoy using Quarto in RStudio but in VS Code I prefer Jupyter notebooks because of the GUI and excellent integration with Data Wrangler. Do you know if there is a public roadmap for your VS Code extension? It would help me decide whether I should consider transitioning from notebooks to Quarto.
With that said, Quarto works very well _with_ Jupyter notebooks. You can develop in them and then use them directly as inputs to our system. This is how, for example, Jeremy Howard and Rachel Thomas from fast.ai use it (https://www.fast.ai/).
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?
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.
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.
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]
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.
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.
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)
Quarto's html output on the other hand is generally lovely for accessible output.
When I migrated my own tooling from rst, I was looking at Quarto but ended up rolling my own pandoc/md tooling.
AND the biggest advantage: it does not require R. I also like it because it brings the Rstudio style notebook to Python. I dislike Jupyter style notebooks, which are these chunks. Just a personal preference.
1. ```{python}
Folks have already noted that you can run content through any Jupyter kernel. That lets you run Python and Julia code in a familiar runtime environment, and without having to install the R runtime and dependencies.
I also think that our IDE tooling is pretty good. If you're running in VS code, we'll (for example) highlight problems in your YAML frontmatter, resolve document crossreferences in the editor, etc.
We do this in an editor-agnostic way, so the Quarto IDE tooling can be adopted by third-party. We (Posit the company) develop the RStudio integration and VS Code extension, but there exist modes developed by the community such as quarto-nvim.
A good way to think about Quarto is "a next-generation RMarkdown with many lessons we learned and an emphasis on multiple language support".
it’s a great way to lay out documents with code and have them exist in almost any format.