[MrJohz]

The only new runtime feature that Typescript brings to Javascript is enums.* Everything else is just types. Interfaces, for example, are just a way of defining a shape that data will fit to. They are (almost) equivalent to the `type MyType = { key1: string /* etc */ }` construct, and behave more like an ML record type than a Java interface.

Also, I don't know what exactly you're describing, but objects as optional named parameters are a common technique in Javascript and therefore very well sorted in Typescript. I'm on my phone so this might not work brilliantly, but something like this:

    // This could also be an interface... ;)
    type Params = {
        // These keys are optional
        // (Note the question mark)
        height?: number | string
        width?: number | string
    }
    
    class Rectangle {
        constructor({height, width}: Params = {}) {
            console.log(height, width);
        }
    }

I've not checked that, but it should type check fine. We need to tell Typescript that the param keys can be optional, I used the question mark here, but if you've already got a type, you can use the Partial<T> type to cover it to having all optional keys. We also need to see a default value if the object isn't passed, but that's true in Javascript as well (otherwise we'd get a runtime exception that you can't destructure undefined).

I can definitely empathise with the idea that some Typescript developers just use it as an opportunity to write Javascript-flavoured Java, but this is mostly a stylistic choice (and completely possible in raw Javascript too). But Typescript is very explicitly designed you match the usage patterns of Javascript directly - i.e. if your Javascript code runs (and makes sense), you should be able to write an identical version in Typescript and have it be accepted by the type checker. Obviously that's never going to be entirely the case, but I really find I have many issues porting idiomatic Javascript too Typescript - and where I do, it's usually because the Javascript was wrong in the first place.

* That's not actually entirely true, I forgot about field declarations in constructors, but I don't think I've ever seen that used in the wild outside of very old Angular codebases.

[eyelidlessness]

I like enum and use field declarations as much as possible. But I use classes as value types so my goal is to make them as concise as an equivalent function if possible. The fact that they’re classes is just an implementation detail primarily for performance purposes.

There are a few others, mostly discouraged these days (namespace and module runtime keywords come to mind). Mostly they’ve treated these as legacy mistakes (good!), but they introduced a new one recently that baffles me given that posture: `accessor` as a shorthand for getter/setter pairs, with no clear authoring benefit for working with the underlying private value.

[MrJohz]

In that case, why not just create an object? With a constructor function, that could look something like

    (name: string, age: number) => ({ name, age: age * 2 })

Or even just without the constructor, if the data is so simple:

    { name: "Bill", age: 62 }

I'd have thought that would be the quickest option, because then you're not messing around with prototypes at all.

Also, what do you mean by the accessor shorthand? I don't know what you mean off the top of my head, and searching for it has just brought me back to this post!

[eyelidlessness]

Using a class has some JIT optimization benefits if you always construct a value of the same shape.

Accessors: https://devblogs.microsoft.com/typescript/announcing-typescr...

[MrJohz]

That's true of objects too, as long as they have the same shape (which Typescript naturally helps with!). As long as the optimising compiler can see that your objects all have the same shape, and that you're always using the same properties, you're golden.

I hadn't noticed the accessors thing before, but it looks like that's an ECMAScript/TC39 thing, I guess to support the decorator implementation. Thanks for the link!