4 ms·

Typescript is ES with totally optional type information, which protects you from a whole lot of bugs and for javascript bad API design (i.e. horrors like APIs w

Typescript is ES with totally optional type information, which protects you from a whole lot of bugs and for javascript bad API design (i.e. horrors like APIs which return different types with different input). I can understand that it feels strange, especially to someone who has had little exposure to languages outside of Javascript. However it is very much worth investing the time in learning it. 15 years ago I was making the same argument to Visual Basic developers about C#..

Touche 11y ago
You're wrong, there are various other differences. Some of what TypeScript implements isn't supported by JavaScript yet (like import/export for example). It's very much a different language, which is fine, but it is annoying to constantly hear "it's just JS with optional types".
- pfooti 11y ago
  I use import / export in my regular javascript. I just use babel and browserify for it. I am sure that there are typescript language features that aren't "just optional types", but I don't think import / export is so far outside the normal ES/next kind of norm that you'd call it some kind of MSbomination.
  - Touche 11y ago
    Babel is not "regular JavaScript", your import/export statements won't work when browsers and Node support them (you are required to include the .js extension and Babel doesn't enforce that). Babel also supports things like JSX and Flow.
gshulegaard 11y ago
I'm sorry but I will never use Angular 2.0 unless it can be used with straight JavaScript. I am a backend developer that, for personal projects, needs to do small amounts of front-end work. Anything that potentially increases complexity or involves a redundant learning curve (learning yet another _imperative_ language that compiles into JavaScript anyway) is not something I am going to invest time in. It's a shame too, I was a pretty big Angular fan. I used Angular, Ember, and even React and for several reasons I ended up settling on Angular as my favorite SPA framework (back in 2014 and 2015). Back when they announced Angular 2.0 would be TypeScript based, I felt like it was a mistake and that feeling has only gotten stronger as TypeScript has continued to fall behind EMCAScript (http://kangax.github.io/compat-table/es6/ http://kangax.github.io/compat-table/es6/). If TypeScript adopts compilation down to WebAssembly, that would be a reason to learn it/give Angular 2.0 a chance for me, but until then I will stick to Angular 1.0 or move towards React for my next project...which is a shame because I really don't like Reacts focus on the V of MVC. Maybe I will go back and check on Ember, but I wasn't a fan of it's tight binding of Models to Views (sometimes I just need a VC or a V and not a full MVC)...but maybe it has changed.
- squeaky-clean 11y ago
  > I'm sorry but I will never use Angular 2.0 unless it can be used with straight JavaScript. It can. Typescript is just optional information added to your Javascript. All Javascript is 100% compatible TypeScript. You can use TS extensions anywhere you like, your whole codebase, only certain function APIs, or nowhere at all.
Roboprog 11y ago
Ugh, I'm tired of mandatory "OOP for dummies" a la Java (and C# to a lesser degree). I've been programming since the early 80s, and I have been exposed to more than just Javascript, or Java/C# for that matter. (BASIC, Fortran, Pascal, Lisp, some assembler, xBASE, C, some C++, Shell, Perl, Java, C#, Ruby, Javascript, some Python, some Objective C, some Scala, Groovy and smatterings of other proprietary / DSLs) My first job in the mid 80s was in a language with runtime typing. My experience is that "strong" (compile/parse time) typing is not the panacea that many say it is. I've seen far more damage caused by C style "operator precedence stew" issues (vs Lisp style all funcs w/ parens). It's like the Type Police have to punish us for the dark era of C/++ Play-dough Pumper byte molding the industry had to put itself through in the 90s. In fact, I would much rather see a language that forced modules/data/functions to be flagged which were not immutable/idempotent (which should be an enforced default), rather than an even-trade-at-best static type feature. Yes, that means your "main" would be flagged as "dirty", so it could do I/O, but your library modules (lang; 3rd party; app) would mostly be pure functions. Anyway, I much prefer dynamic (runtime) types and FP with an occasional dash of OOP style Javascript to the "Let's be like Java!" cult. As Douglas Crockford likes to say "Those people will go to their graves, never knowing how miserable they are". Ironic, considering how the coming holy grail of ADTs/Objects was beaten into us in Uni in the 80s, and FP all but ignored.
- Roboprog 11y ago
  As long as I'm peeving at length about the Java meme plague, I wish the whole MashedUpCamelCraps identifier style would just die, already, vs you_can_skim_this style.

Touche 11y ago

You're wrong, there are various other differences. Some of what TypeScript implements isn't supported by JavaScript yet (like import/export for example). It's very much a different language, which is fine, but it is annoying to constantly hear "it's just JS with optional types".

pfooti 11y ago
I use import / export in my regular javascript. I just use babel and browserify for it. I am sure that there are typescript language features that aren't "just optional types", but I don't think import / export is so far outside the normal ES/next kind of norm that you'd call it some kind of MSbomination.
- Touche 11y ago
  Babel is not "regular JavaScript", your import/export statements won't work when browsers and Node support them (you are required to include the .js extension and Babel doesn't enforce that). Babel also supports things like JSX and Flow.

