I think what the parent meant was that VSC (along with Atom, and to lesser extent SublimeText) is a good example of "the middle way" that is rapidly gaining popularity. First we had console editors, but they weren't powerful enough, especially for newer languages/frameworks. Then we had full IDEs (VS/Eclipse/IntelliJ), but they got to be slow and clunky. Now the trend is toward "enhanced text editors" (VSC/Atom/ST): editors that can have modular plugin functionality and interact with the console so you don't lose any of its versatility. They're usually faster and more lightweight than IDEs but keep most of what you need. The parent is saying that Eclipse was the flagship of "Generation 2" and VSC is for "Generation 3"

And remember, no one is saying you have to use these programs. Console editors and IDEs will still be here. This is another option for people who want it, which has turned out to be a lot of people.

What part of the IDE's is slow and clunky. Is it just startup you're talking about or other parts? I'm a heavy Intellij user as well as vi user and, apart from startup, don't notice any speed differences.

When you've got 10 subprojects open and every few new lines of code you save your file, resulting in a build triggering a cascade of plugin actions and more than a few seconds of mouse spinning, then yeah IDEs are slow and clunky.

When my IDE stops working one morning because yesterday's system crash resulted in a plugin being unable to load properly and subsequently peppering me with dialog boxes or worse, crashing the IDE, then it is definitely clunky.

When I just want to do code browsing across 500,000 lines of code and it takes 2-3 seconds every time I hover over a symbol just to populate the object list, that is slow.

Your experience sounds great. My experience has been that every IDE configuration falls into rot after 6 months to a year or so and the whole thing needs to be deleted and reinstalled. That's also slow.

Meanwhile, vim+ctags+gdb have given me years of reliable service. More than once I've had an IDE collapse into a pile of errors and turned to my trusty basic tools, only to leave the IDE as the steaming mess that it turned into for weeks or even months as I just didn't need that browsing or inline debugging power at the time.

It seems to me that if you were to disable the plugins, then you're kind of back to the equivalent of vim+ctags+gdb functionality. So, when saying an IDE is slow and clunky compared to an editor aren't you comparing apples and oranges?

Have you considered disabling some of those plugins? the functionality they give you is not worth the performance hit. Using an IDE does not mean you can't use the terminal at all.

I kind of agree with this. The thing is, Emacs has always been "Generation 3" in your terminology. Atom and VSC are kind of bringing the Emacs way (extension language is implementation language, not restricted to a narrow plugin API) to a new generation, along with the graphical experience that Emacs doesn't provide (yes, I use GUI Emacs. Yes, Spacemacs is nice. Atom with Material-UI plugin is still prettier).

I'll be an Emacs user for life, but I am currently recommending Atom to people wanting to move away from language-specific IDEs and dabble in a text editor, because it has enough of the Emacs nature while not being too daunting.

What I'm taking issue with is the description of VSC as "changing the way we code on Unix/Linux". Given your interpretation, Atom and SublimeText and other tools predate VSC and fill much the same role. So I don't see VSC as being transformative in that way. That's not to say it might not be a nice tool, but it's not a revolution either.

I understand; I just think you're being a little harsh on the OP, even if their language was a bit exuberant. They said they tried Atom and found it too slow, so if VSC was the first "3rd gen editor" (a term I just made up) that was usable in their workflow, then for them, it is a revolution. Assume good faith when comments are ambiguous :)

Yep, that's what I meant, earlier I didn't have such an awesome text editor with git inbuilt, eclipse is clunky and stuff, vi and emacs are too hard to learn, didn't have that much time to learn every small stuff that vi can do, so vscode changed the way I write code, and for most of the "new" developers, it will change the way they write code, gone are the days when you are staring at the screen wondering what was that shortcut. at least for developing webapps

Eclipse is not a code editor. It's an IDE. It offers a bazillion things out of the box (a lot of it that VS doesn't do without Resharper), but you're going to pay the price in terms of performance and RAM, sure.

I would strongly suggest that at some point in your career, you take the time to learn either vi or Emacs, even if you still use VS Code everything.

I do use vi, it is amazing, but if I want to develop a large web app then I'd rather use vscode and use vi when I am in the geek mode and don't have to manage a lot of files. Thanks for the tip :)

> First we had console editors, [...] Then we had full IDEs [...] Now the trend is toward "enhanced text editors" (VSC/Atom/ST): editors that can have modular plugin functionality and interact with the console so you don't lose any of its versatility. They're usually faster and more lightweight than IDEs but keep most of what you need

Emacs has functioned as an "advanced text editor" for at least 20 years and probably longer. There's a very common misconception that Emacs is a "console editor", but the reality is that when you first launch it in a windowed environment you get something that looks an awful lot like Sublime, VSCode & Atom: a text editor window with a menubar and toolbar similar (yes, it's not perfect!) to what you'd expect from any other editor native to your chosen platform.

The time investment involved in learning how to use it is also considerably less than implied elsewhere in this thread. In fact I really doubt that it's significantly more than you'd have to spend educating yourself about any other "advanced editor"'s configuration, keybindings for non-obvious actions, extension mechanism, etc. It's easy enough to learn the (admittedly unconventional) keybindings for a handful of common things like opening and saving files when you have the menus to refer to, and by default it'll even open a buffer containing clickable hyperlinks to helpful things like tutorials. I still haven't seen an editor or IDE with better built-in help.

Even configuring Emacs isn't all that hard: there's a built-in interface for installing packages, most of which will pretty-much auto-activate once installed (i.e. less need to mess around with elisp), and for changing configuration there's "customize", which is a nicer way to change configuration variables than just editing a JSON file. When you do have to start writing some elisp code (you'll almost certainly have to write a little) the documentation is superb and there are more than enough resources on the web to help you. A programmer who is already familiar with a dynamic language like JS will probably have less trouble learning elisp than a C programmer did 20 years ago.

None of which is to say that there aren't areas where Emacs isn't behind. I'd like to see better support for projects, snippets and auto-completion out of the box, as well as being more nicely pre-configured for popular languages like JavaScript and Python. Emacs 24 is four years old at this point, and that's a very long time for any developer tool to stay still.

These days I'd say the most confusing thing about Emacs is working out which of the many competing packages you should choose for whatever it is you're trying to do. Age is working against it here, because what was the almost-universally-recommended package five years ago - for which you'll get plenty of helpful google search results - has often been superceded by something better.

But with a handful of plugins installed (yasnippet, helm, projectile, auto-complete) it's (IMO of course) still the best editor out there.

Emacs doesn't have tabs. You can spin that any way you want: that tabs are an inefficient system, that tabs are limited, that Emacs offers more powerful systems but right now Emacs doesn't offer non-manually managed tabs respecting the tabbed interface convention found in any mainstream editor or even mainstream application (web browsers, etc.).