Why not just use an IDE if you want IDE features?

After I posted about my Sublime Text 2 git plugin I got one response which I thought was worth responding to.

That looks helpful, but I often wonder why not just use an IDE if you want IDE features.

Obviously I have a bias here, but I’ll try to be fair to IDEs…

An IDE is an editor that does a lot of things, many of them well. If there’s something you want to do it’ll almost certainly let you do it, but if you’re not happy with some basic element of how it works then you’re stuck having to find a new IDE. (Yes, I know, many IDEs have plugins available, but I’ve never had that much luck with them.)

IDEs also tend to be built with a workflow in mind. If you conform to that workflow then they’ll be good to you, but you want to deviate from it you may have to fight with your tools.

A lightweight-but-extensible editor (e.g. Sublime, TextMate, vi, and so on) tends to focus on having a really good editing experience. So you start with good editing, and then you pick and choose the “IDE features” that you want to mix in. If part of the editor doesn’t work how you want you might have to find a new plugin for it, but since it’s not a massive and complicated system it’s likely to be easier to find that plugin.

Neither is necessarily better, but they do tend to appeal to different types of developer. Web developers, needing to work with a number of different file types, and not generally having complicated build system requirements, gravitate towards the lightweight editors.

UPDATE: To be clear, I’m not saying either is better. It’s a matter of personal choice and situation. As someone who mostly does web development in dynamic languages, I like using a fairly lightweight editing environment. If I wrote in Java I’m sure I’d be singing the praises of IntelliJ/Eclipse/whatever, because I understand that Java is almost impossible to write well without an IDE.

