Hacker News Reader

Comment by RyanCavanaugh | Hacker News Reader

It's important to not conflate static typing with OOP. If you think about static typing only in terms of OOP, of course you're not going to like it - classes are not the right abstraction for many problems.

The TypeScript compiler (which is written in TS) itself uses zero classes. There's no need to use classes to get static typing. If you're writing TS the "right way", you write the JavaScript you would have written anyway, and add type annotations to create contracts and descriptions of behavior.

View on HN

TypeScript has an okay type system, but it has a very "C#"feel to it. I don't mean from a technical point of view, but the way its advertised, the way its documented, the language used in the terminology, and obviously, the company behind it.

So of course, when you give TypeScript to someone who doesn't have a strong "normal" JavaScript background, they'll jump straight in what they are comfortable with and go full enterprise Java on it.

Note that even vanilla ES6 had this problem, just to a lesser extent. All languages have shit like that... JavaScript itself does (we're just used to "the good parts" after so many years, but it took a long time.

The fact TypeScript provides some of those construct doesnt mean we need to use it, but it means less experienced teams will.

I'll never join a company that uses TypeScript unless I get to see the code base first.

> TypeScript has an okay type system, but it has a very "C#"feel to it. I don't mean from a technical point of view, but the way its advertised, the way its documented, the language used in the terminology, and obviously, the company behind it.

It has some very un-C# like features: https://www.typescriptlang.org/docs/handbook/advanced-types....

I am always surprised when people in JS-land say they don't like types when every major framework then goes on to recreate 80% of the framework of types rather than work in a truly prototype-oriented world.

> I'll never join a company that uses TypeScript unless I get to see the code base first.

Given the way those sorts of things work, you're basically saying you don't want to work with typescript because someone might use a feature you feel uncomfortable with. That's good to get out of the way up front, but it also projects the image you have a huge chip on your shoulder and assume everyone else is an idiot who doesn't understand things as well as you do.

Wouldn't you like to work at a place where you discover something new? I am sick to death of being the subject matter expert, myself.

I specifically said that I didn't mean from a technical point of view. I know full well about typescript's features :) I generally try to avoid talking about things I haven't tried extensively.

And for your second point, I love to learn something new! But that is specifically something I've had to deal with far too many times already (not just with TypeScript), so it wouldn't be new. And it is quite common these days for companies to show you their code when they get near offer time, or to discuss their architecture and coding philosophy, so I very rarely have surprises on that front anymore. Doesn't mean I don't learn new things. I don't avoid things that haven't burnt me yet. Heck, even if they did, it might be because I didn't do it right. But there's only so many times I can get burnt before I start avoiding certain things :)

> I generally try to avoid talking about things I haven't tried extensively.

I don't mean to press this point too hard, but you feel comfortable offering a dissuasive opinion on something but not "talking about it"? I don't know how to interpret that.

> But that is specifically something I've had to deal with far too many times already (not just with TypeScript), so it wouldn't be new.

I don't know what you mean by this either, I'm sorry.

> And it is quite common these days for companies to show you their code when they get near offer time, or to discuss their architecture and coding philosophy, so I very rarely have surprises on that front anymore.

I certainly think the second half of this is true. I think it's quite rare for companies to actually share real production code in any significant volume, unless of course it's already in the open.

> But there's only so many times I can get burnt before I start avoiding certain things :)

Again... what do you mean? Are you implying that Javascript has burnt you? Or Typescript? Or you won't use technology funded by Microsoft?

I'm sorry, I read your post several times trying to understand your intent, but I ended up with more questions than I started with. That's probably on me.

> I'll never join a company that uses TypeScript unless I get to see the code base first.

That seems reasonable. But wouldn't the same thing apply to Javascript? Terrible Javascript code bases are very common.

Generally the terrible JavaScript is stuff you don't have to argue until you're blue in the face to avoid. A lot of people have bad JS code base, but they know they are bad and are trying to do better. That's fine by me.

For this particular stuff, if a team is really into the whole OOP/classes things, it's not like a small feature like arrow functions vs not, or semi-colon vs not... it will dictate the entire architecture of the entire code base, and it's easy to detect, so why not?

Reply on news.ycombinator.com