13 ms·

VS Code has come a long way and Is overtaking JetBrains by innovation speed it seems, largely thanks to its rich plugin ecosystem. However, I think it is not qu

by 0x008 5y ago

VS Code has come a long way and Is overtaking JetBrains by innovation speed it seems, largely thanks to its rich plugin ecosystem. However, I think it is not quite there yet, largely due to bugs which need to be ironed out. My observations from daily driving VS Code insiders for half a year: - stuff breaks and will not work for multiple weeks. this is especially frustrating if you use setups which are considered “exotic” by the devs (like having IPv6 disabled). But that is Insiders for you. - Remote dev support is a lit better than JetBrains (also it is not in the free editions of JetBrains) - UI customizability is miles ahead in JetBrains. Just an example: there has been a Ticket open in VS Code to enable moving the outline view to the right side of the UI for years and they say it is not possible because that would need some large refactor. - JB Debugger is more convenient and easier to use - Tests and TDD work better out of the box in JB. No finicky manual switching between test output and Debut Console needed like in VS Code. - VS Code language servers seem to be quicker in building index. I had Pycharm Stuck in a seemingly infinite Index Rebuild multiple times. - setting up languages and projects in Vs Code can be exhausting and seemingly impossible sometimes (Monorepo…) - finally: refactor methods are wayyyy ahead in JetBrains products. Since VS Code depends on open source implementations by plug-in maintainers/language servers for these, they tend to vary a lot from language to language. I could go on and on. But my general feeling is that VS Code is more flexible and has more features at the cost of a worse UX, largely due to its open source nature. JetBrains has a way better UX and is more solid (hello enterprises!) and will eventually catch up to some of the more Revolutionary new VS Code features, but it has a lot slower update cycle. If you want to get work done and your use case fits into a JB product, use it. If you want one application that can do everything under the sun, get VS Code.

pjmlp 5y ago
Given how many avoid as much as possible to pay for their tooling, versus what happens in other professional fields, as long as Microsoft keeps shipping VSCode (naturally paid with Azure and Office profits), long term what JetBrains does better won't matter. If JetBrains was so sure about their customer base they wouldn't have started with a VSCode competitor.
- native_samples 5y ago
  VSCode is clearly a threat as any large firm market dumping is to any company. But JetBrains have seen off free competitors many times before. They matured in an environment where the go-to IDE was Eclipse, also free, also funded by a behemoth. The thing is that without profits to justify continued investment, executives at firms like Microsoft or IBM eventually get bored of old projects and quietly defund them. JetBrains seems to try to limit the number of free-for-browny-points projects it runs. There are some, most notably Kotlin, but by and large cool but expensive-to-develop new features are things you pay for, e.g. Code With Me. That gives JB sticking power. Also, Java/JVM has been a good platform for them over the years. The tools they're using are fundamentally well designed and it shows. Classical Visual Studio got knocked out of the race a long time ago, partly because it was written in C++ and failed to make the jump beyond 32 bit Windows. It took forever to go to 64 bit and never made it to non-Windows platforms. The JVM largely abstracted JetBrains from both transitions (albeit in recent times they've had to become co-maintainers of Swing), allowing them to focus on just adding features. And Java's general features and robustness compared to HTML5/JS mean they can ship features and improvements at an incredible pace. They have historically also dogfooded their own philosophy. IDEA was never rewritten from scratch. It's been continuously upgraded and refactored for 20 years now. I actually worry a bit that they're losing this and becoming more "California" with efforts like Fleet and Space because those look suspiciously like large rewrites rather than incremental refactorings. Space might take off but I have grave doubts about Fleet. The way they developed Kotlin with great Java interop and even an auto-converter tool, and then started using it in IntelliJ development, is a much more JetBrainsy thing to do.
  - pjmlp 5y ago
    Rider hardly matters to Windows development as it can only do a subset of Windows development is all about. As for Java, Red-Hat and Microsoft are the ones integrating Eclipse into VSCode. In what concerns Kotlin, the child's future is pretty much dependent on JetBrains/Google marriage happiness.
  - mcv 5y ago
    Exactly. The fact that Jetbrains challenged and survived many excellent free IDEs proves that they offer real value that many people are willing to pay for. I generally love and prefer free and open source software, but I pay for my own IntelliJ license.
