9 ms·

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

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 9y ago
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.
- hacktothefuture 9y ago
  Great question. This is a cause for concern for me as well.
- kamarg 9y ago
  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.
- wincy 9y ago
  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 9y ago
    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.
- danielpatrick 9y ago
  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.
  - kevindqc 9y ago
    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)
  - leshow 9y ago
    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?
- vog 9y ago
  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-typescript.html#/ https://djcordhose.github.io/flow-vs-typescript/elm-flow-typ...
  - throwasehasdwi 9y ago
    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 9y ago
      Whoops, you are right. Removed the misleading part of my comment.
  - deleted 9y ago
    [deleted]
  - coldtea 9y ago
    >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.
- jmcmichael 9y ago
  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 https://github.com/angular/angular-cli
jondubois 9y ago
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.
- superninja234 9y ago
  "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.
- throwasehasdwi 9y ago
  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?

alttab 9y ago

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.

hacktothefuture 9y ago
Great question. This is a cause for concern for me as well.
kamarg 9y ago
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.
wincy 9y ago
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 9y ago
  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.
danielpatrick 9y ago
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.
- kevindqc 9y ago
  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)
- leshow 9y ago
  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?
vog 9y ago
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-typescript.html#/ https://djcordhose.github.io/flow-vs-typescript/elm-flow-typ...
- throwasehasdwi 9y ago
  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 9y ago
    Whoops, you are right. Removed the misleading part of my comment.
- deleted 9y ago
  [deleted]
- coldtea 9y ago
  >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.
jmcmichael 9y ago
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 https://github.com/angular/angular-cli

jondubois 9y ago

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.

superninja234 9y ago
"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.
throwasehasdwi 9y ago
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?