5 Reasons To Not Use C# IDE For TypeScript Development

CodeJourney - IDE for TypeScript

I know a few fellow devs who still use Visual Studio or Rider as their IDE for Typescript. If you’re one of them, this is going to be a little rant on you all 😄

In this short article, I will give you my 5 reasons why the backend code editor might not be the best IDE for frontend development 😉

NOTE: calling this post a “rant” is obviously humorous 😉 This article is my own opinion, not a hate on anyone using different IDEs than I do.

1. Rider and Visual Studio are slow

While I consider Rider much faster than Visual Studio, even the JetBrains editor is too heavy for TypeScript development. Both of these apps are not good candidates for an IDE for TypeScript. They were designed to work with complex, backend solutions. These IDEs include a lot of features by default that can’t be turned off, most of which are not needed when working with frontend code.

This gets even worse if the solution you open contains both backend C# project and React app’s code, as it is in Visual Studio’s .NET+React template. With time, even loading such a solution takes a lot of time. Especially if you use Visual Studio with ReSharper 🙈

2. Less IntelliSense and tooling support

From my experience, Visual Studio doesn’t show as much IntelliSense info as, for instance, Visual Studio Code does. The navigation in TypeScript code doesn’t feel as smooth as it should.

When I tried to use Rider or Visual Studio as IDE for TypeScript, I had issues working with popular frontend tooling like Prettier and ESLint. Theoretically, there are plugins for both of these IDEs, but in my experience they don’t always work properly. For instance, the “Format on save” feature of Prettier often doesn’t work in Rider for me. ESLint makes Visual Studio even slower (is that even possible?! 😅).

It’s hard to fully explain if you only worked with TypeScript in Rider or Visual Studio, but I promise you that switching to VS Code makes a huge difference 🤪 Read on to get to know why!

3. Confusion of concepts

Let me explain my approach to frontend and backend first. To me, as a full stack developer, working on a frontend app requires a different mindset than working on backend. For instance, developing a React app requires me to think The React Way (we discussed it already in an article about React state management).

In my view, editing both frontend and backend code in the same editor makes you confuse concepts. If you learned JavaScript/TypeScript after working with C# for some time, you probably experienced trying to use let in C# or declaring C# types with colon (:) 😅 But this is only a tip of the iceberg.

I think having a separate IDE for TypeScript makes you nicely switch context when working on the frontend app. Opening my TypeScript code editor, I immediately start thinking in frontend. It instantly switches my approach to writing code. I somehow start to behave like a frontend developer, not a full stack one.

I think such approach is beneficial. For instance, it lets me work on my frontend code as I would be a real consumer of the backend API, not the person who can implement the backend in whichever way I want. Thanks to that switching of viewpoint, I can focus on designing my frontend code properly, without worrying about the backend.

I also tend to make less assumptions like oh no worries, I will do it on the server. At that moment, with my IDE for TypeScript open, I am a frontend developer. It often leads to better API design later on, because I don’t make any assumptions about the backend. Working on a frontend part of the app, I usually use API mocks first, knowing only the shape of data that should come from the API. Only later, when I’m done with the frontend part, I switch to Rider to actually implement the API.

Of course, this can also work the other way around. You can first work on the backend, design your API according to the best practices (again – without even thinking about your frontend app) and finally switch to the frontend IDE, build the UI and consume the API instead of using mock in the first place.

I hope you got what I mean here, but it’s not easy to clearly explain 🤪

4. Temptation to sneak C# concepts to TS

This point is a consequence of the previous one. If your IDE for TypeScript is the same as your C# code editor, you will be tempted to sneak C# concepts into TypeScript. I often see .NET developers entering TypeScript world using var by default (which is kinda deprecated in JavaScript and considered a bad practice today) or enforcing C# brackets formatting style in their frontend code. I also noticed overuse of classes and inheritance in TypeScript, as well as confusing passing value/reference data directly into components instead of properly using state and props in React.

To sum it up: isolating yourself as a frontend developer by using a TypeScript-specific IDE (like VS Code) will help you learn good frontend practices quicker 🙂

5. Because VS Code is better 😀

Last, but not least: the main reason to not use Visual Studio or Rider for TypeScript development is simple: Visual Studio Code is better! 😀

VS Code is industry standard for frontend development today. According to Stack Overflow Developer Survey 2023, over 70% of all developers use Visual Studio Code:

Visual Studio Code is the most widely used IDE for TypeScript (and IDE in general)

VS Code is lightweight. It doesn’t have all heavy features included by default. If you want something additional, it must be installed as an extension. By the way, the extensions are really great and actively developed by the community.

VS Code is mostly written in TypeScript, which makes is somewhat designed for TypeScript. It has great search features, awesome IntelliSense for TypeScript and works really fast. Especially compared to Visual Studio or even Rider.

Visual Studio Code can also be run on any platform. It even has a fully-featured web version. The IDE is also completely free and open-source.

I think I won’t continue listing numerous advantages of VS Code here. If you’re reading this, and you are still not encouraged to switch to VS Code for TypeScript development, please give it a try 🙂 Or another try if you already tried, but it didn’t click. This time, first watch some introductory videos with tips on how to get started and get the most of the editor. You can also check the VS Code extensions I use on a daily basis to make your work with this editor easier.


That’s it! I really wanted to write this article one day. Do you know that feeling when you learned something new or made significant progress in some area of your life, and you see people still struggling with what you have overcome? It’s this moment when you would really love to give these people all of your knowledge and make them magically change their lives – the same way you did 😀 I feel exactly that when I see fellow developers struggling (it’s a matter of opinion, I know 😀) with Typescript in Visual Studio 🙈

I know I can’t change you and your beliefs and I don’t want to do that. But the great thing is that I can share my point of view and try to encourage you to alter yours a little. At least try and let me know what are your thoughts on that 😉

Also, if you’re a frontend or full stack developer working in a backend IDE like Rider or Visual Studio, let me know why! I’m really curious. Did you try VS Code? If yes, what didn’t fit?

.NET full stack web developer & digital nomad
2.3 3 votes
Article Rating
Notify of
Inline Feedbacks
View all comments