JupyterLab vision for the next few years

[lresende]

We are seeing aggressive strategy from IDEs to penetrate and/or disrupt the Jupyter Notebook UI arena, in particular JupyterLab. In parallel, we have seen a lot of the cloud vendors enabling Jupyter Notebooks as a service with enhanced UX capabilities that are kept proprietary and not contributed back to the community.

I believe the JupyterLab community should step back and create a 1-3 year vision/strategy plan. This plan would provide directions on areas to focus aiming in maintaining its prominence as the de-facto UI for data science interactive workloads. The vision should also consider the personas we serve, and consider areas that we should prioritize to be more competitive when compared with IDEs providing support for interactive applications integrated with Notebooks.

Thoughts?

[goanpeca]

Thanks for opening this issue @lresende: some thoughts on things that might be important to broaden the scope and facilitate the use cases of many users.

• [ ] Localization and internationalization. Work has been started on that front but there should be a plan with some milestones in terms of full localization, internationalization and globalization (fancy term for the merge of the previous 2)
• [ ] A lot of users just want to download an exe, or a dmg and click install and have a JLab icon that launches a desktop app. Maybe some (enterprise) users do not really see a use case here, but a lot of smaller groups, companies, and the single user might benefit a lot from having a simple application download with the standard expectations and auto-update features
• [ ] As @afshin pointed out in the meeting, JLab should provide enough IDE-like features so that staying in there when moving from a Notebook based XP to a more "standard" coding XP is comfortable and nice enough that users do not feel they cannot do what they want without providing all the bells and whistles a more dev oriented IDE would. Now how much is too much? and how many bells and whistles are acceptable for a given timeline?
• [ ] Being built with TS, JLab might have distanced itself from its origins where the Data Science users could make some extensions in Python and hack away. It may be possible to provide a Python API to be able to perform "common use" or simple extensions, without having to do the whole TS lock-in 🤷 .

[echarles]

Thx @lresende for opening this, It is IMHO very important.

I don't think trying to imitate an IDE is the way to go. IDE fat-client installation applies to a fraction of the potential users, VSCode is anyway leading the pack and JupyterLab has more to offer and can serve a lot more of different use cases.

I am seeing JLab as a collection of components that can be integrated and used by:

• IDE like VSCode (VSCode is already powered by JLab)
• Any web applications.

So a collection of client and server components:

• With customisation, theming, binding with frameworks like React.js (or any other trending ones).
• With bindings to online kernels hosted on e.g. binders... or other providers.
• With pluggable AAA (Authentication, Authorization, Auditing)
• With Real Time Collaboration

On top of that toolbox, JLab would ship 2 reference implementations like:

• The current JLab which is for power-user and prolly intimidating for the others.
• A real clone of the classic notebook with 100% conformance on key-bindings (users I meet often come back with that issue). I favor here a rewrite from scratch than a strip-down of the current JLab.

And would ship easy tutorials to embed those in 3rd party applications.

... and yes, one-click installation would be super-useful (but less important to me than the above).

...and hosted VSCode in the browser looks terribly like powering GitHub CodeSpace (See https://github.com/cdr/code-server for open-source implementation of VSCode as WEB application).

[echarles]

We often compare/refer to VSCode but RStudio is another tool worth looking at. They have fat and web flavors with the exact shining UI: An editor mixing code/text/latex/..., a console, a variable inspector and a bottow-right display for the rest (graph, filetree, help...).

Are we in a state to do that easily? We miss the editor mixing text/code (for now attaching a md or py file to a console is a uncomplete workaround). We don't have a variable inspector component (3rd party ones exist).

Assuming we have those components, we could add a third reference implementation (JStudio :)) aside the 2 ones I have listed (current jlab and classic clone).

This makes me think when Mozilla has broken its monolith distribution (which even included a html editor) into Firefox, Thunderbird... and regain market at that time.

Also, an hidden gem is located in the examples folder too much invisible and not marketed (we link to them sometimes when users ask questions on kernels...). Those examples look too me like the premise of what I would love JupyterLab to be: a reusable set of components to build secure, scalable and collaborative data driven applications in the cloud.

[echarles]

Typing when thinking... I feel that the current way to integrate more and more external extensions into the default distribution has its limits.

[blink1073]

I feel that the current way to integrate more and more external extensions into the default distribution has its limits.

Yes, we will need a clear strategy about what is in core once it is easier to install extensions. We should be following the data from things like the the 2015 UX Study.

