[danielpatrick]

I've been using Angular 2 for a medium sized application that will be going into production within the next few weeks. I'm not affiliated with the Angular team at all.

I started using it when this app was very much a POC last summer, just as the Angular team was finishing up the 2.0 release.

I learned firsthand last summer the issues with using a framework that was still in the oven: constant updates and some dependency changes. That was no fun for some time.

But I'll say now that it was worth it. (Maybe I should have started a little later, post-2.0 release). But I'm now building out a decent sized and complex application much faster than I'd ever done before.

It is strongly typed, it is modular, and it has dependency injection. Oh and it's strongly typed. I can't emphasize the importance of this enough. I know you can use typescript without Angular, but that the Angular community and the docs are all in typescript make this a typescript-native framework.

I'll never look at JavaScript again if I don't have to. You and your IDE and the rest of your team can know an object's Type without having to scrounge around, it's such a blissful departure from JavaScript.

It definitely has a learning curve. If you're spinning up a simple web app it may or may not be for you. (...though now I use it to spin up simple web apps because I'm used to it and it's so good for that) But for anything complex that is being worked on across a team, I recommend you take the time to learn it.

It's not perfect, nothing is. But it is leagues ahead of any framework I've used on the front end. And having gone to Typescript, I will never use a native JavaScript framework again.

[alttab]

What's been your experience with browser-side debugging? The one thing that scares me about typescript is you end up debugging something you didn't write.

[danielpatrick]

Yes, good question.

I use VS Code (with the Chrome debugger plugin) and that works like a charm. I don't debug javascript in the browser anymore.

TS provides source mappings to map the compiled javascript back to the source (similar to a .dll's .pdb maybe?).

It took me some time to set up the config file which proved to be a headache (because webpack was screwing with the source maps), but again once that was set up it has been a breeze to debug right in my IDE whenever I want.

[leshow]

Odd, I'm new to vscode, but I tried to set up this plugin and it was completely unusable to me.

Perhaps you can describe the steps you followed? I tried installing the plugin and launching chrome with the debug flag, then setting a breakpoint in vscode. Is there something I am missing there?

[kevindqc]

That's been my experience too. Also once angular-cli seems more stable, I will probably switch to it and delete webpack (I know angular-cli uses webpack behind-the-scene, but at least I don't have to deal with it directly)

[kamarg]

You can tell the Typescript compiler to generate source maps that allow you to debug your Typescript code in the browser with a single configuration item in tsconfig.json. Chrome (and maybe Firefox?) will download them by default when you open up the debugger.

[jmcmichael]

By default angular-cli produces source maps in dev mode. These work transparently when viewing source and using breakpoints in Chrome, Firefox, Safari, Opera. Just install @angular/cli create a project and a few components and check it out: https://github.com/angular/angular-cli

[vog]

That's why I'd personally prefer Flow for that. It has a more elaborate type system anyway. [1]

Moreover, Flow is pure annotation, which can be removed by Babel. And Flow is also backed by a large company (Facebook instead of Microsoft).

However, if you do want to generate JS, use a language that elminiates runtime errors almost completely, such as Elm or OCaml (through bucklescript or js-of-ocaml).

[1] The following presentation contains some scary examples of incorrect code not rejected by Typescript. I'd rather prefer Flow which errs on beeing too strict: https://djcordhose.github.io/flow-vs-typescript/elm-flow-typ...

[throwasehasdwi]

Your comment neglects to mention that Typescript debugging is generally easy because one of the design goals of typescript is to produce javascript that matches what a developer would write.

Debugging javascript produced by Babel is generally hell in comparison. The transforms done by Babel are not designed to be human readable and they generally aren't.

[vog]

Whoops, you are right. Removed the misleading part of my comment.

[coldtea]

>And Flow is also backed by a large company (Facebook instead of Microsoft).

Only Facebook doesn't care much to back or promote Flow, besides the occasional blog post, whereas Microsoft has created a whole IDE / VS Code support for it, great tooling, documentation, etc.

[wincy]

At least in Chrome it'll pick up the mappings and let you directly debug the typescript you wrote. Worst case the javascript isn't nearly as gnarly as you'd think.

[alttab]

But then you need to be good at Typescript, React, AND Javascript to build a feature. And that's not even considering databases, server middle ware, etc.

[hacktothefuture]

