The described features are not what TypeScript itself wants to be, and I think if it wasn't for backwards compatibility the team would remove some of them.
IIRC namespaces as well as the `import = ` syntax come from a time where ESM wasn't a thing yet but a module system was very much needed. So now that ESM can be used pretty much everywhere namespaces can be avoided and therefore reduce the learning surface of TypeScript.
Enums IMO have no advantage over union types with string literals, e.g. `type Status = 'fulfilled' | 'pending' | 'failed'`. They map way better to JSON and are generally easier to understand, while still benefiting from type safety and typo protection.
Well the private keyword is kind of like namespaces in that it came from a time where the feature was needed/wanted, but the EcmaScript spec was not moving fast enough. So they made their own version of it which is now obsolete.
And for decorators, IIRC the decorator spec has already moved on and TypeScript's implementation is no longer up to date with it. And the spec itself is only stage 2 as mentioned in the article, so I wouldn't recommend using decorators either, you will face breaking changes with them some time in the future.
Furthermore, it is far more likely that you run into trouble when using one of these features with a compiler that is not TSC, e.g. esbuild or Babel. Decorators have never been working all that well with the Babel plugin. Enums are probably fine here.
const MyTypeValues = ['a', 'b'] as const;
type MyType = typeof MyTypeValues[number];
Well I would say having to not repeat and update your code everywhere when you change or add a possible value is a pretty big advantage.
// filename: role.ts
export const Role = {
CUSTOMER: 'customer',
ADMIN: 'admin',
SYSTEM: 'system',
STAFF: 'staff',
} as const;
type TRole = keyof typeof Role;
export type TUserRole = typeof Role[TRole];
This way I'm not spreading "special" strings all over my code (always a sign of code smell for me), I can changed everything at a central location, and it's valid JS (it's just an object).
EDIT: I know that `as const` seems unnecessary but I'm pretty sure it's needed for some reason, I whittled this down to the smallest/simplest code block I could and I just copy/paste this pattern whenever I need enum-like functionality.
export const Role = {
CUSTOMER: 'customer',
ADMIN: 'admin',
SYSTEM: 'system',
STAFF: 'staff',
} as const
export type Role = typeof Role[keyof typeof Role]AFAIK, your solution is (slightly) worse than an enum in several ways and better in none:
export enum Role {
CUSTOMER = 'customer',
ADMIN = 'admin',
SYSTEM = 'system',
STAFF = 'staff',
}
See https://www.typescriptlang.org/docs/handbook/enums.html#cons...
> Const enums can only use constant enum expressions and unlike regular enums they are completely removed during compilation. Const enum members are inlined at use sites.
Unless you're a solo developer, what's more important it to agree on languages and conventions that apply to your team's projects. Once that's done, any change to the team's work process should be a conscious, measured decision.
Note that I also used CoffeeScript 10ish years ago and still consider it to be a superior experience to working in plain-old Javascript.
Occasionally I think I might want to use enums in a place but then find that other solutions like const collection objects or plain constants works fine enough for the purpose at hand. I don't think it's a problem if folks use enums though, it's really not a big deal.
I’m genuinely looking forward to the day where we have other viable options for the DOM. I see TypeScript at best as a temporary band aid because you’re still stuck in the god awful NPM ecosystem at the end of the day.
What? This is IMO bad advice. Having a sum type is quite handy for general type-checking, at least insofar as the type truly is an enumerated type (i.e. all possible values are known at design-time). There have been times when TypeScript enums have been indispensable to me when declaring the external interface to some client-facing API. Whatever the API boundary is, a sum type is useful.
Also, TypeScript gives general intersection types, which is quite rare among its peers. (What I wouldn't give some days for mypy to have intersection types, or bivariant functions, or conditional types, or ...)
The only other impetus for this post I can imagine is some weird desire to see typescript as a strictly separate layer above JavaScript that "could be removed" if we wanted it to be. I suppose that was the project's original telos, but today the abstraction is leaky in a few places. I'm a world where JSX is common and radically departs from what would be considered normal JS, I don't see a problem with TypeScript being leaky here and there. Hell, I'd prefer TS to be leakier and add opt-in runtime checking (i.e. code gen), because it would make my life easier in certain instances.
- https://stackoverflow.com/questions/40275832/typescript-has-...
- https://github.com/microsoft/TypeScript/issues/32690
In a TS codebase I'm currently working on, we have the policy of never using "plain" TS enums. Instead, we have a tool that generates our own enum objects using a schema and a generator script for the cases where we want "rich" enums. For other use cases, we use string unions a lot (in combination with a helper function that allows exhaustive matching).
That's a problem a lot of developers won't have. I've covered a lot of ground without ever finding a tool that either hasn't been retrofit to support TypeScript or that has issues that are tickled by TypeScript generated code. My blunt recommendation if somebody hits that problem is to find a better tool.
You can't test if a given string is an element of a union without writing a custom helper and/or allocating a runtime array of the values.
On the other hand, if you don't need to test unknown strings, then union types disappear at compile time, whereas enums are compiled to real, runtime, objects.
Enums don't look like naked strings in the code. Frankly, it's just nicer on my brain to see `return Color.Red` than `return "red"` and wonder if "red" is just some random text or if it has semantic meaning. Hopefully your IDE is smart enough to take you to where "red" is defined as part of a union type when you want to see other options. Granted- the most popular editors ARE smart enough to do that, but that doesn't help when just reading code with my eyes instead of my hands, or in patches/diffs.
It's true that enums are harder to support for alternative compilers. Especially `const enum` seems to be harder.
As long as it is supported — and at least esbuild does, who cares (as a user). Should I start avoiding every JS feature that is hard to implement in alternative JS runtimes?
Actually, as Amish communities are part of the human ecosystem, maybe we should also restrict anything we build in the real world to something that can be useful to the Amish and stop building anything requiring a power grid ?
enum HTTPMethod {
POST = 'post',
// ...
}
enum FenceMaterial {
POST = 'post',
// ...
}
Private fields have the same benefit, which is particularly useful for treating abstract classes as nominal interfaces. But yes, if your target environments support private fields natively, it’s more idiomatic to use those than the private keyword now.
I generally avoid namespaces, but they’re also sometimes useful eg satisfying weird function signatures expecting a callback with additional properties assigned to it. This is of course uncommon in TypeScript, but fairly common in untyped JavaScript and its corresponding DefinitelyTyped declarations.
Lets say I have a function that converts sizes to pixels:
const sizeToPx(size: ‘small’ | ‘med’ | ‘large’): number
type ButtonProps = { size: ‘small’ | ‘medium’ }
const Button = styled.button(({ size }: ButtonProps) => ({
height: sizeToPx(size)
You’re correct there’s a risk of a type collision. But I have never experienced anything like that. Seems pretty unlikely.
enum Size {
small = 'small',
medium = 'medium',
large = 'large',
}
type ButtonProps = { size: Size.small | Size.medium }
Regarding likelihood of collision, it’s easy for me to imagine mixing up 'post' in an API call to a vendor for fence materials lol. In any case I find the added safety comforting, particularly over a language where interfaces tend to be exceedingly dynamic and flexible.
> Avoid adding expression-level syntax.
https://github.com/Microsoft/TypeScript/wiki/TypeScript-Desi...
And that makes sense to me. IMHO it's best to consider TypeScript as a tool that aims to help you write JavaScript by catching common errors; it's more like a linter than a separate language in that regard, and is what sets it apart from something like CoffeeScript, and helps it avoid falling into the same traps.
I wish people wouldn't think like this; it's very possible to write perfectly acceptable JavaScript that's fundamentally terrible TypeScript. By "fundamentally terrible", I mean unnecessarily untypeable, or unnecessarily difficult to type. If you're just writing your usual JavaScript without thinking about the types just figuring you'll "lint" it later with tsc to catch some bugs, if you aren't thinking in TypeScript from the jump, you're likely to make your life much more unpleasant down the line. It's similar to the relationship between C and C++.
[1]: https://github.com/microsoft/TypeScript (repo description)
When I initially saw Typescript, I thought the point was to add features from strongly-typed languages and then transpile into Javascript. (IE, a more modern version of GWT, a Java to Javascript transpiler.)
The point of the article, though, is that Typescript works best when its extensions to the language can simply be dropped. That's clearly a "we've worked with this for many years and this is a big lesson from experience" statement, so I wouldn't discount it.
It's the other tools that author is/was using that are having issues. It's silly to provide blanket statements about very useful features like enums or namespaces just because some third-party tool is struggling with them IMO.
Namespaces mKe no sense to me. It’s probably because Microsoft drives TypeScript, but even though I was a C# developer for 10 years before moving on, they’ve just always been terrible to me. Their functionality is the sort of thing that is nice in theory, but really terrible in real world projects that run for years with variously skilled developers in a hurry.
Private is silly to me, but this is mostly because classes are silly to me. I can see why you’d want it if you use a lot of classes, I just don’t see why you would do that unless you’re trying to code C# in TypeScript. One of the things I loved the most about switching from C# to Python was how easy it was to use dictionaries and how powerful they were. The combination of TypeScript interfaces, Types and maps is the same brilliance with type safety. But once again, it’s sort of the thing where classes sometimes make sense, and when they do, so might private.
But features like enums are part of the reason why we even have tools like TypeScript, because JavaScript lacks these features.
Switching between Python and TypeScript/JavaScript all the time, using ‘#’ to define private field feels weird and I personally prefer more explicit way of writing code. Plus AFAIK the ‘private someField’ is common in other languages (Java, Scala,…).
The real trouble occurs when TypeScript implements something because that looks like the way things are heading, but then they don’t head that way, and JavaScript and TypeScript diverge incompatibly. The type stuff is generally fairly safe, and fundamentally necessary, but some of the other stuff they’ve added isn’t safe and isn’t… as necessary, at least. Decorators are the current prime case of this divergence problem: they added a feature because it was useful, lots of people wanted it, and that was what people expected JavaScript to get before long, and some were using already through a Babel extension but people were sad about having to choose between nifty features (Babel) and types (TypeScript); and then because they’d added something not in JavaScript, why not go a bit further? and so reflection metadata came along; and then… oh, turns out decorators are actually heading in a completely different and extremely incompatible direction in TC39 now, but people are depending on our old way and PANIC! It’s been a whole lot of bother that will continue to cause even more trouble, especially when they try to switch over to the new, if it gets stabilised—that’s going to be an extremely painful disaster for many projects, because “experimental” or not, it’s a widely-used feature of TypeScript.
This is not the only such case; there’s one other that caused a lot of bother comparatively recently, but I can’t think what it was (I don’t work in TypeScript much).
Sciter used what was loosely a fork of JavaScript when it started, and diverged, for quite decent reasons in some cases I will admit, but this divergence caused more and more trouble, until recently they gave up and switched to JavaScript, … except with a couple of incompatible deviations already and more on the table as probabilities. Sigh. I had hoped a lesson had been learned.
So yeah, I’m content to call these things misfeatures. TypeScript overstepped its bounds for reasons that seemed good at the time, and may even have been important for social reasons at the time, but you’re better to avoid these features.
In it he talked about how Angular 2 pushed decorators in to TS. And to this day, Angular is the only major JS thing that I can think of that uses decorators.
Creating that ng-abomination was not enough. No. Google also had to poison a perfectly fine language.
https://github.com/emberjs/rfcs/blob/master/text/0408-decora...
https://guides.emberjs.com/release/in-depth-topics/native-cl...
Otherwise I'm not aware of any cases besides decorators where TypeScript did something that was incompatible with a later ECMAScript development.
type methods = 'a' | 'b'
const value: methods = 'c' // error
Mechanically, a const dictionary, or a string union might achieve the same.
But semantically, an enum (sometimes) reads better.
That’s nonsense, the code is there otherwise what are we talking about?
You just need to understand how some TS features map to JS, that’s all.
> The downside to enums comes from how they fit into the TypeScript language. TypeScript is supposed to be JavaScript, but with static type features added. If we remove all of the types from TypeScript code, what's left should be valid JavaScript code. The formal word used in the TypeScript documentation is "type-level extension": most TypeScript features are type-level extensions to JavaScript, and they don't affect the code's runtime behavior.
And:
> Most TypeScript features work in this way, following the type-level extension rule. To get JavaScript code, the compiler simply removes the type annotations.
> Unfortunately, enums break this rule.
And then there is an explanation about why this is important: it makes life hard for tooling, especially fast tooling; for in the absence of such features, JavaScript tooling can support TypeScript with little bother, just dropping the TypeScript bits and getting equivalent JavaScript; but in the presence of such features, they have to either use tsc (slow!) or implement more TypeScript-specific stuff.
Compilation of most TypeScript features to JavaScript simply removes the TypeScript bits. Enums, however, have to be transformed, adding to the output JavaScript something that was not in the source JavaScript.
The author of the article surely knows the significant difference between JS private fields and TS private fields: TS private fields can be easily circumvented, whereas JS private fields cannot. See TS playground link[1]
I think this is a significant enough point that people should not be taught that TS's private is just a different way of doing the same thing. I've always said that TS is basically a fancy linter, and sometimes that's exactly what you want.
TS's private keyword communicates programmer intent, but lets you do what you like when you really have to. Just like the rest of TS.
[1]: https://www.typescriptlang.org/play?#code/MYGwhgzhAECC0G8BQ1...
The point is that we as developers choose to respect the typechecker.
I'm not saying that TS being a "fancy linter" is a bad thing - I actually think quite the opposite.
type HttpMethod = keyof typeof HttpMethod
const HttpMethod = {
GET: "GET",
POST: "POST",
} as const
type HttpMethod = Extract<keyof typeof HttpMethod, number>
const HttpMethod = {
GET: 0,
POST: 1,
0: "GET",
1: "POST",
} as const
- Avoid enum with negative integers because it generates code that cannot be optimized by the JS engine
- Prefer ESM modules to namespaces, because the first can be tree-shaked.
1) Enums have a unique (and, imo, mostly undesirable) model for interacting with the rest of the type system, which isn't what you'd naively expect. If you try to treat an enum like an object-literal (`as const`) when it comes to type-level manipulation you're going to have a bad time.
2) Implicit numeric enums (i.e. the ones most people use by default because they require the least amount of typing) make adding new values a _backwards-breaking change_ if you insert them before existing values, and you send them over the wire. Let me repeat that: adding new values to an existing enum is a _breaking change_.
3) Giving a field or parameter an enum type will not actually cause the Typescript compiler to complain if you put in a value that's not part of the enum! Example:
``` enum Fruit { APPLE, BANANA }
interface FruitSalad { base: Fruit }
const salad: FruitSalad = { base: 5 }; ```
Assigning `5` to `base` (which, you might expect, would only accept `Fruit.APPLE` and `Fruit.BANANA` - and perhaps even `0` and `1` as valid values) is in fact something that the compiler will let through without complaint.
4) Debugging is a headache, since reverse-mapping them gives you... a number.
You might say that most of these problems are solved by using string enums - sure, but then why not use an object literal instead? To save yourself from needing to write a single additional type definition? IMO, that is not worth the issues you run into with respect to the first problem.
They can also be used in the more traditional form to represent some arbitrary values.
They shouldn't be overused, though.
Typescript and JavaScript have a newer brand # to make fields private. The native feature will have runtime benefits while the private keyword creates fields that's are public at runtime.
I still use the private keyword because constructor shorthand doesn't support brands.
constructor (private field)
constructor (#field) // errorAnd ladies and gentlemen, the generated code...
var __classPrivateFieldGet = (this && this.__classPrivateFieldGet) || function (receiver, state, kind, f) { if (kind === "a" && !f) throw new TypeError("Private accessor was defined without a getter"); if (typeof state === "function" ? receiver !== state || !f : !state.has(receiver)) throw new TypeError("Cannot read private member from an object whose class did not declare it"); return kind === "m" ? f : kind === "a" ? f.call(receiver) : f ? f.value : state.get(receiver); };
Nothing about this says "native JavaScript" to me. Who cares that a private field is technically public at runtime?
If you want "native" JS output, use the tsconfig option... "target": "esnext
I don’t particularly care what the generated JS looks like when I do all my work in TS, but I do care that the type system of the language I do work in works in a consistent manner.
I mostly agree with the rest of the article’s recommendations, but don’t fully agree with their reasoning.
- Yes, namespaces should be avoided, but not because they generate extra code. Namespaces are not recommended anymore and modules (actual JS modules not TS’ `module`) is the recommended approach now.
- Yep, private fields are better for ensuring a field is truly private.
- I think decorators are fine to use if you’re prepared for your code to potentially break in the future if they’re standardised. Developers use new/unstable features all the time (e.g. stage 0/1 JS proposals via Babel, nightly Rust toolchain). And I don’t believe the lack of standardisation of decorators should be a factor in deciding whether to use a library that requires these.
reviews Angular app
oh
Everything has its place, and for allot of the features of TypeScript I think they are designed to be useful when you have a large number of developers working on incredibly large codebases.
I suppose in some ways it's like C++, you can decide to fully embrace all of its features, or code in a much more C like way, just taking advantage of classes.
It comes down to personal/team preference, what works for you.
Personally with TypeScript I'm inclined to code in a "closer to JavaScript" way (but taking full advantage of types obviously), but would happily work in whatever style was prevailing in the project.
I feel like most of the typescript code i've been in recently looked like it needed 0 more class declarations.
- Abstract classes are useful for defining nominal interface types
- Classes are a clear signal that a set of methods are designed to interact with related data types
- The prototype chain can be helpful for debugging where POJOs may lose information in the call stack
- JS runtimes can sometimes optimize classes in ways they can’t with POJOs
(btw, don’t try using Angular at all if you are already happy with your career)
React, Lit, angular, all use classes to define elements (yes you can use functions for a subset of components, but not all)
When the prototype chain is involved I think the value gained from structural typing tends to decrease -- or at least exposes the programmer to more sharp edges.
In fact, the only major problem I have with TypeScript is the lack of operator overloading [1]. This feature has been denied with the exact same justification. They will not add any feature that emits additional logic, so they cannot add operator overloading unless JS adds it. Also they will not add anything that needs runtime type lookup.
I think very simple, stupid syntactic sugar would be sufficient to solve 90% of use cases. For example, and please don't take this apart, I'm just making it up on the spot: transforming `a + b` to `a._op_add(b)` if a is not provably `any` or a primitive type.
Without operator overloading, for example vector math looks really ugly. I hope somebody will make at least a babel plugin or something to allow that.
Do they?
It seems to me that namespaces are more powerful and convenient than JS modules as they enable more structure.
I have only dabbled in TS and am not sure how useful they are there. But I assume they would be similar to PHP/C#/Clojure namespaces on a conceptual level.
VueJS 3 in particular is much better suited to use TS than its predecessor (without any additional plugins).
I’ve yet to see typical front end code that really benefits from strong typing or even just the use of enums. I tend to accept language limitations and focus on designing my programs around those instead of wasting my energy on fighting on niche language extensions…
There are features of the type system you should definitely avoid unless you're writing a library. Enums aren't it.
I like TypeScript a LOT, but to be honest I only use about 10% of it. Anything more than that and it gets too confusing for the next developer in line to work on the code in my experience.
As for the fact that types cannot simply be stripped out, I've found building using plain tsc and have the bundler target tsc's output directory. This separation is needed since most tools don't support TypeScript project references anyway which I find extremely useful for organizing internal modules.
There are many features in Typescript where it simply isn’t just outputting a subset of the input, and many of them are the best parts of Typescript.
If you just want JavaScript with types, there are other languages that do that, but Typescript offers so much more.
It's pretty what TypeScript's going for though:
> Avoid adding expression-level syntax.
https://github.com/Microsoft/TypeScript/wiki/TypeScript-Desi...
Compiling to readable JS is not one of TS's goals. For example:
https://www.typescriptlang.org/play?noImplicitAny=false&targ...
From the language goals
> 4. Emit clean, idiomatic, recognizable JavaScript code.
https://github.com/Microsoft/TypeScript/wiki/TypeScript-Desi...
Well designed Abstractions are good, not bad…
Usually generic code tries to make everything type safe but having some portions of your code be dynamic is completely fine imo.
The private keyword is obviously preferable to "#" in environments in which you are targeting older ES versions.
We use enums and private keywords. With the private keywords, all I care about is that it is logically correct. We use private when things are truly private, i.e. they are only called from within the same class and don't need to be made visible to the view template or outside of the class. I honestly don't care what this transpiles down to, the point for us at least is not to make things "truly private" (good luck with that in JavaScript). It's simply to compiler-enforce rules. We also have ESLint to ensure that our private fields are all below the public ones to keep things nice and neat.
I also enforce that we actually make things as public although that isn't needed, and I enforce returning void.
So instead of:
someMethod() {}
I have us use:
public someMethod(): void {}
Just to state what you intend.
I realize "I don't care what this transpiles down to" might really irk some people, but I really don't. In our C# back-end I am much more strict about this stuff, but in JS at the moment given the standardization of the #private fields and the fact I consider them really ugly, I honestly don't care. Just give me a clean code base that enforces we can't reference private fields and methods from our templates.
For enums, I recently wrote a method that does exactly what this article says not to do, use it for GET, POST, and PUT.
What would be a cleaner way to write this? If it has to be refactored into something much "uglier" I don't think I'd prefer it.
this.downloadService.fileWithProgress(url, RequestType.post, ActionType.download, body)
It’s not just JavaScript. With reflection in C# and Java, you can mess around with private variables from outside the classes. For Java, this can have some pretty interesting results, such as 2+2 being equal to 5.[0] The whole point of compiler level annotations is to keep good programmers honest.
If some devious JavaScript developer wants to ruin your library, that's their fault.
#define private public
#import <something.h>
Worth mentioning that you can disallow reflection via the security manager, at least in earlier versions of the JVM.
this.downloadService.fileWithProgress(url, 'POST', 'download', body);
...
public fileWithProgress(url: string, reqType: RequestType, actionType: ActionType, body: ...): void {
...
}
...
export type RequestType = 'GET' | 'POST' | ...;
export type ActionType = 'download' | ...;Apart from that, because Typescript has powerful union types, not using enum is perfectly fine as well, for example instead of:
enum Relation { Less = -1, Equal, Greater }
Object.freeze(Relation);
const Less = -1;
type Less = -1;
const Equal = 0;
type Equal = 0;
const Greater = 1;
type Greater = 1;
type Relation = Less | Equal | Greater;
As for private and #, the biggest disadvantage of # is that it is so slow currently. But that will change hopefully soon when # is not compiled as WeakMaps by TypeScript. I would hope they compile private to # later on, backwards compatibility be damned :-D
It's true the down-levelled code that uses WeakMaps is slower. The decision to downlevel is in the hands of the user and is controlled by the tsconfig "target" option.
The only environment that needs downlevelled #private fields is IE11.
I most strongly disagree with the recommendation against enums. Realistically, you will probably never run into a compiler bug from enum emit; maybe something like this might happen with a very complicated runtime feature, but enum emit is dead-simple and hard to get wrong (at least if your toolchain has any tests at all, which it presumably should). And they're generally convenient and fill a useful niche, especially numeric enums with implicitly assigned values. (I'm also curious what the article's authors think of const enums.)
Namespaces have been soft-deprecated, modules are pretty much just better, and so I quite agree that you shouldn't use them, though I'm not sure the risk of compiler bugs is the most compelling argument against. (It is more compelling than with enums, since the required code transformations are much less trivial.)
Decorators, especially with metadata, facilitate lots of useful things that otherwise just aren't possible in TypeScript. It's also the case (though the authors seem unaware of this) that they will never be standardized in the current form that TypeScript has them, because they were based on an earlier version of the design that has since been pretty explicitly rejected. The risk isn't that decorators are never standardized; if that happens then TypeScript will just keep the current design forever and things will be mostly fine. The risk is that they get standardized in an incompatible form and then you have an interesting migration ahead of you. TC39 won't do this lightly, but no one knows exactly what the future holds. So it is a tradeoff to think carefully about, though in the end reasonable people will disagree.
# vs. private is mostly a matter of style/taste, with two exceptions. First, if you have any code on your page that you don't trust not to be doing weird things, strongly consider #, since it provides protection against corruption of internal state. Second, if you have to support older browsers that don't support #, then don't use it; the compiler can downlevel it, but only at significant code-size and performance cost that you don't want to pay (and debugging it in the browser will also be annoying).
Do the authors also disfavor parameter properties? Those also require emit beyond just stripping types, but are super-convenient and useful and don't really conceptually complicate things.
Incidentally, the feature at the top of my own list of "TypeScript features to avoid" (other than namespaces and other soft-deprecated features) is something entirely different: conditional types. Most other advanced type-system features behave reasonably predictably most of the time, but conditional types are very demanding of maintainers' knowledge of fiddly type-system details. I'm not saying it's never worth it (and in particular the built-in utility types are usually fine even though they're conditional under the hood), but whenever possible I try to reach for something else.
That's true, but diagnosing other bugs is an absolute pain in the butt when your enum value at runtime is 0, 1, or 2. You get all of the readability of C with none of the performance :)
Is there really such a thing? Everyone seems to be writing TS with the "fake it until you make it" mantra, never quite reaching the "make it" phase. People still use "interface" and "type" interchangeably without rhyme or reason. Or "import" vs "import type". No one knows what they are doing in TS. Or why. Just look at this entire comment section.
Angular 2 would look very different without it.
Honestly most of these features are really useful, and as someone who never wants to work in raw JavaScript, I wish they were just added to JavaScript instead. Why shouldn’t JavaScript have enums, namespaces, private modifiers which aren’t #, and decorators? JS already gets new features which break backward-compatibility, mine as well add features which fix compatibility with TypeScript.
About the only positive that is qualitatively different is the simplicity of comparing the output to the input. But for someone building a large typescript codebase, and who uses sourcemaps, it's not really a big issue. There are many many languages that compile-to-JS, and I feel that insisting on 'purity' for purity's sake isn't really a good justification. That, TS as a super-set of JS instead of as a isomorphic mapping between constructs is a perfectly viable way to innovate in the language space.
But this doesn't justify removing every codegen feature. Namespaces and enums won't make your code less reasonable, and moreover they're just syntax sugar, they don't change actual JS semantics.
One cannot use Typescript without understanding Javascript, since every single Javascript library is not written in Typescript.
No one should need or worry about what an abstraction compiles to unless they’re specifically working on that abstraction or there’s a language bug.
The problem with Typescript is that too many Typescript developers don't understand Javascript itself, which is an completely different issue. That and the obsession for some to reproduce JEE everywhere including in the browser...
But before that there were countless competing models for creating objects or object factories.
Obviously, JavaScript is an object oriented language, too. You cannot escape that fact if you are determined to make the browser paint anything.
Classes effectively solved the "How?"
To pretend you don't need object orientation in JavaScript is really trying hard to make JavaScript into an entirely different language.
I can't speak for frontend code, but on the backend:
It feels at least somewhat obviously true that unique names are good. Even if you aren't operating in a language which has global imports (which is most nowadays), unique-as-possible names can help disambiguate-at-a-glance something like:
const user: User = await getGoogleSsoUser();
// 100 lines later...
console.log(user.microsoftId); // wait why isn't that field available?
// ok i'll fix this
const googleUser = await getGoogleSsoUser();
// obviously that makes sense; but what about the type?
export function getGoogleSsoUser(): Promise<User> {}
// wait... should that return a Google API user object? or our own user model?
// let me scroll 200 lines up, ok its defined there, open that file...
// or just:
export function getGoogleSsoUser(): Promise<GoogleUser> {}
But this gets hairy really quickly.
// google will provide these types... but lets assume you're writing your own
export type GoogleUserV1 = ...;
export type GoogleAPIV1GetUserResponse = {
user: GoogleUserV1,
}
export type GoogleAPIV1ListUsersResponse = {
users: GoogleUserV1[],
count: number,
}
// ok lets import them
import { GoogleUserV1, GoogleAPIV1GetUserResponse, GoogleAPIV1ListUsersResponse } from "my/service/google";
We can solve the second problem by doing an old-style wildcard import:
import * as google from "my/service/google";
const user: google.GoogleUserV1 = await getGoogleSsoUser();
With namespaces:
export namespace Google {
export namespace User {
export type V1 { ... }
export type GetResponse { ... }
export type ListResponse { ... }
}
}
// now to import it
import { Google } from "my/service/google";
const user: Google.User.V1 = await getGoogleSsoUser();
The argument against presented by the article boils down to: it creates unnecessary fluff in the emitted javascript. That's a reasonable argument; it does. In practice, it's more nuanced. First: I've never seen it cause an issue. So, premature optimization, YMMV, etc. Second: the fluff is erased for types anyway; so it only becomes an issue for functional code defined like this (all of my examples were in types, but its easy to imagine a Google.User.List function). Third, though not a direct counterargument to the article: it's literally how Google organizes the types we've been talking about [1] (though, how they organize the functional code, I'm not sure).
[1] https://github.com/DefinitelyTyped/DefinitelyTyped/blob/mast...
Maybe recommend not to use Typescript altogether then. Their only reasoning for this seems to be that the features "be more likely to break when using build tools other than the official TypeScript compiler".
> What is there left to use in the end? Type annotations?
I've always used TS for the types and nothing more, and been happy with it. Seems to me that most of the JS community has come to adopt this approach over time, and I don't see what's bad about it.
That's what Typescript mostly is, that's where its success comes from. Type annotations for existing JS code. The vast majority of people need to type existing JS code, and compile to JS. A few minority need some specifics from the TS type system. Outside of that, there are other options.