[krassowski]

Should we have a new UX study? Also, please have a look at the study "What’s Wrong with Computational Notebooks? Pain Points, Needs, and Design Opportunities" from Oregon State University, Microsoft and University of Tennessee-Knoxville. There are points (in interpretation and methodology) I disagree with, but still a valuable contribution.

I think about IDE-like features a lot. I see that there are different paths ahead but I will be working to make the LSP integration as reliable and feature-full as possible (we could certainly use a hand!). Then, there is the ease-of-installation which may be actually a challenge - currently, we require node, python extension, lab extension, and the servers; all have to be properly instaled (most needs to be installed from the command line!) and novices trip on virtual environment issues (e.g local/global installations, using conda without fully comprehending it, etc). Obviously modules federation will be a step forward - but it will not be a perfect solution for LSP extension because some servers still require node...

[meeseeksmachine]

This issue has been mentioned on Jupyter Community Forum. There might be relevant details there:

https://discourse.jupyter.org/t/cripplingly-slow-ui-am-i-the-only-one/5351/7

[matthew-brett]

In case it's useful, a summary of recent StackOverflow IDE rankings. It seems that VSCode is eating quite a few lunches, but particularly Sublime Text, Atom, Eclipse and Notepad++.

[blink1073]

Another data point: https://www.jetbrains.com/lp/python-developers-survey-2019/

[blink1073]

The "Tools and features for Python development" section of the above survey has a lot of overlap with our 2015 UX Survey results.

[blink1073]

Also, thanks for putting that together @matthew-brett!

[choldgraf]

a couple of thoughts (thanks @lresende for kicking off this discussion)

