RFC For a VSCode PDE

Hi!

We have a RFC (request for comment) around making the PDE a fork of VSCode.

This is a pretty intriguing proposal, but we would absolutely love to hear what the community thinks about it!

How would this make your life better? Worse? What kinds of challenges and opportunities do you see if we were to commit to moving in this direction? Would you help with this effort? :slight_smile:

I’m not good at ceremonious letters to the community, just go check out this RFC okay!?!? Let us know what you think ok!??!?!!?!

EDIT:

I want to add some additional details about the motivation behind this proposal quoting the RFC:

  • Ease our maintenance burdens by leveraging a larger open source project
  • Use a newer front-end UI toolkit to access a larger pool of potential contributors
  • And most importantly, continue to provide a UI that is friendly to beginners and artists who don’t want to write their own build scripts, as the PDE has done for nearly 25 years!

Moon :woman_mage: :broom:

Maybe as an experimental venture for those who want to go there, but in my opinion it would be a mistake to abandon what you already have without clear evidence that the competition is better. The current editor is very user friendly and simple to use. I’m skeptical that anything that comes from the other side would be easier to use. In my experience the learning curve for apps from big corporations is pretty steep and I’m afraid that you would lose your appeal to beginners, artists, and part time programmers who like ‘easy’. On the other hand, advanced programmers might want to try the proposed new venture.

Hi! Some thoughts:

  • Personally, I avoid anything Microsoft related. I don’t trust the company (I’ve used their products, also Mac and Linux). Here’s a list of controversies. How much is choosing vscode vouching for Microsoft?
  • How much effort would it be to maintain a fork? Would Processing need to be updated for every vscode release?
  • Would the Processing maintainers know the vscode source well enough to notice when unwanted features are added to it, which should not land in Processing? How much effort will it be to strip new unwanted features?
  • Processing will not have a say on the direction the IDE is developed.
  • See Visual Studio Code CVEs and Security Vulnerabilities - OpenCVE . Would such issues affect Processing? Would the fork allow installing any extensions, including harmful ones?

This user would stick to an old version, but I guess others might enjoy the new.

Majority of the newest IDEs are compatible w/ VSCode extension ecosystem and have its LSP framework support.

I’ve asked this using Gemini AI btW:

Which IDEs offer VSCode compatible addons?

Because VS Code’s ecosystem is massive, several other IDEs and code editors have adopted compatibility with its extension API. This allows developers to use VS Code themes, language servers (LSP), debugger adapters (DAP), and keymaps outside of the official Microsoft environment.

The primary IDEs and editors that offer VS Code-compatible addons include:

1. Cursor & Windsurf (AI-First Standalone IDEs)

These are modern, AI-centric IDEs built directly on a fork of VS Code’s open-source core (VSCodium/Code - OSS).

  • Compatibility: 100% Native. Because they share the exact same foundation, they natively support nearly all VS Code extensions.
  • Extension Access: You can import your entire VS Code profile, themes, and extensions with a single click during setup. They feature their own marketplaces that mirror the VS Code Marketplace.

2. VSCodium (The Pure Open-Source Alternative)

VSCodium is a community-driven, freely-licensed binary distribution of Microsoft’s editor without the proprietary telemetry, tracking, and branding.

  • Compatibility: High. It executes extensions identically to VS Code.
  • Extension Access: By default, it uses the Open VSX Registry (an open-source alternative to Microsoft’s marketplace) rather than the official Microsoft Marketplace due to licensing restrictions. However, you can manually install .vsix files or configure it to point to Microsoft’s gallery.

3. Eclipse Theia (The Cloud & Desktop IDE Framework)

Theia is an extensible, open-source IDE framework designed to run both on the desktop and in the browser (it powers platforms like Gitpod and Google Cloud Shell).

  • Compatibility: High. Theia was built from the ground up to support the VS Code extension protocol natively.
  • Extension Access: Like VSCodium, it relies on the Open VSX Registry for hosting and installing plugins.

4. Positron (The Data Science IDE)

Developed by Posit (the creators of RStudio), Positron is a relatively new, next-generation IDE tailored for data science (Python and R).

  • Compatibility: High. It is built using the Eclipse Theia framework, meaning it inherently supports the VS Code extension architecture.
  • Extension Access: It leverages the Open VSX Registry for installing compatible extensions seamlessly.

5. Neovim (via coc.nvim)

While Neovim is a terminal-based text editor rather than a full-scale Electron app, it can achieve incredibly deep VS Code compatibility.

  • Compatibility: Medium-High (Language/Autocompletion features only). By using the coc.nvim (Conquer of Completion) plugin, Neovim can host and run full VS Code extensions.
  • Extension Access: It focuses heavily on language servers and autocompletion extensions, allowing vim users to use the exact same language intelligence as VS Code.

6. Lapce (The Rust-Based Performance Editor)

Lapce is an ultra-fast, native code editor written in Rust with a UI built entirely on GPU acceleration.

  • Compatibility: Partial/Growing. It supports the VS Code Language Server Protocol (LSP) and is actively building out a plugin system that leverages VS Code’s architecture to capture its ecosystem.

A Note on the “Marketplace Catch”:
Microsoft’s official VS Code Marketplace Terms of Use restrict access exclusively to official Microsoft products (like VS Code and Visual Studio). Because of this, independent IDEs (like VSCodium or Theia) pre-configure their systems to use Open VSX. While Open VSX has almost every major extension, if a niche plugin is missing, you can usually download the .vsix file from GitHub and manually drag-and-drop it into the alternative IDE.

yeah definitely agree with the “avoid microsoft” camp.

i’ve pivoted to VS Codium but it has some weird bug with iCloud that makes it super laggy.

Right now though there are already a few Processing / p5 extensions in the extension marketplace, so why would a full fork be needed if the extensions already exist?

Processing: GitHub - processing/processing-vscode-extension: This extension provides support for the Processing programming language in Visual Studio Code. · GitHub

p5.js: GitHub - IrtizaNasar/p5-2.vscode: A Visual Studio Code extension that quickly generates new p5.js 2.0 projects with a clean, minimal setup. Perfect for artists, designers, educators, and anyone getting started with creative coding. · GitHub

Both are available in VS Code marketplace and in OpenVSX.

Hello @moon,

I fully support the Enhancement details in the RFC.

It is my understanding that the RFC prototype is a fork of the open‑source VS Code codebase combined with the Processing core, Java and App with the potential for better future integration with a modular approach.

I would also like to see the decoupling of the CLI so that it can easily be integrated with other code editors of my choice.

The RFC states:

The Processing CLI currently requires the whole PDE to already be installed on the user’s computer, so we’ll want to work toward making the CLI standalone to remove the dependency on the current PDE implementation.

processing4/BUILD.md at main · processing/processing4 · GitHub
states:

Processing consists of three main components: Core, Java, and App. The Core is independent, while Java and App depend on it. Currently, Java and App are interdependent, but efforts are underway to decouple them.

Google Gemini interaction:

If the Processing core and CLI are isolated into separate, downloadable modules under the LGPL (or a similarly structured copyleft license), a VS Code fork released under a permissive license (like MIT) can pull them in dynamically without triggering license contamination.

As long as the VSCode fork interacts with the core/CLI via a clean separation, such as standard CLI process calls, IPC, or dynamic linking, the permissive editor code and the copyleft processing runtime remain legally distinct.

Go for it!

References:
Visual Studio Code - Wikipedia

:)