MattGaiser 5y ago
> If you want to get work done and your use case fits into a JB product, use it. If you want one application that can do everything under the sun, get VS Code. You can buy all JB products for about $200. So while no one app does everything under the sun, they cover most things one way or another.
- pjmlp 5y ago
  Except little things like refusing to support JNI development, which Eclipse and Netbeans support out of the box for at least since 2005, and Google has customized Android Studio to support it, given the NDK. They rather sell InteliJ + Clion licenses for that purpose.
- bredren 5y ago
  I’ve reported many bugs and created or been routed to vote for a lot of feature requests for Pycharm. It does feel like jetbrains covers most things, but if you use the tool constantly you start to notice items that have been languishing in their tracker despite long standing community requests. For example .env support to load environment vars into the IDE’s Run and Console is only handled by plugins. Not only do these break occasionally, but there is a security problem because these plug-ins often handle secrets. There’s a solid backing for pulling this into the IDE, but jetbrains hasn’t acted on it. Another example is providing UI for the git flow style development. Although many consider this to be a legacy style compared to trunk-based, git flow continues to be in very active use. The plug-in for this behavior, I believe, for all jetbrains IDEs at this moment is still broken for 2021.3.
jen20 5y ago
> VS Code language servers seem to be quicker in building index. This largely depends on which language server. VS Code simply refuses to deal with a multi module Go repository I interact with regularly because the language server doesn’t deal well with that and it’s considered “unusual”. Meanwhile IntelliJ has had no issue with it. Heaven help you with VS Code if you’re using Bazel and want things to Just Work with regards to code navigation and so forth.
- thebean11 5y ago
  To be fair Bazel can be sketchy on IntelliJ too, especially with Go (although enabling gomodules fixed a lot of those issues for us).
  - jen20 5y ago
    True - the Bazel plugin often lags significantly behind IntelliJ releases too. That said it's a world apart from the basically broken experience you get in VS Code all the time.
WorldMaker 5y ago
> due to bugs which need to be ironed out > My observations from daily driving VS Code *insiders* [emph. added] I think at least some of your concerns here about bugs that need to be ironed out is that you are using the Beta channel as a daily driver instead of the Production version.
- 0x008 5y ago
  Yes, that is why I explicitly stated it in my comment that I use insiders. However, it is not so simple, I only started using insiders because of the aforementioned problems with IPv6 which were not solved in the regular releases for 2+ months, but were already solved in insiders. It is not so simple as to say all of these bugs wouldn’t happen if I used the stable release branch. It goes both ways. I got some new bugs and I lost some old ones, it is a two-sided sword. And even the stable releases are too buggy too really rely on it, because a lot of bugs and/or problems (also some I mentioned in my comment) are present for months/years.

by 0x008 5y ago

pjmlp 5y ago

Given how many avoid as much as possible to pay for their tooling, versus what happens in other professional fields, as long as Microsoft keeps shipping VSCode (naturally paid with Azure and Office profits), long term what JetBrains does better won't matter. If JetBrains was so sure about their customer base they wouldn't have started with a VSCode competitor.

