Is there a Jupyter alternative that's just for JavaScript? Like Observable but not Observable.
The new Jupyter Book
51–60 of 69 posts
Re: The new Jupyter Book
#52Earlier quoted context omitted.
As I understand it, Jupyter Book takes one or more Jupyter Notebooks and converts them into a static "book" output (looks like it primarily targets HTML output but with LaTex/PDF possible)
Yes that's about right :) The book can contain a mixture if Notebooks and normal markdown files, and also text representations of notebook files (see https://jupyterbook.org/content-types/myst-notebooks.html ) The initial focus has been HTML, but now there is work ongoing to create a nice LaTeX/PDF "theme"
I mean even for a single notebook the display looks pretty nice. Might consider using for single notebook books just to avoid dealing with the hassle of themes and jupyter extensions.
Re: The new Jupyter Book
#53Is there a Jupyter alternative that's just for JavaScript? Like Observable but not Observable.
There is Storybook that might scratch some of the itch.
Re: The new Jupyter Book
#54I was just discussing with my friend (who's currently writing his master's thesis) about how frustrating integrating Python results with LaTeX papers can be. In my experience (who wrote his master's thesis last year), it was not necessarily the worst, but it required me to complete my methodology and presentation entirely before putting things in LaTeX, because otherwise I would have to spend ridiculous amounts of time updating values that impact multiple tables and graphs.
I hope this is it. LaTeX won't go away anytime soon, but being able to turn a notebook into a near-finished thesis/book (in TeX) would be a-mazing.
Re: The new Jupyter Book
#55I love the Jupyter ecosystem but it's frustratingly messy sometimes. There's already "nbconvert" built in to Jupyter (lab), built on Pandoc. It's extremely under-documented but it's possible to extend it with templates to generate arbitrary outputs. I've done this to directly generate branded PDF reports via latex. Jupyter Book has a lot of overlap with this feature, but rather than building on nbconvert/pandoc, it s…
The JupyterLab extension system is the biggest offender imo. "Oh, I need to install the python package and the jupyter extension separately ? And there are no breadcrumbs if I install one but not the other? And I have to figure out which versions are mutually compatible with each other and jupyterlab because 'everything latest' sure isn't? And I have to install extensions to get features that used to be built-in? And…
Imagine you manage all this but they change something fundamental and you have to (get everyone else to) reinstall all of it.
Re: The new Jupyter Book
#56Earlier quoted context omitted.
This looks great, as extended commonmark support knocks down the last major pain point to switching to Sphinx for docs in the projects I've worked on. The only remaining tooling gap is a markdown linter implemented in python.
Why a python linter? Text editors are usually language agnostic and separate from other tooling.
If the rest of the documentation workflow is in python, it would remove the need to install another entirely separate scripting language runtime to do those checks on every developer laptop, CI system, etc.
Re: The new Jupyter Book
#57Is there a Jupyter alternative that's just for JavaScript? Like Observable but not Observable.
I built Starboard (https://starboard.gg), its interface is similar to Jupyter, but it runs entirely in the browser (which has pros and cons)
Re: The new Jupyter Book
#58Earlier quoted context omitted.
I'm personally a huge fan of `mdbook`, which seems to be the Rust equivalent of R's `bookdown`. I've switched out internal documentation over to it from `gitbook`. https://github.com/rust-lang/mdBook
mdBook is nice indeed but it still lacks a proper way to create PDFs. `bookdown` has a very smooth way to do that. The only thing I don't like is that is very R centric in terms of syntax for adding tables, graphs and whatnot. It's not pure markdown. For things that will be online only mdBook is great. I'm currently testing honkit which is a gitbook-cli fork and it seems OK.
> It's not pure markdown.
Be fair, it's not trying to be and not claiming to either.
Re: The new Jupyter Book
#59Earlier quoted context omitted.
The JupyterLab extension system is the biggest offender imo. "Oh, I need to install the python package and the jupyter extension separately ? And there are no breadcrumbs if I install one but not the other? And I have to figure out which versions are mutually compatible with each other and jupyterlab because 'everything latest' sure isn't? And I have to install extensions to get features that used to be built-in? And…
Imagine you manage all this but they change something fundamental and you have to (get everyone else to) reinstall all of it.
We maintain a custom internal Docker image that everyone uses for their JupyterLab needs to make this manageable; that way, we only have to get everything to work once, and everyone else can just docker pull :latest and be good. It's become a rather large image, since it needs to have everything anyone uses, but for a small-ish team, this has worked well for about two years or so now.
Another upside: There is a GCP gcloud one-liner to start a VM for a given Docker image, and the image is designed to work both locally and in a GCP VM, with notebooks in a git repository that gets checked out automatically on container creation, so switching from laptop to 16-core VM to churn through a large dataset from a bucket is pretty seamless.
Re: The new Jupyter Book
#60Call me old-fashioned, but I dislike Jupyter notebooks, or really anything that I can’t easily use with my editor of choice, diffing tools, etc.
Jupyter should just be an editor and execution engine that operates on plain text code, using specially formatted comments to delineate cells. If I want to edit it with vim and execute it using plain old Python I should be able to.