Last Wednesday JetBrains, the creator of the popular IDE IntelliJ Idea, announced that they had made JetBrains Fleet available to the public for preview. Many of you have been surprised by all the effort that JetBrains has been directing to Fleet and also all the noise around Fleet in the community. Let’s go through some of the details and reasons behind it.
Introduction
The main reason for building this new IDE seems to be in response to a new trend initiated by the popular VSCode text editor.
VSCode is a very lightweight text editor which allows you to “enhance” it by adding extensions that you can find in the extensions marketplace. Some developers don’t even need/like features like autocompletion or code analysis, therefore they feel more comfortable working with a text editor.
Having some built-in tools added to a text editor to make it more coding-oriented, but still being a text editor, is the preferred option for many developers nowadays.
Also the support for remote development in VSCode has been quite strong and widely adopted by many developers, either using remote machines or Docker containers running locally with a consistent development setup shared among every developer in the company/project.
Some companies are moving developers away from local development environments to provision reusable virtual machines in the cloud that can be easily recreated at any moment. This is a huge advantage for them, as consistency across environments is key to avoid unexpected issues and wasting time investigating these discrepancies. Also this allows companies to spend less money in laptops, developers can now use lightweight laptops like Macbook Air and just use lightweight code editors connected to a virtual machine.
According to the trends, VSCode is close to the top among the most used IDEs at the moment, also being the fastest growing IDE among the top ones. Let’s look at this index of TOP IDEs for example:
As you can see VSCode is second in that list, growing a 1.7% in the last year. IntelliJ is in the sixth place but still growing a 0.9%. What shocked me was that Eclipse is still in the third place, although it has decreased a 1% in the last year (no offence to current Eclipse users 😉 ).
Let’s take a closer look at Fleet now and see what it brings to us.
Installation
First of all, to be able to install Fleet you’ll need to install JetBrains Toolbox. It will show Fleet in the list of “available” applications to install and once you install it you should be able to see it in your installed apps list as shown in the screenshot below taken from Toolbox.
Once installed you can click on Fleet item and it’ll start for you. I’d say it starts considerably quicker than IntelliJ Idea in the first place, so that’s already an improvement.
First impressions about JetBrains Fleet
Once you see the interface for the first time and open a Kotlin/Java project, initially you might feel a bit confused because it doesn’t seem to recognise code syntax or even JUnit tests. For example, initially it won’t show the “play” green button that it normally shows up on JetBrains IDEs when it detects a test.
It’s hard to spot what to do initially to be able to run tests and compile code, although if you right-click on any of your tests it’ll show a very useful hint:
It’s suggesting you to enable something called “Smart Mode“. If you need a guide to take you through all the things you need to do, including enabling Smart Mode, you can read “Getting started with Java” docs. Let’s take a look at the new “Smart Mode“.
Smart Mode
When you enable “Smart Mode” what the IDE will do is to start the backend server, which is the same backend that IntelliJ uses according to some sources. This backend service will allow you to do things like live compilation, autocompletion, code analysis, etc.
Although it was confusing for me at the beginning to find out how to enable all of this, considering that I’m a Kotlin/Java developer, this is actually a very nice feature for developers in general.
Some developers I know don’t even use a live compiler, probably because of the nature of the language they use or the kind of work they do. For example, I know a Quant Developer that works with Python and he basically uses a nice text editor and runs his program to detect compilation issues at runtime; we have to remember that not all languages are compiled languages. Python is an interpreted language, therefore it will get compiled at runtime.
This means that some developers feel more comfortable sometimes with pure text editors, in Java/Kotlin this would be impractical for various reasons.
In order to enable “Smart Mode” you’ll have to find a small icon that looks like a thunder at the top-right corner of your IDE. I have to say that this is quite difficult to spot at the beginning by the way.
When you click on that icon it will allow you to enable smart mode:
Once we enable the “Smart Mode” we can see how things change suddenly. The first thing you’ll notice is that the smart mode icon has been highlighted to indicate that it’s now enabled.
Compilation errors will also be shown immediately once the indexes have been built and tests will be detected, so you can run now from your GUI. How can we run test in Fleet? Let’s find out.
Run Configurations/Tests
There are two ways to run tests: either by clicking on the play button that will show up on the left hand-side or by creating a new configuration. You can check how to create a run configuration here.
In the three images shown below you can see the steps to create a new run configuration: click on play button on the top-right corner, “Create Run Configuration in run.json…” and edit your run.json to include your new run configuration. Also please notice that by default is detecting my Spring Boot application, so I can start my application without creating a new configuration.
The main problem I see here is that you need to know the syntax for the run.json file beforehand, that generates confusion initially. I had to check the documentation to understand how to create a run for my tests, the result was something like this:
{
"configurations": [
{
"name": "gradle test",
"type": "gradle",
"tasks": [
"test"
]
}
]
}To be completely honest, initially I was disappointed but probably because we all don’t like changes in general. After a while I realised that this is actually a very good idea. Why do we need to have hundreds of run configurations for each language and tool available by default? Even if we’ll never use 90% of them!
In my opinion the new design of the run configurations is much simpler and avoids adding unnecessary complexity to the editor. Developers know the tools they use and they should be able to define the ones needed just one time and always reuse it. The only doubt I have now and something that I’ll have to look at in the near future is how to check or define shortcuts, as they don’t get suggested on any of these actions. We’ll look now at the panels configuration!
Panels
Another aspect about Fleet I like is the simplicity to manage the tool panels. You can expand or collapse your tool panels by selecting the buttons on the top-left corner. The bottom and right panel are collapsed by default, if you click on any of them you’ll see a by default empty panel that allows you to add only what you really need to use.
I think this is a big improvement as well, remove all the clutter and give the developer the freedom to enable only what they want is always good! If you click on “Open Tool” it’ll give you some options and you have complete freedom on where to place your tools. I think this is amazing!
Settings
Another aspect that has changed substantially in Fleet is the settings management. IntelliJ has so many settings that it’s hard sometimes to find what you’re actually looking for to modify.
Fleet has modified the settings in a way that it can now fit in a single page. Also the project settings are now on the same page in a new tab, so you don’t have to be jumping off from preferences to projects settings as we have to do on IntelliJ.
We’ve gone through some of the key aspects of the user interface in Fleet, let’s look at the performance aspects of this new IDE.
Performance
In terms of performance Fleet seems to be faster in general. For big projects it’ll still take a few minutes to update indexes and have the IDE ready the first time, as the backend is the same that IntellliJ currently uses.
If we look at the memory usage it doesn’t look low. If we open VisualVM we’ll see that Fleet runs two processes, backend and the IDE itself.
When we look at the backend it takes around 1300MB of heap space for a big size project. This should be similar for IntelliJ though, we’ll check that later. Please note that these metrics are when the IDE is just providing live support to our codebase and it’s not running tests or any application.
With respect to the UI, the memory usage is not low either, considering this is just the GUI. In total Fleet is using 1.6GB of memory in our host.
If we compare these metrics to IntelliJ IDEA, we can see that Fleet is consuming more memory. Something quite disappointing, as I was expecting to find a lower memory consumption for an IDE that it’s supposed to be more “lightweight“. However, CPU looks higher when indexing files on IntelliJ, what could indicate that garbage collection activity is much higher on IntelliJ.
Conclusion
In general we think that Fleet has made some good steps towards what the goal show be. However, we think there’s much work to do and clarifications to be made in terms of extensibility for example. At the moment is unclear if developers would be able to add extensions in the same way as VSCode does. Also performance could be improved to achieve a better user experience.
Please keep in mind that Fleet is currently in public preview, so it’s not in a mature state yet or even a deliverable state probably. That means that it might be a bit early to fully understand the real possibilities of Fleet.
If you are interested in more articles about Kotlin or Java, you can find them in the following links: Kotlin articles and Java articles.
That’s all from us, we hope you’ve enjoyed this initial review of Fleet. As always, we hope to see you back soon and please follow us if you enjoy reading our articles!
You must log in to post a comment.