Great question. This is a cause for concern for me as well.

[jondubois]

I don't particularly like TypeScript. It slows me down because of several reasons:

- Compile time means that it takes more time to debug anything.

- The rigid interfaces mean that I need to spend more time researching how to use various modules/libraries (maybe code completion would offset this problem but this is only possible with a heavy IDE that has intellisense or similar - Not Atom).

- When I want to test something quickly, I often get annoying compile-time errors along the lines of 'code is unreachable...' among others.

- It requires more planning to do anything (since you have to design the interfaces before you can start to implement). This is also not good if you just want to try something quickly and then roll back later.

- Changes to one class/interface tend to have a large cascading effect on other classes/interfaces so it takes more time to make changes to code - This happens with JS too but to a much lesser extent.

- Adds lots of unnecessary dependencies to my project.

- Complicates setup and DevOps tasks, Dockerizing, (E.g. due to version mismatches and thousands of other potential issues) etc...

The reason why I don't like heavy IDEs is because:

- They're slow and clunky (sometimes they freeze for a long time in order to index content)

- The use up a ton of memory.

- They make your team lazy when it comes to structuring your source code into proper folders (since you start to rely more on search features of the IDE to find things).

- They take ages to install.

- Support fewer operating systems.

- Are usually proprietary and difficult to customize.

- More prone to bugs.

[throwasehasdwi]

Your complaints against "heavy" IDE's don't make sense. All of the points you made either aren't valid or don't matter.

- They're slow and clunky Not anything I've used. Eclipse and Visual Studio run nice and smooth on a decent machine.

- The use up a ton of memory. Who cares. Slack and anything based on electron uses hundreds of megabytes. Chrome regularly uses gigs. Most of the IDE's I use take less than 500 megabytes of ram, even phones have plenty.

- They make your team lazy when it comes to structuring your source code into proper folders Absolutely not. Your reasoning is that making things easier = making code worse. The IDE you use has nothing to do with your dev culture

- They take ages to install. Some of them do, notably Visual Studio. All the other ones I've used just take a few minutes. Also, who cares??? You only have to install it once, what is 5 minutes for an app you're going to use for thousands of hours???

- Support fewer operating systems. No. IDE's based on java run on almost anything. Again I think you're speaking from the experience of using visual studio.

- Are usually proprietary and difficult to customize. Also no. Every IDE I've used supports plugins and an unholy amount of configuration options. Every IDE I use is open source, again except visual studio.

- More prone to bugs. What? Why? How?

[tukelully]

Alot of these things do matter and it seems to me like all you're doing here is excusing bloat via hyperbole. I don't even agree necessarily with a lot of the parent comment, but I disagree with yours.

[coldtea]

>The rigid interfaces mean that I need to spend more time researching how to use various modules/libraries

Why, otherwise you'd just throw random parameters in a module's functions and see what sticks?

>Compile time means that it takes more time to debug anything.

Most people compile their JS anyway, TS or not, with Babel et al.

>maybe code completion would offset this problem but this is only possible with a heavy IDE that has intellisense or similar - Not Atom

VS Code has code completion for TS and is similar to Atom. And even Sublime Text has code completion for TS (based on tools MS itself provides for "intellisense" style predictions).

>- It requires more planning to do anything (since you have to design the interfaces before you can start to implement). This is also not good if you just want to try something quickly and then roll back later

Doesn't make any sense. It's not as if you don't need to know the interfaces before you start to implement with regular js. Only there you need to hunt for the documentation to tell you what's expected to pass -- instead of seeing what the types are directly (e.g. with intellisense).

>- Changes to one class/interface tend to have a large cascading effect on other classes/interfaces so it takes more time to make changes to code - This happens with JS too but to a much lesser extent.

It happens to the exact same extend in JS. Only with TS you are shown where the problems are automatically, with JS you have to hunt those places or discover it at runtime.

The rest goes downhill...

[superninja234]

"It requires more planning to do anything. This is also not good if you just want to try something quickly and then roll back later."

Since you can pretty much type javascript in to a TS file and it will work I don't see this being valid.

Also planning is good, if your not thinking about the structure of your code (which does not take that long) then your just producing diarrhea.

[merb]

> - Compile time means that it takes more time to debug anything.

how can this be an issue? even javascript needs to be concated minified and whatever to take it into production. it's not like that any human writes minified and mangled javascript with direct gzip.

