For everyone who just wants to see the summary of how I'm doing Angular and TypeScript development today, TL;DR would be enough. If you want the whole story - why I chose those tools, skip it and move forward to the full post.

TL;DR

You can use any editor to write TypeScript code, as long as you use VS Code. Keep reading to find out why.
I highly recommend using angular-cli to scaffold your project, unless you need proper i18n support right now. In that case there are other generators which plug in ngx-translate, such as ngX-Rocket. As of January 2018, full i18n support with angular-cli isn't due for another 2-3 months at least.
In case you used AngularJS as a sort of glorified jQuery, instead of building an SPA, you might rather be interested in Vue.js than Angular.

Full Post

Typescript

I started using TypeScript together with AngularJS back in 2012. Back then, life for a TypeScript developer was difficult at best. For the first year, we were writing code in Visual Studio, which compiled it to JavaScript. Since we needed that JavaScript code on the build agent, and Visual Studio wasn't running there, we just committed both files (.ts and .js) into git. This kind of worked while I was using Visual Studio for C# development as a back-end for the AngularJS code, but started falling apart, as soon as I wanted to use TypeScript for NodeJS or Meteor applications.

3 years ago, the beginning of 2015, I published the post TypeScript Development in Practice, which summarizes the tools I used until that time. Unfortunately (or luckily?) the section about how I configured Sublime Text to work with TypeScript got outdated fairly soon. Just a few months later, in spring of 2015, Microsoft released the first version of Visual Studio Code(later in this article referred to as VS Code). To this day, it's the editor with the best out of the box support for TypeScript I've encountered. I'm especially favoring it over big and clunky IDEs like Visual Studio or WebStorm.

Angular (and AngularJS) Tooling

While support for coding in TypeScript had improved rapidly within the blink of an eye, with the release of VS Code, how did the AngularJS (and later Angular) tooling do? In the second half of 2014, the amazing Yeoman gulp-angular generator saw the light of day. I jumped on using it almost immediately, to get rid of my Visual Studio dependency. Throughout the years the gulp-angular generator became FountainJS, as they kept extending the offering beyond AngularJS to React, Angular and now Vue.js. The FountainJS generator is, as far as I know, basically the only choice for AngularJS.

With Angular (version 2 and beyond), the Angular team understood the need for tooling and brought the angular-cli (or as it's called now @angular/cli). If you're new to Angular, I'd suggest you to just start with the angular-cli. By now (soon version 1.7) it works very well and supports all the different ng compiler commands, as well as tslint and i18n. You get everything out of one tool. There is currently one exception to this general rule, if you need proper i18n support right away, then you're slightly out of luck.

i18n in Angular projects

Personally I didn't manage to get i18n running properly in my old AngularJS projects. Actually, I didn't manage to get it running properly almost anywhere. However, the new i18n approach in Angular is so nicely easy. Just annotate tags and attributes you want to translate with i18n and done (more on it in the official documentation). Unfortunately, as of January 2018, this only works in HTML templates and not for TypeScript (or JavaScript) strings. There are a bunch of GitHub issues addressing this. As of today, the most up to date information can be probably found in this comment. So, depending on when you'll read this post, you might want to use ngx-translate instead of the default Angular i18n option. There is a great generator scaffolding a project with ngx-translate called ngX-Rocket, but maybe FountainJS or other Yeoman based generators do that as well.

AngularJS to Angular

All in all, I'm very happy about moving forward with Angular. It became a great tool and ecosystem for building large scale Single Page Applications (SPAs). As I already mentioned before, it's also the first time, when I feel confident that we are building a translatable application. In fact, it is already translated into multiple languages and we have users who don't speak (almost any) English and therefore work with the application in one of the translated languages.

This was about building SPAs, but many people also used AngularJS to enhance screens which are actually rendered on the server using PHP, Razor views (in ASP.NET MVC) or similar technologies based on Java, Python, Ruby, ... I've seen the term glorified jQuery being coined, to describe exactly that usage pattern. Although I can't really find it on-line anymore, it means in essence, that you use AngularJS to enhance one screen, but the functionality you're adding could have just as well been added using plain JavaScript or jQuery.

Imagine a simple user management screen with a list of users and a details view. When you switch between the list of users and a specific user, you get a page rendered by the server. However when you render the confirmation dialog, if you really want to lock / delete a user, or the pop up to reset the password, you use AngularJS. The reason this is a bad idea, is the huge load of AngularJS coming down to do something, you could easily get done with the default Bootstrap and jQuery libraries, which are much smaller in size. Long story short, this isn't possible to do with Angular anymore. Not only is it impractical, because Angular feels even bigger and bulkier than AngularJS, it just straight out isn't (really) possible. At least not if you want to take advantage of all the other features it offers, like AOT.

There is a feature planned, called Angular Elements ...

Angular Elements will (when it’s ready) allow you to extend the reach of your Angular code. By allowing you to package your Angular components as Custom Elements, we hope that this will add the capability to leverage your Angular efforts outside the context of an Angular application. (source)

But even if that is ready, it won't be possible to just mix Angular into some server rendered code back and forth. Instead, if you just want to add a bit of JavaScript to your existing HTML code and have 2-way data binding at your finger tips, like you had with AngularJS, you might want to have a look at Vue.js. From their introduction page you can read, that Vue is ...

... a progressive framework for building user interfaces. Unlike other monolithic frameworks, Vue is designed from the ground up to be incrementally adoptable. The core library is focused on the view layer only, and is easy to pick up and integrate with other libraries or existing projects. ... (source)

It is much smaller than Angular (or AngularJS for that matter) and can be used to start enriching existing static HTML pages. There is no built-in support for TypeScript in the vue-cli yet (yes, seems like everyone has a cli these days, and that is AWESOME), but there are some issues tracking it, and it might come with version 3:

Until then, you can try this template by microsoft: https://github.com/Microsoft/TypeScript-Vue-Starter

Summary

Those were my 2 cents on how AngularJS and TypeScript development evolved and how you should consider either Angular or Vue to be the future, depending on what you need. In short this means:

You can use any editor to write TypeScript code, as long as you use VS Code.
I highly recommend using angular-cli to scaffold your project, unless you need proper i18n support right now. In that case there are other generators which plug in ngx-translate, such as ngX-Rocket. As of January 2018, full i18n support with angular-cli isn't due for another 2-3 months at least.
In case you used AngularJS as a sort of glorified jQuery, instead of building an SPA, you might rather be interested in Vue.js than Angular.