native_samples 5y ago
VSCode is clearly a threat as any large firm market dumping is to any company. But JetBrains have seen off free competitors many times before. They matured in an environment where the go-to IDE was Eclipse, also free, also funded by a behemoth. The thing is that without profits to justify continued investment, executives at firms like Microsoft or IBM eventually get bored of old projects and quietly defund them. JetBrains seems to try to limit the number of free-for-browny-points projects it runs. There are some, most notably Kotlin, but by and large cool but expensive-to-develop new features are things you pay for, e.g. Code With Me. That gives JB sticking power. Also, Java/JVM has been a good platform for them over the years. The tools they're using are fundamentally well designed and it shows. Classical Visual Studio got knocked out of the race a long time ago, partly because it was written in C++ and failed to make the jump beyond 32 bit Windows. It took forever to go to 64 bit and never made it to non-Windows platforms. The JVM largely abstracted JetBrains from both transitions (albeit in recent times they've had to become co-maintainers of Swing), allowing them to focus on just adding features. And Java's general features and robustness compared to HTML5/JS mean they can ship features and improvements at an incredible pace. They have historically also dogfooded their own philosophy. IDEA was never rewritten from scratch. It's been continuously upgraded and refactored for 20 years now. I actually worry a bit that they're losing this and becoming more "California" with efforts like Fleet and Space because those look suspiciously like large rewrites rather than incremental refactorings. Space might take off but I have grave doubts about Fleet. The way they developed Kotlin with great Java interop and even an auto-converter tool, and then started using it in IntelliJ development, is a much more JetBrainsy thing to do.
- pjmlp 5y ago
  Rider hardly matters to Windows development as it can only do a subset of Windows development is all about. As for Java, Red-Hat and Microsoft are the ones integrating Eclipse into VSCode. In what concerns Kotlin, the child's future is pretty much dependent on JetBrains/Google marriage happiness.
- mcv 5y ago
  Exactly. The fact that Jetbrains challenged and survived many excellent free IDEs proves that they offer real value that many people are willing to pay for. I generally love and prefer free and open source software, but I pay for my own IntelliJ license.

MattGaiser 5y ago

> If you want to get work done and your use case fits into a JB product, use it. If you want one application that can do everything under the sun, get VS Code. You can buy all JB products for about $200. So while no one app does everything under the sun, they cover most things one way or another.

pjmlp 5y ago
Except little things like refusing to support JNI development, which Eclipse and Netbeans support out of the box for at least since 2005, and Google has customized Android Studio to support it, given the NDK. They rather sell InteliJ + Clion licenses for that purpose.
bredren 5y ago
I’ve reported many bugs and created or been routed to vote for a lot of feature requests for Pycharm. It does feel like jetbrains covers most things, but if you use the tool constantly you start to notice items that have been languishing in their tracker despite long standing community requests. For example .env support to load environment vars into the IDE’s Run and Console is only handled by plugins. Not only do these break occasionally, but there is a security problem because these plug-ins often handle secrets. There’s a solid backing for pulling this into the IDE, but jetbrains hasn’t acted on it. Another example is providing UI for the git flow style development. Although many consider this to be a legacy style compared to trunk-based, git flow continues to be in very active use. The plug-in for this behavior, I believe, for all jetbrains IDEs at this moment is still broken for 2021.3.

jen20 5y ago

> VS Code language servers seem to be quicker in building index. This largely depends on which language server. VS Code simply refuses to deal with a multi module Go repository I interact with regularly because the language server doesn’t deal well with that and it’s considered “unusual”. Meanwhile IntelliJ has had no issue with it. Heaven help you with VS Code if you’re using Bazel and want things to Just Work with regards to code navigation and so forth.

thebean11 5y ago
To be fair Bazel can be sketchy on IntelliJ too, especially with Go (although enabling gomodules fixed a lot of those issues for us).
- jen20 5y ago
  True - the Bazel plugin often lags significantly behind IntelliJ releases too. That said it's a world apart from the basically broken experience you get in VS Code all the time.

WorldMaker 5y ago

> due to bugs which need to be ironed out > My observations from daily driving VS Code *insiders* [emph. added] I think at least some of your concerns here about bugs that need to be ironed out is that you are using the Beta channel as a daily driver instead of the Production version.

0x008 5y ago
Yes, that is why I explicitly stated it in my comment that I use insiders. However, it is not so simple, I only started using insiders because of the aforementioned problems with IPv6 which were not solved in the regular releases for 2+ months, but were already solved in insiders. It is not so simple as to say all of these bugs wouldn’t happen if I used the stable release branch. It goes both ways. I got some new bugs and I lost some old ones, it is a two-sided sword. And even the stable releases are too buggy too really rely on it, because a lot of bugs and/or problems (also some I mentioned in my comment) are present for months/years.