Came across this PR today: https://github.com/julia-vscode/julia-vscode/pull/980
it looks like the Julia community are creating a new Julia-focused notebook format (called .jlnb) via their VSCode extension. Just FYI in case folks are interested.
2 Likes
YES. This was one of this topics of my session at JuliaCon on Wednesday! I should start another topic in the Binder category with the findings from that.
3 Likes
Would love to know what you think about this! TBH I am kinda bummed about it - especially because it seems like it was partially due to VSCode having their notebook support wrapped up in the Python extension rather than the Julia one :-/ it doesnāt seem healthy to see the ipynb format fracture just because one proprietary interface didnāt implement a good enough notebook support 
but maybe I am missing some extra context for why a new format was created
3 Likes
Actually the discussion wasnāt so much about the new format, but I think folks would like it if Binder supported VSCode UI out of the box. And I think thereās many avenues that idea could be developed down.
2 Likes
Would love to hear your thoughts over here too: Connecting Jupyter and Theia 
I think the biggest downside of VSCode is that it is proprietary. Iād feel better offering something like Theia or VSCodium perhaps. That said, itās gobbling up more and more of the world (and pretty soon GitHub CodeSpaces will start offering vscode for free in a very binder-like manner) 
1 Like
David Anthoff has done a lot of work on julia support in repo2docker. We could ask him if he has time to join a team meeting/this discussion if we want to figure out more stuff.
1 Like
David is also the main person behind the vs code julia plugin, IIRC, and the one in the JuliaCon chat talking about the experiments with a Julia notebook format. I think it would be great to have a discussion with him about their goals and how they might align with our recent discussions about a text-based format.
2 Likes
David was also the one at my JuliaCon session
I thought VSCode was open source? It has an MIT license on GitHub https://github.com/microsoft/vscode
1 Like
Sadly - VSCode has a few serious problems in terms of open source. As Microsoft says
ā¦ it is more accurate to say that Visual Studio Code is ābuiltā on open source, rather than āisā open source
Specifically (same MS URL):
Microsoft Visual Studio Code is a Microsoft licensed distribution of āCode - OSSā that includes Microsoft proprietary assets (such as icons) and features (Visual Studio Marketplace integration, small aspects of enabling Remote Development).
The āVisual Studio Marketplace integrationā is a particular problem because it means that other distributors of the codebase, such as VSCodium or Theia, cannot use the MS extensions site, and have to build and maintain their own. From VSCodiumās README.
According to the VS Code Marketplace Terms of Use, you may only install and use Marketplace Offerings with Visual Studio Products and Services.
Beyond that, is the anxiety that many feel at an open-source codebase that is, in practice, driven almost entirely by Microsoft developers. From a blog post on Theia:
VS Code is a Microsoft product that is largely developed as open source, but is controlled by Microsoft. Anyone who relies on VS Code is then dependent on the future investment of Microsoft to continue supporting on-going development of the product.
The fact that Microsoft has de-facto control means that we have less reason to be confident that the direction of the project will benefit the community, at the expense of Microsoft, should that conflict arise.
2 Likes
+1 to reaching out to David to hear his take on it. TBH I am a bit surprised that the Julia community decided to go all-in on a platform that is controlled by one company, but ĀÆ_(ć)_/ĀÆ
@sgibson91 I think itās worth disentangling a few different āaspectsā of open source (as I understand it) and how each relates to VSCode.
Open components - in this respect, VSCode does decently well. Many of the underlying components (Monaco being the most well-known example) are openly-licensed. However, as the JupyterLab team learned when they tried to integrate Monaco with JupyterLab, many of these components make assumptions about VSCode infrastructure being present, so arenāt designed to be super easily/readily reusable elsewhere. That said, I think when people say āVSCode is open sourceā this is really the only thing that it appliesto.
Open governance - in this respect, VSCode does poorly. There is no open governance of VSCode development, nor of the open source components underneath. Those are all Microsoft products and driven by Microsoft roadmaps/PMs/etc. As @matthew.brett mentions - right now Microsoft has decided to align itself with open source (and making a strong marketing push to brand VSCode as āopen sourceā for various reasons). What will that look like in 1/2/5/10 years? History says that relying on a gigantic company with monopolistic tendencies is an anti-pattern if you care about public goods and collective power.
Open products - in this respect, VSCode also does OK but not great. VSCode is a proprietary distribution that contains a collection of open source and proprietary components. Sure you can fork VSCode and keep only the open source parts (thatās what VSCodium is). But then you realize that there are actually a lot of proprietary things interwoven in VSCode in subtle ways. E.g., as others have mentioned the āreal time collaborationā API is proprietary, and many of the extentions that ship with VSCode are proprietary. As time goes on, I suspect VSCode will change the ratio of āopen source to proprietaryā extensions within VSCode such that the āopen forkā versions will become relatively more underpowered.
A good example of the tensions that can arise with this are actually related to Julia notebooks. In the PR where they propose creating jlnb files, David actually mentions that one reason theyāre considering .jlnb is because the .ipynb format in vscode is managed by the vscode-python team. In other words, Jupyterās vision of a truly multi-language and multi-stakeholder layer of infrastructure is potentially going to be fractured because a product team inside of Microsoft is building āJupyterā tooling that is too Python-specific, and on a platform that is becoming so popular that it is influencing decisions about Jupyter tooling in a way that Jupyter has no say into.
Or to put it shortly if VSCode were translated into the Jupyter ecosystem, itād be like if:
- JupyterLab was a product of a single large company called
The Jupyter Corporation - This company also ran a totally proprietary version of JupyterHub on its own cloud
- This company also controlled the most popular platform for doing open source development, and could use that platform to encourage the use of these products above other options.
- All development of core JupyterLab components, APIs, and key extensions were done by this company
- JupyterLab shipped the
pip install jupyterlabversion with a bunch of proprietary extensions pre-installed - JupyterLab encouraged communities to fork it and create their own JupyterLabs if they didnāt want the proprietary stuff
- JupyterLab encouraged a lot of open source development and experimentation within jupyterlabās ecosystem, but where the ecosystemās platform was controlled by
The Jupyter Corporation.
Donāt get me wrong, I love VSCode and use it all the time. From an engineering perspective it is super impressive, and I also appreciate all of the effort theyāve put into making it very extensible (and easy to extend). And I should also be clear that all of this is totally Microsoftās prerogative, thereās no reason that they canāt operate in this way, it is IMO in their interests as a company. I just think we should be realistic about itās role in the arc of āthe open communityā and its relationship to research and education. I think itās not realistic to think of Microsoft as āa friend of open sourceā but more like ātemporarily aligned with the interests of open sourceā - it may be true now but the last 3 years are a tiny blip in the history of Microsoftās culture. Whether it is Microsoft/Google/Amazon/etc we want the infrastructure and platforms in our community to be governed by the commons, not by any single entity that doesnāt have a properly open and multi-stakeholder governance model.
note: Theia is I think an interesting project here, because it basically re-uses a lot of the VSCode components but packages them in a distribution that is also open source and designed for composability and reusability. That distribution is managed by the Eclipse Foundation, which is a multi-stakeholder group. Iād feel a lot more comfortable if we found ways to empower the Theia/Eclipse community, rather than to work within the sandbox that Microsoft gives us.
2 Likes
Thanks for the info everyone. To be clear, I answered the question by saying āI think thereās a reason we donāt do this, but I canāt remember what it is right nowā. This is obviously it! (I actually think a VSCode extension that automatically gives you a Binder kernel would be more interesting than us serving the VSCode UI.) Given VSCodeās popularity, itās good that we have a party line to tow and now I know what it is!
And now Iāll stop hijacking the thread about Juliaās new notebook format
3 Likes
FWIW - I am not trying to give the party line here, just giving my perspective. As I mentioned, I also love VSCode and use it all the time, so I am conflicted here. Binder should be facilitating the workflows that make research and education most-impactful in the ways that align with our values. Maybe VSCode is a part of that, but I just want us to have maximal information as we make those choices, thus my wall-of-text above
As another example: we also offer RStudio, which is similar to VSCode in its hybrid āopen source but produced entirely by one companyā nature. We have to get permission from RStudio Inc to use the trademarks etc, and yet we still offer it to users. I think VSCode is in a similar category.
1 Like
Hi everyone! @sgibson91ās excellent session at Juliacon last week made me think that it would be good to have some more contact between the Julia VS Code team and the Jupyter effort, so I browsed around and the first thing I see is this thread So here I am, and I think it is a great idea to connect!
I should clarify probably one thing right away: we have not made a decision to create our own notebook format. We have a PR that implements a native notebook editing and run experience for Julia in VS Code and it uses a custom file format, but the whole thing is WIP at the moment and whether we will go with a custom format or not is up in the air right now. Certainly a possibility, but a the moment we are much more focused on getting the actual functionality of the notebook UI up and running, rather than focus on the the file load and save story.
But one thing is becoming pretty clear in this process: the notebook UI we will end up with is going to be much richer than what Julia users will have in JupyterLab. Weāll have full language server, debugger, workspace viewer, plot pane, documentation browser etc. support from day one because we built these things pre-notebook days and they can now be integrated with almost no extra work into the notebook UI. Iām a huge JupyterLab fan, but when I recently realized that we will probably have the premier notebook UI for Julia in VS Code and not JupyterLab, it did give me pause and made me wonder about the larger strategic implications for JuptyerLabā¦ I say ārecently realizedā because there was very little strategy behind any of this on our end, it was more that all of this fell into place when MS started to work on the notebook API (which btw. is entirely distinct and unrelated from the existing Jupyter notebook support in the Python extension for VS Code).
In any case, I think some generic meeting would be great. I could report a bit on what our plans are on the Julia extension side of things. I also saw that there were various discussions ongoing about Theia, and how Jupyter might in general be able to integrate more with that or VS Code directly. I could probably say a few things about that as well. In particular Iām just very, very familiar with the VS Code extension points, which might be useful for that discussion. Could one of you take the lead in setting up such a meeting? I really only know @sgibson91 and @betatim from this thread, so wouldnāt really know who should be invited. My email is anthoff@berkeley.edu.
Oh, and we just had two talks at Juliacon about the state of the Julia VS Code integration, that might be a quick way to get a sense of the functionality we have. Video 1 is https://www.youtube.com/watch?v=rQ7D1lXt3GM (there is a very short demo of the notebook PR in there) and video 2 is https://www.youtube.com/watch?v=IdhnP00Y1Ks.
4 Likes
A good starting point may be our monthly team meeting, or do folks want something separate?
1 Like
Iād prefer something separate, and invite JupyterLab and Jupyter Notebook people, as well as post on the ongoing notebook format thread elsewhere.
2 Likes
Thanks @davidanthoff for reaching out! Iām excited to hear about how the Julia community has been navigating these issues, and where they see this space moving forward.
I agree with @jasongrout that itād be good to have this meeting in a place that the JupyterLab/Notebook communities can interact, ask questions, etc. Thatās probably the part of Jupyter that has thought the most about these kinds of issues (and also probably the most likely intersection point?)
I would be very interested to join such a meeting, though canāt be the one to organize (and may not be able to attend) because Iām expecting a baby girl literally any day now. @davidanthoff and others if you want to hop on a short call this week Iād be happy to do so just to touch base, but if youāve only got one meeting in you, Iād recommend it be one w/ the broader community and I can always check the notes.
Iāll try to think about my main questions around VSCode/Theia/Julia/Microsoft and will post them here in case it sparks ideas or discussion.
@choldgraf Good luck with that project, and get some sleep while you still can
I think having a meeting this week would be good, it would be great if @choldgraf could be part of that. I certainly would be up for another one later on.
If someone sends me some emails of folks that should be part of that, Iāll send a scheduling poll around.
2 Likes
Thanks folks for the details! Iād be very happy to join such a discussion as well - @davidanthoff if youāre looping people in for scheduling, feel free to use my campus emailā¦
I would also like to be a part of this discussion, if you schedule it! s.shanabrook@gmail.com
thanks 
Iām free most afternoons this week. Shall we pick a time and invite whoever is available to make it then, with a plan to have a broader lab/notebook community meeting later on? (I assume itāll be complex / take time to organize between all of these folks for this week). I donāt want to limit the conversation to just my schedule, Iām just worried that if itās not this week, Iāll probably be unavailable until like October 