Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ask HN: Is TypeScript worth it?

news.ycombinator.com

Post reply on HN
Print view View original

371–380 of 469 posts

Re: Ask HN: Is TypeScript worth it?

#371

Post by osigurdson »

beaker52 wrote: post #250
benfrl01 wrote: post #209

Earlier quoted context omitted.

> TS saves me time every day. Hmm, not my experience. I do TS for years now and still today I'm spending more time on fighting/pleasing TS compared to the actual code. JS with all its node_modules dependencies is a complete nightmare to get the typing right. I regularly have to change good solid code to please TS, but at the same time TS often doesn't complain when the typing is obviously wrong. I once started with A…

I’m noticing a pattern in your arguments. You need to understand that I (and I suspect many others) don’t have the same experience as you. I don’t _fight/battle with_ the type system, I work with the type system - and I enjoy it. It saves me countless hours. I don’t actually use javascript without TypeScript anymore - it’s simply not worth _not_ using it - for me. You ask whether it’s worth using it - and you keep te…

It sounds you are essentially recommending therapy for those who don't like TS.

Re: Ask HN: Is TypeScript worth it?

#372

Post by eitland »

tomxor wrote: post #295
CSMastermind wrote: post #116

I'm old enough to have worked on two different large enterprise applications which predated TypeScript and it was a nightmare. Personally I've found that JavaScript lends better to a functional style of coding but there are no protections in the language to enforce this and both codebases I saw had a weird mismatched set of object oriented and functional style principals. Defined classes, prototypical inheritance, mo…

> especially when you're 20 function calls down a stack trying to understand what's happening. Yeah I hate code like that too, but it's not clear to me how type checking would help.

Because you don't have to use the debugger or mentally map the code all the time to see the (actual) shape of the objects at any point in the call chain?

Re: Ask HN: Is TypeScript worth it?

#373

Post by osigurdson »

benfrl01 wrote: post #209
ericmcer wrote: post #192

Earlier quoted context omitted.

Thanks for your work, TS saves me time every day. I was saying something similar to the op 3-4 years ago but really cannot picture working without some kind of type safety in JS now.

> TS saves me time every day. Hmm, not my experience. I do TS for years now and still today I'm spending more time on fighting/pleasing TS compared to the actual code. JS with all its node_modules dependencies is a complete nightmare to get the typing right. I regularly have to change good solid code to please TS, but at the same time TS often doesn't complain when the typing is obviously wrong. I once started with A…

Assembly? No types there, just registers. The only distinction is floating point and non-floating point registers.

Re: Ask HN: Is TypeScript worth it?

#374

Post by eitland »

bborud wrote: post #355

What is a bit sad is that JS and TS both get in the way of the development of something more sensible to replace it. I had hoped that WASM would make application development for the browser a bit more sane. I had hoped that someone would create an application framework for a sane, strongly typed, mainstream, compiled language that has decent tooling. With compiler and dynamic loading as part of the runtime. JS is a g…

I haven't tested it but I know Kotlin.js exist and you can use it with React. It wouldn't surprise me if it is good but at the moment TS is good enough and "everyone" knows it.

Re: Ask HN: Is TypeScript worth it?

#375

Post by vagrantJin »

To make an anology.

Js is a shovel. Simple. Does its thing. Digs dirt in our quest for gold.

TS is like adding a two stroke petrol engine so the shovel vibrates up and down. Loud, jerky, difficult to handle.

