Anyone wondering whether JetBrains IDEs are still worth it - absolute yes from me. VS code is a UX mess by comparison. Webstorm can be tricky to configure with Typescript but once it’s setup my goodness it’s good.
I use another big tool which is around 20 years old, and that can do everything and a ton more from a single screen at the same speed or faster, with greater integration.
Yet people don't touch it because it's old, complex, looks ugly and its UI is too dense.
Oh, I forgot, it also includes a learning curve, but the same people devote their lives to "rice" their Vim installations for months.
Example: now that I'm a solopreneur I use JetBrains DataGrip, and overall I am very pleased with it. But I couldn't have it on my previous two jobs. One of the jobs restricted my work computer to only allow MySQL Workbench (arbitrary Powershell scripts also were allowed, of course), and the other one didn't want to pay for a licence, no matter how much I pleaded.
So before I had to make due with (admittedly) inferior tools because they were free and available as the lowest common denominator in the general workplace.
Being comfortable with the tools affects a large part of my productivity, and I'm more productive with a crappy-but-familiar toolbox than I am with the unknown spaceship.
Again, the tool I gave as an example has integrated configuration snapshots, and if something breaks I can revert to a config 2 seconds or 2 years before, including component versions installed at that time.
To be honest, I probably used that feature at most two times in the last 20 years.
Workplace restrictions something off-limits and I can't tell anything about. The people I gave examples are persons I know and they have no such restrictions in place.
Switching from a large, complex tool that includes a learning curve is expensive. You set a high bar for switching from Eclipse because you are used to it, paid a learning price and are productive in it. And you are right. But that also means that picking such a tool from a multitude of options should be done after careful consideration, which is exactly what using smaller tools provides.
On a somewhat related note, I want my professional software to only provide a (great) speedup of development. I want them to only do what I could do without them (even if it takes a week instead of a minute). This means I can often look at things that fail to work and understand what is failing. This is also helped by new engineers starting with smaller tools and building up to integrated, distributed tools only after knowing how individual elements work and can be connected. Integrating with a (good) big tool is then not a fight as it brings a "wow" moment -- "instead of doing all this by hand I can do it with a few mouseclicks!". My 2c.
In this case, it's not. Eclipse put Integrated into IDE, but doesn't subtract transparency in the process. You can see what it does, tweak every step meticulously if you want, and return to defaults with one click, if you prefer.
What this transparency brings is mental flexibility and understanding. Do I want or need to switch? I'm doing the same thing in Vim or KATE of BBEdit in 15 minutes. Maybe I stumble with a couple of shortcuts, but that's not a problem.
The funny thing is I see the compiler command every time I press build, so it's burned in my memory after a day. While I can read valgrind outputs and understand what it says, Eclipse highlights the lines automatically, so I'm faster. While I can gnuplot performance graphs, Eclipse auto-builds them so they are on my desktop after a 10 hour torture run.
In my case, Eclipse enables me to carry a whole toolbox and more in a single folder, yet all the tools it uses and what it does is so transparent that I can switch away on an instant if I don't get my installation with me, or I'm connecting to a server in a datacenter far, far away.
I don't like to be blindsided by my tools. I like blinkenligths in a way, and Eclipse gives me these blinkenlights while being highly automatic.
So while I understand your case, it doesn't apply to Eclipse, at least, because it's not a strangler, but a great enabler and HUD in my experience.
For the time investing part, I don't grind. I get a tool, and start using it, and when it becomes limiting, I start poking it and learn what feature solves that problem at hand. By that way, I learn the tool as I go, and if the tool can't expand to my needs at some point, it fades away from use gracefully. I don't do "stop, drop, roll" thing while changing tools, so I can't paint a timeline about when I picked a tool and dropped another.
I primarily do Java development. I started with eclipse, fell away because at the time it had pretty awful maven support. Moved over to Netbeans which has pretty good maven and java support, but went through a somewhat "unsupported" period of time and ultimately I moved over to intellij.
Intellij has been a joy to work with in Java code bases because everything just works and the smart features are actually worth it. Intellij can do pretty major refactors that both netbeans and eclipse can't think of. Further, it has really good code improvement suggestions that neither eclipse nor netbeans had. I can also simply check out any code base and tell intellij to open it and be up and running immediately.
A yellow line in intellij is almost certainly something you can right click on and hit "make better" and you'll have better and easier to understand code as a result.
All that said, you sound like you are working with a C/C++ environment. I've not done a lot with Intellijs clion so I couldn't tell you how comparable it is. It wouldn't shock me to learn eclipse is better as intellij is really well built for dynamic languages, maybe not so much for statically compiled languages.
For C/C++, Eclipse has a "so-called" indexer, which indexes the whole project, does static analysis on the fly, provides great auto-complete and warns you about gotchas. Since it can read the whole project, it has a better view than a C++ LSP, and it works reasonably fast and provides great detail.
Also, Eclipse has "Linux Tools Integration", which is also a boon for C++ development on Linux.
All in all, it helped me to build a materials simulation code without any memory leaks and with great performance insights, so I can't complain. Plus, I love build and launch profiles of that thing.
I have to use IntelliJ due to Kotlin codebase, but I'm still more of a fun of Emacs and I don't like Idea that much. I think IDEs somewhat lack the power that simpler tools have, which is automation.
One thing I miss from IntelliJ is programmability. That's why I still use Emacs on workplace for anything outside of Kotlin (git, grepping, note-taking etc). I even edit code in Emacs from time to time when it's easier to write a Lisp function which will batch edit code than doing keyboard macro.
Another thing I'm missing from IntelliJ is determinism. Everything is asynchronous, so the same combinations of actions can lead to different results, making automatisation painful.
https://dmitrykandalov.com/liveplugin
IntelliJ is very programmable, but it can be a bit intimidating because out of the box it assumes that you want to program it by creating plugins. That's very different to the elisp REPL driven approach. LivePlugin bridges the gap by letting you control the IDE from a repl-like console, building up scriptlets that use the same plugin APIs. There are examples for how to do things like add menu items, explore the semantic PSI trees, trigger refactorings or do whatever else you want to do.
- Tracks the mode globally (rather than per editor), and treats mode-switching as an edit operation (so if you accidentally enter a read-only tab in insert mode then you need to switch to another tab, escape, and then go back to get your keybinds back.
- Doesn't bind escape in sidebar dialogs, so trying to exit insert mode in a terminal or commit dialog just defocuses the sidebar instead
- Still applies its other binds, so even falling back to CUA/IntelliJ keybinds doesn't work either!
- Makes no effort to integrate IntelliJ keybinds, all you get for conflicts is "would you like to lose the Vim or IntelliJ functionality that binds this key?"
The difference is stark when you compare it to something like Evil that actually values the user experience. (How's that for an irony?)
(Thirty years in, still using IDEs as glorified text editors, still dropping to vim on a regular basis.)
Jumping into a new language with JetBrains is the difference between me spending 2 hours figuring out a codebase and submitting a PR, and me spending 2 hours fucking around trying to fix things.
I still don’t use an IDE for projects up to a certain size, but after a certain point, being able to also store all the nitty gritty bits about a project (building, profiles, environment, flags, etc.) in a project saves more time than it requires to set them up.
Most of my work is in Go, Rust and Typescript.
I was told by Jetbrains representatives that Fleet is now deprioritized internally, which is a pity.
I switch to Jetbrains from time to time because there are many impassable serious bugs in VSCode, on the other hand…
Webstorm closer but overall a bit better than vscode. The latter benefits from typescript support, but the former has much nicer devx
I really liked JetBrains tooling in the past, but that and then they also started hitting me with spammy advertising right after I paid for another year, and just couldn't stand it, refunded and cancelled.
Unfortunately they are forcing a VSCode UI on everyone and outright lying about their adoption figures (claiming it's off by default and everyone actively chose to use it). The new UI is just as much a broken mess as VSCode. The only way I can get work done is by using my fallback license for the 2023 versions.
It is apparently inconceivable to JetBrains that power users exist and pay good money for power user tools. JetBrains only cares about VSCode script kiddies anymore.
update: emphasis on "heavy". It's good for python projects. For some one-off script I'm more likely to use Zed. pyCharm indexing drives me nuts sometimes. But Zed lacks the features that I use in pyCharm for larger projects.
JetBrains has always had issues with performance and slightly clunky UI. But in return there's just a pile of amazing refactoring and analysis tools that nobody else offers.
I pay for tools that make my job easier so I can concentrate on delivering. Working without RustRover or CLion is just unpleasant.
I have an emacs + LSP + Rustic etc configuration which does about 80% of what I can do with RustRover. But it's brittle, slow, and takes work to maintain. VSCode suffers from similar problems (not slow, but brittle and ergonomics are worse).
This always felt to me like an old-school woodworker saying you can do a large project with hand tools.
We can start with basic things: the contrast, in default settings in dark mode for both. In theses conditions, Rider contrast is too low for a screen you have to stare all the day, compared to VS Code.
Commonly used item are in sub menus (in vscode they are sorted by most commonly items on top), common shortcuts requires finger gymnastics.
- it has bad defaults for theme (which I bet most devs change immediately anyways on every IDE)
- “common items” (which when unspecified could be assumed to be subjective to each persons workflow) are hidden in submenus?
- “common shortcuts” (again unspecified) require stretching (again, something trivially changed)
Unless you have more these feel not only extremely weak but extremely subjective. Please avoid trying to phrase your opinions as some fact it’s a tiring trope these days.
- “default theme sucks and is bad accessibility”. On its own this is objectively provable of course except when you’re talking about probably the single most commonly changed setting in a coders primary IDE other than maybe font. Calling the app objectively bad because it chose a bad default theme that gets immediately changed is a weak take
- “hidden menu options” this is the subjective one as I called out unless you can provide examples that are universal.
- “bad keyboard shortcuts” is subjective for the most part but even still is a widely changed option and very easy to fix. So calling the app objectively bad for this is also a weak take.
The items in VS Code are sorted the chance you have to use it depending of the context. In rider, commonly used items are in submenu (rename hiding in refactoring), less commonly used items are not in the submenus.
For the keyboard shorcuts, again you can argue practicality as an objective metric. The number of keys for a combo and distance between the keys have a big practicality factor, and Jetbrains IDEs loves F-keys (that you can't reach if you hold a keyboard like ergonomists recommends)
I presume the answer is yes, from what you said. Then it becomes less of an issue, if not an non-issue.
IDEs and code editors are tools which we live with for a long time. Nobody expects their defaults to be unchanged. Otherwise we'd be all using notepad.exe for coding.
Not having the defaults organized by your tastes is not a valid reason for disqualifying a tool out of the gate.
As a counter example, Electron's font rendering is nothing to drool over, from my perspective, and doesn't give an extra point for using it in my case.
The OC point was that VS Code UX "is a mess by comparison", and VS Code UX is fully configurable, therefor if you have a problem with VS Code UX, you are complaining about it's defaults settings.
Also Jetbrains IDEs font rendering is simply awful, it doesn't hold the comparison to electron: https://i.imgur.com/u4ZV2Kd.png
If you still need to customize everything then, well, what did you actually gain over assembling your environment by yourself from actually competent pieces?
That said, every IDE is opinionated about workflows, and if you’re open to adapt to that, the defaults makes sense. Otherwise you slowly hammer it to the shape you want.
For me an IDEs greatest selling point or the infinite flexibility it provides.
No, it’s subjectively bad for you.
It really grinds my gears when people use “objectively” when being objective is to deal purely in unbiased observable, repeatable facts.
Your justification starts first with screen contrast - something that is truly in the eye of the beholder.
Then you go on about “finger gymnastics” for shortcuts - again something that you (and yes I don’t disagree others as well) suffer from.
Neither are issues that have bothered me one iota - so much so that your mention is really the first time I’ve thought about either.
However you then compare this to another app that also has many detractors thus creating an instant bias.
Due to the poor font rendering and colors picked in Rider, by default there is a contrast of 4.77 which is just meet the minimum ratio, and for an app you stare all the day at, it's not enough.
From the firefox docs:
> Having good color contrast on your site benefits all your users
It's written all your users, it's not subjective.
Which is what? Is it a well defined fact?
So, they’re recommendations, not facts.
A fact is not a recommendation.
You can cling to this until the cows come home, but anything visual is dependent on the viewer. It’s not a fact. It’s subjective.
Anything else is subjective.
A UI can never be objectively bad because it is based upon how someone sees it.
For me, Gimp has a subjectivity bad UI because I’ve never been able to get my head around it.
Other people find it’s perfect and that it’s really easy to use.
Both statements are subjective.
“Objective” and “subjective” are both words that have well defined accepted dictionary definitions.
I often open code written in vs code and immediately spot a bunch of bugs
- The autocomplete popup sometimes froze the IDE completely (and killing the process caused minutes of data loss), open for close to a year
- Since two months ago, the Typescript language server fails to start in Vue projects (due to a broken update by the Vue team). A fixed version of WebStorm was released yesterday, in the meantime you were apparently expected to search for the error message, stumble upon the YouTrack page, and apply a workaround
- Performance is abysmal in a larger React MUI project, think 10-15 seconds for feedback on code changes, sometimes errors just stick around for a good minute or more, or even stay until you manually remove all code and put it back
- In some situations WebStorm makes autocomplete suggestions that aren't allowed - think effectively a type T with keys K | L, where Omit<T, K> leads to only suggesting K properties, while removing the Omit makes it suggest both K and L properties
- After updating from 2024.1.X to 2024.2.Y, the window had no buttons for minimizing/maximizing anymore. Now, this was partially caused by my environment, but after I found a workaround it was closed as "Third Party Problem". Still feels like a regression to me, since my environment did not change.
I've mostly stopped updating the IDE, as almost every version brings new regressions in basic editor features. This morning I updated and tried to copy some text. WebStorm showed me a "Copying..." dialogue for more than 30 seconds.
I have high hopes for "Junie" but fear it's going to be a while before it's ready for prime time.
I wonder if AI assistant will be deprecated once Junie is GA. Anyone know?
Phpstorm ran out of chances I'll give it. Last three tries all went the same way, permanently stuck indexing a project and being an overdeveloped notepad.exe during that; when vscode and phpintelphense could go from cold boot to code assist in seconds on the same project.