First Impressions Of JetBrains Fleet

With the recent preview release of Fleet by JetBrains there was a chance to give the next generation IDE a spin. Many Software Developers view the IDE as a competitor to VS Code, which already has significant market share in the Software Development tools market. JetBrains is one of the few companies that operate in this market who would be able to challenge VS Code. VS Code already has a head start on Fleet with VS Code being around since 2005 (initial release on April 29), and there is a large ecosystem of plugins available. Many software development tools even use VS Code as a base, via a third party plugin (eg PlatformIO IDE).

Performance

Startup time with Fleet is significantly faster than IntelliJ (eg 3s for Fleet, 10s for IntelliJ). This makes using Fleet as a Programmers Text Editor viable for quickly editing a Kotlin source file for example. The key for significantly quicker startup time is with having Smart Mode turned off, and only turning it on when you need an IDE instead of a Programmers Text Editor. CPU usage at times is too high for what is supposed to be a lighter weight IDE than IntelliJ for example. Exiting Fleet takes longer than it should, although it is currently in a preview version therefore that issue should be resolved quickly in the next version.

When Fleet is contrasted with IntelliJ one would notice that switching between files is noticeably faster. IntelliJ will often have some annoying short delays when switching between files. Indexing in Fleet takes just as long as IntelliJ. It would be nice if indexing was a much faster process. Overall Fleet is noticeably snappier than IntelliJ.

One big performance disappointment with Fleet is that the IDE uses far too much RAM for an IDE that is supposed to be significantly lighter on resource usage than IntelliJ. On Linux for example, the IDE will easily start at around 850 MB, and it doesn’t take long for the IDE to reach 1 GB. RAM usage MUST be significantly lower for Fleet by the time the first stable release arrives!

User Experience

First impression of Fleet’s UI is one of minimalism, with the UI being very clean and uncluttered. One odd thing about the UI is the absence of a menu bar, yet menus are crammed into a toolbar button which is non standard UI design. If a desktop application is going to have lots of menus then they should be in a toolbar, not crammed into a toolbar button! At the end of the day Fleet is supposed to be a desktop application, not a mobile application. While I understand the design goal is for the UI to be minimal, that doesn’t mean a menu bar can’t be included with an option to hide it if needed. Icons are very badly designed to the point where it is difficult to distinguish between them (lack of colour and discoverability).

Installation of Fleet has to be done via JetBrains Toolbox. This means installation of Fleet on all supported platforms is non standard. Proper installation of programs on Linux for example, is done either through packages (via a Package Manager), or FlatPak/Snap (with everything distributed in self contained file). It is very puzzling why Fleet is installed through JetBrains Toolbox. No other application does anything similar when it comes to installation. JetBrains is reinventing the wheel when it is unnecessary to do so.

No visual indicators are provided in the UI to show a remote session in use (eg a connection to a remote device via SSH), and the following information about the remote session:

• Session type
• Address
• User
• Session health
• Average latency

Even more odd is the absence of a button in the toolbar to disconnect a remote session. When starting Fleet no one expects the IDE to retain the last open remote session, which is odd (unwanted) behaviour. Remote session management hasn’t been made a standard part of the UI.

It is disappointing to see that Fleet has very poor UI scaling support with extremely limited options to adjust UI scaling. No UI font settings are available, which would significantly improve UI scaling if present. Instead one has to use the zoom level as a messy workaround that doesn’t work very effectively. The Terminal pane exhibits broken scrolling behaviour. When typing in the pane it doesn’t automatically scroll to the bottom. Content copied from the Terminal pane cannot be pasted into a different application (eg Geany). No permanent scroll bar is present in the Terminal pane. The Structure pane is missing. Without it there is no way to visually show defined symbols in a file, and provide quick navigation.

Kotlin Support

