Could Neptune Really Replace Jupyter? | by Emmett Boudreau | Towards Data Science

Last year in October, I took a look at a Julia package called Pluto.jl. Pluto.jl is a notebook server for the Julia programming language that has a lot of unique features that set it apart from its competition. As I am an IJulia user primarily, I of course ended up comparing this solution to Jupyter Notebooks. In a lot of ways, I believe the notebooks traded blows. However, there were some fundamental issues I was facing with Pluto.jl and the ideas behind it that made the notebooks much less usable when compared to their Jupyter counter-part for me personally. If you would like to read that article, you may do that here:
towardsdatascience.com
I found that in my experience with Pluto.jl, it was much more tedious to use than just about any other solution I have worked with. Once again, I would like to note that this was my preference, not the fault of the package. However, I found that the reactive nature of the notebook often got in the way of executing just about any cell of code. This was very frustrating to deal with, because on paper Pluto.jl sounds amazing. The notebook is reactive, so there are no state issues that can make notebooks be less reproducible. This concern is something I adopted from one of my favorite machine-learning enthusiasts, Joel Grus, who is also the author of one of my favorite books from O’Reilly. To quote Grus directly,
“ We can completely mislead our output by simply changing the order of execution of these cells.”
Of course, a concept like that is pretty terrible for something like science, especially in terms of creating reproducible research. Pluto.jl attempted to solve this by adding the reactive feature, but in my opinion it falls a bit short by not keeping up with what you are doing effectively enough. Additionally, having to begin and end any multi-line cells is also rather tedious and annoying. Despite the failing of the reactive feature in this regard, I think there are a lot of other redeeming qualities to Pluto notebooks. This is where Neptune.jl takes the cake and wins for me.
Neptune.jl is a new modification of Pluto notebooks that has the primary purpose of being Pluto without the reactive feature. This means that the ability to use notebook cells in pure Julia is now possible without having to deal with the reactivity of Pluto getting between you and your code. This is desirable to me because we can effectively cut out Python as the bridge between the Julia language and the kernel, and instead work with pure Julia through and through.
More exciting is how Neptune and Pluto notebooks save files. Neptune files are not stored in an IPython notebook containing a bunch of JSON data that tells Jupyter how to decode all of your cells. Instead, Neptune files are stored safely and securely, nested inside of a .JL file, with markdown cells made into multi-line strings. For me, this is a pretty big selling point of utilizing something like Neptune or Pluto over Jupyter Notebooks. Furthermore, this can be a huge advancement because now we can have applications and notebooks in the same file. Not only that, our applications can be very well documented right off the bat, because all of our comments are now retained within this .JL file! We could always run this file by calling it with Julia. We could even include it, it is a Julia file! A Julia file is going to be a lot more diverse in this regard than something like a notebook file.
The only concern I hold with this is viewing this notebook from different applications. There have been times where I have looked at the source of a notebook inside of Github. This would not be possible with Neptune or Pluto. However, viewing the Julia code in most situations I believe would actually be apt, and perhaps that might even be a preference on Github so long as no show() method is used to show something HTML or image-wise.
Neptune also has a few other changes that have been made, but in order to check out those changes we will need to add the package with Pkg. For a while, the package was not available in the Julia General registry, but as of now it is registered, and we can add it via the Pkg REPL.
julia > ]pkg > add Neptune
Now we will import Neptune and use the Neptune.run() method in order to start a new notebook server.
using Neptune; Neptune.run()
You might recognize this home screen if you have ever worked with Pluto.jl, as it is the exact same one with the exception of the text in the middle. Here, we also get a pretty good description of exactly what Neptune is. Neptune is a notebook server that follows the ideas presented by Jupyter, which serves as the inspiration for the package, but the server is also powered by a fork of Pluto.jl.
Creating a new notebook, we quickly see that the reactivity from Pluto.jl is nowhere to be seen — which for me personally, is quite a sight for sore eyes. However, one issue that I still get frustrated by is the inability to use the shift+enter hot-keys to create a new cell. It is easy to see why this is not the case, I think that measuring the input of a cell like this prior to execution in order to check for hot-key input might cause a lot more headache than it is actually worth. That being said, I do believe that most Data Scientists use this hot-key very frequently, so it is certainly something I would note as a frustration. Reaching over to my mouse every time I want to add more code is incredibly tedious in my opinion.
The stylistic choice to put the output above the input is also something I have a bone to pick with. It seems nonsensical to me. The output is a direct result of the input, and always comes after it, we do not read a page bottom to top, so it really does not make much sense for the output to be above the cell. I continuously think that cells have not ran when they actually have, the output is just simply above the cell rather than below it. Of course, this is a complaint of Pluto.jl, not Neptune.jl, but Neptune.jl being a fork of Pluto.jl means that it also inherits its problems. One thing I will say about Neptune that is negative, however, is that the favicon is really ugly. That might sound like a bad critique for something like this, and it is, but I would prefer there not to be one instead of having a picture with a white background behind it that has the wrong aspect ratio.
Fortunately, there is one thing that has been taken out of Neptune.jl that was in Pluto.jl. This removed feature is one that I despised with Pluto.jl, and it was the inability to create multi-line code cells without a begin and end. It is easy to see why this was, I imagine it was likely due to the way Pluto.jl saves its files. However, I did find it rather annoying to need to write begin and end every time I wanted to write a new line of code. Funny enough, I might have actually been the one to suggest this change, so I am incredibly happy to see it pull through so flawlessly in Neptune.
In the spirit of open source, we have received a fork to Pluto that I believe features a lot of dramatic improvements to the original notebooks. While a lot of concepts in Pluto.jl are pretty cool, I think that a lot of them also get in the way more than they actually help with Julia programming. In a lot of cases, I was incredibly annoyed to have the reactivity be included as part of the notebooks. I think that the reactivity is actually still a great idea, but likely still needs some elbow grease and intelligent programming put into it to truly be remarkable.
So the question is, can this really replace Jupyter notebooks and IJulia for Julian Data Science? For now, I would have to say my answer is no. The main reason I say this is because there are still some output bugs with Neptune.jl that have carried over from Pluto. Sometimes, output just will not appear — and of course, this can be frustrating. I think the concept of notebooks in a .jl file is certainly alluring, and I am sure I can see notebook solutions like these working out very well some day. However, today might not be that day, unfortunately. Writing this article has actually made me want to create my own notebook server in order to create it exactly how I would want it to be. That would certainly be an interesting project!
Although I think that Neptune is a better solution for me personally, I will still be sticking with IJulia. I think that there are some flaws from Pluto that carry over into Neptune, unfortunately, but there surely is a future for both packages — which I am excited for! I think that with just a few tweaks, both of these notebook servers could be apt replacements for me to use instead of Jupyter. I will say, however, I think that a lot of this comes down to personal preference. I just happen to prefer Jupyter over both of these packages, and others might not end up feeling the same way, so I do encourage readers to try out both of these notebooks and make up their own mind on which is better! Thank you for reading, I hope this article helps in finding the best notebooks to write Julia in for you!