My gut sense from watching this for a while is that Fleet is a hedge by JetBrains against the risk of technical obsolescence for the IJ platform. VSCode introduced some key architectural changes and new UI which may or may not actually be better than their own products, but, if they
are better then JB would be left without a good way to respond.
So. They start Fleet. Different to their existing products in several ways:
1. Doesn't use the Swing UI toolkit. Uses a custom home-grown thing on top of Skia. Still JVM based though.
2. Runs heavy computation in a backend with a network protocol between that and the UI.
3. Has a VSCode style UI.
4. Uses JSON files for configuration.
Meanwhile they are also attempting to respond to the threat with IJ itself. So they have been prototyping a new VSCode style UI in IJ, implemented with Swing. I'm using it at the moment and I have to say it's actually quite nice. I was super skeptical at first. No, really skeptical. I liked the classic IJ UI, nice and dense, lots of features. But the new UI has won me over. It's been freshened up, is still just as efficient, looks nicer too. I think the success of that project (at least for users who want it) calls into question a big part of the Fleet value prop. Also they've been adding remote development/backend support into IJ itself, a lot of that is being built around their pair programming Code-with-me thing which is a fairly sophisticated data sync protocol under the hood.
So JetBrains is setting themselves up here for some serious product management pain. The IJ team are rising to the challenge and it's not at all clear that VSCode will retain its competitive advantages beyond price within a year or two. Swing is not turning out to be the millstone around their neck they apparently feared, and the new UI feels modern and fast even though it's based on this old toolkit. Meanwhile the VSCode architecture in many ways doesn't make sense and is clearly the result of asking "how can we build an IDE within the constraints of a web browser" and not "how do we build a great IDE"? The client/server architecture is quite painful in all kinds of ways compared to threads+locks, devs tend to have good enough machines for code indexing and comprehension, and IntelliJ index builds can be outsourced to the cloud anyway. If IJ starts to really nail the Gateway stuff (see the recent Google Cloud Workstation announcement), what does it leave Fleet for? And how would they resolve these two competing products?
If I were running JetBrains I'd be tempted to keep resources assigned to Fleet relatively limited and wait to see if it takes off organically, whilst simultaneously closing the gaps in IJ with VSCode. This does not just mean the features listed so far but also means getting serious about their "lightedit mode" and plugin API. JetBrains have a cultural problem in which they historically have actively resisted anything resembling code documentation, thinking that code should be self-documenting. Their plugin API docs are still poor and incomplete even after many years partly as a consequence, and although the JVM can run many languages, JB only really support Java and Kotlin for plugin dev. VSCode has taken off partly for the same reason NodeJS and Electron did - it lets web devs apply their skills in a new context. Language server took off because it lets obscure language communities use their own language to make IDE plugins instead of needing to use Java. Add Graal to IntelliJ, make JS a first-class plugin language and explore how to do non-network based integration with other languages. It would help them a lot.