P.S.: I'm not a fan of TypeScript. But to say you need to compile it, is just an excuse.

[WorldMaker]

The Typescript compiler is also happy to run directly inside the browser because it is itself written in JS. I've debugged projects where the TS is compiled at runtime inside the browser and F5 refresh is the entire build process.

Though it's just as easy to use a good IDE's build button (VSCode Ctrl+Shift+B for instance) or TS works well as a watch process that watches for saves and compiles them when you save.

[leshow]

> - It requires more planning to do anything

That's the idea. You think about what you're going to write in a strongly typed language rather than just throwing stuff at the wall hoping that something will stick.

> - The rigid interfaces mean that I need to spend more time researching how to use various modules/libraries

I don't understand this. In one case you have an API where the types of all the functions is available, so you can see almost right away how to use it. In the other case you have to rely on someone providing you really good documentation OR you read the implementation.

> - Changes to one class/interface tend to have a large cascading effect on other classes/interfaces so it takes more time to make changes to code - This happens with JS too but to a much lesser extent.

It's either you find the error at compile time or at run time. Don't kid yourself, there's a 'cascading effect' in both typed and untyped codebases, just in the typed one the compiler will help you find errors.

Granted, I'm not the biggest TS fan, I'd take Elm or Purescript, or even Flow. But your gripes seem to be directed to typed languages in general.

[jondubois]

>> - It requires more planning to do anything

> That's the idea. You think about what you're going to write in a strongly typed language rather than just throwing stuff at the wall hoping that something will stick.

I think this is a valid point for developers who only have a few years of experience but I've been coding professionally for over a decade now - I don't need the compiler to artificially slow me down - I'd rather spend my mental energy thinking about the algorithm/architecture in its purest form without getting caught up in trying to satisfy the compiler's tedious requirements.

For me programming in a typed language is like using software that always asks you "are you sure you want to do this?" every time you tell it to do something. It's OK if you're a beginner, but I just find it frustrating.

I spent many years programming in ActionScript 3 and then Java so I feel like I've given typed languages a fair shot.

[leshow]

> I don't need the compiler to artificially slow me down

It's slowing you down because you've written code with errors. Those type errors are still in your dynamic code, you just can't see them.

> I spent many years programming in ActionScript 3 and then Java so I feel like I've given typed languages a fair shot.

I don't think you have, you've missed many wonderful modern type system features.

Algebraic types, for one, aren't present in either of those languages and are massively useful, replacing 'null' (with a type like Option/Maybe) and exceptions (with a Result/Either concept) in many languages that have them.

Not to mention, with a language that has type inference, you don't even have to write the type in many cases, and yet you keep the guarantees of a strongly typed language.

[coldtea]

>I think this is a valid point for developers who only have a few years of experience but I've been coding professionally for over a decade now - I don't need the compiler to artificially slow me down

You'd be surprised.

There's a reason that developers after decades of dynamic languages turn increasingly to types (of which Flow and TS are examples in the JS world).

[lilactown]

VS Code (equivalent to Atom in power and scope) has the best intellisense for typescript. I use it over full-fledged IDEs (Intellij IDEA) all the time.

[danielpatrick]

> The rigid interfaces mean that I need to spend more time researching how to use various modules/libraries (maybe code completion would offset this problem but this is only possible with a heavy IDE that has intellisense or similar - Not Atom).

Obviously, to each his own.

I'd encourage you try Typescript again though. Your given reason doesn't make much sense. Regardless of whether the language is strongly typed or weakly typed, you still need to use modules and libraries correctly. "Not having to research" means you're just going to end up throwing data at a library without knowing what it's expecting. The research has to happen in both scenarios, but with typed languages it's easier. The research is just in the code already. (Try VS Code, not a "heavy" IDE by any means, but it has native support for TS code completion.)

If I have any modular interface, you need to know what to pass me. If you're receiving data from me, you need to know the structure of what I'm sending back to you.

In a weakly typed language, you can guess at what data structure I'm going to want. You can fish around in my returned data for what you're looking for with no guarantees. You have to look for docs, which may or may not be up to date.

But in a strongly typed language, the code is the doc. You and I and your IDE and my IDE are all on the same page. And the docs are always up to date. You can't pass me data that I'm not expecting and you always know how to access the data I'm returning to you.