I’ve been using Jupyter, but I know there is also Pluto, and perhaps others. Does anyone have suggestions or preferences?
1 Like
I have used both in the past, but recently I found the trick to disable the internal package manager of Pluto, and I think this my best notebook experience so far.
6 Likes
I use cell mode in my own branch of vscode extension which has saving of inline results to file to survive vscode window reloads. Since I don’ t need many plots and prefer more info density of inline results.
2 Likes
I used Jupyter in my Python days, but only use Pluto in Julia.
Pluto has the advantage of being internally consistent, which is a big bonus over Jupypter for integrated projects and reactivity.
The trick to avoid package conflicts, as mentioned above, is to use project Environments and install all your (non-Base) project packages there.
begin
using Pkg
# create new or open project Environment
Pkg.activate("some_project_environment")
# print the packages in the Environment for ease of check
Pkg.status()
end
Install the packages you need with
Pkg.install(["package1","package2", ...])
and then
begin
using SomeBasePackage
using Package1
using Package2
end
2 Likes
Pluto is satisfying. Another workaround you might need though is to save outputs of long calculations (e.g. using Serialization) and hide those cells from the reactivity somehow. I’ve used just an if-else switch that I change when ready to re-run.
1 Like
My current preference is Quarto. It does support Jupyter notebooks, however, I like its cell mode best. If I need more static output I use Quarto’s HTML capabilities and in case of PDFs its support for Latex KOMA-Script (I have not tried Typst yet). Of course, I like Pluto as well.
4 Likes
There is also Neptune.jl, but I am not sure if it is still maintained. I have not used it, but I think Neptune was supposed to be somewhat of a feature comprise between Jupyter style cells and Pluto reactivity.
1 Like
For fast prototyping I prefer Pluto.jl – together with the trick of using my local environment if I prototype on development branches. A nice thing is that a Pluto notebook is also just a Julia script file (with fancy comments)
For “final versions” I prefer Quarto, since that renders nicely into e.g. PDF or into examples/tutorials in a documentation and is itself a Markdown file. Note that Quarto by now also has a “pure Julia” way (without Jupyter in-between ) the QuartoNotebookRunner.jl
I dislike Jupyter is its format it is saved in, makes it really complicated in a git repo.
4 Likes
I also use both Jupyter and Pluto, depending on the use case, but for Jupyter, the Jupytext extension is absolutely essential and gets around pretty much all problems with the .ipynb format.
6 Likes
Nice, I have to try that somewhen; every now and then I have to use notebooks when Teaching numerics, which is here in Python (I still advertise a bit of Julia for sure).
1 Like
Pluto every time. To handle the long running problem, I tend to make lots of changes without pressing enter, then when all my inputs are ready, I press ctrl+s to save and it runs everything just once.
5 Likes
I love using Pluto and love how seamlessly I can place reactive widgets, but it’s not always possible in the world where everybody else uses Jupyter.
It’s easy for me to get my colleagues to install a Julia kernel in their Jupyter environment than it is for me to ask them to spin up Pluto. I wish Interact.jl was still maintained as it provides a good feature parity with ipywidgets.
3 Likes
I honestly just use the VSCode extension and have mostly stopped using notebooks. It is very convenient, so I don’t miss notebooks at all for the most part.
I’ve used Jupyter in the past, and personally I think that is still the way to go as far as notebooks go. Pluto was something I just could not get used to.
5 Likes
Thank you all for the useful discussion!
100% agreed with this. I’m currently trying to set up a set of exercises for my class (I want the ipywidgets-style stuff so students can interact with the code without having to directly write or modify it, since my course has no formal coding prereqs) and almost just gave up and did it in Python because of how annoying it was to find a Julia version that could still work with Interact.jl AND also with Plots.jl (1.8.3 does the trick if anyone is wondering, for older versions of Julia Pkg can’t get some binaries that Plots needs but for newer versions, Interact borks).
Don’t get me wrong, Pluto is really cool, but when I want to run something in the cloud (in my case on ChemCompute) so that students don’t have to set up a local installation of anything and I don’t have the time or resources to set up my own server to do this with Pluto (which AFAIK is what is necessary right now, the Binder hack sort of works but takes like 6-7 minutes to spin up a notebook), Jupyter is really the only choice since it works with so many existing platforms.
I also think from a strategic perspective, effectively abandoning Jupyter for this kind of application is premature for this community as a whole. If I want to convince a Python user to try Julia and they’re very used to Jupyter, it’s so much lower of a barrier if they can do it in that familiar environment (and then maybe be tempted to try Pluto later on…) than to ask them to change both the language and the style of notebook in one go.
Relatedly, I know Pluto is pushed heavily for educational purposes (and I agree that it’s great for that, the reactivity really helps establish better patterns), and IMO a simple cloud solution that supports Pluto would go a long way in this regard, too…
(ETA: not intending to minimize the fact that something like Interact.jl obviously takes meaningful development effort; more emphasizing that it’s something worth prioritizing and trying to support if at all possible)
9 Likes
I don’t know much about JavaScript ecosystem, but it seems like a library to provide simple abstraction to render widget for Jupyter could be built on top of Bonito.jl.
1 Like