Visual Studio or Rider? Comparing the old and the new
So you develop .NET apps, which IDE (Integrated Developer Environment) should be your primary developer tool? The official .NET king: Visual Studio? Or Rider, an infant from the praised IDE family of Jetbrains. It’s not a trivial choice, both options look very similar and appear to have essentially the same feature set. How are they different? Rider is certainly visually more modern and it surely carries the power of ReSharper but can it really replace longstanding dominant Visual Studio for a .NET dev? And do recent features like IntelliCode or performace improvements for ReSharper change things for Visual Studio? I’ll try to help make the meaningful distinctions between them clearer by comparing the two IDEs in terms of their utility to me as having been a .NET developer for several months.
This is written for Visual Studio 15.7.3, and Rider 2018.1.
My IDE background
My journey began with BlueJ, a modest programming learning tool where modules (in this case classes) are displayed as a UML diagrams, and navigating between modules means finding and selecting them in a diagram. I soon became frustrated at bugs and missing capabilities of BlueJ’s text editor and ventured into the world of IDEs, starting with Eclipse where I began exploring the rich feature set of an IDE. From Eclipse I eventually found IntelliJ, made by Jetbrains, the same company who makes Rider (back then their company was called IntelliJ).
Since then I’ve gone back and forth between text editors like Sublime Text and Vim, and fully-fledged IDEs, mainly in the Jetbrains suite (with the help of my free student license). Along the way I’ve visited these text editors: Sublime Text, Vim, Atom, Notepad++ and non-Jetbrains IDEs: Eclipse, Visual Studio, and Jetbrains IDEs: IntelliJ, Android Studio, Webstorm, Rubymine, PyCharm, and Rider. As you might guess: I’m a Jetbrains fan. I want to mention this so it’s clear I have a bias from having spent so much time using and learning on Jetbrains IDEs. Comparatively I spent only a few weeks with Visual Studio before finding that Rider worked for me and gleefully switched (mostly) to it.
Where VS == Rider
In many ways Rider is just like VS: they share the same basic IDE border layout, their capabilities are roughly the same. Many tools and patterns are shared in both IDEs in areas such as in the build tools, debugging, testing, code navigation. They each have a plugin community and a built-in plugin explorer.
Layout. There has been a convergence
Both IDEs use a single OS window with embedded tool windows that are laid out in a border layout (left, right, top and bottom of a central pane (the editor in this case)). The top is used for controlling run/test/debug configurations and the title bar. The usage of the left, right and bottom panes are the same for both IDEs (and other IDEs too): on the left is the file “solution” explorer, the bottom has the build/compiler log and test runner. Tool windows can be moved between border panels in both IDEs.
Similar tool sets
Many features like debugging, building/cleaning, and the solution explorer look and behave almost exactly the same on both IDEs; in fact it appears that Rider has intentionally designed parts of it’s UI to feel like VS’s. After all, people who will be interested in Rider will likely be migrating from VS as it’s the de facto .NET developer tool and the IDE currently with the highest market share. Jetbrains has also had time to understand the VS experience having developed ReSharper (which adds functionality on top of VS).
Where Rider wins: the power of VS, but with better UX
The most important difference between the two IDEs for myself has been the higher quality user experience (UX) of Rider. For me that has meant smoothness, reliability, less breaking flow and frustrating behaviours, and ultimately better supporting me to achieve my goals (getting good work done quickly). Where Jetbrains IDEs do well is in great presentation of information, clean and concise visual design, more intelligent behaviour, intuitive and easily-learnable features. It’s not that Rider is necessarily more powerful, it just seems to do the basic things very well.
Which features are better on Rider?
Among the most-useful IDE features for me, I’ve found that Rider delivers a better experience at global search, code navigation and investigation tools. I’ll go more detail into two of those in the following sections:
Global search
VS’s go to all does find things for me, but with ReSharper I sometimes notice high latency before I see results. Without ReSharper recently visited files aren’t as highly ranked. Rider’s search everything feels smooth in comparison and seems to provide consistently good results.
As for string-searching: VS’s find in project, again works but it takes ages compared to Rider’s find in path and irritatingly presents results with full file path prefixes (and no highlighting), so I may have to scroll sideways (by grasping what can be a tiny slider handle) to see what the actual lines are. It also means that lines are out of alignment, making them slower to scan through and compare. In contrast Rider seems to search lightning-fast and presents results in a much more helpful way; find in path also lets me peek at the rest of each file to quickly see context.
Code navigation and investigation
Rider’s find usages is more configurable, has better presentation, and has a little more polish than VS’s find all references. Again, Rider’s presentation is cleaner, and Rider let’s you choose how much context is shown (do I need to see the project, package, class, method?), and allows results to be split by read/write which I’ve found useful. An example of the kind of polish that VS is missing: when there is only a single reference to a symbol (e.g. a variable, method, etc) which happens regularly, Rider will jump to that instead of bringing up the regular sidepane with the list of usages that you would normally have to navigate from.
Minimising interruptions & waiting
VS with ReSharper seems to liberally stall the UI thread [although this has improved noticeably since I first wrote this a few months ago]. With my company’s monolyth project loaded I’m immediately warned that ReSharper is causing VS to slow down. It’s not rare for VS/RS to interrupt me to perform it’s errands. Often it’s when I’m using the editor normally. The global search feature sometimes seems unprepared for me when I first use it because it takes seconds for me to even see the text I’m typing, with another delay to show me search results. The project I’ve been labouring VS with is legacy (over 10 years old) but there are surely many other businesses with similarly legacy .NET projects. Rider suffers from occasional hiccups similar to VS but it shows resilience in important areas like general responsiveness, search speed, and file syncing times under the same large project.
These kinds of issues may seem pedantic but they interrupt flow for the user and (at least for me) become aggravating, especially with an IDE being a sovereign application (one that commands much of your working attention). Research has shown that once people perceive something to be of a certain level of interactivity they will treat it as human. How would you feel about someone constantly interrupting you throughout the day for no good reason?
VS with ReSharper is so slow to reload file changes for us that it’s faster to close and re-open it than to wait for VS to catch up for large projects. When joining my current workplace, I was disturbed to find that it was common for developers to use command line shortcuts svs (close VS) and vs (open vs) to close and re-open VS every time they want to switch between branches. It’s as though the designers of VS didn’t expect it to be used for large projects under source control. To be fair this latency has reduced since I first encountered it, and especially when ReSharper is disabled.
Another example of this kind of behaviour is when I want to build (or do anything) upon first loading a solution (or switching branch): VS won’t let me do anything until it’s finished completely reading and understanding the solution it’s loading. In contrast Rider quickly loads file changes into the editors and immediately lets me initiate actions which — if Rider is not ready are deferred and automatically executed when Rider does become ready.
Something I stumbled across when I became interested in input latency is an write-up that at researcher at Jetbrains wrote about editor responsiveness and how it can be improved for Jetbrain’s IDEs. According to the write-up these improvements would put IntelliJ IDEA at a lower editor latency than lighter editors like Sublime Text and Notepad++.
Upsource integration and better Mercurial support
Code review integration isn’t something I expected to get from an IDE but it’s been welcome in my development workflow. Where I work we use Upsource (a Jetbrains code review tool) where I work, so integration with Rider adds useful reviewing actions to the IDE like being able to switch to the branch/revision of the code being reviewed, make comments directly from the editor, and receive review notifications. With the Upsource plugin you also start seeing ghostly comments in the margins of files from time to time for code reviews from time past. I’m not sure if all comments from the past are shown or how they’re chosen but I suppose it could be interesting to get insights from coders of the past.
The old vs the new
Coming from Jetbrains land, VS feels like an IDE from the past that has modern features built on top of it. It reminds me of Microsoft Office 2003 or Eclipse (IDE) which is known for being a swiss army knife of features and lacking cohesion. VS still requires confirmation from the user to save their files to disk, even when developers today are savvy with source control management tools like git and are regularly switching between versions of their project (No VS, I don’t want my edited files to persist across a while switching branches). In contrast Jetbrains IDEs tend to look and feel good; visually minimal and clear, and performant.
Rider’s shortcomings: build inconsistencies and lack of support for old .NET things
For all the praise that I’ve given Rider there are a few ways in which it fails me; the biggest being that it sometimes has trouble building our main solution (.NET project) at the company where I work. It’s also missing older .NET features and profiling tools which VS does provide, but for me these are only occasionally useful.
Oh no, Rider. Build issues?
A build-related issue I’ve had with Rider is where it will refuse to compile certain C# module-related import statements (I’ll edit this when I find out what these are). I currently solve this problem by building with VS once and then Rider seems to accept the imports.
This build issue is disappointing and is the main obstacle stopping me from entirely switching entirely from VS to Rider. For all that I’ve complained about VS, at least it lets me build solutions reliably (or if it doesn’t, someone will find a solution soon because everyone else at my work uses VS).
Rider’s Lack of support for older .NET features
The only other thing that I’ve called on VS for (post-Rider) is to generate a designer.vb file for a .NET Web Control. This was difficult to go without as it seems that the knowledge of how MS web form elements are linked together has been lost from the world (my workmates didn’t know and I couldn’t find answers online). Perhaps the developers of Rider forgot this too.
VS’s shiny new “IntelliCode”
Could VS’s recent advancements in its IntelliSense one-up Jetbrains’ Code Completion that they put front and center in their ReSharper marketing? IntelliCode goes a step further than its previous IntelliSense by intelligently suggesting APIs (methods/functions) to use based on what their usage in reputable projects on GitHub.
To me this seems like a nice quality of life feature, especially when it comes to learning libraries/frameworks. One of the main draws of Jetbrains IDEs and ReSharper is it’s useful code suggestions; on Jetbrains’ marketing comparison of vanilla VS and ReSharper, several of it’s top boasts are code analysis and suggestion features. IntelliCode seems to show that the Visual Studio team does indeed care about quality of life features and are capable of competing with Jetbrains similar features.
Conclusion
So I’ve found that Rider delivers a better overall experience for me as a developer. It’s visual design is clear, it’s more performant, it behaves more intelligently; it’s generally easier to use well.
There are many reasons how this could have happened: perhaps VS devs have had difficulties shedding an ancient platform (first released in ’97) vs IntelliJ (Jetbrains’ platform) starting among a future generation (’02) of IDEs. Jetbrains is also able focus on developers while Microsoft has many types of customers to serve. Additionally, Jetbrains has been able to transition into Rider through learnings gained from developing ReSharper on top of VS.
However, what VS affords me (its functionality) isn’t much different to Rider. Some of the complaints I have about VS performance can be attributed to an uneasy integration with ReSharper; and with the introduction of IntelliCode I can see appeal in ReSharper dropping. Does ReSharper have a place in IDE world any more with Rider in the picture?
Visual or UX redesigns for VS could go a long way, and Visual Studio Code is in some way this, delivering a cleaner, trimmed down IDE/editor (but with less functionality). Perhaps these lightweight IDE/editors like VS Code or Sublime Text will eventually overtake heavyweight IDEs like VS and Rider if community-driven plugins can deliver better experiences than boxed IDE tools (although integration of these plugins is problematic).
For now I’ll stick to Rider with VS as backup. I’ll remain a little jealous of IntelliCode, profiling tools and any other power that I may miss in Rider but I’m also excited for how Jetbrains responds to IntelliCode; surely they’ll also improve their code completion eventually, and I’ll be able to use it across other Jetbrains IDEs.