Join the Conversation


  1. If I had two wishes free, I’d first wish for world peace, and secondly I’d wish in our industry people would not talk about stuff the do not use, Textmate users talking about IDEs, Ruby users talking about Java, the list is endless.

    Why not just talk about the stuff you know?


    PS: e.g. compare the really good editing experience in TextMate to the not really good (why?) editing experience in IntelliJ. Facts not unbased bashing.

  2. @Stephan: Touchy, much?

    I didn’t say IDEs had bad editing experiences. I said that if you didn’t like an element of them then it was often difficult to change it. I’ll grant an implied contrast because I called out the editing experience on the lightweight editors, but I think that’s mostly because that’s the entire thing those ones sell on. If TextMate didn’t have a satisfying editing experience there would be no reason to use it, whereas IntelliJ could still sell itself on its wide array of other features.

    I even ended with a whole “it’s mostly a matter of personal taste” disclaimer.

  3. @David: Touchy? How could I be touchy as a 20 years VI(M) user, a Textmate buyer and user and a 10 years IntelliJ user. No. Just call me conservative as I prefer facts over general sweeping opinions.

    “I said that if you didn’t like an element of them then it was often difficult to change it.”

    How so?

    “I even ended with a whole “it’s mostly a matter of personal taste” disclaimer.”

    That is an easy way out I think, if it is mostly a matter of taste, then why write a blog post about IDEs, presenting”facts” (wrong ones, “IDEs also tend to be built with a workflow in mind”)?

    Don’t take it personal, I’m just fed up with our industry of fact-less-opinion-driven-generalizations of languages, tools and frameworks.


  4. Annnnnd… This is why I rarely ever leave comments on things, and stuff… Developers tend to be the biggest jerks hands down.

  5. @Stephen: Sorry, that was a sort of tetchy reply. Possibly commenting at 4am is a bad idea for me. 🙂 I’ll admit that the workflow bit was kinda vague. It has felt to me in my experience with IDEs that they were really intended for a project with a whole code-then-compile cycle, generally in environments where the phrase “build system” is meaningful. Trying to use such IDEs for more webby development has then felt… off, somehow. It may just be that I’ve been burned by Eclipse and Visual Studio, or that they’ve improved since I last tried them.

    As for “why write a post?”, the answer would be: because I saw the question in the title asked, and wanted to take a shot at answering it.

    In retrospect, this is kind of a holy-warrish subject to talk about.

  6. Why does one need to inspect your form elements to find out what the fields are? The speech bubble with the chess pawn is probably a name whereas this field with the speech bubble and a crayon is surely the comment. So that leaves the other box with the pawn in front, where the box might be an envelope. Yeah, probably email. And the dog-eared document with the house or arrow is undoubtedly one’s home address, which I’ve duly filled in.

    Now, I return your dear readers to their quibbling.

    1. @Name: Because I picked this theme 5 years ago, and haven’t quite talked myself into fixing it up now that I know better. It’s a terrible excuse.

  7. Oh, OK, Stephan, you’re not touchy. Really.

    The editing experience in IntelliJ sucks because it uses a non native Swing editor with extra latency added in for fun for most actions, from typing to completion. Same goes for Eclipse, which uses a semi-native component. A huge runtime and a GC doesn’t bode well with editing speed.

    Oh, and the “swing can be as fast/good enough” etc crowd, please go away. It’s not 2001, it’s 2011, the Desktop wars are over, Swing lost. If it weren’t for IDEs, crappy internal corporate apps and such it wouldn’t be used anywhere.

    (I’m a 15 year exp. developer, used Java for a decade, with Vim in the start, Eclipse later, also worked professionally with Python, C and most parts of the whole Web “stack of worms”).

  8. Funny, your comment form is more accessible to blind people (thanks for the “alt” tag) and less to “”normal”” people.
    It doesn’t happen often, thank you for making them understand how it feels.

  9. I’m mistly a Ruby on Rails developer and started with IDEs. Then I have learned and switched to VIM. Back then the main reason was that I worked on lowe end Ubuntu box and both Aptana and NetBeans felt sluggish (not only due to IDEs being heavy, I also suspected some JVM issues but couldn’t trace them).

    Recently I tried RubyMine and what put me off was complexity. Things that put me off:

    It still felt sluggish during some operations on MacBook Pro with 2.2GHz i7 and 8GB RAM. It’s probably due to code analysis in the background. My current project is an Enterprise (read: big and bloated) accounting and management application with tons of legacy code.

    I’m often running multiple test suites in parallel: full unit test suite running at glacier speed in the background, another unit test suite for a separate heavy application we stuck into the back-end as an accounting engine, single test file very frequently while attempting to do TDD. Besides that I’m launching app server on separate port, rsync test suite to a Ubuntu VirtualBox, SSH into it and from there run an hour long Capybara black-box test suite (they launch and drive Firefox to test the app from the UI). While RubyMine does run tests for me, I did not even attempt to stick all those parts of my workflow into the IDE. So I’m left with running a bunch of terminals anyway.

    I’ve had some issues with rvm+bundler+rspec test stack in the back-end accounting engine application. I was able to make it work in about an hour, but this left me thinking how much time will I have to spend in future. Infrastructure in Rails world is fast moving targer for an IDE to integrate with.

    I’m doing quite a bit of remove debugging and remote pairing sessions – all across the ocean. Vim is particularly good at navigating and editing code with significant network lags. Instead of scrolling with keys and waiting for the cursor to appear at particular line, I’m using search commands and immediately start working with the line – without waiting for the screen to refresh. I also tried some collaborative editing plugins for the IDEs but gave up after an hour.

    I have to solve new infrastructure/stack/workflow problems quite often, I manage to do it in reasonable time in console and fear that I would get stuck on some of them if I want to stick to IDEs. Being a little bit compulsive-obsessive regarding my workflow, I’d probably waste too much time trying to make things work inside an IDE.

    There, I think I managed to depict my point of view without passing too much judgement on IDEs (-:

  10. Plugin-able editors are slim IDEs. IDEs are editors with preinstalled (and some times uninstallable) plugins. It’s not a binary thing, but a continuum.

  11. @Stephen – If you don’t like this article why not comment only on the articles you do like? Huh? Boooom!

    David I hope you keep writing about things you like and don’t. I will be the one that decides if I agree or not.


  12. @foljs:
    “the editing experience in IntelliJ sucks…”
    Huh? How so? I’ve been using Intellij as my primary IDE for Java to build very large scale web applications and tooling for the last 9+ years. One thing I have never hear anyone say is that their editing experience in IJ sucks. I’ve also used Eclipse extensively and have built sophisticated plugins with it. After using IJ I can say that Eclipse is disappointing — IJ is so polished and is always a notch or two above Eclipse, this matters. Even so, I could never go back to a text editor (I used Brief back in the day, then switched to Codewright).

    In the absence of IDE tooling a software project of any size is almost certain to suffer huge maintenance costs over time. By tooling I mean parser feedback, type and member navigation and discovery, deterministic code completion and refactoring, and, yes, compile-time build feedback i.e. my IDE s/b able to build the entire project incrementally using rules consistent with the team’s central build tools.

    Now I don’t mean to stoke the dynamic v. static debate. But if your project involves a dynamic language at it’s core, most of what I’m saying is void. No static typing pretty much means no tooling.

    In my experience the text editor people fall into two camps: those that use dynamic languages (or old or fringe languages) and those that, for whatever reason, have not yet truly experienced working on a project in Intellij or, sigh, Eclipse. There are some exceptions, but the former don’t have much of a choice. Their decision to use a dynamic language sealed their fate. I used to belong in the latter group. I suffered under VS, Jbuilder, early Eclipse, and felt IDEs just sucked “you can pry my text editor from my cold dead hands.”. But then 9 years ago I started work on a project that was started in Intellij. I was apprehensive and and only used it for debugging at first. A month or so later I was a convert. Never again would I consider building software in a text editor, even the small stuff.

    A bit more than I planned to say, but the premise that IDEs are too confining is questionable. “IDEs” is not a subject we can treat as a whole. Talk about a specific one, and then talk about specific things with which you find fault. Then step back and examine the broader picture — the purpose of an IDE. If you’re honest with yourself, you’ll find it difficult to argue in favor of a text editor as the foundation of your “tooling”.

    1. But if your project involves a dynamic language at it’s core, most of what I’m saying is void. No static typing pretty much means no tooling.

      on the other hand, some dynamic languages are still compiled, and interpreted languages (yes, such as Ruby) depend upon unit tests as a substitute for compile time checking.

      1. Right, but testing is no substitute for tooling. Any project too big to stick in your ear canal is too big for a text editor. Even tiny projects are hard to understand for someone new or for the author if it’s been any length of time since he last contributed to it. Without proper tooling it’s much more difficult to grok the codebase. Where’s this method defined? What implements or overrides this method? What calls this method? What methods can I call from here? What uses this type? What type is this parameter? I need to rename this type and these methods need to move. I need to refactor the signature of this method. This method should be inlined. I need to extract a variable for this expression… The list goes on. These are things I need everyday. My codebase would suffer tremendously without this level of tooling. In fact it probably wouldn’t exist.

        Rich error feedback, navigation, completion, and refactoring are vital to the long term success of most software projects. Maybe that accounts for the recent trend where lots of projects are started with Ruby, but the successful ones are not finished with Ruby.

  13. TECO, Librarian, Roscoe, vi (not Vim), emacs, ProjectBuilder, Xcode, Eclipse, TextMate. The odd one out? Eclipse, of course – because I have to use it for certain projects, unless I want to rewrite a large stack of plug-ins including specific file editors.

    What I don’t like about Eclipse is the non-native structure, so that most keybinding conventions for my platform are ignored, and the obtuse way that features are hidden. It does some things much better than TextMate or Xcode, but the vast majority it does far, far worse. I’ve heard good things about IntelliJ and NetBeans, but they aren’t an option for my projects.

    Java used to be entirely usable from a classic programmers editor; I think it’s Java programmers in general who have become dependent on the full-0n IDE experience, rather than the editors lacking features.

    1. There are a lot of analogies I could make regarding your assessment that Java programmers are now dependent on IDEs. It’s true, but it’s not like IDEa are some kind of crutch. Well in some cases maybe, for instance I no longer rely on my memory for class hierarchies and where classes reside etc. I’m lazy that way. But a solid IDE enables me to do more and do it faster and more reliably than with my quaint text editor. Why in the wide world of sports would I even consider going back? So, yep, guilty as charged, I am indeed dependent on my IDE.

      That said I am more than familiar with Java’s pain points. As a language it suffers from mollasses-like innovation from Sun/Oracle. The libraries suck. The language deficiencies pretty much prevent any interesting frameworks from developing e.g., no way to add methods to existing types, no closures, almost no type inference, etc.

      All that said I will never start a project in an environment where I can’t use deterministic static tooling. I’ll settle with less than desirable frameworks in favor of some hope to be able to maintain the project beyond a few thousand lines, involving a growing team, where I can cleanly separate API from implementation, and know that my codebase and my team via tooling will remain agile… er, bad word these days… how about ‘nimble’?

Leave a comment

Your email address will not be published. Required fields are marked *