While I found ng1 useful, I'll never touch this one. I can see now how dependency injection can be both a blessing and also a curse in some contexts. I also can see how Typescript features can shape a codebase and ultimately make it look like Enterprise Java, instead of making it easy to use and to learn.
I also just don't like the over use of non standard features like decorators. There is a chance they don't make it to the spec, what then ?
As is shown with the decorator transpiling in both typescript and babel, it doesn't really matter if it never makes it to the spec: you can still use it using a compiler. I use it in my own production software and it is a real blessing when trying to use a more OO approach in a JS world
> it doesn't really matter if it never makes it to the spec
I does matter as there is difference between introducing type support in a language and introducing features that completely are non standard. Now imagine TC39 introduces a decorator syntax that is not compatible with Typescript's implementation ( it happened in the past with previous Typescript module syntax and the language had to break compatibility )
Angular 2 is completely based on the use of decorators to inject almost anything. Sometimes the decorator definition itself is bigger than the class using it.
It matters if the person who wrote the babel plugin stops supporting it. This is the problem I have with the babel culture, I don't think people realize that they are really inventing their own language which is a mismash of various language features they like; some of which is part of a real language, some of which is not.
> I also can see how Typescript features can shape a codebase and ultimately make it look like Enterprise Java, instead of making it easy to use and to learn.
Meh, I don't see how this is a bad thing. We need some more software engineering in the javascript space instead of cowboy hacking.
> We need some more software engineering in the javascript space instead of cowboy hacking
Are you saying that the ability to write entreprise java code is what separates "software engineers" from "cowboy hackers" ? That statement is arrogant.
My point is the use of Typescript doesn't produce idiomatic Javascript code, since it encourages writing front-end code a certain way. You might like it, fine, I'm personally not willing to deal with that kind of over engineering blessed in the Java world, I know what it leads to. If this approach was really successful everybody would be using JWT by now. Obviously they don't.
> Are you saying that the ability to write entreprise java code is what separates "software engineers" from "cowboy hackers" ?
I'm saying that software engineering doesn't need to be simple, it needs to be solid. I think type safety is one of those features that makes a language more solid.
Complexity for the sake of it doesn't make software engineering solid. JEE complexity doesn't come from the need to be solid but from Java's flaws. In my book it's the very definition of bad engineering.
Have you used TypeScript? I thought the very same things until I started using it. TS does a great job of maintaining the spirit and feel of JS. It's not a "C# for the web", it really is "JavaScript with types"
It is C# for the web, of which a small subset is great and can be used to make "JavaScript with types".
Or rather, TypeScript isn't bad, but the way it is documented might convince people to do bad things. It took forever to get "the good parts" of JavaScript in people's head, and that doc is really a step backward.
If you just use TypeScript's types and run away with that though, it's pretty good. If you start using classes all over, rely on private/protected/public like crazy to make complicated domain models, abuse decorators to hell, enums, etc... then it's C# for the web.
It doesn't have to be used that way, but those features made available and having a high focus in the official doc is causing a lot of issues when people coming from Java/C# hop in a TypeScript code base.
We don't use TS here, but when we hire people who come from TS companies, we have to tie them down for them not to start writing C#-like code, and remind them that it's structural typing, etc.
I have to disagree. For starters classes came from ES2015. They're an official, first class construct of JavaScript now, whether we like it or not. Decorators are also from ECMAScript. Whether people use TypeScript or not, a lot of what you're complaining about is coming regardless.
The visibility modifiers are optional, only checked at compile time, and quite frankly solve a problem that JS developers have been solving badly for a decade now. From "gentlemen's privates" (ie, if it starts with an underscore please don't touch it or rely on it!), to closures to CommonJS modules, all ridiculous contraptions essentially designed to give you some sense of privacy in the language.
TypeScript doesn't have enums. Instead it allows you to restrict a string to a finite set of values. Which basically boils down to JavaScript "enums" with a dash of static typing thrown in.
I have no doubt TypeScript tends to attract C# and Java developers. But that doesn't take away from the fact that TypeScript is a proper superset of JavaScript, it doesn't force you into a rigid class system at all (structural typing for the win), and really, truly is "JavaScript with types".
Decorators aren't in EcmaScript yet. And the ES standard changed since they were implemented in TS (I honestly don't know if TS changed to accomodate or if they're just mismatched now).
TS sure as hell has something called "enum", which is NOT the same as their string literal types (those are good).
I disagree about the privates: closures are perfectly good functional ways of handling them, and if you didn't want that, we have symbols now to do it for "real". And privates aren't terrible. Protected however are OOP bullshit.
Though my primary point isn't in how its features are implemented: it's how they're advertised. That, to me, is what makes TypeScript "a C# for the web". It's implementation isn't terrible, especially if you stick to the "good parts". However, the "good parts" they advertise/encourages are javascript "bad parts.
Ah you're right, I forgot about the numeric enums. I was thinking strictly string based.
I honestly think "protected" is not worth fussing over. Not to mention JS becomes more classically oriented every day. I predict ES2018 adds "protected" :)
Anyway I honestly don't have much opinion on how they are marketing TS. The language itself is well done and that's all I really care about.
I also just don't like the over use of non standard features like decorators. There is a chance they don't make it to the spec, what then ?