• Differentiate from, don't compete with, VSCode. IMO JupyterLab is currently thrown around in the same category as VSCode. I see why people do this, but I don't think JupyterLab's aspiration should be to "beat" VSCode. Instead, I'd put a lot of thinking into why JupyterLab is a different kind of tool than VSCode / atom / sublime / etc, and why that kind of tool is better for data workflows than "a developer IDE that also does data stuff". If we cannot come up with an answer for why a data-focused interface is obviously better for data workflows, then JupyterLab will have a hard time competing. What are the unique aspects of data science that do not make sense in a traditional IDE? How can JupyterLab be the best at those things?

  • A related point to this - I don't think that VSCode should be shunned as an interface that nobody in the Jupyter community develops for. VSCode will continue growing its notebook support, and IMO it's in the interests of the Jupyter community to be in dialog with the people (whether they're MS employees or community volunteers) growing notebook experiences there. This will particularly be important in terms of standards - otherwise we'll end up in a future where there are VSCode-specific notebooks, JupyterLab-specific notebooks, Colab-specific notebooks, etc.

• Find ways to make the UI flexibly opinionated. Right now JupyterLab gives you a very unopinionated UI but with a lot of flexibility. You get standard UI elements but not a lot of decisions are made for you - the user is expected to open a notebook / text editor / etc on their own. On the contrary, the notebook UI was extremely opinionated - you got what you got and that's it (JQuery extension hacks notwithstanding). I think people like opinionated UIs when they're focused for the right workflow. The trick is giving people control over which UI they see for a particular use-case. JupyterLab should make it easier to fire up more opinionated UIs (one of these needs to be a dedicated notebook UI) with the same ease as typing jupyter notebook. These more workflow-specific UIs should also work with JupyterLab extensions so that you can really tailor the experience for the use-case. Sure, it's possible for me to manually install the right extensions, arrange the windows in the right places, and save the "workspace" for use later. Most people will never do this. Instead people need to be able to do something like pip install jupyterlab-studiointerface and have this install a bunch of extensions and add a button to "activate" this interface within jupyterlab as well as a CLI entry point to activate it. Once activated, users should be able to switch back to other JupyterLab interfaces easily and extremely quickly.

  • As an aside: I also think of JupyterLab as a different kind of tool from the notebook UI. The Notebook UI feels like an end-product for a particular workflow, while JupyterLab feels more like a "UI sandbox" that is composable and configurable. I think the sandbox is great, but we need that "end product" option as well.

• Improve the ease and fluidity of developing extensions. On that last point - developing extensions is how the community can participate in the JupyterLab ecosystem without being core developers. It allows the community to explore a much bigger design space and leverage the flexibility of the lab interface. However, in my experience developing extensions is cumbersome and confusing for the kinds of users that are in Jupyter. These folks are not Javascript developers. They could learn/hack together some JQuery on the old notebook interface, but developing an extension now requires an understanding of javascript frameworks and modern web workflows. There are definitely benefits to this, but it comes at the cost of making it much harder for the "casual enthusiast" user to become an extension developer. There is a lot of creativity and potential in that casual enthusiast community that I think we are missing out on! JupyterLab should prioritize making "developing on top of JupyterLab" to be something that is as easy, fun, agile, and creative as possible. In parallel, it should put effort into creating a lot of introductory-level material for how to develop in the JupyterLab ecosystem.

I think that if JupyterLab makes progress on both of the above pieces, it would make a huge difference. Incentivize (and make it easier) for people to build extensions on top of the composability of JupyterLab, then make it easier for users to fluidly use those extensions / interfaces. Develop a few "core" interface configurations for JupyterLab (e.g., "notebook UI", "RStudio-like UI", "Dashboard UI") and empower a developer community to figure out what other possibilities are out there.

I'll leave it there for now because I don't want to wall-of-text y'all ;-)

ps: I recommend folks check out some of the conversation in this discourse thread about jupyterlab / classic notebook UI.

In that thread someone brought up Blender as another tool to think of for inspiration. I found the Blender video they linked to give some interesting thoughts about UI design and how it can benefit complex workflows.

[saulshanabrook]

I really appreciate this conversation starting up!

Hot Take

We should figure out how to move on top of VS Code / Theia.

VS Code / Theia

Theia is an Eclipse project that focuses on being open source and in your browser, but building on VS Code.

I believe the TypeFox folks were originally basing things off JupyterLab/Phosphor and have now moved to VS Code/created Theia. See https://github.com/eclipse-theia/theia/issues/6501.

Why?

Because then we could focus more of our energy on the things that makes Jupyter special, like data science, education, pushing the boundaries of interactive computing, and collaboration. And we could leave the parts that are about making an IDE experience (debugging, window layout, extension infrastructure, performance) to the teams with the history and drive and mission to do that, like Microsoft and Eclipse.

How?

In this imaginary future, "JupyterLab" would simply be a certain distribution of Theia with certain extensions and settings included by default.

Why not?

One concern that some people have raised about moving to VS Code is related to the single stakeholder nature in which it is developed and governed.

It would be interesting to hear from the TypeFox and Eclipse folks how they have felt engaging with this and how they see that space.

Also, there isn't notebook support yet in Theia (https://github.com/eclipse-theia/theia/issues/3186 ). The live share feature of VS code is also not present, since it isn't open source (https://github.com/eclipse-theia/theia/issues/2842).

I am curious from other people who use JupyterLab, if there are other major issues from moving to this approach and obviously from the other maintainers how they would feel about it. Or if this has come up in the big institutional adopters (and funders) of JupyterLab, like Bloomberg and JPM. Have you talked internally about switching to VS Code/Theia instead of JupyterLab?

I am also cognizant of the fact that JupyterLab, to me, is a means to an end of exploratory computation and a community of people that I care about. As someone who helps maintain this library, I would like to find a path forward that lets us leverage our effort and time most effectively, by collaborating with other groups.

[bollwyvl]

The idea of "Lab" (vs Studio, or all the other things we tossed out when naming the project) was that we're trying to serve individual scientific computing users, teams, and the global scientific community. That means supporting the scientific method from education up to scientific publishing. The fact that a scientist must increasingly write code in between is relevant, and being able to support a scientist doing that to the extent needed is indeed among the challenges that will cause otherwise-enthusiastic users to abandon ship.

But, when I'm wearing my developer hat: my experience has been that Lab is a more malleable substrate than code. Teams can ship more customized things on it. I don't think doing static (a la jyve) would be possible with the Code baseline.

With my desktop support hat on: we've almost gotten users out of the nodejs woods on 3.x... even some of the language servers can be webpacked (during a build), despite the vscode upstream having wontfixed the dependency issues around it. The walled garden of extensions isn't monetized yet, but there's no telling, and downstreams like theia and vscodium can't actually support all of the extensions, even though they share an upstream. And who even knows if vscode works in Firefox?

Some areas I am less negative about:

• computational publishing
  • we're slowly making progress on generating publication-grade PDF
  • publishing a workspace as a statically-hostable, yet still interactive site
    • jyve, stdjs, etc. with pyodide, etc. is going to be game-changing for a simplicity of deployment, especially in education
    • having a "dev mode" browser kernel for lab itself while it's running "normally" will make it far easier to understand how to do extension development
    • heck, wasm kernels on the backend are going to eventually make a lot of sense: no k8s
• get better at bringing new interactive computing specifications, formally, into the Jupyter family
  • DAP was needfully heavy, but the kernel-based approach is probably going to work out great for LSP, and not require anything more than reserving a comm name
• create more data-driven ways to build 80%-100% extensions, themes, syntax, commands, etc
  • doing this over JSON schema means basically all kernel languages can play
  • leave a few outs for handling that one bit of actual ts(x) you need, but leverage the insights we get back from the tooling
• absolutely first-rate integration with hub
  • a major coup would be getting a Lumino frontend into Hub, Binder, etc. and starting to share more code, theming, etc.
  • we'd have to get the initial load time way down
• outreach to open source projects that enable science, business, and education teams
  • jitsi, drawio, gitlab, zulip are all offerings that respect privacy

[Carreau]

• Find ways to make the UI flexibly opinionated.

A real clone of the classic notebook with 100% conformance on key-bindings (users I meet often come back with that issue).

Yes absolutely yes for both of those except for the rewrite part). VS Code is itself a really good example, it is first and foremost a text editor, and is it way easier to recommend as it does just that already super well, and on top of that it can blossom into a full feature IDE once you are ready. And @matthew-brett comment shows it well:

VSCode is eating quite a few lunches, but particularly Sublime Text, Atom, Eclipse and Notepad++.

Eclipse is for sure an IDE, but Sublime, Notepad++ and (to a lesser extent) Atom, are way closer to good text editor.

I would try to get a version of JLAB which is focused on one document per browser tab with one of those view much closer to classic notebook, which eventually can let user grow to full lab instead of a rewrite.

I think also that clear repacking/branding of JupyterLab with a set of simple preconfiguration could go a long way to form smaller dedicated community. VSCode is really attractive to developer, but we have a bunch al data scientist in many domains.

It would be good to pick a few extensions and default configuration and specific css theme that target a number of use case, say for example

• Astrophysic,
• ML
• Genomics,
• Earth Science
• Education
• ...

With their googlable distinct names.

[bollwyvl]

@Carreau Right, going beyond just an installer, here are examples of cross-platform, one-click, non-root installers centered around a Lab configured with different goals, with the full required compute stack underneath:

• robotlab: a Lab focused on writing and executing acceptance tests
  • a lot of space taken up by OpenCV, Selenium, Firefox, and some super gnarly windows stuff
• GTCOARLab (wip): a Lab focused on quantifying the underlying mathematics of reinforcement learning models
  • tensorflow torch are heavy
  • also is going to have a full latex stack

As a first go-round, officially offering one of these kitted out for training lab developers would probably make a lot of sense: typically takes at most 20 minutes once you have the install media on the users box to get up and running.

[choldgraf]

There is also flybrainlab which uses a customized JupyterLab w/ lots of extensions etc designed for computational / systems neuroscience.

[matthew-brett]

When I'm teaching my students, I tell them they will soon need to follow the advice in "The Pragmatic Programmer"

The editor should be an extension of your hand; make sure your editor is configurable, extensible, and programmable.

https://bic-berkeley.github.io/psych-214-fall-2016/choosing_editor.html

I feel I will have served them poorly, if they take a long time to move out of the Jupyter Notebook interface.

The question I have is - is JupyterLab designed to be that editor, that is "an extension of your hand"? Is the intention that many people will use JupyterLab as their primary editor for text as well as notebooks? If so, how many people use it that way? If not, then when what role should it play?

[goanpeca]

I think is important to make a distinction between the vision for developers and for end-users. Probably the user-oriented vision should take the front seat in this discussion.

[matthew-brett]

@goanpeca - my argument would be that it would be a mistake to concentrate on the "user" at the expense of the "developer" that the user should become, as they continue to learn. If only because, I believe it would be a dangerous place to position JupyterLab, in between the absolute beginner (who is relatively well served by the traditional notebook interface) and someone who wants to become proficient in using scientific code (who should and will start to learn VSCode, or PyCharm or Atom or Vim). The obvious risk is that students go straight from traditional notebook to VSCode or similar, and miss out JupyterLab in the middle.

[matthew-brett]

As a dreadful warning as to what can happen to users who get stuck in the traditional notebook interface - see the "Study 3: interviews with data analysts" section in https://dl.acm.org/doi/abs/10.1145/3173574.3173606 .

[choldgraf]

I think it all comes back to the question: "Is it possible for a highly-flexible and extensible development environment to also be a first-class data science environment? If the answer is fundamentally "yes" then it will be hard to beat out VSCode or whatever projects w/ equal amounts of resources replace it, and we should be re-focus efforts from building an entirely separate parallel web framework to instead trying to make sure the web IDE that wins is the one that has a good open governance and community structure.

If the answer is "no, data science is a different kind of thing from development and warrants its own interface" then I think that's where JupyterLab should position itself. If this is the answer, then I'd urge the JupyterLab community to think about how to encourage and facilitate a flexible transition back-and-forth between JupyterLab and <IDE of user's choice>, with the assumption that we want people to use the best tool for the right job, and JupyterLab will never be the best tool for development. Then, focus the JupyterLab experience in a way that really highlights the "data stuff" and makes it clear why it's the best choice for that workflow, while <IDE of your choice> is the best choice for doing development.

[matthew-brett]

@choldgraf - nice summary. So, to help make that as specific as possible - what aspects of data science workflow can one not easily cover with:

• Current VSCode?
• Atom + Hydrogen + Jupytext?

And - once these are clear - how difficult would it be to extend these systems to cover the missing cases?

[smackesey]

I see that this is a team repo so I'm not 100% sure I should be posting, but @saulshanabrook on the Discourse forum suggested that I contribute to this discussion so here's my two cents. The below take is certainly the product of my own biases and not based on a study of JupyterLab's existing userbase. But I haven't seen the general idea proposed, so I'd like to throw it into the arena. For background, I work with JupyterLab mainly in the context of computational neuroscience. I'd also like to preface this by thanking you guys for all your hard work on the platform to date.

I would like to see JupyterLab become the hacker's data science environment. I believe that this niche is (a) open; (b) unlikely to be contested by any of JLab's current competitors; (c) achievable. On top of that, it would be awesome and potentially revolutionize data science work.

In the world of software, there are two broad categories of product:

Hacker-focused. These products are typically extremely customizable, powerful, and performant. But the interface is often complex, lacking in bells and whistles, and somewhat intimidating. Examples include Vim/Emacs text editors, Linux, the mutt email client, Ranger file browser, and many other command line programs. They are almost always open-source.

Average-consumer/enterprise-focused. These products are "friendlier" (at first glance, anyway). They are often "What-You-See-Is-What-You-Get". They have shiny GUIs, animations, and lots of nested menus. But they are often irritatingly inflexible, suffer from limiting and inefficient interfaces, and have maddeningly poor performance due to unnecessary visual effects (compare text-based Ranger to MacOS Finder...). Examples include Microsoft Office Suite, Windows/MacOS, Gmail, etc. The vast majority of the good ones are developed by business-- open-source ones usually have all the flaws listed above but worse, and are uglier to boot.

In the rapidly developing world of general-purpose data science IDEs, there are not yet any clear winners or losers in either space. Indeed, the spaces have not yet been differentiated. Jupyter Notebook (and by proxy JupyterLab) gained significant market share as one of the first apps in this world, but now its starting to face real competition. And there is every reason to expect that this particular software category will follow the same trend as others-- the "user-friendly", "for-the-masses" throne will be claimed by something corporate-backed, like VSCode. JupyterLab won't be able to compete in this space. But, we can also expect that Micosoft won't pursue the "hacker" niche, for the same reasons that corporations rarely pursue this niche in other domains.

So there is a throne waiting to be claimed for the Hacker-focused VIM/EMACS of data science environments. And JLab is well-positioned to pursue this throne. It already has a successful brand, large user base, working product, and contributor community. But, I think there would need to be some major changes for JLab to go this route.

The two most important things are to embrace customizability and focus on core performance. Right now JLab has issues in both these areas. The performance is often weak (as discussed in this Discourse thread, and the customizability and docs regarding extensions are pretty weak.

Finally, here are some specific ideas for steps in the Hacker-focused direction:

• Support embedding of external editors. NeoVim is designed to be embedded in third-party GUIs. I'm a Vim addict/fanboy so I'm biased, but it would be a killer feature to use a real underlying NeoVim instance as an editor. CodeMirror is just not very good for heavy lifting. This would also neutralize one of VSCode's major advantages (people can use a power editor they already use for other things for notebooks).
• Decouple notebooks from files. Notebooks should be like buffers in a text editor-- often paired with a file, but not necessarily. This allows quick temporary notebooks, either user or software-generated. Imagine having an interface that allowed you to browse a database and dynamically generate a temporary notebook, all within JupyterLab.
• Offer at least the option of an initial experience closer to bare metal. When I open JupyterLab now, it looks like a typical GUI program-- tons of menus. It restarts my last session by default, which is annoying since it often means starting up a ton of kernels. I would prefer to launch JupyterLab to a single, empty buffer notebook and a more spartan intermediate interface (of course, you should be able to build on top of the initial "sandbox" to create rich customized environments, as @choldgraf and others suggested above).
• Support alternative notebook renderers and further rich customization of how cells are displayed. The default display of a linear vertically-oriented series of input/output is OK for most tasks but not always ideal. Sometimes it would be nice to have input/output cells side-by-side.

I could list more but I'll stop there. What all of the above have in common is that they increase the flexibility of JupyterLab. I believe that there are amazing exploratory data analysis use cases and interface motifs waiting to be discovered. They just have to be enabled by a suitable platform. JLab is both (a) relatively well-positioned to become that platform; (b) unlikely to face much competition in this niche from VSCode et al.

[ellisonbg]

Lots to process here. Will comments more on other aspects, but will start with this:

I believe that VSCode is incompatible with the open source vision of Jupyter, and not a suitable foundation for it. Jupyter has always been community driven and multistakeholder. VSCode is controlled by a single corporate entity. This is manifested in the following ways: 1) The VSCode Marketplace doesn't allow third party applications to use it, which is why Theia and code-server have built and maintained their own extension services, 2) key parts of the code base remain proprietary (real time collaboration, web based versions such as CodeSpaces).

More importantly, the roadmap for JupyterLab (and any other part of Jupyter) should be focused on building things for actual Jupyter users (lab, classic, huh, ipython, etc.). In this org, I believe we should take time to understand what JupyterLab users are doing, what their pain points are, what their needs are, etc. - and use that to drive the roadmap. That was how I read the initial post of @lresende and I believe that is what we should focus on in this thread. It is this focus on our users that led us to build JupyterLab in the first place, and is driving much of the work for 3.0, including the improved extension system, the debugger, and the classic notebook mode.

[ellisonbg]

To practice what I preach, here are the main user focused things that I view as being roadmap worthy:

• A mode that provides the effective experience of the classic notebook (doesn't have to be an exact copy, but should be close enough).
• More seamless extension installation, search, discovery, management.
• Real-time collaboration across all document types, with built in commenting and annotation.
• Improved auto-completion (likely through LSP integration of some sort).
• Improved large notebook rendering performance.
• Accessibility.
• Internationalization.
• Move the command palette to being a modal interface rather than the L panel.
• Supercharge the data grid.
• Enable in-application development of extensions.

[ellisonbg]

One way that I have started to prioritize issues in a user-centered manner is to sort them by reaction (comment or emoji):

https://github.com/jupyterlab/jupyterlab/issues?q=is%3Aissue+is%3Aopen+sort%3Areactions

Users would benefit massively if we started at the top and went down the list. The same sorting on the classic notebook also gives a similarly useful signal:

https://github.com/jupyter/notebook/issues?q=is%3Aissue+is%3Aopen+sort%3Areactions

This isn't perfect, but is a great start.

[meeseeksmachine]

This issue has been mentioned on Jupyter Community Forum. There might be relevant details there:

https://discourse.jupyter.org/t/building-uis-on-top-of-theia/5410/1

[choldgraf]

Just a note that I opened up https://discourse.jupyter.org/t/connecting-jupyter-and-theia/5410 to discuss the VSCode/Theia point more broadly because I think it's an interesting topic to dig into, but don't want to derail this thread w/ a protracted discussion here.

[choldgraf]

Just a note that if y'all are interested in prioritizing features by user +1s etc, you may be interested in some infrastructure that we're using in executablebooks/. This feature voting page contains a little table of issues across all executablebooks/ repositories, sorted by 👍 votes. We're going to try and encourage users to use 👍 in this way to vote for things that they want to see.

In case it's useful:

We retrieve the latest data from issues here: https://github.com/executablebooks/meta/blob/master/.github/workflows/retrieve_issues.yml

And here's the JS that creates this little table for use in the docs: https://github.com/executablebooks/meta/blob/master/docs/_templates/layout.html#L15