I believe this is a reaction to VS Code, which has supported this functionality for a while already.
e.g., quassel, an irc bouncer + client, used the same term since 2007.
JetBrains first major product was an addon to improve the suggestion abilities of Visual Studio, and VS Code is a downgrade even compared to normal VS
I'd not have described them that way.
Yes:
> distributed architecture. For more details check out the Fleet product page [link].
> [Fleet product page:] Distributed for flexibility
> Fleet’s architecture is designed to support a range of configurations and workflows. You can simply run Fleet just on your machine, or move some of the processes elsewhere – for example by locating the code processing in the cloud.
But then they say "distributed" so that would mean many backend machines, not just one. What on earth is the backend doing where one instance is not enough for one client? How could one client UI possibly need more than one backing instance? Sounds horribly inefficient.
Being able to develop on a huge beefy cloud instance, with managed background services, possibly with different architectures, from your laptop is huge.
> But then they say "distributed" so that would mean many backend machines, not just one.
‘Distributed’ doesn’t mean ‘many’ - it’s distributed over two.
> ‘Distributed’ doesn’t mean ‘many’ - it’s distributed over two.
A client<>server architecture is generally not considered "distributed" unless there is multiple servers involved, at least how the terminology have been understood until today, if it changed suddenly.
Usually when it comes to these kind of architectures, you'd refer to them as "thin clients", and the architecture has been around since mainframes if not longer.
Ok? What's that got to do if it's useful or not.
> Usually when it comes to these kind of architectures, you'd refer to them as "thin clients"
Ah well the difference here is the client does a lot more work - it's running the editor, the editing and the editor state, it's not just transmitting input and receiving drawing commands.
It means that the editor is split into two (or more) parts: a UI that runs locally on the machine you're sitting in front of, and a server that can run anywhere that does I/O, analysis, debugging, etc. It's useful e.g. if you're running Windows but target Linux (run the server-side in WSL), for dev containers (run the server-side inside a container with the toolchain for your project), or to develop in/for the cloud.
Presumably this is just easy to configure integrations so you can do things like run a build job on your CI/CD platform, push/pull artifacts, deploy applications, etc.
I assume this is their answer to that.
The older Jetbrains IDEA IDE is a monolithic local application. E.g. it does both UI navigation _and_ batch processing work like source code indexing.
Fleet is re-architected to be "distributed" aka "client/server" style into a "lightweight" frontend + "heavyweight" backend. E.g., the frontend does UI navigation and basic syntax parsing but the backend (which can be on remote servers) can do code indexing. As a bonus, the code index database can be shared by many frontends.
Code indexing for huge repos (e.g. 1 million LOC) takes a very long time and is one of the complaints of classical IDEA IDE performance being sluggish.
Take the "code indexing" example and extend it to other "heavy" backend batch processes like linting, testing, etc. The backend can also be in the cloud.
As a footnote, Fleet is also a competitive response to MS VSCode by having collaborative features. But my comment mostly answers the "distributed" aspect.
Related articles:
https://www.infoworld.com/article/3664112/jetbrains-fleet-th...
https://blog.jetbrains.com/fleet/2022/01/fleet-below-deck-pa...
crud app with frontend + backend is not distributed, but it definitely is client/server architecture
but that's just nitpick, iirc "distributed" means something different in their context
There are several meanings of "distributed" :
(1) multiple servers coordination like Google's MapReduce BigTable, Cassandra, Hadoop, etc
(2) describing a split client+server architecture that may have just 1 server. This usage of "distributed architecture" in discussions was more common in 1980s/1990s with the rise of client/server computing. Visual Basic CRUD, PowerBuilder, SAP R/3, etc.
In the Jetbrains article, if you do Ctrl+F search for all occurrences of "distributed", it is clear they're talking about meaning (2): https://blog.jetbrains.com/fleet/2022/06/fleet-below-deck-pa...
To answer your previous question: >I'm guessing they mean the architecture is decoupled, [...] but with a fancier word?
It's not a fancier word. Jetbrains is re-using an existing description of "distributed==client/server" that's been around for decades. It's just that "distributed computing" has been recently dominated by the examples of meaning (1) above.
They are reusing the IntelliJ backend, which I don't believe has out of the box support for a language not on that list
Ok, polygot makes sense, it supports more than just one language. But what does distributed mean in this context? You run the editor across many machines? What does that mean? Coming from a backend perspective, it quite doesn't make much sense. Thinking about it from a client-side perspective, I'm guessing they mean the architecture is decoupled, meaning basically plugins/extensions but with a fancier word?
Judging by the "Features Matrix" (https://docs.google.com/spreadsheets/u/1/d/e/2PACX-1vTWt9RlJ...), sad to see not a single non C-like language is being considered.