A sane person looking in would wonder why not just buy a jackhammer(java/c#)? Or use an excavator(Rust/C++)?

Why is it neccesary to attach an engine to a shovel?

Re: Ask HN: Is TypeScript worth it?

#376

Post by abalashov »

hbrn wrote: post #164
confidantlake wrote: post #92

100% worth it to me. I love typescript. Working on large enterprise applications where one function calls other function and it goes 10+ layers deep I don't know how I would work without typescript. Just being able to see this function takes argument of type FOO and returns type BAR[] is incredibly valuable.

One thing I often tell people is that if a particular technology makes it easier to work with code that's 10 layers deep, it will also make it more likely that people will write code 10 layers deep where they would previously do 5 layers. Somewhat similar to https://en.wikipedia.org/wiki/Jevons_paradox

Yes! This is one reason I really like Go. I'm not exuberant about it the way some folks are, but amidst ambivalence about some aspects of it, this is one thing it really gets right. While it's hardly impossible, it's not that easy to write completely impenetrable code Go.

Re: Ask HN: Is TypeScript worth it?

#377

Post by c0n5pir4cy »

sngz wrote: post #234
larsrc wrote: post #214

Is it worth it compared to what? Plain JS? Transpilation from a different language? Rust? Growing apples? I have used plain JS, GWT, and TypeScript. TS is an incredible improvement over the two others. The TS type system is excellent, very expressive and helpful. An important advantage you get from static typing is that your IDE has more information to work with and so becomes more powerful. If you code in a text edi…

try out dart, its much better than TS

Not that TypeScript doesn't have it's pain points but having tried Dart on an Android application recently, there are so many things I dislike about the language and it's ecosystem compared to modern TS/JS. I feel like it would have been a lot better than JS when it came out but now it's painful to use in comparison.

Definitely my preferred route for building mobile apps now though.

Re: Ask HN: Is TypeScript worth it?

#378

Post by abalashov »

nc wrote: post #333

One pitfall i've found with TypeScript is getting too clever with type definitions. Too much abstraction can end up eating up a lot of time (especially with a large team). This happens because as you say, the error messages are verbose and hard to follow. Once we started keeping our type definitions small and simple we've found it's hugely beneficial.

Very much right. If the TypeScript team created basic typing without endless permutations of infinitely clever ways to create composable type hierarchies, I'd like it more.

The problem with the endless permutations of infinitely clever ways is that people actually use them. You end up with shims and meta-shims and meta-meta-shims and adapters to turn this unwieldy behemoth into that one in just the right place. Very soon, you get something like Kubernetes, in the sense that the entire structure is imperiled by the weight of its own complexity.

Re: Ask HN: Is TypeScript worth it?

#379

Post by osigurdson »

dfreire wrote: post #337
eitland wrote: post #305

Short answer: It is worth it if you want me on the team. I refuse to work with anyone who throws out TS for JS in 2023. Slightly longer answer: I have said a number of times "Javascript is a simple version of Java in the same way as a bike with one wheel is a simpler version of an ordinary bike." The same can be said about JS and TS. If you want to do any serious work you go for the serious thing even if it means occ…

I don’t want to sound harsh, but saying Javascript is a simpler version of Java just tells me you have never used Java seriously. It’s like saying Korean is a simpler version of Spanish. Yes, Java and Javascript are both programming languages, but they don’t even share the same paradigm. You might be confusing the motivation that led to the creation of Javascript with the actual implementation. Having said that, I ha…

How about instead of analogies (which we've misunderstood even on this thread), just say this: "Java and Javascript are very different languages, don't be confused by the similarity of the names".

Of course, at this point virtually everyone knows this, now we are only arguing about which analogy to use to describe something we all understand.

Re: Ask HN: Is TypeScript worth it?

#380

Post by victorNicollet »

k__ wrote: post #325
yakshaving_jgt wrote: post #293

Earlier quoted context omitted.

> it features one of the most ergonomic type systems I have ever worked with. This is surprising. Which other type systems have you worked with?

Yes, I found the ReScript/OCaml type system much more ergonomic.

Having worked with OCaml and F#, I find that TypeScript requires fewer changes to non-type code in response to changes to the types.

For instance, given `type T = { a: string; b: string; c: string }`, if I want to make `b` and `c` nullable but always provided together:

    // OCaml
    type TOpt = { a: string; bc: (string * string) option } 

    // TypeScript 
    type TOpt = T | { a: string; b: undefined; c: undefined }
With the TypeScript approach, code which worked with T still works with TOpt (only requiring an `if(x.b)` guard). With the OCaml approach, any code that accessed b or c needs to be rewritten.

The same applies to cases where an object can be in several different modes, but some properties are present in all modes. For example, an AST node can be a literal, identifier, binary operation, etc. but it always has a source location and an inferred type. In OCaml this has to be represented by either separating a "common properties" type from a "kind of node" union type:

    type node = { loc: location ; inferred_type: exprtype option ; kind: nodekind }
    and nodekind = Lit of string | Id of string | Unary of op * node
Or by repeating the common properties in all union type constructors:

    type node = Lit of location * exprtype option * string
              | Id of location * exprtype option * string
              | Unary of location * exprtype option * op * node
Both are tedious (although F# makes the second one slightly less tedious by allowing one to define computed properties on union types). By contrast, TypeScript allows you to have only one type:

    type NodeCommon = { loc: location; inferred_type: exprtype|undefined }
    type Lit = NodeCommon & { kind: "lit"; value: string }
    type Id = NodeCommon & { kind: "id"; value: string }
    type Unary = NodeCommon & { kind: "unary"; op: op; node: Node }
    type Node = Lit | Id | Unary
Post reply on HN