> All the necessary static type analysis will be happening automatically in your brain.

Tell me you’ve never developed large projects on a team without telling me…

Tell me large projects did not exist before TypeScript.

Large projects have overwhelmingly been written in statically typed languages throughout the entire history of our industry. Large projects in Javascript is a comparatively recent development, in that context the rise of Typescript is completely understandable.

Sure but why does TypeScript have to be even less graceful than C# which is arguable the Gold Standard of static typing?

It's simply a hurdle rather than a blessing all too often.

No issues with C# however.

I use C# as comparison as it comes from the same house and was arguable used as inspiration for TS.

> why does (language explicitly designed to compile down to JS with 0 adaptation layer) have to be less graceful than (thing made by the same people but with no such constraints)?

Hm.

Genuinely trying to understand.

Argued from first principles:

Since TS is a superset of JS,

we can assert that the both constitute opposite ends on the spectrum of static typing.

Thus, surely there are infinitely many levels of possible gracefulness in-between?

IOW: If JS can live with no constraints, then why can't TS live with with slightly more graceful ones than the current?

That’s called adjusting strictness flags.

Imagine doing something similar in C#, i.e. copying all properties from one arbitrary object to another. This would require the use of reflection and would not be typesafe at all, since reflection in C# is not typesafe.

> All the necessary static type analysis will be happening automatically in your brain.

That's exactly the point: nobody wants to do this in their head, and humans are far worse and less consistent about these kinds of computations than machines. Plus, as the size of a codebase grows, the chance that you have it all in your head approaches 0%.

Also, I'm not sure what "linter wars" have to do with TS?

Static type analyzer wars really.

Sure I say go for it for those super galactic world changing giga projects but most simply aren't that.

A project with well organized, clean code without a lot of junk will be a small, easily overseeable project, for a long long while.

Biggest advantage I've seen from using it, is the ability to quickly get into old code. Sure, well I'm writing it. I have a mental understanding of all the different types, but I don't two years down the line.

Also, when multiple people are working on the same code, it's nice that they all are forced to spell things the same way...

I recently created a new NextJS project.

For my little site I needed an input element with type=file.

So I was getting started, with TypeScript and all, like the swaggest of web developers.

Came the moment for the actual file input:

TypeScript REFUSED to accept the input element's type as "HTMLInputElement" when that is literally its type.

After TypeScript eating up about 1 hour or so of my time, I decided to get rid of that piece of sh*t for squiggly underlining all my code in Red simply because it's too retarded to understand it.

Any of the TypeScript lovers care to explain?

Needless to say, I ultimately went about doing what I wanted in 5 minutes in VanillaJS and was happy ever after.

Call me again when TypeScript does its job correctly.

So you formed your strong opinion, based on one hour of trying it. Gotcha.

As to your problem: Use ˋ... as HTMLInputElementˋ if Typescript wasn't able to narrow your type sufficiently, or you believe that the value of typing this case isn't worth the effort. This should be somewhat rare.

Use ˋ... as unknown as HTMLInputElementˋ, if your idea of the variable is completely different from Typescript. But at that point you likely _have_ made a mistake somewhere.

Use ˋ...: anyˋ if you want to completely turn off checking. In most projects, this has to be explicitly specified for each parameter and declaration.

It gets more verbose, the more unsafe your code is.

It's impossible to try to debug your problem with so little to go on. Maybe the type was unioned with something incompatible. At some points, you need to resort to runtime type checking: `if (x instanceof HTMLInputElement) { // TS will know it's a HTMLInputElement at this point } `

Enabling Typescript on an existing, untyped project is going to be rough to start. You'll need to gradually increase the strictness levels and perhaps work on typing one module at a time. With an entirely new project, start with maximum strictness, and things will come together much easier. You might need to learn to do things in new ways to make it easier to work with TS, but that doesn't mean it's wrong.

Certainly, 1 hour to attempt to use any new technology is way too little time. I'd say a minimum of a week of honest effort with a new toy project is warranted before deciding whether it's not for you.

Just type (… as HTMLInputElement) and be done with it. It’s really not that hard.

Duh, that's what I did. And every other variant one can possibly think of. To no avail.

That's what cost me the hour or two.

This works like a charm in a strictly typed language like C#, but TypeScript just hasn't got it down correctly yet.

Show a sample of the issue if you can.

The code in question:

    (e: Event) => {
        let t: EventTarget | null = e.target;
        // here "t as HTMLInputElement" did not work
        if (t instanceof HTMLInputElement && t.files && t.files[0]) {
            const file = t.files[0];
            if (file) {
                (myImageElem! as HTMLImageElement).src = URL.createObjectURL(file);
            }
        }
    }

TS wouldn't accept it. My guess is it's not cluttered enough.

My final vanilla version OTOH:

    (e) => {
        const t = e.target;
        if (t.files) {
            const file = t.files[0];
            myImageElem.src = URL.createObjectURL(file);
        }
    }

How is the latter not a million times more elegant? Why do I need to clutter everything with types that I won't even think twice about?

That second version is literally 100% verified and valid Typescript.

`e` is inferred from `HTMLProps<HTMLInputElement>['onChange']`

`t` is inferred from `e`

`files` is inferred from `t`

No halfway experienced TS developer would write any of these annotations.

If you got the myImageElem from a ref, you may need to add a !, because yes, it's not technically guaranteed that the ref is set by the time the callback is called.

Well I haven't ever used next.js in particular, but if I go open a .tsx file and add <input type="file" onChange={[final vanilla version code]} />, it works fine.

t gets inferred as `EventTarget & HTMLInputElement`

The only error is that "myImageElem" isn't defined by the snippet, which is to be expected.

If I insert your first snippet, it complains that (e:Event) isn't the right type, but (e) or (e:any) makes the whole thing happy (except "myImageElem").

If I remove the imprecise "Event" typing on e, then your first snippet can be simplified to:

  let t = e.target;
  if (t.files && t.files[0]) {

If I keep (e: Event), then the code with "instanceof" works, as does:

  let t = e.target as HTMLInputElement;
  if (t.files && t.files[0]) {

> The only error is that "myImageElem" isn't defined by the snippet, which is to be expected.

It's the ID of a DOM element. No need to define it (for me). But anyway still good I will try your code, thanks.

In that case the only thing you need to make your vanilla code work as typescript is to put the following somewhere:

  declare var myImageElem: HTMLImageElement;

`(e: Event) =>` means you accept any event whatsoever.

That is probably true, however as I said it should (IMO) still work if I then cast its target to HTMLInputElement.

You’ll know all the types of your own code by heart, maybe.

But I doubt you’ll be able to keep up with contributions from three other devs to a massive codebase.

Typescript makes it easier to understand what’s going on at a glance (or a hover, or a ctrl+click) - I’m fine with loosey goosey JavaScript for a solo project, or even a two person collaboration, but for a big team effort? I’m gonna need those strict typings to help keep everyone’s contributions consistent.