Kotlin is supported out of the box, and is currently the language with the highest level of support. Gradle Kotlin Script support is flakey (very slow auto complete, syntax checking doesn’t work in a remote session etc). Indexing isn’t cached for Kotlin Source, and Gradle Kotlin Script files. Some basic code editing features are provided for Kotlin projects. Do note that Fleet has a limited number of code editing features for Kotlin, since Fleet is supposed to be a lighter weight IDE than IntelliJ. Smart Mode will need to be enabled to get access to many code editing features. Currently there is no documentation on which code editing features that require Smart Mode to be enabled.

It is unknown how far Kotlin support will extend with Fleet; does it cover all the Kotlin development platforms (eg Kotlin WASM)? Templating isn’t available for Fleet, which would greatly save time in creating a fresh Kotlin project (eg a full stack Kotlin web project), or inserting a complex Kotlin code snippet. Already Kotlin support is significantly better than what VS Code provides (via an unofficial third party plugin) by a wide margin. VS Code’s Kotlin support is utter rubbish to the point where even basic syntax highlighting doesn’t work properly (eg for string interpolation), and Kotlin language support lags far behind. One can say that VS Code provides a very low bar for Kotlin support that can be exceeded easily.

Fleet seems to be a best fit for Kotlin developers that are developing Kotlin projects that aren’t JVM or mobile (Android/iOS) based. Especially if the Kotlin project is targeting a native platform (via Kotlin Native) like Linux/Embedded Linux for example. Remote development of Kotlin projects with Fleet is likely to exceed what IntelliJ provides in the short, or medium term. IntelliJ’s remote development support is mainly limited to Kotlin JVM projects.

Kotlin Native

A valuable opportunity was missed to support Linux development on an ARM64 device via a remote SSH session with Kotlin Native. The Fleet team should have heavily pushed the Kotlin team to release a version of the Kotlin Native compiler for the Linux ARM64 platform. Having this would establish a significant reason for using Fleet, especially when it is well known that Kotlin Native support is very limited in IntelliJ. Really evident when doing high level Linux/Embedded development targeting ARMv7/ARMv8 devices using IntelliJ. An experience that is best described as having one hand tied behind your back with crippled legs, wondering around in a black abyss trying to find a clear path through to the other side, all at the same time you are asking for assistance yet no one hears your cries for help (dead silence).

Support is missing for knm (Kotlin Native Mapping?) files; i.e. no syntax highlighting. Kotlin Native Definition files (.def) aren’t supported. Debugging a Kotlin Native project is a complete no show. No plans have been laid out on what debugging tools (memory analyser, local/remote debugger, profiler etc) will be provided by Fleet for Kotlin Native projects.

If Fleet is used to handle a Kotlin Native project then C support is available, but is unofficial and limited to syntax highlighting only (can’t build C libraries, no syntax checking, missing go to definition etc). Enabling Smart Mode doesn’t result in improved C support. The C language should be officially supported by Fleet, but for some strange reason it isn’t even though C++ is officially supported. Much more work needs to be done to ensure there is solid C support, which even works straight out of the box for Kotlin Native projects through tight integration.

Conclusion

Although it is early days for Fleet it has become evident that the IDE cannot compete with VS Code in its current form. With the way things are progressing Fleet will only gain significant momentum with Java/Kotlin developers, and some other JVM developers, especially when they need more advanced remote development support that IntelliJ doesn’t provide. Also Fleet will appeal to the same developers when they need a more lightweight IDE, or a basic Programmers Text Editor.

Turning a Programmers Text Editor into an IDE with a click of a button is an excellent idea, which in practice works reasonably well but needs significant fine tuning to optimise the performance. Without a plugin system Fleet’s support for various technologies is very limited. The Free version of Fleet requires constant phoning home, which is unacceptable for an IDE which is supposed to be competing with VS Code, and makes Fleet unusable in environments where Internet is unavailable, or is heavily locked down (for security/privacy reasons). JetBrains need to be reminded that the Community edition of IntelliJ can be used completely offline, why should Fleet be any different with the Free version?