gshulegaard 11y ago

I'm sorry but I will never use Angular 2.0 unless it can be used with straight JavaScript. I am a backend developer that, for personal projects, needs to do small amounts of front-end work. Anything that potentially increases complexity or involves a redundant learning curve (learning yet another _imperative_ language that compiles into JavaScript anyway) is not something I am going to invest time in. It's a shame too, I was a pretty big Angular fan. I used Angular, Ember, and even React and for several reasons I ended up settling on Angular as my favorite SPA framework (back in 2014 and 2015). Back when they announced Angular 2.0 would be TypeScript based, I felt like it was a mistake and that feeling has only gotten stronger as TypeScript has continued to fall behind EMCAScript (http://kangax.github.io/compat-table/es6/ http://kangax.github.io/compat-table/es6/). If TypeScript adopts compilation down to WebAssembly, that would be a reason to learn it/give Angular 2.0 a chance for me, but until then I will stick to Angular 1.0 or move towards React for my next project...which is a shame because I really don't like Reacts focus on the V of MVC. Maybe I will go back and check on Ember, but I wasn't a fan of it's tight binding of Models to Views (sometimes I just need a VC or a V and not a full MVC)...but maybe it has changed.

squeaky-clean 11y ago
> I'm sorry but I will never use Angular 2.0 unless it can be used with straight JavaScript. It can. Typescript is just optional information added to your Javascript. All Javascript is 100% compatible TypeScript. You can use TS extensions anywhere you like, your whole codebase, only certain function APIs, or nowhere at all.

Roboprog 11y ago

Ugh, I'm tired of mandatory "OOP for dummies" a la Java (and C# to a lesser degree). I've been programming since the early 80s, and I have been exposed to more than just Javascript, or Java/C# for that matter. (BASIC, Fortran, Pascal, Lisp, some assembler, xBASE, C, some C++, Shell, Perl, Java, C#, Ruby, Javascript, some Python, some Objective C, some Scala, Groovy and smatterings of other proprietary / DSLs) My first job in the mid 80s was in a language with runtime typing. My experience is that "strong" (compile/parse time) typing is not the panacea that many say it is. I've seen far more damage caused by C style "operator precedence stew" issues (vs Lisp style all funcs w/ parens). It's like the Type Police have to punish us for the dark era of C/++ Play-dough Pumper byte molding the industry had to put itself through in the 90s. In fact, I would much rather see a language that forced modules/data/functions to be flagged which were not immutable/idempotent (which should be an enforced default), rather than an even-trade-at-best static type feature. Yes, that means your "main" would be flagged as "dirty", so it could do I/O, but your library modules (lang; 3rd party; app) would mostly be pure functions. Anyway, I much prefer dynamic (runtime) types and FP with an occasional dash of OOP style Javascript to the "Let's be like Java!" cult. As Douglas Crockford likes to say "Those people will go to their graves, never knowing how miserable they are". Ironic, considering how the coming holy grail of ADTs/Objects was beaten into us in Uni in the 80s, and FP all but ignored.

Roboprog 11y ago
As long as I'm peeving at length about the Java meme plague, I wish the whole MashedUpCamelCraps identifier style would just die, already, vs you_can_skim_this style.