Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

How will TypeScript instead of plain JS help the future me? Unless of-course you meant that as a joke (going by the wink).


Type safe code improves code readability, and the future you will most likely read the code you are writing today.


If you were more comfortable/most familiar with strongly typed languages, then yes. But don't assume everyone has your tastes. Java for example is a very strongly typed language, and I find the verbosity makes it harder to parse.

Good, future proof code can be written in any language. There's lots of still functioning, well maintained js written 10yrs back out there.


"I didn't have to write a test to know that I am passing a data structure correctly across every module of my application" is not a "taste" thing and comparing TypeScript to nominative typing isn't a reasonable and fair tactic.

We have legacy JavaScript dependencies and most of them worry me. I don't stay up at night worrying about the domain and range of TypeScript ones even if their testing is weak. There's a reason for that.cs TypeScript is loose where it should be loose and yet strongly encourages flexible but very clear typing that provides significant resistance to broken contracts and misunderstood semantics. I won't hire a web or Node developer who has a problem with it today because understanding the value of gradual and structural typing is, I strongly think, evidence of baseline competence.

"I write worse code, slower" is defensiveness masked as "a taste thing." We've improved the state of the art and it's better here.


If you write JavaScript with a c# frame of mind, of-course you'll find it akward and hard to test. TypeScript is basically JavaScript written in a c# frame of mind, and there is nothing wrong with that. If it helps some people be more productive, then more power to them. but don't fool yourself that TypeScript is the best way to do JavaScript. If you're finding writing maintainable apps in plain JavaScript hard then you are simply doing it wrong. You can learn how to do it right (hint: its a functional, not a class based language) and add one more tool to your box, or you could stick with Typescript and your comfort zone.

I have worked with TypeScript, and I enjoyed it. It reminded me of ActionScript 3, a language I really enjoyed that's more or less dead now. And I also enjoy plain JS, and its just more powerful and expressive.

> I won't hire a web or Node developer who has a problem with it today because understanding the value of gradual and structural typing is, I strongly think, evidence of baseline competence.

If you think the benefits of "gradual and structural typing" cannot be achieved in JavaScript, you clearly don't understand the language. And that's ok. It is also ok hire people you are comfortable with, rather than those who challenge and disrupt your way. And I wouldnt want to work somewhere where the devs are too rigid or tribal about tools. Am more interested in what I'm building, rather than the tools used.


I don't have a good way to describe this post as anything but not-even-wrong. "Hint, it's a functional language"--types are orthogonal to whatever functional-versus-OO dichotomy you've invented in your head. Gradual and structural typing are components of type systems of either static or inferential basis and JavaScript is neither--so, definitionally, you can't achieve them in JavaScript. And given that TypeScript is a strict superset of JavaScript, it's absolutely bonkers to claim that JavaScript is "more powerful and expressive". Should one need to go outside those gradual type strictures, `any` is right there.

I knew JavaScript cold well before I was using TypeScript and I've shipped both mobile and web applications using JavaScript, as well as writing a solid amount of high-performance backend systems. And I ended up writing an eye-gouging number of tests that go away with TypeScript. It is literally, not figuratively, a way to dismiss entire classes of bugs. I may not understand JavaScript, but I'm not the one making factually inaccurate assertions about stuff up in here and that makes me really wonder how solid your conclusions can possibly be.

But as a gentle observation: people don't usually go on about "tribal" developers when the facts are on their side.


Your problem is the emotional denial that there is an engineering trade-off TypeScript makes by adding strict typing to JS. That trade-off is less flexibility and expression, and the gain is more fool-proof code, thats more familiar and comfortable to those more familiar with languages based on classes and strong typing.

> Gradual and structural typing are components of type systems of either static or inferential basis and JavaScript is neither

Whoa! That's a lot of words to basically say "JavaScript does not have static or inferential/derivable types". Kind of like the way type annotations create all that syntax noise. And I was talking about achieving the BENEFITS of "gradual and structural typing". It is done for the the benefits, not for its own sake. Do you even know the benefits? In proper JS, the same is easily achieved by duck-typing, and run-time checking whenever necessary.

> And given that TypeScript is a strict superset of JavaScript, it's absolutely bonkers to claim that JavaScript is "more powerful and expressive"

I touched on the a bit when talking on trade-offs. A superset does not mean super like superman. it means an added layer of abstraction. You are moving further away from the metal, and leaving some decisions to the TypeScript compiler. That means giving away power, and flexibility to the compiler. A good engineer understands, and is not in denial about the trade-offs they are making.

> But as a gentle observation: people don't usually go on about "tribal" developers when the facts are on their side.

What really happens is that people outgrow their tribal instincts once they realize that this are all just tools that come and go, it is the underlying ideas that matter. JS absorbed all the best ideas from jQuery, and jQuery went. It has integrated all the best ideas from CoffeScript (js with a python frame of mind), and coffee-script is no longer the rage it was a few years back. Same is happening with TS, which is why my money is still on JS. The fact is, js will outlive ts.


Java is verbose because it is Java, not because it is statically typed. Let's look at some more modern and ergonomic language instead, like Typescript which is much more relevant to the OP.

The typing there might add a few extra characters to your function definitions but you gain them back in terms of less need for documenting the argument types in comments. You hardly ever see typing inside of functions in Typescript so it hardly adds any verbosity.


Java was used as an example of strongly typed taken to the extreme. Something YOU can relate to, as a TypeScript user. In terms of verbosity, the difference between Java and TypeScript is like the difference between TypeScript and JavaScript.


I do appreciate the comparison and have suffered enough Java in my life to fully understand it. But i have to tell you again, Java is not verbose because it has "taken strong typing to the extreme" (correlation vs causation), it's just a badly designed language. From the same familiy of languages look at C# and Kotlin for example, they are both much stronger than java (minus checked exceptions) but at the same time very less verbose. There are many other examples of this, C++21 is stronger and less verbose than C++98. Rust can also many times be less verbose than C++ or C and at the same time stronger.

In many cases typescript can also reduce verbosity because of more modern features and transpiling. For example early versions had foreach long before it was in ES and before Babel was as widespread as today. In fact you don't even need to add type annotations at all to run typescript, you can let it try its best on plain javascript, in those places where it's not obvious from context, just add the extra :string.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: