Hacker News Reader

Comment by thefaux | Hacker News Reader

This is incredibly impressive but I also simultaneously find it kind of depressing. In my not so humble opinion, typescript is already way too complicated and getting worse thanks to its velocity. A better approach would be to kill typescript's velocity by identifying a stable subset of the language that provides the vast majority of its benefits and optimize the heck out of a parser for that smaller language. This approach would be both easier and more sustainable since it would cap the language complexity making it easier to maintain and/or write alternative implementations.

View on HN

That’s not my experience. If anything, I think the Typescript experience improves with each release: typings get more precise, the type system becomes more expressive and allows to simplify the type declarations that used to be more complex, and best of all, what worked before still works. And in most cases, you’re good to go with the basics, you just know that if you need to declare a complicated type, Typescript got your back.

I agree that Typescript improves with each release as I and the people I work closely with use it, because we use the KISS approach to typing so we rarely do use new features, but when we do need them they're useful.

But then I find some third party code which seems to use the kitchen sink approach to typing, AKA the "look at how smart we are" approach, and it's a nightmare to understand. A type system is supposed to make code easier to work with, by the time you're spending more time understanding the types than the actual code there's something wrong.

In these cases I wish Typescript was more limited and I would gladly give up a lot of the new stuff to enforce simple types across the ecosystem.

That said, I don't really have an opinion on who is at fault here - coders for writing overly elaborate types, or Typescript for allowing them.

Also agree, with each release I get an "Eureka effect" that now I can solve the type issue I strugled couple months ago trying to create to just make some highly used function safer/easier to use for the developers.

Example the new satisfies and some upcomign "as const" features to generics I'm looking forward to

> That said, I don't really have an opinion on who is at fault here - coders for writing overly elaborate types, or Typescript for allowing them.

Backwards compatibility is to blame. Typescript was designed to support a number of patterns which was already used in JavaScript.

For example events are registered in the DOM like `element.addEventListener("click", (ev) => ...)`. The type of the callback will depend on the string passed as the first argument, so the type system need to support literal strings as type discriminators which is a weird feature not necessary in most other languages. If the API had been designed with static typing in mind from the beginning, it would have been designed differently and wouldn't need such a complex type system.

Weird - using constant string discriminators feel very natural and normal to me in Typescript. What do other languages do without them?

Most model it as an actual enum, if backed by strings. Typescript, by comparison, requires being able to indicate a type just from a string argument

Allowing literal strings and type aliases of unions of strings to represent enums doesn't seem unreasonable. It's the same concept as many other languages with some extra quotes, ex. https://ocaml.org/docs/data-types#a-simple-custom-type

This doesn’t change anything:

  foo(get_some_myenum_value(), …)
  {type:get_another(), …}

These are as unguessable as if myenum was a string.

Hmm. That doesn't feel like much of a difference to me?

It's huge? I'm really confused lol. I write in Dart/Java/C++/ObjC/TS regularly to maintain a cross-platform library and this is a massive difference from every typechecker in any other language, much less the narrower thing of if the idea of reifying random strings into an enum is a novel feature. I get a very strong sense from the thread that people are talking past eachother, somehow.

The event type could just be exposed as a regular property so you could write `element.onclick.add((ev => ...)` so you would get static typing without any need for magic strings.

Magic string are use all over JavaScript for different purposes. For example createElement('P') could just be new PHtmlElement() ...

In other cases magic strings could be replaced with enums.

Changing Javascript is explicitly out of scope for Typescript.

I was curious how other languages did discriminators in a way that makes Typescript's feel alien. Just having different functions doesn't really tackle that.

The pattern I'm most familiar with is using type constructors:

   type Shape = Square Int | Circle Int

and then pattern matching:

   print (Square size) = ..
   print (Circle radius) = ...

In Typescript this would be something like:

   type Shape = { type: 'square', size: number } | { type: 'circle', radius: number }

And string matching for type narrowing:

   function print(shape: Shape) {
     if (shape.type === 'square) {
       ...
     } else if (shape.type === 'square) {
      ...
     }
   }

The TypeScript approach is comparatively weird and verbose but also pretty clever since it doesn't require any change to the core language.

It also have some pitfalls, e.g. you can write:

  print({type: 'square', size: 10});

But you cant write:

  const x = {type: 'square', size: 10};
  print(x); <-- type error

You have to write:

  const x = {type: 'square' as const, size: 10};
  print(x);

Things like this just complicates the type system and type inference.

This example looks like a simple sum type with method overload. Don't think that's complex, that's bread and butter in some functional languages.

Now take mapped types, template literal types, key remapping... Those features aren't necessary to express legacy DOM APIs, this is just for the sake of having a complex typing system. And that's not to add a new feature that unlocks some type magic that wasn't possible before. No, those are just shorthands for things that you could already express in the existing typing system.

It is not just to support the DOM it is also frameworks like JQuery, React, Vue etc.

For example the 'options' parameter is a common pattern where an object with a set of properties are provided to override a some default behavior. So you need to define a Foo type with a set of properties, and then you need to define a type which is like Foo except all properties are optional.

Some frameworks implement their own flavor of inheritance e.g. through mixins. The type of an object with mixins is not just the sum of all properties, you might also have one property overriding a property of a different type in base mixin, so you are adding and removing properties. You need a really powerful type system to be able to represent this.

> A type system is supposed to make code easier to work with, by the time you're spending more time understanding the types than the actual code there's something wrong

This may be true in a lot of cases, but certainly not all.

I’ve spent a ton of time on the types that validate that the input/output schema of my request handler function matches the defined schemas, and that was hell, but now any other of our developers will see delightfully red squiggles when they do something wrong. That’s a force multiplier and absolutely worth the effort.

What's bad about using clever types? My (limited) experience is that if they're done well they just work. I don't know why React-Query's types work the way they do, but I quite like that they do. Developing an intuition for it was a bit hard, but I believe this might rather be a failure of the documentation.

And if they aren’t, good luck debugging it. I remember recently some typing issue in a webpack config where a correct key was marked as a type error in a presence of another construct, despite being documented and having an effect.

Also try exploring npm/telegraf classes (auto-documented) by looking at their type definitions. The whole bot api could have been written as simple repeated definitions, but someone chose the clever way of multi-level type mutations and derivatives.

Typescript will soon need secondary community-maintained type contracts that are human-readable and cross-checked with those in libraries. Something like @humane-types/*.

TypeScript is complicated because JavaScript is complicated. As long it's sticking to the core goal of giving JavaScript static types in a practical way, complexity is unavoidable. I think what you want is a new language.

(I say this not as a dig against TypeScript or the way it's been designed; I just think the parent wants it to be something fundamentally different from what it is)

as someone working on a python type checker I can second this. we get occasional complaints that some feature is too complicated or too liberal, and the answer is usually "it works this way because python works this way, we are trying to support as much valid python as we can even if it's hard to express in terms of static types".

People would benefit more from a stricter subset of JS that has decent performance characteristics and actually sound typing.

I agree, but I can't help but think of that meme about there being N+1 standards. The introduction of a stricter subset of JS will make Javascript more complicated, not less. I hate that, because honestly Javascript and the web would benefit form removing a lot of the cruft.

> I hate that, because honestly Javascript and the web would benefit form removing a lot of the cruft.

This is the primary argument against worrying about N+1 standards. We know it's bad, if we simply do nothing at all, we know it will get worse. We can and should at least try.

As someone who's been part of the team who tried to do exactly this, I don't think it can work. Once you start subsetting things it quickly turns towards being "better" than the existing web, and soon all backwards compatibility is gone.

All those legacy features and existing pages are the back pressure that keeps the evolution of the web stable.

"use stricter"

At this point any other language soundly typed or not is semantically a subset of JS (at most plus some of their weird thing, like Rust ownership and move semantics). You are free to pick one and let JS be JS in all its glory.

Or more precisely, TypeScript is complicated because people insist on doing deranged things with JavaScript and its mess of a type system. TypeScript wouldn't need to contain so much complexity if the underlying JavaScript was doing simple, straightforward things. Blaming TypeScript here is kinda shooting the messenger.

It doesn't try to protect you from the really deranged things. Every TS check comes with an implied "assuming you didn't use a Proxy to make this property accessor mutate state or something"

It does reach admirably far into checking the regular dynamic-language programming patterns like using string variables to index into structures. Which is where a lot of its complexity comes from, but I wouldn't call that stuff "deranged". JS is a dynamic programming language, and people write it like a dynamic programming language, and typescript decided to meet it where it was at, which is probably the only reason it's gotten so much traction in the first place

You may not like this freedom, but I absolutely adore it. I really feel restricted when I'm writing in other languages, even dynamic ones after JS and TS shown me what should be possible.

The whole “Type manipulation” section has nothing to do with this issue, but at the same time is the usual source of complexity in type definitions. Even worse, it serves as a clever challenge for people to make such dynamic interfaces well-typed, instead of making it boring, autogenerated once and then discouraged.

Can't agree. Typescript already has a better type system than a lot of languages in common usage, but it's not good enough and we run into issues all the time because it's not powerful enough. It can probably stop adding features someday, but IMO that day is at least a few years away, when it is actually solving the problem of type safety in web development fully.

In particular, supporting nominal typing, fixing the way index types work, and fixing the story of debugging type failures on giant unions come to mind, but there are countless others. (Don't @ me, my day job is a few versions behind and I can't remember what's in the latest version, but there are plenty of other things if not these.)

Yeah I think the new `satisfies` operator and improvements to type inferences in the latest version likely resolve a lot of your concerns.

TypeScript also supports some really advanced typing I've yet to see in other languages like template literal types (don't @ me, I mostly work with dynamic languages at my current job). I feel like even the TS docs haven't caught up to the full power of TS's full featureset

FYI, TypeScript already supports nominal types, but the ways in which you "spell" `nominal` are a little unintuitive:

1. Use an enum

2. Use an intersection with an enum and literally anything else (except a number)

3. Use a private field (only works with classes)

4. Use a `declare const FOO: unique symbol` keyed object intersected with anything else (works with everything including numbers, lots of boilerplate to declare a new nominal type).

I'm aware of some of those, but I think they're all suboptimal compared to actual nominal types.

In particular iirc you can't use your nominal/branded type as a map key in a type-safe way.

Not sure what you mean:

    enum A {}

    type B = { a: number } & A;

    function newB(i:number) {
      return { a: i } as B;
    }

    let b:B = newB(5);

    let m:Map<B, string> = new Map();

    m.set(b, "test");
    m.set({ a: 2 }, "test"); // errors

What he means is that you didn't _used_ to be able to do this:

    declare const NOMINAL_BRAND: unique symbol;
    enum UserIdType {}
    type UserId = string & {[NOMINAL_BRAND]: UserIdType}
    type UserMap<V> = { [key: UserId]: V };

But at some point in the past few years, this is now supported and things like this work as expected:

    const userId: UserId = "234" as UserId
    const coolUsers: UserMap<boolean> = {}
    coolUsers[userId] = true // works
    coolUsers["isThisOkay"] = false // fails

Interesting, I thought that wasn't possible, but now I feel like I'm just confused and mixing it up with something else that wasn't possible but can't remember well enough.

But anyway, what I want from TS is

    type UserId = unique string; // or something
    const userId = "1234" as UserId

and no further boilerplate or trickery to get it to work. Would certainly be nice.

You can get close to that:

https://github.com/seancroach/ts-opaque

you could use a WeakMap to emulate private fields too

My biggest wish would be proper sum types. The current way of manually creating tagged unions is really awkward.

But that won't be added because there is no native JavaScript equivalent.

I wouldn't rule it out. They seem to be increasingly amenable to ergonomic changes that are less coupled to what JS would do in my impression.

I think it can be safely ruled out. TypeScript tenet which they consistently uphold is that types can't influence behavior of the running code.

So to differentiate behavior depending of which part of sum type you got you need some value in the "real world" like a tag that can enable you to do that. Because all the type information is gone at runtime.

Strongest violation of this rule I know of are enums that generate their own JS code, but they are their separate thing. Something like sum types would need to be present everywhere.

Honestly I kind of like it this way. I'm trying out Rust right now and I'm very often surprised how what I do in one spot depends on huge context of all the generic types that can create wildly different behavior (mostly huge variety compile type error messages in surprisingly varied and distant spots) depending on what types they infer.

It's also worse in a lot of ways, not due to problems with expressiveness but more soundness and specification. It's pretty easy to make TS keel over during typechecking.

The other issue with the typesystem is the (soon to be obviated) need to compile to decent javascript and interact with it. That made sense before WASM existed and it will make a lot less sense once the component model is stabilized.

Who is “we” in that phrase? It seems the people I know that use it (from the outside, I don’t do ux) seem content with the current state

Ah, 'we' as in me and the people I work with in my day job.

The thing about TypeScript (or any language) is that one needs to recognize that many features aren’t for us normals. They’re for library developers doing all kinds of wild type stuff. I remember my eyes glazing over at the template literal typings and such. But someone on the discord was like, “if it seems overwhelming, you’re probably not the audience. But you’ll end up using it by using a library that leverages it.”

Always check ts-essentials for the ideal abstractions built with the wild new features.

My favorite language in this category is MLscript. The best part is that type-checking it is decidable! https://github.com/hkust-taco/mlscript

Have you heard of ReScript [1]?

[1] https://rescript-lang.org/

> typescript is already way too complicated and getting worse thanks to its velocity

Is it safe to say a non-zero portion of "the community" is headed the direction of:

write it in _____ + compile it to WASM + glue DOM stuff to it with some sort of JS bridge?

This sounds interesting to me, especially as somebody who was exactly zero interest in learning anything other than regular JS (i.e., no TypeScript, CoffeeScript, or any other JS-extension languages). Is this some kind of pattern, and do you know of any examples that show this?

I see a comment like this every time someone mentions WASM and have to eye-roll a little. Yes transpile-to-WASM techniques exist, but as someone like yourself with a self-professed inability to learn TypeScript, I don't think you are going to enjoy living on the edge of webdev with WASM either... The tooling is nowhere near as mature for one, which is always problematic when starting from a position of little knowledge.

Just search github.com and you will find countless example repos for many languages, but understanding typescript first is probably a more productive use of most people's time.

If you work in web-tech, I consider avoiding JS and TS to be almost negligent to some extent in 2022.

I find this comment validating. Most of the languages I've used start to click and feel good after a while - but it feels like this just won't happen for me with typescript. I'm clearly missing some fundamentals and I'm not even sure what it is I need to go study.

What doesn't click? I've found it pretty intuitive, though I've explicitly avoided making complicated types.

The type erasure. You get this nicely expressive type system that can encode all sorts of useful metadata, and then you have to recreate it all again by hand in 'Javascript' to access it at runtime.

Say I have `type Foo = 'bar' | 'baz'` and want to validate that an input string is within the set of Foo. Why can't I just enumerate the type to determine the valid values at runtime?

For me it's a great feature because it means that the code has purely javascript semantics not influenced by andy generic type magic that happens on compile time.

Occasionally I bump in the same things as you when I'd like to have some JS code generated on the basis of TS type information. I think there could be some preprocessing tools that could generate JS validators on the basis of TS code.

Now, trying Rust I strongly appreciate this separation. In Rust what your code DOES might depend on what you are going to do in the future with the result it returns. It's really shocking for me and makes finding errors really hard when the spot of the error messages jumps wildly across large chunk of your code as I change it.

I really prefer TS philosophy of "types are for you and your text editor and the actual code is for runtime".

Can you explain why you feel that way? I only know JS and TS, and I love TS. With both languages, I understand I'm missing out on a lot, but I kind of assumed that was normal with my level of study (that is, reading in depth to fix bugs or make new features, and generally no further).

how is it getting worse, exactly? I know it has features (all of which are optional) that can auto-generate code, but it _doesn't_ require being used. You can, and largely most do, use it just for the syntax for typing.

Is there something inherent with TypeScript that is causing issues that you can point to?

The funny thing is that TypeScript still has some way to go to be capable of fully expressing JS semantics. This shows that even most complex statically typed languages are way simpler than some dynamic languages.

At this point, TS is becoming C# V2

Is it honestly more complicated than, say, a browser?

Reply on news.ycombinator.com