JetBrains Youtrack 上一个著名的任务项 IDEA-226455: Remote Development Support 昨天被其指派人 Kirill Skrygan 修改状态为「已修复」；Issue 的原始诉求是希望 JetBrains IDE 支持远程文件编辑、构建运行调试，及支持容器化的开发调试环境；并明确提到期望对标 VSCode 的远程开发功能。
从这个 Issue 长达两年的时间线下的密集评论，可以看出「远程开发」从一个充满猎奇感的锦上添花特性、到成为严肃的生产级需求，用户贡献了大量的实际场景；也能感受到 JetBrains 的态度转变：
- 从最早质疑用户需求的有效性，及建议一些妥协方案（sshfs / rsync）
- 产品上多点发力提供解决方案（Run Targets / Projector / Code-With-Me）；实际还是希望在 IntelliJ 产品框架下解决问题，Remote 成色不足；当然 Code-with-me 出发点更多是解决协同研发场景
- Issue 的 Assignee 从前任 CTO Yole 换人成 Skrygan、提出的 Gateway 方案（分离 IDE Backend 和 Thin Client），终于回应了群众们提到的 IDE Tools 去 Local 化的本质诉求
- 推出对标 GitHub Codespaces 的 Space Dev Environments，绑上了自家的一站式协同全家桶产品，也是判断下一代云研发除了 DevTools 编程界面、还有云和协同 SaaS；布阵上更接近于微软家的 VSCode+GitHub+Azure
- 近日 JetBrains 首席段子手 Hadi 高调发布下一代 IDE 产品 Fleet，终于开始放下执念——用自家的 Kotlin 打造下一代 IDE Framework，不再基于 IntelliJ Platform 这一功勋卓著、登峰造极的 IDE 底座（IJ 支撑了 IDEA / PyCharm / Goland 等一票商业化 IDE 产品线，并同 Google 合作打造了 Android Studio）
虽然过程中有一些领先者面对挑战的仓促感，但也能看到 JetBrains 严阵以待的决心，毕竟 JetBrains 作为二十年前 Borland 败给微软的历程的亲历者，想必不愿在云时代的研发工具转型浪潮中败给微软。
JetBrains 这里的几位人物也都是传奇，Yole (Dmitry Zhemerov) 是一手打造 IntelliJ Platform 的巨匠（一些历史故事），Skrygan 是 Rider 的负责人，推荐文章 JetBrains OpenDay 2019 、也可旁观猜测为什么是 Skrygan 来领导这个事情
Quote: https://youtrack.jetbrains.com/issue/IDEA-226455#focus=Comments-27-5125731.0-0
- Our remote development support will not be included for free in Community Edition. We’ve been competing against free products for the entire time that JetBrains has been around, and so for millions of our users have been able to justify speeding money on our tools when free competitors (including VS Code) are available
- The new remote development effort is based on Code-With-Me. Projector will remain relevant in certain scenarios (where you need a browser-based client, for example for tablet user), but for normal desktop use we expect this new tool to replace Projector
2 Major flows in overall “Remote Development” solution:
- Client-to-server flow (mostly used for individual devs with dedicated remote DevMachine)
- Starting from your client machine, you can connect to your dev server via ssh, browse the filesystem, download / deploy / launch the necessary IJ server against remote src; then connect to this headless server and remotely work with your project. All of that is done in UI and accessible from:
- Classic thick IntelliJ IDE installed on your laptop
- Gateway (“thin IntelliJ”) which can only connect to a variety of remote backends and has noting to do with local src
- Starting from your client machine, you can connect to your dev server via ssh, browse the filesystem, download / deploy / launch the necessary IJ server against remote src; then connect to this headless server and remotely work with your project. All of that is done in UI and accessible from:
- Server-to-client flow (presumably, this flow would be preferred for orgs and companies which want to deploy remote DevServer for their employees)
- Admin launch the remote DevServer on a server Linux via the CLI, obtains a link
- Use this link on a client’s machine to connect to an already launched dev server
YouTrack 上还有一个神贴 Support for VS Code’s Language Server Protocol，是一位 Eclipse Theia 阵营大佬提的（Sven Efftinge，GitPod CEO），有点砸场子的味道。LSP 是微软家主导的协议，解耦 Language Tools 和编辑器，依托 VSCode 大获成功。让 IntelliJ-based IDE 来支持 LSP，类似于建议支付宝迁到腾讯云基础设施（比喻），以至于 Yole 如此回应：Language server support cannot be combined with existing IDE tooling; it’s an either/or proposition. If IntelliJ used the language server for Java, it would lose 95% of its feature set for Java development.
Sven 几年前创立了 GitPod，最近一次采访 Erich Gamma，聊到了 VSCode 从 Eclipse 吸取了哪些经验：
- VSCode 的插件都是运行在独立进程，可以确保 VSCode 健壮性（避免因插件 Bug 拖垮 VSCode）和 UI 响应性
- 插件进程同 VSCode 进程通过标准协议（如 LSP、DAP）通信，大大丰富了插件实现的技术栈，比如可以用 C# 写 C# 的语言服务器（Language Server），只要实现 LSP 接口就可以。与之相反的是，为 Eclipse（其实包括 IntelliJ 家族 IDE）写一个 C# 语言扩展插件，需要用 JVM 语言实现，造成极大的开发难度
总结即插件架构及协议设计上的先进性，导致 VSCode 生态远强于 Eclipse（包括 IntelliJ）生态。微软非常擅长于主导协议标准，比如 devcontainer 也差不多是远程开发的标准 Spec，以至于社区里的其他玩家都只能跟随致敬
