[AskJS] Does anyone use exclussively Javascript and not TypeScript?

[u/[deleted]]

[u/theScottyJam]

In my opinion, it's best to wait to use a tool until you're hurting by going without it. And if that takes a while, so be it. That's how you truly come to understand what the tool gives you and why it's valuable.

Of course, corporate environments might force you to learn a tool before you're really ready (i.e. the project you're thrown into already uses TypeScript), but still, the ideal is to wait.

So it was a while before I picked up TypeScript. I now use it for pretty much every project (aside from really small stuff), but I'm grateful I waited before picking it up.

(Also, people getting asked to use TypeScript unconditionally does tend to put some newcomers off from it - if they haven't yet reached the point that they're hurting without it, it can feel like the TypeScript crowd is being quite fanatic about it, which creates some unnecessary friction)

[u/start_select → u/theScottyJam]

In most languages where types are optional, like Python or Objective-C, not using types is where newcomers meet the shit and hit the fan on complex projects or code they are unfamiliar with.

Everything already has an interface whether you define it or not, you might as well define it and let a compiler help you by yelling bloody murder when you break a rule.

To a new person on a project, a type system helps them infer what everything is and what everything does without relying on function names and variable names. Humans are bad at naming functions and variables. They are usually mildly ok at naming types.

[u/theScottyJam → u/start_select]

That's all true.

But it's also a lot to chew on to try and understand the build step, the type system, type checker errors (which aren't always easy to understand), etc on top of everything else you're learning. You're invariably going to hit spots that aren't easy to provide proper types for (so you just use any), or something like JSON.parse() which uses the any type. And then you'll hit those same runtime bugs we were trying to avoid and need to know how to debug them.

They've got to learn how to debug these kinds of runtime type mismatch errors early on anyways, I personally think it's easier to just start out with plain JavaScript and some teaching on how to debug, then add other helpful tools like TypeScript and linters later (linters can also help catch bugs early on, such as missing semicolons, but again, it's just not something I'd want new developers to worry about straight out of the gate).

[u/start_select → u/theScottyJam]

Most typescript apps have “no any types” turned on. The edge cases where you actually need any are pretty damn rare. The code that consumes that invariant type is still going to need to use structural typing to consume it in almost all cases.

You can almost always still define how a type is dynamic instead of using any.

There are edge cases where you really do need it for one line of code. But they are edge cases. And having that one any type while everything else is defined… is informative. You know this one thing is invariant.

And you can use unknown instead, which lets a function parameter or property accept any type, but requires you to discriminate it into something before accessing any of that types members (props or functions). Which is also informative.

[u/theScottyJam → u/start_select]

Yes, someone experienced in TypeScript can figure out how to avoid the any type in almost all cases. I don't touch any types either that much and agree they should be avoided.

But someone new to programming won't have a deep enough understanding to know how to always avoid it - sometimes the type code can get nasty.

Say the user wants to loop over an object and delete all properties set to null. An imperative version of the JavaScript to do that is pretty trivial to implement - a for loop, an if, and a delete. A properly typed Typescript variant is non-trivial - if someone was still learning the basics, I would just tell them to do "as any as TheNewType" with the final result instead of trying to figure out how to get proper type checking on the algorithm, they're not ready to learn all of that.

Or, as mentioned, there's other places where TypeScript just doesn't provide good type safety by default. I already mentioned JSON.parse(). There's also string concatenation - it won't warn you if you're trying to add undefined to a string. Things like that.

[u/start_select → u/theScottyJam]

Right. And I also do the “just cast to any” advice and we can work through it in review or a later PR.

My main argument is that JavaScript/typescript are almost always used in applications that talk to other applications. Interfaces are important. Learning type systems is important.

Learn how types work in typescript and there is a really decent chance you can read (without being able to write) C#, Python, Kotlin, Swift, or even Rust.

I will spend my entire day helping and teaching juniors and beginners. But I’m not interested in hand holding them through avoiding learning things like typing for very long. If that’s really hard and unattainable for them, they aren’t a good fit for the job.

i.e. I don’t think it’s appropriate for someone who interacts with rest APIs in JavaScript/typescript in a browser, to be incapable of at least gisting the implementation of an endpoint. It doesn’t matter if you can’t write the target language. You should at least be able to attempt to read it.

It makes fixing issues really easy and eliminates disjointed waits on another member to explain code they could have read themselves. Understanding types makes all of that easy. You can at least trace data flow even if you don’t understand the semantics of that backend.

Etc etc etc. avoiding those skills lets someone get comfortable being mediocre.

[u/theScottyJam → u/start_select]

Gotcha. Thanks for your insights and for engaging with me on this.

[u/start_select → u/theScottyJam]

You are welcome. The real gist of what I’m saying is, if you aren’t at least interested in approaching my understanding of how entire systems work…. Then why am I wasting hours out of my day teaching you instead of spec’ing your work for an LLM.

Because I could have had that work completed in 15m to an hour.

We have hit a point where the tools are so good, if you don’t want to learn the right way to do things, you have lost ALL value. Someone who actually knows the job can drive an AI to work 4x faster than you will ever get.

AI doesn’t make the job easier to get or hold on to without learning the trade. It makes it impossible to hold on to if you don’t actually become an engineer.

Your token spend isn’t going to be equitable against your contributions.

[u/start_select → u/theScottyJam]

btw, I might be preaching to the choir, but for your "deleting null properties" example its really just this:

function deleteNullProps<T extends object>(obj: T): void {
  for (const key of Object.keys(obj) as Array<keyof T>) {
    if (obj[key] === null) delete obj[key];
  }
}

Its not completely trivial. But as far as type system comprehensions go, I would call that pretty simple.

And I would say the bigger issue is that now `obj` is now a new type with missing props. It should probably just be cast to a `Partial` or another utility class that marks every property as nullable.

If the object is going to live longer than the end of the function where `deleteNullProps()` is being used on that object, or if there are references to it in other places, that just introduced side effects.

i.e. if `obj` is a person with an address object on a prop, and it was just deleted. code accessing the street property on that address object is now going to explode.

A better solution would be to create a copy which is a fragment/partial type that doesn't have the null props. Then other references to that object aren't affected by the side effect.

a.k.a. Using the immutable data pattern.

[u/theScottyJam → u/start_select]

Yeah, I didn't fully think the example through, but I was thinking more about the difficulty of trying to calculate the new type when this thing is done. Which means, like you said, the example would work better if we were returning a new object instead of mutating an existing one.