For example, in a React app if I'd want to jump from a `Route` import from react-router to it's readable code definition , NO IDE or editor around is capable a properly doing the jump, I either get to a Typescript definition (VSCode does this - imo the worst possible behavior) or to some unreadable transpiler outputed code.
This creates a huge divide between framework/library/component-author and "lowly" client/user-programmers.
Compare this to the Python ecosystem where basically any editor or IDE can help me jump to the right place in a library's nice and readable code, and even in the worst case where the author didn't bother to write either tests or docs I can still make use of foreign code just fine...
Jumping to definition works with typescript projects correctly when this is turned on, but it's still not a solution for JS projects with definition files
Your right it is the absolute worst possible behavior.
I get that information when I hover over the method/class/whatever.. I am looking up the definition because I want to see how this works.
And I'm not saying that the devs don't care or not doing wonderful work... just that they've ended up with a codebase where something like this is genuinely hard to do.
And when they'll finally get it will still be frustrating as hell because >50% of the time it would jump to some unreadable transpiled code because there's no actual standardized way to jump to the original source the final js got transpiled from. In an ideal world, if some React component was written in OCaml mixed with Clojure and transpiled to JS, I'd want to be able to jump to the implementation into that actual original OCaml or Clojure code. But I get it, whoever would be smart enough to get that working reliably would probably make better use of their time trying to cure cancer or solve climate issues or go to Mars etc.
1. Minimal interfaces
2. Better documentation
Say like React although the codebase is more or less difficult to read. But the most useful surface-level APIs are quite minimal and intuitive. There are more minimal libraries follow this pattern.
I think that's why this community is moving fast forward because people trying to be communicative, and constantly trying to simplify and introducing new ideas. It's very hard for people just read the code to understand some brand new concepts without a good understanding of the high-level constructs.
(But jokes aside, yeah, you're right, there's lots of JS libs with much nicer interfaces and docs than Python ones, I agree...)
(...hanging out with ppl from the healthcare field made me too used to cruel/gross/insensitive/politically-incorrect/borderline-sadistic jokes, always forget that the rest of the world is less desensitized to death and suffering than us :P)
There are plenty of options to build fast, modern front ends without having to deal with any of that.
And you're right about IDEs too. Given the choice between a full-blown VS.NET + ReSharper versus VSCode + $1,000 in my pocket, it's just no contest. No matter your bill rate, you still break even in single digit hours of productivity gain.
As a solo entrepreneur, it's even more of a no brainer, since it's my free time that I'm gaining by working with better tools.
Not really, if it's your own code that requires a build step, then you control that build step and the tools and all and you can have nice auto-reload and fully working source maps and integration with all your other tools...
Do whatever exotic build and transpilation makes you more productive when developing your application's code. But libraries and frameworks... it's not OK to have a large part of the ecosystem dependent on such build tools and at the same time have no usable tooling standardization to easily implement something as basic as "jump to implementation in original source".
For example, I know a bunch of people that use print debugging, and don’t “get” visual step debugging. But most of those people haven’t used a proper debugger before.
I’m primarily a python dev using vscode. Pycharm debugger (and remote interpreter!) blow away the vscode debugger. But I can use CLI tools (ipdb) nearly as well as any visual debugger. It’s a conscious trade off that I make. Specifically, I prefer the editing experience in vscode over pycharm, but can bridge the gap in other ways.
Know your tools. Know the capability of other tools.
In other words, is your experience that developers who use an IDE are more productive then developers who only use a text editor?
In my experience, the (very few) developers I know who only use VIM or Emacs are way more productive then those who use an IDE.
The reason seems to be that they tend to 'sit back and think' about the task at hand. And then come up with elegant solutions. While the developers who use a lot of tooling seem to hope that the tooling will kinda force them to do the right thing. But from what I witness, that never works out.
I see a similar thing happening with coders who do a lot of tests (test driven development), some tests and no tests. Developers who don't write any tests are often the most productive.
If you look at them in isolation, sure. If you look at the whole team you'll see that the untested code drags everyone else's productivity down because all the other developers can't modify untested code without fully understanding everything it does. They have no tests to give them any confidence that they're not breaking stuff when they change it.
Developers who don't write tests are fine if they're working alone, but they're toxic to team productivity.
The code that comes out of developers that use IDEs is normalized in a way that makes it very easy to change. Sure, if your big enough you can spend all your time inventing linting rules and creating templates to generate scaffolding and tests.
- If you do low-level stuff like writing a hardware driver or a kernel module you will most likely be fine with a normal text editor because all in all it's not that much code
- My friends in a large PHP shop all use PhpStorm to work on large projects. They all tell me that you are way more productive in PHP with the specialized tools that PhpStorm offers. In the whole company there is not a single person who uses emacs or vi for PHP (a lot of them use vi for everything else, but not for PHP)
- I used to have a job where I had to switch between 2 dozen projects in the span of a few weeks and fix things. A proper IDE makes it much easier to navigate code you have never seen before. Without IDEs I would not have been productive in that sort of job at all
Without an IDE that can jump between those assemblies and source files it's an absolute nightmare.
Full disclosure: I'm a vim user.
Such queries are meant to discover notable impact, based on which you might invest in a proper evaluation.
But I suppose people that use emacs and vim are like vegans. Those that do, are definitely going to tell you about it.
If you’ve been doing vim or emacs since the 80s then great but I’m not going to go through months of configuration hell to repurpose vim into an IDE when I can do it the other way around.
A good example is SpaceVim that enables people who don't want to configure everything to use VIM as an IDE that provides most of the tools you'd need for developing.
E.g. it has a linter for python, mouse support and code-completion. I don't need much more to develop most of the time.
VIM is awesome and I think what most people whining about it ignore is the fact it runs in a terminal (vs. some big bloated piece of sh*t).
* Go to definition
* Extract method
* Introduce parameter
* Inline variable
* Rename method
* Rename variable
In a Jetbrains tool these are automatic / atomic operations.
Or have a go at https://github.com/daviddenton/refactoring-golf
* Change signature
* Convert Anonymous to Inner
* Convert to Instance Method
* Encapsulate Fields
* Extract refactorings
* Extract constant
* Extract Field
* Extract interface
* Extract method
* Extract Superclass
* Extract variable
* Extract parameter
* Extract into class refactorings
* Generify Refactoring
* Invert Boolean
* Make Static
* Move and Copy refactorings
* Pull Members Up, Push Members Down
* Remove Middleman
* Rename refactorings
* Replace Constructor with Builder
* Replace Constructor with Factory Method
* Replace Inheritance with Delegation
* Replace Temp With Query
* Safe delete
* Type Migration
* Use Interface Where Possible
* Wrap Return Value
Meanwhile, merely performing a simple pure-text find-replace across multiple files using vim and emacs is a chore. And better hope you don't screw it up because there's often no easy way to safely undo such a change, especially not with a single keystroke. The idea that even master-level users of vim/emacs could begin to hope to replicate the operations listed above with the depth, accuracy, and user-friendliness that IDEA offers is simply laughable. Any granddad worth his salt is perfectly capable of understanding that advancements in software have yielded tools that are by far and away objectively superior for a wide variety of development tasks.
It is not, i do that fine in emacs. Half of your list can be done with regex replace. Things like extract and refactor needs language specific tooling that can be done with text editor too(see LSP). And some stuff on your list doesn't even apply to other languages that they have community support for e.g. Rust.
But sure Jetbrains has put lot of effort on these tools for a few languages that you can certainly benefit for a large project. Outside of that good luck using it for any other language.
Even in the best case scenario where regex works, you've still spent unnecessary mental overhead writing regex, a tool that is so difficult to use properly that it is the textbook example of being a 'solution' that causes more problems than it solves. Why subject oneself to such unnecessary hassle?
It really does help to get a reminder from the IDE regarding which methods exist and what their parameter lists are. For C, ctags works well enough I guess and we can complete function names that way. But for Java and C#, I can't imagine that going well.
Now get off my lawn.....
> Beyond a certain level of codebase complexity, there is simply no way to do the job with a text editor
An absurd claim. How can you interpret my post as a "get off my lawn" type thing?
And some people also still write in assembly. I also thought that any high level language was useless. Then I thought anything more high level than C was for beginners.
But I grew up and start being more concerned with making money and implementing solutions than having geek cred...
I obviously also write more code when I don’t write tests, but the code isn’t better or more useful. I remember the times when there was much less testing so other people’s code was kind of useless a lot of the time.
Personally I use Sublime most, because I’ve done that for years, but for rookies reading this, don’t go and get Sublime just to mimic me. If you’re starting out then use whatever people you can get information from use, so you can ask questions and they have less friction when helping you. So if you write C# targeting Windows, having Visual Studio proper will be a boon so you’re probably using the same thing as the Stackoverflow people. Doesn’t matter that an Internet forum user uses Sublime or vim.
My comment reads like it comes off as snarky, apologies.
Absolutely none whatsoever. If anything it's negative. I have never found "speed of editing" to be remotely correlated with good code or even productivity.
That way it's easier to figure out what's going on in larger codebases, or one even just one you're not familiar with.
Something as simple as renaming a method and it is automatically renamed in your entire code base is a life saver.
Tests aren’t about productivity. They are about maintainability when you have to make changes. How many large code bases have you dealt with?
It's the same gubbins that VS Code uses for all of its cleverness.
Thanks. This comment made me feel like a best programmer.
Jokes aside, I love trying new tools, and it's probably just curiosity, and every tool you try either teaches you something you like, or something you don't. For instance, it's unlikely that I'll ever use an editor that doesn't have a vim-like plugin (for input), but I can't get myself to actually use vim anymore. At the moment I mostly use VSCode, Emacs, or IntelliJ... depending on the language and the support editor's for my workflows (in that language). In emacs, I tend to use the terminal in my editor, whereas in VSCode I'm usually switching between iTerm and VSCode. I sometimes run tasks, builds and debug from IntelliJ, but I'm not sold on the embedded terminal.
I'll have to be honest with myself here though: I often feel that whatever editor I'm using does indeed impact my productivity and that none of them is perfect, and perhaps this is why I'm never happy with any editor in particular. I've never really used a proper IDE other than XCode (maybe emacs counts as one, but I don't think the way I use emacs counts), so I'm always curious when I hear people talk about Visual Studio + ReSharper. I'm not a .Net developer and I don't use Windows, so I'll probably never know.
2. Dev's who use VIM/Emacs are probably already living in their computer so you can't really say if they are good because of the editor they use or the other way round
3. What do you mean by "productive"? Closing more tickets in a sprint? In the end not only individual efficiency is important but also the future of a project. With test you document stuff and ensure at least the tested things won't break (if it's mandatory the tests are executed on every build).
4. Of course tools matter. In our company there is people who still use eclipse and sometimes they just need their time to fix the IDE. My team exclusively uses intellij and I can't remember the last time we had to deal with such a mess.
I sometimes open VS Code for small for small non-project related files, but I am much more productive with an IDE.
One thing that many get wrong in the VIM vs IDE comparisons are the benefits of keyboard shortcuts. They assume that VIM has a significant advantage, but you can have that with IDEs too.
The JetBrains products have keyboard shortcuts for almost anything, so you do not have to use a mouse unless you want to. I'm sure the same could be said about other IDEs as well. Many forget that when they compare against VIM.
- I would also not use eclipse and turn that down
- Maybe you are more productive. I have seen people who will be more productive than you just using their customized VIM (I'm 100% sure about that)
- You say "something" has an advantage over VIM (or EMACS) in the means of keyboard as input interface? Think again or at least try to let someone show you what VIM can do with just a keyboard ;-)
The difference is not only about the control with a keyboard. The true beauty of VIM etc. lies in the fact that you can use it without an X Server (so also over SSH). Then there is efficiency - VIM can do a lot more with a lot less resources. A PC that will already choke when you open up your project in a full-fledged "give me 2GB of RAM" IDE will seamlessly open up in VIM in seconds.
When you're traveling and want to preserve battery, VIM also comes in handy. Not everything I do needs the refactoring features of an IDE and I also don't have to use the test runner every time I do / change something (also there is CLI tools that are totally OK to use).
I think you are trying to compare something you don't really know.
Fast forward a few years on that job, I'm finding myself utilizing a workflow that's tracking closely to ESR's TAoUP. I still have to lean on the IDEs for certain classes of problems that I might come across, but they became a tool in my toolbox instead of being the toolbox.
That was all well over a decade ago. I haven't touched an IDE in my full-time work since 2013 or 2014, when I wrote my last line of C#. If I had to go back, I'm glad that VsCode has appeared on the scene in the meantime, but I wouldn't be thrilled about it.
My personal opinion is that living at the layer that I live at, in a terminal with a multiplexer and doing things that leans heavily the UNIX philosophy, gives me an understanding of the systems that I create that I perhaps wouldn't get otherwise.
I see no correlation at al.
But on the bigger issue, correlation is not causation.
Many new developers start with an IDE because. So you’ll see a lot of inexperienced developers using an IDE. On the other hand, back in the day, if I wanted to have any chance of editing this file on the arse end of a 9600baud dumb terminal then vi is the answer. So there are old bastards still programming, who therefore have a ton of experience, who use vim.
Does using vim make you a good coder? Fuck no. Does using an IDE make you a bad coder. Also no.
I use an IDE. I’ve used an IDE since ‘92. Then it was slick edit on OS/2, at a company working on some of the hard bits of supermarket system, and everyone used it. One of the best programmers I know uses vim. However every other best programmer I know uses an IDE. I suspect the vim guy is wired differently. So if vim seems right to you then use it. If an IDE works then use that. Anyone tells you you aren’t a proper coder unless you use vim or emacs or edlin then they are telling you that they are a pretentious twat. My friend who uses vim will not tell you to use vim. He’ll tell you why he likes it.
But write fucking tests.
I've known a few who use sublime text, and there was no correlation with either being a good developer or being productive (though I haven't met a bad developer using sublime yet, mediocre ones are common enough)
On first use I found there were a few frustrations and I still end up with lots of quotes where I type something= only for phpStorm to enter quotes for me that I am not quite expecting.
I also had a problem of finding 'jkjjkjk' in my code from vi habits of using the j key to move in the document.
For me phpStorm is where the real work happens, I know I am not really good enough to do it in vi whereas I once believed that. Sometimes you see a missing closing bracket highlighted in phpStorm and know you would have wasted a minute or two testing had it been done in vi.
This should not pass code review. If it doesn't have tests then it's a landmine for other programmers in the future, since they can break it without realising - possibly entirely indirectly, such as through a library change.
The most "productive" techniques I've seen are all metaprogramming - assemble something which matches the domain well and use that to produce a large volume of code from specification-as-data.
(Oddly, the only area where nobody bothers to do automated integration testing in my experience is embedded code, possibly because it's too hard to set up)
I'm in no way saying these developers are not good developers, but they do produce a product that's often below par, below expectations, and below what they could do with proper tools. I do not understand why they stick with substandard tools. If you want vim key bindings, they are available in any ide. Startup time is simply not a factor when it occurs at most once per day, if that. I think developers love to focus on issues of personal preference and fashion to the detriment of using the best tools available. Sure, if you can produce great code with a great attention to detail with the editor of your choice, great. Keep at it. But if you can't keep up with the attention to detail and numerous requirements that go into writing great code because your tools are inadequate, defending the tools because of personal preference and fashion is ridiculous and lessens the quality of the final product. That is unacceptable.
I've not necesserily always used test driven development, but something close to it, especially for non-UI code where I try and aim for high test coverage.
I believe at least for Emacs people use it because it's an interactive environment like Slime. With this kind of interactiveness, I can think by playing with the code. Just like sketching with a pencil instead of a pen.
Most of the time 'sit back and think' doesn't work because if your business model is dynamic you have to break your existing design and refactor, unless you are just solving a problem in a small generic domain. At least for OO languages. That's something IDEs are used for.
The best developers I have worked with, in terms of either productivity or 'ability' use high level tools all of the time. And among the worst developers I have known are people that only use vi.
> I see a similar thing happening with coders who do a lot of tests (test driven development),
I mean, yes, but isn't that obvious why? In my work I can safely say I've written the most code in the shortest amount of time. This has allowed us to meet deadlines. But it's all untested. Writing tests obviously takes more time and effort, but I do think they are a good thing. Getting 100% test coverage for every project and following TDD too strictly is silly, though.
Regarding the floating promises warning, this setting is off by default, so you have to know it's there to activate it. Additionally, VSCode's integration with tslint output is mystifyingly poor, and I assume it is this that the author is referring to. There's clickable output in the build output window, but no popups in the text editor.
I like to run the compiler and linter manually, so I can see all the issues in one list. Popups in the editor are handy but clickable output in the build output window is good enough.
Some people prefer to work with file watchers, so the error/linter output is not as accessible. They probably need to be able to see everything in the text editor. But even if you work the way I do, you may well wonder why you don't get tslint editor popups. I've certainly wondered it myself. I can do without, but they're certainly handy.
FYI TSLint still has a large amount of config required to get it working, and the vscode integration still has a "wont-fix, upstream" bug where it won't lint files unless they are open in the editor. So you need to manually run tslint from the commandline. See: https://github.com/Microsoft/vscode-typescript-tslint-plugin...
I'm guessing that webstorm does this this more auto-magically for the user.
The key factor for me, is the ability for the tool to understand the codebase at some level. It needs to be able to tell me where a symbol is used, let me refactor that symbol (e.g. adding a new mandatory argument, or changing the argument order, or renaming the symbol) with as little extra work from me as possible.
Jetbrains tools allow me to do all of that (in PHP at least. I write about as much JS as I eat mud) where no others I've seen do.
Just because VS Code feels lightweight, doesn't mean there is any fundamental limitation preventing it from supporting all the features mentioned in the post. In fact, as the author and others mentioned, you can achieve many of the same features with plugins in VS Code.
Yes, WebStorm is better in the points mentioned by the author, and the JetBrains IDEs are amazing in general. But saying it's because one is the editor and the other an IDE is completely wrong.
You would typically point an IDE at a metafile that described the source files, build settings and so forth and it would discover the editable files. All this in a semi opaque manner, bootstrapped by some menus or templates. In contrast in an editor, you might generate the metafile only when your project becomes too big for the defaults to be sufficient.
You're right that the distinction is much more blurred now. For example you can do a lot in Visual Studio now without using a "project" file.
I can’t count all the languages IDEA Ultimate (also JetBrains) supports via plugins.
(I also have a license for Sublime Text and used that for years. I still prefer vscode now. But a developer's IDE/editor is a deeply personal choice and everyone should use whatever software they're most comfortable and productive with.)
For example, the other day I went to install a GraphQL extension for syntax highlighting and there was something like a half-dozen competing extensions, with no good way of figuring out why I should use one versus the other. I eventually ended up picking the one that looked the simplest, because all I really wanted was syntax highlighting and nothing else.
For example when I installed VS Code I needed a Git extension. There are zillions but only two or three that are clearly ahead of the pack and it only took a few minutes to try each one.
Even if all those extra features are useful, I'm still willing to compromise the core experience of editing and navigating code, as that's always what I'm going to be spending the majority of my time doing. I need that to be fast, easy and reliable, which is not what I have found to be the cast in IDEs, vs editors.
At my workplace, most developers are either full stack or backend (python). As such, we have a grab bag of PyCharm licenses. However, I am purely a frontend developer, so frontend related tools are much more important to me then python support.
Unfortunately, the last time I tried PyCharm the integration with linters, toolchains, different template languages etc. was quite limited. Or perhaps I couldn't find the needed extensions or where or how to configure the right settings. I don't know if this is a JetBrains IDE thing, or simply because PyCharm is so geared towards Python development only.
The projects I work on are integrated in different backend systems. So one might be a C# project with Razor templates. Or it'll be some PHP with another templating language. Or it might just be mustache or handlebars. It might be a SPA in Angular, Vue or React. It might be purely Node.JS project. Some projects have Webpack, some have a Gulp toolchain. Linters might differ between projects. Folder structure also differs, one might have the git repository in the root. Another will have it one or two levels down. Some use a python virtualenv. Others use a docker container. Others use no enviroment management at all.
In my experience, because of the different nature of the projects, the PyCharm editor offered little extra functionality over Atom/VSCode, while missing a lot of simple extensions that Atom/VSCode does have. I was also quite a bit slower to start up.
Is it possible to configure / extend PyCharm to offer the same frontend related functionalities as WebStorm, or is a separate license needed? And is there support, or are there extensions, to support different toolchains, linters, templating languages etc. per project? The backend language support can be limited, as long as the very basics are there, and I'd like advanced frontend support for refactoring, debugging, etc.
Get IDEA ultimate (also jetbrains) and just install the language plugins you need.
Isn't IDEA to Java what PyCharm is to Python?
Fresh example from yesterday: I open a .graphqlconfig file in WebStorm, which is a JSON file. Good luck making WebStrom open it as a JSON file... One minute later, I've opened the file in emacs, M-x json-mode, M-x mark-whole-buffer, M-x json-reformat-region, did the changes I needed to do, carried on with my life.
So it's not that WebStorm (or any other fluffy high-level tool) is perfect or "enough". There is always this one thing that will make your life miserable if you are religious with these things.
VSCode is massively easier to configure and has a lot more plugins. Most major plugins are covered by Webstorm or plugins, but it's the small things that give you an extra push.
Webstorm is more polished. VSCode is faster and more configurable. They are nearly equal rivals in my book, except one thing. Git integration in VSCode is horrendous. I work with git constantly while I code and the lack of proper support is a considerable productivity hurt.
For most of the functionalities, I think WebStorm still won.
But VSCode typescript completion is great. WebStorm typescript completion is somewhat strange.
However, the mindset of WebStorm follows IntelliJ, of course. You cannot switch projects or single file as simple as code editors. Although it can be achieved but it still feels weird. IntelliJ is constantly trying to improve this like scratches, but it will be still different from code editors.
And something off topic, I found IntelliJ/WebStorm is pretty much following Emacs for a lot of features. Like the VSC system is very alike Magit and they deprecated their RestClient and use an editor-based approach just like Emacs RestClient, or simply scratches. Seems a very good strategy to copy from Emacs community at least for MVP.
Once you take SVG to a certain level the desktop graphics programs no longer help, they add too much cruft and you also can't do things like have the origin of your drawing in the middle of the canvas. Having the origin in the middle makes things easier to mirror, rotate and so forth, which you might need if building an icon set.
Being able to live-edit a SVG opens new possibilities, you don't have to assume that you need the graphic design tools to 'draw a box' and you can keep shapes such as circles as circles, not some huge long list of points specified to 9 decimal places.
Right now I am building a SVG drawing that needs to take numbers to draw it to scale, I would never be able to do this without building a prototype in a JetBrains editor.
For web work I use VS Code because it has the best plugins for Vue, React, etc. I would also use it for less popular languages.
I know a few developers who stick to editors like VSCode for those kind of reasons, but as it turns out, they actually never spent time learning how WebStorm works.
WebStorm and the rest of the JetBrains family of IDEs are extremely configurable, and speed is not an issue in my opinion: I've spent a lot of time programming with PHPStorm (including database servers and Web servers running in the background) with a 1.1ghz 12" MacBook.
In addition, it comes with batteries included. No need for plugins for what should be standard functionality.
Looking at them work, they could save so much time refactoring, jumping between code, clicking instead of using shortcuts, etc. that the investment would be paid back within at most a week.
Speed is totally an issue for me with Webstorm, there's a small typing lag, very small yeah but noticeable, no typing lag is my top priority in an editor, above all the other features.
> Looking at them work, they could save so much time refactoring, jumping between code, clicking instead of using shortcuts, etc. that the investment would be paid back within at most a week.
Every Webstorm user talks about refactoring like a major feature for them but I found it not that useful personally, that's not a feature I would use anyway.
Xed is a fork of pluma, and is an X-App included with Linux Mint. (Seems to be under very active development.) 
Pluma is a fork of gedit2, seems mostly to integrate it nicer with MATE. (Seems to be under very active development.) 
gedit is also still around, and is still "Gnome's text editor", and seems to be under very active development. 
For me the IDE is more like a text editor bundled with extra goodies. E.g. multi-window (thus multi display), more elaborated software hierarchy (not just for code editing) vs. a main panel as editor and side panels as auxiliaries, automatic window management like Eclipse perspectives (or in VS, when you debug, it switches to the different window layout).
It’s not black and white unless you go with nano or notepad.exe. You can also roll your own ide with tmux, i3 etc.
btw have you guys ever tried to hack gvim window handles into Visual Studio? :-)
Now you better use WebStorm for the frontend part, right ?
In case of VSCode, one Editor to rule them all, both backend (Ruby) and frontend(Typescript) part.
All functionality of Webstorm is included in RubyMine and PyCharm (I use PyCharm daily). Ref: https://www.jetbrains.com/ruby/features/
All are working on my latest version of PyCharm Pro.
It's not a slim software, sure, but 16 GB?