VSCode is growing which is concerning, not from a competitive point of view but actually from the point of view that there is clearly a lack of understanding of what an IDE gives you. VSCode is a code editor with some features that you’d find in an IDE, and extensions that can provide additional functionality – so if people are turning to VSCode for developing it may imply that developers don’t know what a fully-featured IDE can give them. In the web space it is understandable to use an editor as web developers are typically working with dynamic languages, and often use other tools like browser plugins to give them what they need.. But in Java, especially professional Java, you really get a lot out of a good tool that has integration with the application server and you can really use the analysis and refactoring and everything.
IME a lot of developers don't like their IDE heavily coupled to backend servers and environments, but actually prefer the "code editor + useful features" approach. It makes combining with CI/CD a lot simpler for one, since the activities run on a project can simply be the same as those run on the pipeline. A quick "mvn install" is often enough for many/most modules. Many devs only really want advanced editing + syntax highlighting + language server.
What an absolutely tone deaf thing to say. "It can't be our product that's using out dated philosophies. It's the users that don't know how to use it properly"
In good faith, I read it as "users don't even know what they're missing out on". To be honest, I feel like some of the comments here are at least partially proving them right in this regard.
The article now has an update that confirms your reading:
I can see that by using an abridged and edited version of my analysis of the data for this blog post that I’ve unintentionally spread confusion. I’d like to clarify the intention behind my comments on developers and IDEs. For me, if developers don’t understand what IntelliJ IDEA gives them as a fully-featured IDE, that’s a failure on my part, since it has been my job for six years to educate developers on what an IDE (specifically IntelliJ IDEA) can do for you. I feel very strongly that one should never blame users, or prospective users, for failing to understand a product.
My personal viewpoint on IDEs for Java developers comes from having been a Java developer for 20+ years, working on production Java projects large and small. I can’t imagine trying to create a complex enterprise application without the considerable help you get from an IDE like IntelliJ IDEA. I have also seen lots of developers using VSCode and I completely see the use cases that code editors cover well. There’s always room for more than one tool in your toolkit, and understanding what a tool does well helps us pick the right one for the right job.
I used IntelliJ for almost two years, JS and Java. I hope I never have to use it again. It's laggy, clunky and with a less than intuitive UI. Yes, it is powerful but it doesn't weigh up for its shortcomings.
I never did understand all the Eclipse hate, especially when compared to IntelliJ. I use both regularly and the only thing Eclipse is missing for me is a proper searchable command pallete. Code navigation, refactoring, debugging and version control all work great, it's much faster and resource-friendly than IntelliJ and many things are a lot more straight forward (like the lack of IntelliJ's confusing changesets and non-native file pickers).
I work on an enterprise project with 100+ gradle projects and a pile of targets for docker containers, kubernetes deployments, DB schemas, Redis stuff, etc..
Eclipse is incredibly slow in this use case compared to IntelliJ and would frequently gobble 10GB of Ram. I switched from Eclipse to IntelliJ earlier this year after years on this project and IntelliJ is amazingly better.
But if you're using some different build system and a different type of project configuration maybe it's the other way around..
The last project I used Eclipse on consisted of like 50 different maven modules. Plus we were also using a mix of Java and Scala code. The Scala plugin we were using seemed to make everything run very, very slowly. At times, it couldn't even keep up with my typing.
This was back in 2011 though. Obviously things have changed.
The difference between Eclipse and IntelliJ was like night-and-day, however, in terms of performance.
I used Eclipse a long time ago and it had horrible performance. But IntelliJ quality had been really bad in recent years. Minor updates causing major performance regression, taking massive CPU when nothing is being worked on. It was way more stable product in earlier versions.
Perhaps Eclipse has improved. The last time I personally used it for a project was back in 2011. It was slow, laggy, and I found the UI to be less friendly than IntelliJ. Obviously some of that is personal preference.
Neither did I. I was introduced to Eclipse before I got my first job and today, 9 years later it still gets the job done. I briefly use IntelliJ IDEA CE only for one static analysis plugin that works better in IDEA, most code editing is in Eclipse.
I don't love eclipse, not a person to get too attached to an IDE, but it is an incredible piece of open source software. It works.
Also too much effort in rewiring keyboard shortcuts that have made their way to my muscle memory. So eclipse it is.
Thanks!! I opened it once by accident and haven't managed to find it again (it's not called "command pallete" so I couldn't find anything in the docs). I suck at remembering keyboard shortcuts, so this is going to be a significant productivity boost!
Funny InteliJ made me love Eclipse again, and other than Android Studio, I don't plan to touch anything made by JetBrains unless required to do so due to work contracts.
I recently used VS Code for a personal project involving embedded C++ development. I used the PlatformIO extension. It was nice! I will definitely try it for other projects in the future.
I haven't had this experience - but I do have a relatively powerful PC (16gb ram, SSD, Ryzen 3600). IntelliJ has always been really responsive for me, even on large projects.
In my experience helping others get set up, slow JetBrains tools are usually an AV problem, or a (shudder) spinning rust problem. It seems like the developers agree, given that new versions will offer to setup AV exceptions for you automatically.
Well, seems heavy handed either way to give vscode such attention when vscode was only 4% of respondants. Seems reasonable that you wouldn't want a full fledged IDE in certain cases. For example, a small simple project, or if you're mainly a frontend dev who just needs to add a small API
It would make much less sense to wait until the cool, free tool was more popular before reacting to it, no? They're not worried about eclipse, it's not very well liked. VS Code by comparison has a lot of shine on it.
I feel like it's on the product to make those benefits apparent and easy to use. They're selling me (the user) not the other way around. The message comes off very privileged IMO.
I'm admittedly an IntelliJ fanboy but I also make extensive use of VS Code and I think JetBrains are 100% correct. The kind of extra features you get from a really good IDE are so easily worth it if you spend even a small amount of time learning how. You may need to invest an hour or two getting it to understand your project setup but then you have real-time debugging, refactoring, granular test running (and debugging) right away. I think the move away from IDEs is coupled to the move away from strict typing (which I also hate) because IDEs lose value when they can't reliably understand your code.
Yes, but on the other hand, IDEs are slow. I don't mean to say VSCode is lightning fast, but it starts in less than a second. By that time, IntelliJ didn't even open it's loading window. And were talking about a top-of-the-line Ryzen 7 laptop with an NVMe SDD.
For longer sessions that's not a problem, but when you're on battery or quickly hopping into the project to look something up it makes a lot of difference. Also, opening up a foreign project is two clicks and one second, compared to project creation and then loading+indexing when using IntelliJ.
I love the IntelliJ line of IDEs. But VSCode outcompetes it in simplicity by far. Especially when we're talking about something like a simple Node project, where compilation+execution is far simpler than something with a full build pipeline with artefacts.
But the trade off here is indexing. Visual Studio code provides no indexing functionality by default (some LSPs provide basic caching but not much). This is the killer feature for me. I can load up Kubernetes in Goland, cook an egg on my laptop while it indexes (about a minute) and have lightning fast goto def and find reference for the rest of the day. VS Code will load quickly but every single goto def will take ages.
I prefer to have the application ran on my machine in a fashion similar to how I'm going to deploy it. Using a "large" ecosystem IDE detracts from that as the application is now ran by an application rather than in a system. And almost all the features you listed are possible in VSCode. You just have to take an hour or two to set your system up to run it.
> And almost all the features you listed are possible in VSCode
As someone who wishes they could drop everything else and just use Kate or VS Code, I disagree. IDEs like those that JetBrains offers have refactoring tools that are unmatched by what VS Code and its plugin ecosystem currently provide.
Depending on the language you're writing VS code plugins are a bit hit and miss. I've tried using it for Rust dev for example, and everything kind of worked, but with way too much jank. I constantly had problems with autocomplete suggestions being duplicated and linting being slow or not updating errors. Enough to make me wish I had a dedicated IDE.
More widely used langs have better experiences though I'm pretty sure. And maybe Rust support has gotten better? Seems that other commenters in this thread had positive experiences.
There has been rapid improvement in rust-analyzer for a while, so yeah, stuff has been getting way better for quite a long time. Every week there's new stuff with it.
I think there's room for both. And if I've learned anything watching node developers working in VS Code it's that they work exclusively in webpack dev mode and let npm worry about production.
I get real-time debugging, refactoring, and granular test running/debugging in VS Code. I also work almost exclusively in TypeScript, F#, and Rust. My anecdata says that this argument isn't very accurate.
How is there a move away from strict typing? If anything it's the opposite in dynamic languages - Python/typing, Ruby/Sorbet, JS/Typescript, PHP/type hints.
For those who don't know, JetBrains has a plugin for Rust (I think really targeted at CLion but i think its installable from multiple IDEs like Pycharm as well)
VSCode doesn't interpolate HTML variables for me. Its the small features that add up over time I miss whenever I try to switch development environments.
VSCode has a really good TypeScript/JavaScript and admittedly Python developer story, and the ecosystem has produced some pretty robust Style editing extensions, but if you want things like autocompletion for your template variables, I've always found you have to look elsewhere, whether it be handlebars, django templates, Jinja templates etc (and this is one example, among many)
VSCode doesn't autoload JSON schema (need an extension or hope for the best)
VSCode Extensions are also suffering from some pretty serious lack of maintenance too. Lots of extensions, very little movement on updates. I've had more than one of them break on me in major ways.
I wonder how much of that is just the lack of really good IDE tooling for Rust? GoLand is pretty good, so I don’t know if similar question applies to Go.
Java pretty much requires an IDE because it's verbose, bloated, everything is inconvenient without IDE assistance and it's easy to create bugs.
Something as simple as opening a file of code requires IDE, because everything is hidden behind `./src/main/java/com/whatever` nonsense. The language was designed for IDE.
In Rust there is hardly any need for IDE (or a debugger), as long as your text editor has LSP support. Hell, even without LSP support it feels quite OK to write Rust code.
I use Intellij for Java, and Kakoune for Rust, and I really dislike working with Java. The fancy refactoring features don't make up for how verbose, clunky and inexpressive Java is.
The Rust way is to have great modular and reusable tooling for everything. Even stuff like complex refactoring can be achieved without an IDE with something like https://github.com/google/rerast
Yes but they are clearly missing something and that's simplicity. I use goland because ei get go refractor and move utilities but I get annoyed when I feel like I have to fight it to do simple things. I think the default keyboard shortcuts between the two products show a lot.
Yeah, they just don't get it, they have stayed for so long in the enterprise java world that they can't comprehend that everybody else moved on from those bloated IDEs. On my case if I had a choice even between Notepad++ and IntelliJ (to pick an extreme example), I would still use Notepad++.
VScode is a very nice middle ground where the defaults make sense and you can get powerful extensions for everything else you want, there's a reason it's so popular.
Am I the only one who finds it a little bit ironic to call IntelliJ bloated, and then recommend VS Code, which may not be that "bloated" feature-wise, but is based on a browser engine, so also not really light on resources? A VS Code-like product using the Sublime Text engine would be the ideal development tool for me. As long as that's not available, I'm using PHPStorm at work (my company is paying for it) and VS Code for my private projects in Go - still haven't tried out Goland, IntelliJ's Go IDE, but so far I'm happy with VS Code.
HotSpot, under a typical configuration, eats up about 250MB just sitting there doing nothing. I don't know what Electron does under similar circumstances because I've never tried to measure it, but I know that I regularly see Electron apps using less than 70MB, so we can estimate an upper bound on Electron's typical contribution to bloat as being no more than ~30% of Java's.
For a slightly more apples-to-apples comparison that's also quite a bit more apples-to-jicama, if I open vscode and IDEA on the same project (a small one I'm just getting started on), vscode and all its helpers are using 316MB, and IDEA is using 1.08GB. I doubt that much of that difference is actually attributable to using a browser rendering engine for GUI layout. In fact, I'm guessing that Chromium's net impact on the situation falls below the noise threshold of this comparison. So, yeah, not worried about it. FWIW, vscode also started up quite a bit faster, and I experience less keyboard lag when using it.
And, if we're looking for mature and full-featred cross-platform GUI toolkits, that's about it for your options. Yes, there's QT, but, with a sticker price of $4000/developer/year, it's hard to criticize people for not choosing it. And there's GTK+, which is fine, I suppose, but not exactly everyone's cup of tea.
Long story short: This Electron-flaming meme is getting old. If you don't like JavaScript, just come out and say it. If you don't like how Chromium is eating the world, that's a fair point, too. But stop scapegoating Electron for things like how Slack's desktop app used to leak memory at an astonishing rate. That was always the app developer's fault, not Electron's.
> HotSpot, under a typical configuration, eats up about 250MB just sitting there doing nothing.
This is much lower in newer jdk's [0].
> For a slightly more apples-to-apples comparison that's also quite a bit more apples-to-jicama, if I open vscode and IDEA on the same project (a small one I'm just getting started on), vscode and all its helpers are using 316MB, and IDEA is using 1.08GB
I believe this to just be intellij bloat and not JVM because it just does too much. I run VSCode with the Java plugins and ZGC (read: eclipse language server, which is all jvm) and the language server only ends up using around 250mb of ram.
I that you're right that it's just IntelliJ doing too much. Similar to how the Slack app's formerly astonishing memory consumption was because it was trying to retain all of Giphy in memory for all time.
Somewhat related, back when I was a C# developer, I spent a long time being confused over the community's somewhat polar opinions on whether Visual Studio is slow and bloated, or lean and snappy. Eventually I realized that the difference of opinions was because some people's employers buy them copies of ReSharper, and others don't.
IntelliJ has more features than even the best language service I’ve used, C#’s. The language server tools are catching up but for integration and polish you still can’t beat JetBrains.
On the subject of the (lack of) snappiness in Visual Studio + ReSharper, Jetbrains Rider comes with the ReSharper functionality built in and feels a lot snappier.
HotSpot, under a typical configuration, eats up about 250MB just sitting there doing nothing
Mmmm, I have two projects open in IntelliJ right now, one of which is quite large, quite a few tabs, and it's using 366mb of heap.
You have to watch out though - Java won't collect garbage if it doesn't have to. This fools a lot of people. They look at memory usage and assume it must really be using that much memory, even when it's not. From the perspective of the JVM if the memory is there, it may as well be used, because freeing RAM just to leave it pointlessly empty just wastes CPU time, battery, generates waste heap etc. Why not use it? The only time it matters is if you have something else that wants the memory and it can react to that I believe. Or if you're measuring it against other tools of course.
I guess over time this will go away as a talking point because the JVM is getting more aggressive at collecting memory even when there's RAM spare, partly because of containers and partly because of threads like this one.
That's already happening with modern JDKs and GCs; as of JDK 12, G1 uncommits unused heap eagerly (see https://openjdk.java.net/jeps/346), and the parallel GCs Shenandoah and ZGC do the same.
Considering how avid Electron user tell others how files should not be even bigger than few hundred lines considering electron croaks on that. Or without irony they tell how fast Electron is on 6-core/32GB machines and that everyone should upgrade. They should be last person to talk anything about performance.
> Long story short: This Electron-flaming meme is getting old.
No I think it remains perfectly relevant today. And Electron products are not really enough shit that they so well deserve.
I think this is a great comaprison of the wrong things - i do not believe RAM used is what matters, not if it's under 4 Gb.
I think it's CPU, and VS code consistently takes more CPU to achoeve the same job, and for longer.
> HotSpot, under a typical configuration, eats up about 250MB just sitting there doing nothing.
Citation needed. Because right now we're running most our Apache TomEE and Tomcat applications in prod on a 64m or 128m heap and handle hundreds of requests or messages per second. And this is on an ancient JDK1.8. On JDK11, we're thinking of running between 16m and 32m heaps.
Yes. So the absolute worst case scenario is one our 128mb heap apps that uses direct memory byte buffers for off-heap object caching. It's resident set size is roughly 387m, which up to 196m of that is byte buffers. I can tell using JPS the heap is full allocated, and the application has been running for several weeks so I imagine the cache is full. That leaves an overhead of 64m.
For funzies, I looked at one our ActiveMQ Message brokers, which are ran on 1g machines with a 640m heap. The heaps are fully allocated and the resident set size is ~658m. Linux reports it has 66M of free memory and 95M of available ram. 440m of swap is being used and is only lightly being paged out under light load of 400 msgs/s. This same setup can push 2000msg/s before GC thrashing becomes an issue and we need more heap.
So no, I don't think there's any truth to the claim "Hotspot always uses an extra 256m of memory". Sounds like the kernel is doing what it's supposed to: free memory is wasted memory.
Slack's bloat may be the developer's fault, but the same could be said about Atom, and Discord, and Evernote, and Skype. And even if you can't say it about VSCode itself, you can certainly say it once you introduce a handful of extensions.
Electron isn't the problem. All of the technologies it is built on are the problem. They require extreme measures to control quality and maintain performance for anything larger than a trivial crud app.
You'll have to post more about the OS and how you measured memory consumption. If you're just looking at something like htop, it can be pretty misleading.
I dread the day Siemens inevitably buys Qt (it will happen) and the license structure changes to $65k/per-seat buy-in to the “base” toolkit which includes QObject and nothing else. Also, a $7k/year per-seat maintenance fee for “base”.
If you want the QtGui module, look north of $100k buy-in.
I'm well aware that VSCode as a tech product is also full of bloat internally, the difference is that this bloat is mostly hidden to the user. What they have going for them is that it's a well designed text editor with sensible defaults in the first place, it "just works" and it's simple, that's also why it's so popular. You can add as much (or as little) as you want on top of it.
The UI is also a lot cleaner. There are only a couple of icons and each of them does something I use regularly. Jetbrains products have 300 icons and I use about 5 of them. Once I worked out I could do everything I use rubymine for in vscode with plugins I stopped paying that license fee.
> VS Code ... is based on a browser engine, so also not really light on resources?
You say that, but IntelliJ is not exactly slouching on resource usage. I see far lower memory usage in VS Code than I do IntelliJ opening the same projects.
I see this critisism of VSCode a lot - but the job of a browser engine is to render text really fast! Rendering text is something you want to do in a text-editor is it not? Why not use the best tool for the job?
You're probably right that something like Sublime Text is faster - but that's a massive undertaking that would take a lot of engineering to get right.
The job of a browser is to render a wide range of UI specifications reliably and support a collection of broken but grandfathered web languages, not to render them quickly. Speed is nice, but it comes after those concerns.
The point of Electron is to allow people to develop UIs quickly, leveraging their experience with the web. Electron is extremely bloated & slow. To some degree it has to be.
If browsers were about speed, they wouldn't interpret Javascript. I'd argue they'd probably force the UI to be specified in a form that explicitly disallows inefficiencies and probably isn't turing complete. I'd argue a domain-specific solution for rendering highlighted code specifically could be a lot faster than a browser, like multiple orders of magnitude. We know that's the case by virtue of the fact we could even do it at all in the 80s.
As someone who used to heavily use intellij and visual studio, and briefly defended them when I transitioned to a shop that was full of vim/emacs hipsters, I throw up in my mouth a little bit every time I recall the times when I was using them.
Funnily enough, I also found myself using Java and .net less and less. I never had much love for Java, but C# was an amazing language that somehow got gobbled up by the Enterprise black hole and it's a huge shame.
This is the central question in my mind too. In a typical work day I might launch a project once. Heck, I might only launch it once a week to be honest.
I spend all day navigating and reasoning about the codebase I'm working in, so I need strong tools that aide me in that. That's where VSCode doesn't hold a candle to Rider IME. So Rider is my daily driver at work.
The responses from some devs leave me wondering what their env/projects/work day actually look like and how does their tooling actually work for them in practice.
It would be incredibly interesting to see the landscape of different work envs and tooling and do a comparison of what happens in each given env when you swap out the tooling.
A typical work day has me working in at least two different projects. Visual Studio/Rider is so heavy that I don't want to keep two instances of it running all the time and it's so slow that switching between projects in a single instance carries a heavy context switching cost. I also have a set of markdown files that I use as a second brain which I like to open periodically to check notes or jot down ideas.
> Do you work on multiple things that don't require coding?
I also write documentation, answer emails, review PRs, occasionally modify art assets, maintain team documents, etc. I don't always want Visual Studio/Rider hogging all of my memory or chewing up the CPU.
> Why does launch-time matter at all?
I hope what I already wrote made it clear but TL;DR I jump between projects, don't want multiple instances consuming all my resources, and (bonus) I frequently need to restart Visual Studio because it can get in to a weird state when working in C#/F# hybrid projects.
Maybe VSCode could show a little traffic light next to each plugin indicating its latency impact.
What IDEs have going for them is that the features are generally constructed by people who know what they are doing and test them at the same time. Whereas a plugin could be written by anyone. Also there's a great "works on my machine" when it comes to performance: the plugin author will just test the plugin on its own rather than with a bunch of other plugins, so their performance target is artificially low.
The number of new non-enterprise projects built on C# is off by a factor of 10-100x compared to Python/Node/Rust. And even in enterprise, it's now dying. .net core is an attempt to rescue it on the cloud but it's too little too late.
No matter how amazing the language is, it has become hard associated with enterprise work and not much else. It didn't need to be that way, that's Microsoft's doing.
> it has become hard associated with enterprise work and not much else
Maybe you are right on that, but why do you consider that a bad thing? Different languages are for different things.
Your statement of non-enterprise projects off by a factor of 10-100x is partly because people jumped on the non-statically typed mess that Python is. Especially with all the AI related stuff.. yeah if you are doing some random little research project and you are a math person but don't want to take the time to do programming "correctly", then sure you can jump into python, use some libraries and get some results. It has it's purpose.
I don't know it's just silly to bulk everything together and pretend you can compare them.
Also saying .net is dying in enterprise is basically laughable.
Languages have evolved. Now developers EXPECT languages to come with a FREE suit of command line tools for linting, static analysis, formatting, package management and what not. FROM there ANY text editor should be able to take advantage of all these command line tools to provide a good developer experience.
The time of bloated IDEs is over. And you're right, I need to be able to run all CI tools the same I do on my development machine and the CI server.
Obviously, WYSIWYG and other graphical builders will always need a specific IDE in order to do RAD, but these are special cases, not the norm anymore.
Nothing prevent jetbrains from selling CLI tools that perform all the tasks in their IDE, especially when many of their IDE do rely on open source CLI tools at first place.
But If I'm developing say an Android app and I'm not the design integrator, I shouldn't have to fire an slow and heavy IDE just to write a bunch of Java classes. I have my maven manifest and it should be all I need to compile a project.
Re: Obviously, WYSIWYG and other graphical builders will always need a specific IDE in order to do RAD, but these are special cases, not the norm anymore.
I don't know why it died, WYSIWYG and GUI-friendly IDE's allowed higher productivity in that "one-man-bands" (small staff) could do the entire project. Now development is often layered into specialists. Things like UI design and ORM's have longer learning curves, which emphasizes specialists. But staff is larger per feature: less productive. (There are many times I wanted to shoot Bootstrap in the head when I couldn't get it to act how I wanted. Something in WYSIWYG that would take 20 seconds becomes a 2 day trial-and-error session in Bootstrap.)
WYSIWYG/GUI-IDE saved money. Most businesses don't run their internal productivity software on mobile anyhow. "Progressive" UI's are a money sink in practice.
The trend predictors got it WRONG: desktops live on in biz. Our anti-state-GUI web standards don't help. Businesses really want cheap rich desktop-like GUI's for productivity software.
I'm not against flow-based layouts, but they should be an option, along with WYSIWYG.
Can I ask where you you see this demand, is it industry specific?
I was under the impression that the benefits (easy deployment to a known runtime aka the browser, open ports (80/443) in the firewall, large developer pool, potentially cross-platform use) outweigh the UI shortcomings and budgets were shifted to web-based productivity software.
The features you list are not necessarily mutually exclusive, but too many think they are, and that's the problem. For some reason people seem to think it's either rich GUI -or- web. With a decent stateful GUI markup standard, we can have the best of both. HTML wasn't meant to be stateful nor for rich interactive GUI's. Faking it with JavaScript has proved a bloated crashy mess.
End users who care about productivity want rich GUI's. Rich GUI's use screen real-estate better than "progressive" web apps and have abilities like right-click, rollover text, etc.; and it's cheaper to develop because they (optionally) can use WYWIWYG for many parts of it. WYWIWYG is just plain cheaper and easier to get right. You don't need "flow layout" specialists who can tame sucky CSS/DOM, which makes alchemy look logical.
Remember that businesses don't really care how software works as long as it does the job and is affordable in creation and maintenance. The bloated web stacks are not. It's too much code to do the same thing UI-fit tools did with less because they were closer to the CRUD/GUI domain itself. Web stacks are too fucking layered such that you spend most of the time managing communication between layers instead of on real biz logic. I stand by this and if you look at the code you should agree.
We DEVOLVED. Current web standards may be fine for social media, but not real work. We let the "cool stuff" pollute real work in cubicle-land. Oh, and git off my lawn! ;-)
I thought you meant native desktop apps, not web apps.
I remember when ExtJS was positioned in the late 2000s to mimik rich desktop UIs and I think there are still lots of component based frameworks to use and pay for, if Bootstrap doesn't cut it. The prices are steep though.
As far as developer productivity, the desktop-oriented IDE's were indeed better. Yes, you had less choice, but that didn't matter much if tried to think like a plumber instead of Picasso. The problem was that deployment and installation was a pain. Microsoft actually improved that for its products, but I believe if we had a stateful GUI markup standard, we could have very similar tools without desktop installs (other than installing a GUI browser).
Oracle Forms kind of worked like this (mostly before Java era), although its GUI control language was proprietary and not XML. Oracle Forms had its warts, but was a good proof concept for the GUI browser. Developers got a lot of work done under it.
In the case of developing a Android application there is nothing keeping you from using the tool of your choice to write the code in, and simply using what ever plugins are available to your editor of choice to run the compile steps, deployment to a device or an emulator etc. After all you only need a single line command to compile a properly configured Android project into a releasable APK.
But when I want to write my code, get correct linting, inline documentation, Java-to-Kotlin conversion of old code, the whole range of interacting with the device I am running my code on, management of my Gradle tasks, VCS integration, Task contexts, remote connections to test databases (and the whole other metric ton of features I wont get into) I will always take Android Studio over what ever flavour of the year text editor.
> Now developers EXPECT languages to come with a FREE suit of command line tools for linting, static analysis, formatting, package management and what not.
The key selling point of Intellij IDEA is they come with semantic refactoring tools, for something like "move this method into its parent class" or "extract the selected methods to a new interface", which is still rarely seen in the wild, and didn't get mentioned at all in your list, but it saves real time.
It saves real time if you write your code the way IntelliJ wants you to write your code.
If you structure things differently - say, by steering clear of subclass inheritance, or keeping interfaces small, or not using the Bean pattern, then you can pretty quickly discover that there aren't all that many IDE refactorings that you actually use.
At this point, most the refactorings and code actions that I'm actually using exist in vscode as well; IntelliJ's main advantage is that I'm (somewhat) more able to use them efficiently without taking my hands off the keyboard.
Extract interface, implement interface, extract method, move(to own file) only exist for go and c# via jet rains and are practical for anyone writing real world code.
Interesting, I'm not a Java dev (mostly C, C++ and Python) but I turned to VSCode exactly because it is more lightweight than Visual Studio. The many little pauses and delays in "Visual Studio proper" drive me nuts, and most of the features in VStudio each only serve a tiny section of users, while making the IDE slow for everyone (and TBH when I tried the various Jetbrains IDEs, they are even worse in terms of laggy UI than VStudio).
VSCode with its flexible plugin system got this right. Even though it isn't a speed wonder itself, it's still better on average than most "heavy weight IDEs" I've seen).
You can configure linters for VS Code and other editors. If it's just "what IntelliJ enables by default" then that's pretty subjective. I've seen some terrible code as a result of developers changing things just because their IDE decided the old code was smelly.
The developers in the team do not change linting rules as they want. But I am not referring at small stuff, recent things for last weeks(maybe VS code does this by default or maybe you need 12 extra extensions that makes things much slower, let me know)
- I go to fix some issue and my IDE shows me that the code is copy-pasted in 3 places so I knew I have to extract a function, do some cleanup and fix all 3 affected places.
- bug appeared other a refactor, checking the code in the IDE I can see a red variable name, it was red because it was undefined(this is in JS code)
- sometimes when using soem inner function I would try to do something like "this.something" but the IDE notices it and warns me that in this scope "this" is soemthing else
I am also impressed that it can most of the time understands frameworks and libraries like angular or jQuery
It is an old project, setting up a strict automated CI would just block us until we fix all warnings or disable them. With a good IDE you can spot the issue int the location you work, you say change most of the "var" to "let" and "const" but you can ignore the ones that are not related with the thing you are working on. With an automated thing you either fix all at once or you have to set ignore rules or write ignore statements int he code.
I would be interested to read more on how to add such a strict CI to an existing project.
I'm sure you could get the linting tool to run only on changed files (we have a pre-commit git hook that does this at work, although we have CI set up to run against the whole codebase). To be honest though, I think the best approach would to pick a few of the rules you consider to be the most important and just be suck it up and spend a couple of days fixing all the errors. It likely wouldn't take you long to make that time back.
Agreed, but for sure having a CI with parts of the rule won't be as good as having that and on top an IDE that has all the rules On and even more you can see the warning as you type not after you committed and submitted a PR.
Well sure, but text editors like VS Code and Sublime can do this too. You usually need to install a plugin but everybody I know who uses these editors installs the relevant plugins for the languages they use.
VS Code is particularly smart in that will pull in TypeScript definitions for libraries and use those for auto-completion even if you are not using TypeScript (and are using plain JavaScript).
This is definitely true. The tradeoff being that JetBrains IDEs are much slower (particularly to startup), much more resource intensive, and of course more expensive.
Startup time is bad, yes, but I think it’s a reasonable trade off for the features I get and plus I tend to launch it once and then open files with the command line tools, which is basically instant. Granted I’m spoiled on my personal machine with a six core i7, 16GB RAM, and an NVMe SSD.
> Granted I’m spoiled on my personal machine with a six core i7, 16GB RAM, and an NVMe SSD.
I think this makes a big difference. I also have 16GB RAM and a fast SSD, but I'm on a 2-core MacBook processor. I find that with all of the various different projects I have to interact with in a day (I'm the tech lead at my company) I can't leave an IntelliJ-based IDE open without it slowing the rest of computer down to the point that it's impacting my productivity.
IntelliJ rocks but you’re seriously underestimating tools like SonarQube and CI pipelines. If you’re working in a crusty old system, you will be blown away by the kinds of things they uncover out of the gate. “Strict” CI is all relative, one option is baselining your project, which adds suppressions everywhere that has errors, allowing you to track new violations and fix the old ones as you go.
I recently spent a day configuring SonarQube rules for Java and I'm not particularly impressed. It does not reveal much more than standard Intellij code analysis.
Also nice advantage of Intellij hints is that most times they also offer auto-fixer so it's very safe to apply the fixes.
If you have relatively modern code with reasonably good practices, sure. I ran it with the default rule set on a 15 year old C# codebase of about 150kloc and it found several quite serious vulnerabilities and a whole boatload of logic errors.
> Setting up eslint or related tools in a CI pipeline would let you catch these in an enforceable, consistent, decoupled way.
…minutes, hours or sometimes even days after the code was written. Not every project can run its CI pipeline in seconds, incrementally, or on the developer’s system.
The advantage of any IDE is the “integrated” part. Linting is one thing, showing the results in a way that makes it as easy as possible to act on them is where an IDE beats a DE that does the linting in a “decoupled way”.
Really? Are CI tools parsing the code and will detect that this.something is not defined here? I am presently surprised so let me know what tool does this.
Most cli tools can be easily integrated with continuous integration platforms like GitHub actions / Travis CI.
See static analysis tools and code quality one's, in php these are Psalm, php-stan, php code sniffer and others.
For JavaScript see ESLint with recommended rules from different companies, typescript with allow js turned on to analyse javascript code and other tools for statically checking css, html and more.
Do you know more? I am assuming the IDE has only one AST and uses custom tools and not running 10 different tools in background but my assumption could be wrong.
> The many little pauses and delays in "Visual Studio proper" drive me nuts, and most of the features in VStudio each only serve a tiny section of users, while making the IDE slow for everyone (and TBH when I tried the various Jetbrains IDEs, they are even worse in terms of laggy UI than VStudio).
I don't know how long ago you tried Rider, but after more than a decade of using Visual Studio I had had enough of the lag, broken features and instability - I moved to Rider, and couldn't be happier. In fact, I'd say it's one of my favourite ever pieces of software. It obviously loads much slower than VS Code, but then in operation if feels snappier and never lags. I've also never once had a release version crash, which for such a complex tool is pretty impressive.
I use it every day, but onyl for it's CMake support, syntax highlighting and 'go to definiton' etc functionality. I don't use it for building though, that's still done on the command line.
I did! Mainly on Linux because QtCreator is one of the very few Linux IDEs where the debugger worked out of the box (now I switched to VSCode too there, mainly because it allows the same development environment across Windows, Linux and Mac).
True, QtCreator performance is fine. But I found the whole toolchain integration (Kits?) and cmake integration a bit weird if I remember right.
Java people always tout their advanced IDEs as a major benefit of working in Java. But the thing is that Java is a language that is unusable without a strong IDE and that is not an advantage.
Unusable? I wrote java with a text editor for three years and got a lot done. I wrote C++ for about 10 years with a text editor (It was called an IDE but it was a text editor with a debugger).
But having a language that enables the functions of an IDE is a big advantage. A good text editor that manipulates characters efficiently is absolutely valid. But an IDE that treats code as an AST gives you a lot. After all when you think of code you think of it in trees/graphs: You go to fix a bug, one of the first things you will probably ask is "what calls this code?". Being able to do that, right up to the top of the call hierarchy, instantly, without having to run the system is a huge advantage.
An IDE gives you the tools to reverse engineer the design (or lack of it) from the code.
> You go to fix a bug, one of the first things you will probably ask is "what calls this code?". Being able to do that, right up to the top of the call hierarchy, instantly, without having to run the system is a huge advantage.
This is indeed useful, and languages with semantic IDE tools are indeed better at it. But this works for me in JavaScript 90% of the time with just text-based (and I think it probably tracks imports) tooling.
One should always strive to use the simplest tool that gets the job done. Java comes with an insane stack by default. Not only must you understand all those parts (the vm and IDE), you must have a strong enough computer to work with it. Java developers always need the beefiest most expensive machines to work.
No, I don’t think this is a supportable assertion. The “simplest tool that gets the job done” is obviously a ridiculous over-simplification, since even Notepad will allow you to write Java apps. The choice between different development tools is down to the specific environment, developer requirements, and preferences.
Also it’s not 2000. A Java IDE will work fine on any computer you can buy.
IDEs can help to learn programming and can facilitate exploration. Step-by-step debugging and refactoring are a crapshoot in less advanced editors, but both are powerful learning aids if they are easy to access - which they are in IDEs. Both IntelliJ and Eclipse are very easy to explore - just point-and-click, no need to set anything up if your language is well supported. Experienced devs also benefit, since IDEs are made to manage and navigate complexity that will inevitably show up in any mature codebase.
Your runtime and tooling will always be a dependency, and you will always have to learn enough to troubleshoot it regardless of the language. PHP, JavaScript, Ruby and Python are no different to Java - the SDK must also be installed and kept upgraded, you still have to fix your application to work with a newer runtime when the language changes or when fixes are backwards-incompatible, and your SDK version might still clash.
Performance is not an issue in practice. I only ever noticed IntelliJ being slow on a machine that was too slow to run a web browser, and I don't think that such machines would be very common because people would just get rid of them. Resource use has ballooned over the past few years due to the rise of Electron, so your machine already needs to be powerful enough to run Discord, Slack, Postman, or whatever other applications you wish to run in parallel. Adding a JVM alongside that is not much of an ask, given that IntelliJ consumes around 500 MB with two fairly sizable projects open.
> One should always strive to use the simplest tool that gets the job done.
why in earth would you think that. we get further as a species because we develop more complex tools to achieve our goals, be they nuclear reactors, smartphones, etc.
Simplest tool that gets the job done does not mean it is simple. There's still the the part that gets the job done, so it still can be essentially complex tool.
Accidental complexity, on the other hand, will only slow you down in the future, or even make you incapable to continue further development.
In a professional sphere, appropriate tools are the best one can afford (i.e. the best that justify their cost).
Simple tools are only appropriate for cheap, low-value projects (e.g. don't set up an IDE and build automation when some trial and error with Maven to compile something occasionally is enough).
It's very naive to assume that just because the general category of the base material is the same, the construction techniques are similar. Even the materials are not actually the same, modern bricks are a lot more complex than basic bricks. I doubt any civilization even 500 years ago, let alone thousands of years ago could have made them. And we make them like this for reasons such as increased durability, better thermal insulation, probably reduced production costs, etc.
For all intents and purposes a modern brick might as well be carbon fiber compared to ancient bricks.
I don't think Java the language is particularly unusable without an IDE compared to eg ad-hoc approaches extending weakly-typed languages with type annotations such as TypeScript and Python (while not 100% relevant, I even refactored maven+ant driven builds into Makefiles calling plain javac *.java as recently as a couple months ago, using vim as code editor).
Java IDEs are so thorough that I learned Java from NetBeans autocomplete rather than any tutorial.
Which is not to say that my understanding of Java extends to working professionally in it; I'm a functional programmer and broadly unfamiliar with modern Java's specific patterns.
Conversely I'd say that a language that doesn't enable an IDE to provide some of the features Java does (first and foremost: call graphs) is unusable, period.
Java developers seem to habitually use metaprogramming facilities that make it impossible to determine what code is calling what other code by hand, let alone using single command in an IDE. When not doing this, they are usually creating interfaces with a dozen implementations that wrap and delegate to one another. So I would very much like to know what calls what, and this is a reason I cannot use Java.
> Java developers seem to habitually use metaprogramming facilities make it impossible to determine what code is calling what other code by hand
I assume you mean reflection - this would be very untypical for normal business logic code and would get smashed very quickly in any code review. It's also far from nice and easy code. You can program "dynamically" in Java, but it gets ugly quickly which in itself discourages you from doing that habitually.
Reflection is used mostly in frameworks only.
> When not doing this, they are usually creating interfaces with a dozen implementations that wrap and delegate to one another.
Sure, Java devs have so much time that they don't implement the business logic once, they create dozen different implementations just for the fun of it. Again, this situation (one interface, many implementations) happens mostly in frameworks and rarely in business code.
If you want to hate on Java, use some real arguments ...
> I assume you mean reflection - this would be very untypical for normal business logic code
No, a lot of java critics complain about it being hard to tell what's calling what at the framework-to-user-code boundary
That means not only reflection, but also most Dependency Injection (Spring autowiring, Guice...), anything that runs on annotations (including @Test and JAX-RS), any code auto-generation (e.g. Protobufs, Jooq), most mock libraries (e.g. Mockito) and most configurable logging, especially the logging libraries that try to auto-detect one another.
Of course, some would say those problem are with Corporate Java Culture choosing to use all those things, rather than the Java language itself.
The loosely coupled metaprogramming of frameworks like Spring is an indication of how feature-poor Java is in those areas. Autowiring and mocking should be first-class features with dedicated syntactic elements, rather than something that's handled by third parties with opaque annotations that mean nothing before the application is run.
I understand that Java wants to remain conservative with its development roadmap, but the fact that the majority of an ecosystem uses a third-party framework is a good reason incorporate something similar into the language.
> No, a lot of java critics complain about it being hard to tell what's calling what at the framework-to-user-code boundary
That's rather an industry criticism since these problems exist everywhere and are often direct consequence of trade off for looser coupling.
There are also often alternatives - e.g. Dagger for DI and MapStruct for mapping which go the code generation path which allow you to statically inspect the whole code path, you can also always trade the looser coupling for more directed paths e.g. for logging by avoiding the wrapper and using a logging library directly.
> That's rather an industry criticism since these problems exist everywhere and are often direct consequence of trade off for looser coupling.
No they don't. Java is just not expressive enough, so library/framework authors have to decide between bloat or magic and they often choose magic for better or worse. There are languages that doing better in this regards.
As we are talking about Java, the closest language would be Scala. The language is much more flexible and powerful. This brings different problems onto the table, but it resolves the issue with awkward framework annotation/wiring problems that I have experienced in Java way to often.
> Of course, some would say those problem are with Corporate Java Culture choosing to use all those things, rather than the Java language itself.
I'm not sure this is necessarily a culture, either. Java tends to be picked more for applications with more demanding/richer requirements, and so they need to do a lot. This demand for features drives a demand for richer frameworks. You see this exact thing happening with JS on the client. So to the extent this is a problem, perhaps it is a general software design problem.
The main metaprogramming facility in Java is annotations. Some annotations work like higher-order functions, except that my advanced Java IDE is unable to find what function is wrapping the annotated function. Some other annotations work more like macros, but there's not a convenient way to evaluate the macro to have a look at the code it would generate.
I previously asked in another forum about this sort of thing and heard that I should read the docs. I suppose when working at a big company ships internal libraries that expose annotations and use inheritance extensively, but do not have docs, I should just pretend that I am not actually in such a situation, or something.
> Some annotations work like higher-order functions, except that my advanced Java IDE is unable to find what function is wrapping the annotated function.
Intellij can show you which aspects have been applied for e.g. AspectJ or Spring AOP.
I mean if you or your company really insist on writing your own metaprogramming library then yes, IDE can't do much to help you, but that hardly represents industry practice.
It's funny, because I always complain about interfaces with just one implementation, I've never complained about an interface with dozens of implementations :)
This is a real world problem, and I say that as someone who has been doing Java and Scala for many years. When you are exploring code trying to figure out how it works and what it does, it's easy to follow the chain of what method is this, where is it implemented, where is this symbol imported from, etc. Subclassing introduces some ambiguity in method parameter types, but at least you can get some information from the documentation of the interface or abstract class, and you can find usages of the method and see what concrete types are passed in different places. Where it really breaks down is dependency injection and annotations. When you hit these, it's no longer "command-click" or "google for Javadoc" to find out what's going on; it's a minor research project. With annotations, if you can't find the information you need in the documentation, you will have to search the source code of the framework and study the code that processes the annotation before you can even locate the code you're looking for[0].
You might be thinking this is pretty awful, but hey, software is complicated, you have to understand the code you're working on —- fine. It's reasonable to put this amount of effort into the code you are actually working on. But when you're working on service A and have a question about service B, it's nice to be able to pop over to service B's source code and find the answer without investing a lot of time understanding the technologies underlying it.
This is why "enterprise" Java programmers end up obsessed with anointing "best practice" frameworks. Me relying on a big magical framework for everything I do is only problematic because some other people don't use it. Solution: let's establish my framework as the "de facto standard," and then nobody can complain that it's ridiculous overkill for simple applications. Let's make proficiency with my preferred framework part of the definition of being a professional Java developer, and then nobody can complain about how time-consuming it is to get up to speed with it.
The alternative is to use libraries instead of frameworks, use as little magic as possible, and work in a language that is powerful enough that you can write straightforward code and still say everything you need to say in a reasonable amount of space.
Consider the simple, ubiquitous case of writing a method to implement a POST endpoint in a database-backed CRUD web service. Suppose you need to authorize the request according to some business logic, deserialize the entity body, validate the body according to some business rules, get a database connection, construct a query, run the query, process the query results into a response object, set the status code and headers for the HTTP response, and serialize the response body. Why shouldn't all of this functionality be discoverable in the code via chains of method calls from the method that implements the endpoint? With a concise language and a well-organized codebase, this is entirely possible. Readers of your code can see: here's where to dig in if I want to see how the request is deserialized, here's where to dig in if I want to see how the database query is constructed. If your code becomes exhaustingly verbose when you express it in this straightforward way, then your language is failing you.
As a fan of Scala, I have to admit that Scala introduces a similar difficulty with implicits (and the horrible practice of using wildcard imports to import entire menageries of implicit methods and values, which is epidemic in FP-style Scala.) Implicits are indisputably widely abused, but at least IDEs can show you how implicits are resolved at compile time, and in your own code, you can make implicits reasonably readable without IDE support by declaring them in an enclosing scope with a good name.
[0] I'll make an exception for one style of annotation: annotations that point you directly to the relevant code, like @ExceptionMapper(MyExceptionMapper.class). This is almost always all the information I need, the only exception being if the person who wrote MyExceptionMapper misunderstood some subtlety in how it gets wired in via ExceptionMapper.
A lot of problems with modern programming can be traced to the "pipe compiler" like model, where your development environment is nothing more than a file editor with a shortcut to run the compiler. It doesn't understand the code, and it can't really help you, and the compiler only really outputs errors.
Java is perfectly usable without an IDE. Just like any other language is usable without one.
The question is: why? Why would you not use an IDE? Looking at refactoring capabilities alone you'd want those for any language [1] And on the fly actionable code analysis [2]? Why would you not want that for a programming language?
I guess it is partly the design of the application: Enterprise Java apps often contain lots and lots of classes and have deep inheritance trees. So if you have a piece of code that says "foo.save(a, b);", then which of the 132 different "save" methods that your codebase contains is being called here?
And because Java is statically typed, this enables you to do things like changing the name of the "save" method in 83 of the different 132 instance, namely the method from class "Widget" and all its subclasses. And, of course, update the right callers.
If you are doing Python or JavaScript, you often don't have much of a clue what the type of "foo" is in that "foo.save(a, b);" call, and so you don't know which of the "save" methods are being called. And you know that when creating your app, so you stay clear of class hierarchies that require this IDE functionality to untangle :-)
> I guess it is partly the design of the application: Enterprise Java apps often contain lots and lots of classes and have deep inheritance trees. So if you have a piece of code that says "foo.save(a, b);", then which of the 132 different "save" methods that your codebase contains is being called here?
Deep inheritance trees came out of fashion (everywhere, not just in Java) long time ago. Inexperienced developers can misuse inheritance in Python just like in Java.
> And because Java is statically typed, this enables you to do things like changing the name of the "save" method in 83 of the different 132 instance, namely the method from class "Widget" and all its subclasses. And, of course, update the right callers.
As opposed to Python or JS where "we don't know for sure so it's gonna be safer to not refactor".
> And you know that when creating your app, so you stay clear of class hierarchies that require this IDE functionality to untangle :-)
Inheritance in JS is not widely used since even the concept of classes is still very new and technically not safe for use (not supported in IE), not because JS devs are somehow wiser and self-limiting themselves to one level inheritance.
(unless you mean prototype based inheritance which is very different beast)
> unless you mean prototype based inheritance which is very different beast
All inheritance in JS is prototype based inheritance. The class syntax is just syntax sugar prototypes. In theory you can do all sorts of crazy things with prototypes. In practice people use them just like classes. The reason people don't use inheritance in JS has nothing to do with browser support.
> All inheritance in JS is prototype based inheritance. The class syntax is just syntax sugar prototypes.
And async/await is promise based yet it results in quite different programming style. It doesn't matter which primitives are used for feature implementation.
> The reason people don't use inheritance in JS has nothing to do with browser support.
I don't think so. Since the advent of ES6/Babel/TypeScript I see inheritance on frontend daily.
I do a lot of work with Emacs and it's my preferred text editor. I think of myself as productive with it and I do a lot within Emacs; for instance using Magit to work with Git. Typically I'm working with Python or Clojure.
That said, when I need to work on a Java or C# project I put Emacs aside and reach for my preferred IDE. There is overlap between a text editor and an IDE; certainly I can _make_ a text editor do _most_ of what I get from an IDE but is it really worth the effort?
In my opinion, IntelliJ is on point here in some cases; I suspect developers coming from a background in front-end or a language like Python or Ruby are very comfortable with their text editor and tend to use these same tools for work with Java or C#. In this case it is likely that they are to some degree unaware of the benefits of a more integrated IDE.
In terms of CI integration, in my experience this has never been a problem (I have never really used Eclipse). My Java IDE uses the Maven configuration to manage the project and the CI process calls Maven from the command line. In the C# environment, the command line tools works in a similar way.
This is the place I'm in too. In projects more under my own control, I use Emacs for JS and Clojure.
At work, I deal with JS, Python, and Java. I don't really care to spend the effort to configure Emacs to handle all the oddities of a super old codebase reliably. I just grab vscode or intellij. They're fine.
I am the same way. I use emacs for git, org notes, small adhoc scripts, but for actual project work – IDE, hand down. I have converted a long time emacs user to try PyCharm once. He was skeptical for a long time, then he switched.
Indeed. I hate it when my code runs in an IDE and not from command line, or vice versa. Maven, custom JAVA_HOME and JVM arguments, conda environments, ... are a pain to integrate across different environments, especially since every IDE does its own thing.
Pretty easy to use and IDE to dev stuff and just run it on the command line. I used to do that all the time. You aren't forced to actually run the software through the IDE.
Depends. IDE is usually just invoking the build tool chain. That usually can be invoked from CLI too. Like for Java the gradle or maven stuff or .NET the MSBuild stuff.
I sort of mix and match depending on what works best for a given project.
While they're very obviously in the "competition-induced" panic, there is still a point.
The disconnected VSC model - main company in charge of the editor, and third parties in charge of certain language plugin[s] - puts some languages' support at risk of being insufficiently developed.
I "only really want advanced editing + syntax highlighting + language server", and use VSC, but, while its support for "statically typed languge #1" is ok, the support for "dynamic language #2" is atrocious, to the point of being unusable (poor "go to definition", editor aggressively misaligning lines of code, etc.). I'm not sure it will ever reach sufficient support.
On an IDE, this doesn't happen, because the developing company must, within a certain qualititative extent, take care of all the functionalities.
I'm not sure what your definition of an IDE is, but the notion of a core platform with language-specific extensions on top long predates VSCode. Visual Studio proper works in exactly the same way, for one; and then there's Eclipse, NetBeans etc. If anything, this has been the conventional way to do IDEs since early 00s or so.
With Code they’re running out of process and communicating via IPC/RPC most of the time which introduces instability that I’ve never experienced in Visual Studio, Rider, or IntelliJ
There are many things in Visual Studio that run out-of-process, and coordinate via IPC. It's an implementation detail, and does not change the fundamental approach.
Also, many things in VSCode can be done in-proc as well if one so desires, including debuggers and language servers. Most extensions do them out-of-proc because it gives them more flexibility (esp. wrt implementation language for those components), and because it's easier to test such isolated components.
>IME a lot of developers don't like their IDE heavily coupled to backend servers and environments, but actually prefer the "code editor + useful features" approach
Personally, I use VSCode for generic text editing, scripting, taking markdown notes, general purpose review/browsing repos (e.g., opening up a project to review a couple of python classes), etc. It's nice for switching between a variety of languages and use cases. I like the integrated terminal, the directory search feature (so much less clunky than the equivalent Mac Jetbrains IDEs' features), the multiselect text editing experience, the ease of configuration, and the general responsiveness.
But if I need to do a deep dive on a language, I generally switch to a fully featured IDE. For example, if I need to refactor 10000 lines of C#, I'm definitely going to switch to Rider or VS with Resharper where the built-in refactoring, debugging, and static analysis tools are so much more powerful.
So really I see them as different tools for different use cases. VS Code is nice for my fluffier, tech lead work, where I tend to bounce around between fifty disparate tasks in fifty different contexts. Rider, Pycharm, CLion, etc. are more useful for me when I have to fall back into doing deep dive technical work personally.
This is pretty much exactly how I use VS Code and Rider too. I find VS Code great as a general text editor with syntax highlighting, and for searching files, writing markdown etc. But for real work, I want a real IDE (Rider) with a debugger, refactoring utils, cloud tooling, database tooling etc.
Seriously? They should have a look into what VS Code (and friends) can actually do! Once you outsource your refactoring machinery into something like TypeScript or Roslyn (C# Compiler) you suddenly have these features available everywhere.
And in that regards, the should also just look what their Resharper Product is doing in Visual Studio and JetBrains Rider.
I think the only lack in editors is visualizations. I think that will be soon a theme in VS Code ;)
I’m a big user of C# and no, despite the language and the editor being developed by Microsoft, the IDE support in VSCode is poor to say the least. For one it doesn’t even support solutions with multiple projects which requires to open another instance of the editor for debugging. Then there is the constant red highlighting that appears in valid files. Then the installation of Ionide tools in C# project... the list goes on, with extensions not working properly yet being required for basic things like XML formatting, the annoying default settings that require Googling because of their naming, the poor performance because it’s an Electron app, etc.
VSCode, when it works, gives one a glimpse of what you be a good IDE (Visual Studio proper, JB Rider), yet is light-years away of being one.
Well it is still developed. It will get better over the years to come.
I was addressing the c# refactoring s. They were delivered with roslyn to VS and exposed to VS Code via OmniSharp. The gap of C# refactoring in the VS 2008/2010 era is due to the Roslyn project blocking all other efforts. So C# refactoring are only realized via Roslyn Analyzers and with that available to VS Code.
And VS Code is executing them nicely. There is no gap.
A transcript of a talk by Charles Petzold that I think is relevant to the conversation in the replies to this comment: "Does Visual Studio Rot the Mind? Ruminations on the Psychology and Aesthetics of Coding"[1].
It is not heavily coupled to backend servers and environments. Disable all plugins and it'll be pure Java IDE. That's what I'm doing: I'm very careful about Idea plugins. For example I don't use any Spring plugins even when I'm developing Spring projects. Spring without XML is just Java code and I don't need anything else to be productive.
The Delphi, C++ Builder, Forms/WPF/UWP, Swing/JavaFX soul in me begs to differ.
In fact that is the biggest pain in Web projects to this day and I can hardly wait for stuff like Uno and Blazor to bring "Flash" back, if Web Components don't do it first.
After reading your comment I've spent a good 10 minutes trying to find out what are RAD tools (seems to stand for Rapid Application Development tools).
Still no idea. Seems to be a synonym of IDE, but not really?
Think Visual Basic, Lazarus, Delphi, C++ Builder, etc. RAD IDE is essentially an IDE which has deep knowledge about the language and allows for visual design of the GUI - among others.
For example in Lazarus, Delphi and C++ Builder when you edit components in the visual editors (be it the form editor for making a GUI or a data module editor for non-visual components - e.g. editing the routing for HTTP requests in an fcl-web application) you are actually editing live objects which are serialized as part of your application when you save the project (contrast this to something like Qt Designer, Gtk's GLADE or wxFormBuilder for wxWidgets, which only create stand-in controls that pretend to be what you are designing). The IDE exposes the properties and events of those components by using their RTTI information of the object instances directly (instead of hardcoded knowledge of using some configuration file) and it has full knowledge of the source code you are editing so that it can automatically create event handlers, functions, variable declarations, etc for you (no need for special comments or whatever) as you edit the components and the code (this isn't just for component editing btw, in Lazarus you can do something like start writing a `for I:=0 to 100 do` loop, then move the cursor to the `I:=` part, press a key and have the IDE deduce the type and declare the `I` variable if it is missing).
One way to think of it is like if you are making a game in Unreal or Unity where you also work with live objects, but instead of those objects being levels, pick up items and monsters, they are forms, modules and buttons for your application.
This is why it's worth contributing to your language's LSP server[0] and why I encourage every Kotlin dev I see to contribute to Kotlin's[1].
I personally find IDEs are way too complex and cluttered for my personal tastes. To boot, a code editor allows for unified workflows across a broad swathe of languages in ways that IDEs simply can't replicate. It's a pity Jetbrains has long held a dismissive attitude[2] toward developers that don't want a full blown IDE, but that's what you get when there are financial incentives attached.
>you really get a lot out of a good tool that has integration with the application server
I like the really powerful code completion and refactoring tools a good IDE brings to the table but this one strikes me as extremely odd. In 2020, I would want all IDEs to remove this kind of functionality because I don't want to deploy from my IDE ever and I don't want teams that work with/for me to ever use it either. I want to push my git commit and have everything building in my CI/CD pipeline.
I share the sentiment with IntelliJ and I'll never understand the crackheads who use VSCode/Sublime/Atom for strongly-typed languages instead of a proper IDE like Netbeans/IntelliJ/VS.
It's absolute pain to write Rust/Java/C++ in any of those. No safe refactorings (moving classes? good luck), completely random code completion, 0 awares of available libs/SDKs, and so on.
It would seem that most of the developers have no clue what's the difference between a lightweight editor and a full-featured IDE. I think it's just Dunning–Kruger effect on a scale.
I understand that I'll be voted down into oblivion but it really rubs me the wrong way when people confuse some kind of server/application server (???) integrations with an IDE that can offer sophisticated refactorings, a proper type inference, and can infer which functions from which lib/SDK I am using.
Completely agree. Sure, any editor can be paired with static analysis tools to make sure I probably didn't break things, but only a full IDE can just handle the refactor for me so that I don't have to spend time searching, fixing, and checking to begin with.
No, I don't need or use all the IDE features. I don't use the integrated shell, I don't use the git integration, I don't have it handle my packages. I don't see a need for these things when I always have multiple terminals open anyways, but proper code intelligence is not something an editor+plugins can provide like a real IDE can.
Sounds like you're unaware of LSP (Language Server Protocol). "Proper code intelligence" is absolutely something that an editor+plugins can provide, and LSP means that intelligence can be developed once and used with many editors, rather than "integrating" the editor with the code analysis so your choice of one dictates your choice of the other. LSP is just one of those things that makes sense, turning something quadratic into something linear.
I don't care at all if someone prefers IntelliJ over Emacs (that's a pure matter of taste) but the idea that it's impossible for an editing environment that isn't delivered as a single, integrated monolith to expose powerful language-specific tools such as interactive lints, large scale refactorings, debuggers (check out DAP for the debugging equivalent of LSP), etc was never true as a technical matter and is increasingly untrue in the real world.
One of the best developments in dev tooling in recent years is that it is starting to be seen as the norm for new languages to provide canonical language server implementations. Long may that trend continue.
Language server protocols are just re-inventing IDEs, but instead of using shared memory and interacting with the compiler directly you have to use an inefficient JSON pipeline.
No, the choice of a client/server model was a design decision, one that is not unique to LSP and is also used by some IDEs for various reasons (see, for example, JetBrains Rider). Performance is absolutely fine - the only data that needs to be transferred is that needed to drive the UI, which is trivial over a local socket. Had that not been the case, there are plenty of ways LSP could have been designed as an in-proc library interface and remained just as open as it is.
What makes LSP not 'integrated' in the sense of the I in IDE is the fact that it is decoupled from the editor, allowing one editor to work with many language servers and one language server to work with many editors.
> No safe refactorings (moving classes? good luck), completely random code completion, 0 awares of available libs/SDKs, and so on.
Seems like you haven't used VSCode in a long time. It is my primary everyday editor for Typescript, and it has all of those things you listed: I can move a class to a separate file in one click, code completion always follows type system, it is aware of all packages that I have in package.json and offers to import them, and so on.
The IDE/editor distinction really doesn't have as much meaning as it once did.
Try to use it for python or c++ and you will see the problem. I switched to clion as I work in node, python and c++. vscode python support is bellow average and c++ support is bad. clion works great for all those environments.
My biggest problem with vscode is lack of UI configuration. You can have only one panel which is huge waste on big screen. Some useful features compete for screen space (outline vs. project explorer, project explorer vs. debug window etc.). This makes me way less productive than using heavyweight configurable IDE.
I use VS Code on a daily basis. It's my go-to tool for config-based projects (Kubernetes), simple and quick HTML/CSS editing, and the likes.
I've tried it for more serious development for Rust, Python, and TypeScript. While for Typescript the inference is barely acceptable it complete sucks for Rust/Python.
I use vscode daily and recommended it, but to be fair, it's heavily optimized for typescript. The feature may be not available for other language such as java.
This is true, but it demonstrates that VSCode extension model supports this, and nothing stops extension developers from attaining the same level in any other language. Hence my point about IDE/editor distinction.
Sure, why would it not be possible. Intellij and Eclipse also implement all their language support in plugins so why wouldn't VSCode.
But the thing is this is all hypothetical - it is possible if somebody invests those thousands of hours into it. But so far it did not happen for most languages and Intellij IDEs are still vastly superior to VSCode for e.g. Java, Python or C++ development.
Referring to them as "the crackheads" might be a barrier gaining understanding of their choice of tools. :-D
My guess is that was intended as hyperbole, like saying you think they are "crazy" for doing so. Still, I'm thinking you'd be more likely to get interesting feedback by stepping it down a bit.
>I think it's just Dunning–Kruger effect on a scale.
I find it incredibly pompous that you believe that people who have been writing C++/C even Java for decades in editors like Emacs, Vim or even Sublime don't know what they are doing. The IDE vs Editor argument is nearly as old as Emacs vs Vim.
I've seen people who have been on vi/emacs for decades. They truly have zero idea of what an IDE can do.
As a personal anecdote, I've seen people switch from vi to IDEA after a pair programming session. In that session they learned that IDEA has full understanding of the frameworks, configurations, code annotations and bindings etc. that we used in a project, and that you don't need to spend 15 minutes furiously searching in files for stuff when you have to change something in two or more places.
This is a pretty weird take. I've always used two tools - one full featured IDE for whatever project I'm working on, and a more lightweight plugin enabled text editor for SQL, writing notes, markdown etc etc. VS Code has become my goto for the latter, but I can absolutely see myself using it as the main editor for a project. About the only IDE I really can't tear myself away from is IntelliJ for Java - everything else is just ok.
I can use the tool I’m already familiar with, that also supports other languages, that has a huge number of extensions and configuration settings, etc. I personally see this as more important than an IDE, that’s why I for example use VSCode instead of Visual Studio (on windows).
> IME a lot of developers don't like their IDE heavily coupled to backend servers and environments
I think the issue is more how snappy/bloated they are. I don't mind all the integrated features, but IntelliJ has gotten slower and slower over the years, and its starting to get annoying, especially on anemic laptops.
I personally saw no value in intellij compared to what vscode offers.
VScode has won both the intellij Vs eclipse AND vi Vs Emacs holy wars for me. Nothing else matters anymore (unless you need to SSH directly into a box and make edits there of course, for which we have vi) - it really is an amazing editor in my view.
I can't see the need for an IDE like intellij at all when you have an "editor" as capable as vscode.
100%, I'd much rather use the command line if I need to work with Docker, or a database, or the cloud. IDE integrations for these things are limited and have just never worked with real-world projects. I slept on debuggers for too long though; Java debuggers are brilliant.
I still use Netbeans for Java. It's simply the best.
I use VSCode instead of IntelliJ products because it's lighter-weight and I don't have to learn about or fuss with settings. What am I missing out on? Can anyone give me a good blog or video? Not knowing what I'm missing, I'm willing to invest about two hours.
The author clearly should have gone into the specific use-cases he was talking about. An IDE _is_ nothing more than a text editor with advanced features. There's a huge continuum from a basic text-editor like notepad to a full fledged IDE.
I'd particularly like to see a use-case laid out where something like VSCode + Extensions wasn't actually enough. I've been using IntelliJ nearly every day for the past 4 years and I still don't understand how it is any different from a text editor + extensions. IntelliJ is even architected similarly with so many different "plugins" adding full fledged language support for other langages. Goland, Pycharm, etc, are basically extensions for the intellij text editor.
VSCode is 100% free. IntelliJ has a free and enterprise license. I could download the free one, but I feel like I'm missing out on features and would rather go with the option that has everything free. Then I don't have to worry about it. Even though it may not be as good.
The last time I used a Java IDE was in university in 2012, and I've never really touched it since.
I've been recently using VSCode with TypeScript (and Prettier/ESLint). TS is pretty neatly integrated with VSCode, and I've been wondering how similar the VSCode + TS combo is to writing Java on an IDE like IntelliJ?
IME a lot of developers don't like their IDE heavily coupled to backend servers and environments, but actually prefer the "code editor + useful features" approach. It makes combining with CI/CD a lot simpler for one, since the activities run on a project can simply be the same as those run on the pipeline. A quick "mvn install" is often enough for many/most modules. Many devs only really want advanced editing + syntax highlighting + language server.