This looks really promising. But by far the biggest moat that Jetbrains is going to have to cross to get into VSCode territory is the plugin ecosystem. Personally I work on React projects so my first thought was: "is there a Prettier[1] plugin?". Looking through the landing page it looks like Plugins are in the works but until that is implemented, it's going to be hard adopting it.
ALSO I just noticed this but can someone (ideally from JetBrains) explain what this line means: "Requires login and periodic connection to JetBrains servers to verify the project" (specifically the last 3 words of that sentence). Quite frankly this line is extremely alarming, are you saying that you're scanning my project to make sure it's not a "professional" project? I'm going to assume this line means that they are checking the IDE and not your source but I won't be using this product until I get an explanation for this. You can find this at the very bottom in the licensing and pricing section.
JetBrains employee here, and I can clarify the point about “Requires login and periodic connection to JetBrains servers to verify the project”. If you are using Fleet in a Free (hobby) mode, we are verifying that the project comply with one of three criteria:
1. your project is local (no Git or Git Remote).
2. your project is public on GitHub.
3. your project is private but has less than 3 committers.
In this case, we will need a periodic connection to JetBrains servers to exchange information verifying that you can use Fleet for free, but in no way we would send any sensitive information, such as source code, file names, etc.
If you have Fleet license (paid, for example) there are no criteria checks at all, just the license verification with your JetBrains Account. And we plan to support offline usage similar to how it’s done for IntelliJ IDEA-based IDEs now (offline license keys, floating license server.)
Right now Fleet is in the EAP, and there are no licensing checks at all, they are not yet implemented, and we are not yet done with the verification workflow design.
> But by far the biggest moat that Jetbrains is going to have to cross to get into VSCode territory is the plugin ecosystem. Personally I work on React projects so my first thought was: "is there a Prettier[1] plugin?".
This just reinforces my feeling that a major driver behind VSCode's popularity is that people just don't know better [1]
1. Download WebStorm (or IDEA) and write some React in it. And Typescript. Refactor. Move code around. Use suggestions. It's leaps and bounds ahead of VSCode
2. Open settings, navigate to plugins, type in Prettier. Oh look, there's the plugin. An official plugin from JetBrains
I’m pretty sure the verification is going to just be the normal jetbrains license verification service stuff. Since if anything I use has been shut down or offline for about that long I notice it phoning home to check my account license.
JetBrains/IDEA/IntelliJ/whatever is the name now has quite a good plugin support.
I have looked into source codes of some and were horrified, but well, some people actually like Java and like that sort of stuff. Maybe I looked into wrong ones.
VSCode plugins seems to be easier to write, but maybe that’s because I know JavaScript already.
What made me switch to VSCode is that it’s generally snappier, IDEA has the “Indexing” mode that always takes forever
While annoying, all intellij EAPs (early access previews) are very cpu intensive, as they run in debug mode by default to create diagnostics and crash reports. Kinda similar like if you would keep the debugger open in your browser. Not sure if you can disable it, but thats the main reason why I stopped using EAPs for work.
But the ram is typical intellij, they take what they can get from the OS :)
I haven’t experienced this with Fleet after using it some months.
However, from using the other JetBrains tools the performance killer for builds and indexing libraries and documentation has typically been slow file system access.
These IDE even warn you when they detect this. I don’t remember seeing this warning in the Fleet preview.
A common solution is to disable aggressive anti-virus scanning for you project folder and some key application folders so it does not slow down the build.
Another cause is slow remote mounted file systems that you might have if you are using VMs, WSL or Docker.
If I remember correctly the docs have detailed information about this.
I probably have that many LoC between all the open files in VScode on an M1 and also love the performance. Only issue I've had so far is the Terraform Language Server running 18 threads at all times and grabbing too much CPU once or twice a month.
It still a beta, so I think it can be acceptable BUT it is not tiny.
What I like about VSCode is that is slick and lean without plugins, and with remote support it is still "light"...
And I was a huge Emacs, Emacs-org fan, so if I use VSCode because it gets the work done at the end of the day (TM)
> Fleet is our new distributed polyglot editor and IDE.
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?
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 full codebase 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 that also have the client+server diagram:
Distributed means you can run the editor UI and the actual backend on separate machines. One long-term goal of such deployments is developers just having a thin chromebook with the UI and the actual code being on a corporate server, like terminals and mainframes in ye olde days.
I believe this is a reaction to VS Code, which has supported this functionality for a while already.
> But what does distributed mean in this context? You run the editor across many machines? What does that mean?
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.
> But what does distributed mean in this context? You run the editor across many machines? What does that mean?
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.
VS code can connect to a machine running SSH and you edit locally, but all the code, extensions, etc runs on the other machine. It is not just a matter of copying the files back and forth either, and the experience is super smooth. If you open a port on the remote computer with your program, it will even be forwarded.
> 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.
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.
So I tried it out. I own a CLion license and have been using Jetbrains products since IntelliJ 3.0. It seems ok, but very very VSCode-ish.
I tried it with our Rust codebase and it seemed to be fairly competitive with CLion in terms of analysis. I didn't try any refactorings but I did notice that it doesn't have many of them. It was fairly snappy, felt more responsive than CLion. I was disappointed that even after I switched it to "IntelliJ" keybindings many keybindings still were more like VSCode than IntelliJ. I.e. Ctrl-N was still "open new tab" and not "jump to symbol" (have to do ctrl-shift-alt-N for that.)
Overall, I guess I'm curious where they go with it. I won't be trading in my CLion license, though. I am probably not the target audience; I suspect they're looking to capture customers who work in large corporations where VSCode is getting penetration as a hosted/fleet solution. With the default keybindings I suspect those coming from VSCode will find Fleet very comfortable.
For myself, I continue to give Jetbrains money for their IDEs, because as a company they do great work and give good value. I'm happy to modestly help pay the salaries of their employees. I wish them luck.
that's exactly what i was afraid of. them copying vscode. vscode is getting worse and worse IMo. its not even good at the one thing it initially excelled at - being fast. im not even talking about sluggish ui, just all the bullshit what's new and oh let me connect to ssh before you can enter a single keystroke.
but more importantly, i like that intellij is full featured and has proper windows and dialogs and keybindings. vscode tries to cram everything into a single textbox or ui element and it makes everything worse.
give me intellij but let me build a language backend in whatever language i want instead of forcing java on me. and also so that i can run it at my work which doesn't like code on laptops
Some neat info on the performance side of things, Fleet is using Skija[1] and Compose[2] as a rendering engine and UI framework. Skija is a java wrapper for Skia and still does not support the full API. Compose is still relatively new and has not had nearly the amount of man hours devoted to it as Swing. This is just a technical preview, I'm sure there will be plenty of optimizations to come. I think it's pretty exciting to see Skija being used for a mainstream project!
Fleet does not use Compose, but it does use Skiko[1], which also provides binding for Skia[2] (the native graphics library also used by Chrome & Flutter).
The main difference between the libraries is that Skija provides Java/JVM bindings for Skia, whereas Skiko provides Kotlin bindings for Kotlin/JVM, Kotlin/JS, and Kotlin/Native targets. Of course Skiko's Kotlin/JVM bindings can be used with other JVM languages, not just with Kotlin.
To use Fleet you have to download the JetBrains Toolbox. Really? Look, I'm a JB subscriber and have the toolbox, but Fleet should not require another app to launch or update itself.
Tried the private beta for a while, and although it was rough on the edges, I really enjoyed the ability to "enable" the smart mode - if I needed to do a quick edit in a file, without having to load all the IDE magic, I had an editor that was quick to start, and if I needed all the bits and bobs, I just clicked a button and off we went.
What kept me using their main products instead of fleet was the plugins that are available, that makes working just more enjoyable.
I just downloaded the Fleet beta from the App toolbox. First impressions is that it is very clean.
This is essentially Vscode but with Jetbrains language and refactoring engine.
Quick thoughts:
- It needs a bit more autocomplete e.g automatically close tags for React components
- GUI run configuration - they have made it so it uses a JSON file like Vscode to configure, GUI is quicker and easier (can still click run on gutter for package.json scripts so not that bad)
- Sometimes you want to use Vscode to make some quick changes/play around instead of firing up an IDE. Fleet replaces that for me
- Part of me think that Jetbrains should have created paid extensions for Vscode much like Resharper for Visual Studio
They should have went with kotlin-native from the start
EDIT:
Ok i gave it a try, so far very responsive, typing latency feels much better than vscode, overall i like the UX, they kept it simple yet very well organized
So if they are making progress to a distributed polyglot editor, then this mean that we'd be able to run multiple windows of Fleet working on different projects connecting to the same remote host? Is the connection mechanism basically the same as the Gateway product? If so, I wonder if this bug will ever gets fixed, or if it is a "works as intended" that you cannot run multiple projects on the same host? [1]
However this issue doesn't really apply if you create a VM per workspace either manually or the service that is provided...
Sadly no plugin support yet, and no VIM keybdings, that's a bummer.
I loaded up a JS project, but no support for prettier, LSP or eslint formatting means the Format Code feature doesn't match with the rest of the projects style, so I can't use it.
I'll keep it installed and revisit now and then (similar to Nova). Excited to see what they have planned
It’s so slow to startup. On a laptop with 11th gen i5, 16GB ram and a fairly fast NVMe SSD running Windows 11 and I see ~10s startup time. I really hope it succeeds but for a lightweight editor it’s just too slow to start.
Let's see if this competition eventually leads to one of them launching something as snappy as vim but with IDE functionalities.
VS Code is close but noticeably slows down as soon as you install many plugins.
With Fleet, newbies now have an alternative editor cum IDE.
Many people that were into programming in my University couldn't afford the kind of machine that would load IntelliJ or Jetbrains IDEs in short time.
Rooting for Jetbrains to put up a good fight and recover some market share :)
I would love this if it wasn't also built on the Java runtime. I hoped the "from ground up" rewrite to include a new much more performant backend that didn't burn resources. To be fair, I even think VSCode is too slow. I have been loving Helix Editor since it gives a great out-of-the box experience for terminal. But craving a better VSCode replacement. Had high hopes for Fleet, but I guess you can't teach an old dog new tricks.
No Ruby support out of the box - yet there is support for Java (a la IntelliJ), C# (a la Rider), Go (a la GoLand), C (a la CLion), Python (a la PyCharm), Web-anything (a la WebStorm & PhpStorm)...
RubyMine is a great IDE, worth paying for, but this looks like writing on the wall.
I've been browsing their site for a few minutes now and I'm still lost on what Fleet actually is.
It says it's a new IDE, built from scratch, sure, but isn't IntelliJ already the gold standard for many languages? What problems does creating an entirely new IDE solve?
Sorry for the unfamiliarity with JetBrains products. Is this architecture similar to VSCode’s? So the ide has a backend that can run remotely and a frontend client that can run in multiple environments including web? I remember a long time ago pyCharm had the ability to run the interpreter remotely. What are the benefits of pulling more stuff in the backend? Is it in order to be able to run the editor in different environments?
[+] [-] _fat_santa|3 years ago|reply
ALSO I just noticed this but can someone (ideally from JetBrains) explain what this line means: "Requires login and periodic connection to JetBrains servers to verify the project" (specifically the last 3 words of that sentence). Quite frankly this line is extremely alarming, are you saying that you're scanning my project to make sure it's not a "professional" project? I'm going to assume this line means that they are checking the IDE and not your source but I won't be using this product until I get an explanation for this. You can find this at the very bottom in the licensing and pricing section.
[1]: https://prettier.io/
[+] [-] MikhailVink|3 years ago|reply
If you have Fleet license (paid, for example) there are no criteria checks at all, just the license verification with your JetBrains Account. And we plan to support offline usage similar to how it’s done for IntelliJ IDEA-based IDEs now (offline license keys, floating license server.)
Right now Fleet is in the EAP, and there are no licensing checks at all, they are not yet implemented, and we are not yet done with the verification workflow design.
[+] [-] dmitriid|3 years ago|reply
This just reinforces my feeling that a major driver behind VSCode's popularity is that people just don't know better [1]
1. Download WebStorm (or IDEA) and write some React in it. And Typescript. Refactor. Move code around. Use suggestions. It's leaps and bounds ahead of VSCode
2. Open settings, navigate to plugins, type in Prettier. Oh look, there's the plugin. An official plugin from JetBrains
[1] https://news.ycombinator.com/edit?id=33176123
[+] [-] techdragon|3 years ago|reply
[+] [-] shp0ngle|3 years ago|reply
I have looked into source codes of some and were horrified, but well, some people actually like Java and like that sort of stuff. Maybe I looked into wrong ones.
VSCode plugins seems to be easier to write, but maybe that’s because I know JavaScript already.
What made me switch to VSCode is that it’s generally snappier, IDEA has the “Indexing” mode that always takes forever
[+] [-] Justsignedup|3 years ago|reply
Fleet seems like a new lighter architecture. Which is fantastic. My hope is they can actually bring the tools from their other platforms into this.
Otherwise... they might as well just sell a IDE plugin architecture for VSCode.
[+] [-] syspec|3 years ago|reply
[+] [-] keithnz|3 years ago|reply
[+] [-] insane_dreamer|3 years ago|reply
[+] [-] __warlord__|3 years ago|reply
1. My M1 temp went from 28c to 60c
2. CPU utilization to 103%?
3. It's using 3.29Gb of RAM
And it hasn't changed.
With a single python project with 3k lines of code.
VSCode sits at 280Mb and CPU temp around 28c.
Edit:
Vim + SpaceVim sitting at 17Mb :)
[+] [-] sod|3 years ago|reply
But the ram is typical intellij, they take what they can get from the OS :)
[+] [-] mjul|3 years ago|reply
However, from using the other JetBrains tools the performance killer for builds and indexing libraries and documentation has typically been slow file system access.
These IDE even warn you when they detect this. I don’t remember seeing this warning in the Fleet preview.
A common solution is to disable aggressive anti-virus scanning for you project folder and some key application folders so it does not slow down the build.
Another cause is slow remote mounted file systems that you might have if you are using VMs, WSL or Docker.
If I remember correctly the docs have detailed information about this.
[+] [-] nicce|3 years ago|reply
I guess the OS matters.
[+] [-] cguess|3 years ago|reply
[+] [-] ksec|3 years ago|reply
While I dont think VSCode is fast and lean when compared to Sublime or other Native Editor. It is well optimised.
I do wonder if Fleet could catch up or even exceed VSC in the performance / resources usage department.
[+] [-] dicknuckle|3 years ago|reply
[+] [-] geodel|3 years ago|reply
[+] [-] daitangio|3 years ago|reply
What I like about VSCode is that is slick and lean without plugins, and with remote support it is still "light"... And I was a huge Emacs, Emacs-org fan, so if I use VSCode because it gets the work done at the end of the day (TM)
[+] [-] hbn|3 years ago|reply
[+] [-] capableweb|3 years ago|reply
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.
[+] [-] jasode|3 years ago|reply
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 full codebase 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 that also have the client+server diagram:
https://www.infoworld.com/article/3664112/jetbrains-fleet-th...
https://blog.jetbrains.com/fleet/2022/01/fleet-below-deck-pa...
>frontend + backend is not distributed, but it definitely is client/server architecture
EDIT to clarify: the "distributed" is describing "distributed application" of client+server ... like 1st sentence of wikipedia : https://en.wikipedia.org/wiki/Client%E2%80%93server_model
[+] [-] kuschku|3 years ago|reply
I believe this is a reaction to VS Code, which has supported this functionality for a while already.
[+] [-] Denvercoder9|3 years ago|reply
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.
[+] [-] OJFord|3 years ago|reply
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.
[+] [-] tomjen3|3 years ago|reply
I assume this is their answer to that.
[+] [-] rockwotj|3 years ago|reply
They are reusing the IntelliJ backend, which I don't believe has out of the box support for a language not on that list
[+] [-] ellisv|3 years ago|reply
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.
[+] [-] unknown|3 years ago|reply
[deleted]
[+] [-] mi_lk|3 years ago|reply
[+] [-] cmrdporcupine|3 years ago|reply
I tried it with our Rust codebase and it seemed to be fairly competitive with CLion in terms of analysis. I didn't try any refactorings but I did notice that it doesn't have many of them. It was fairly snappy, felt more responsive than CLion. I was disappointed that even after I switched it to "IntelliJ" keybindings many keybindings still were more like VSCode than IntelliJ. I.e. Ctrl-N was still "open new tab" and not "jump to symbol" (have to do ctrl-shift-alt-N for that.)
Overall, I guess I'm curious where they go with it. I won't be trading in my CLion license, though. I am probably not the target audience; I suspect they're looking to capture customers who work in large corporations where VSCode is getting penetration as a hosted/fleet solution. With the default keybindings I suspect those coming from VSCode will find Fleet very comfortable.
For myself, I continue to give Jetbrains money for their IDEs, because as a company they do great work and give good value. I'm happy to modestly help pay the salaries of their employees. I wish them luck.
[+] [-] 8n4vidtmkvmk|3 years ago|reply
but more importantly, i like that intellij is full featured and has proper windows and dialogs and keybindings. vscode tries to cram everything into a single textbox or ui element and it makes everything worse.
give me intellij but let me build a language backend in whatever language i want instead of forcing java on me. and also so that i can run it at my work which doesn't like code on laptops
[+] [-] fayten|3 years ago|reply
[1] https://github.com/HumbleUI/Skija
[2] https://github.com/JetBrains/compose-jb
[+] [-] tsvetkov|3 years ago|reply
The main difference between the libraries is that Skija provides Java/JVM bindings for Skia, whereas Skiko provides Kotlin bindings for Kotlin/JVM, Kotlin/JS, and Kotlin/Native targets. Of course Skiko's Kotlin/JVM bindings can be used with other JVM languages, not just with Kotlin.
[1] https://github.com/JetBrains/skiko
[2] https://skia.org/
[+] [-] EddieRingle|3 years ago|reply
[+] [-] dangerboysteve|3 years ago|reply
[+] [-] topka|3 years ago|reply
[+] [-] tommica|3 years ago|reply
What kept me using their main products instead of fleet was the plugins that are available, that makes working just more enjoyable.
[+] [-] pjmlp|3 years ago|reply
[+] [-] monlockandkey|3 years ago|reply
This is essentially Vscode but with Jetbrains language and refactoring engine.
Quick thoughts:
- It needs a bit more autocomplete e.g automatically close tags for React components
- GUI run configuration - they have made it so it uses a JSON file like Vscode to configure, GUI is quicker and easier (can still click run on gutter for package.json scripts so not that bad)
- Sometimes you want to use Vscode to make some quick changes/play around instead of firing up an IDE. Fleet replaces that for me
- Part of me think that Jetbrains should have created paid extensions for Vscode much like Resharper for Visual Studio
[+] [-] Kukumber|3 years ago|reply
They should have went with kotlin-native from the start
EDIT:
Ok i gave it a try, so far very responsive, typing latency feels much better than vscode, overall i like the UX, they kept it simple yet very well organized
Much better than vscode already, congrats!
[+] [-] no_circuit|3 years ago|reply
However this issue doesn't really apply if you create a VM per workspace either manually or the service that is provided...
[1] https://youtrack.jetbrains.com/issue/GTW-813
[+] [-] artdigital|3 years ago|reply
Sadly no plugin support yet, and no VIM keybdings, that's a bummer.
I loaded up a JS project, but no support for prettier, LSP or eslint formatting means the Format Code feature doesn't match with the rest of the projects style, so I can't use it.
I'll keep it installed and revisit now and then (similar to Nova). Excited to see what they have planned
[+] [-] davb|3 years ago|reply
[+] [-] kaladin_1|3 years ago|reply
Let's see if this competition eventually leads to one of them launching something as snappy as vim but with IDE functionalities. VS Code is close but noticeably slows down as soon as you install many plugins.
With Fleet, newbies now have an alternative editor cum IDE.
Many people that were into programming in my University couldn't afford the kind of machine that would load IntelliJ or Jetbrains IDEs in short time. Rooting for Jetbrains to put up a good fight and recover some market share :)
[+] [-] onebot|3 years ago|reply
[+] [-] uticus|3 years ago|reply
RubyMine is a great IDE, worth paying for, but this looks like writing on the wall.
[+] [-] hampereddustbin|3 years ago|reply
It says it's a new IDE, built from scratch, sure, but isn't IntelliJ already the gold standard for many languages? What problems does creating an entirely new IDE solve?
[+] [-] TheChaplain|3 years ago|reply
[+] [-] barefeg|3 years ago|reply
[+] [-] bluelightning2k|3 years ago|reply
At least that's my understanding.