Comment by dvt | Hacker News Reader

Comment by dvt | Hacker News Reader

Parent Full thread

> Furthermore, TypeScript is a great language and I find myself being so much more productive in it than I was in Java, especially when it comes to refactoring.

I don't really see how. TS doesn't seem to solve any annoying problems I previously had in Java. As a concrete example, it would be nice to have the concept of a DTO as a first-class language feature, but alas, I find myself constantly casting and re-casting, plucking, or writing endless wrappers to make sure properties trickle down (or up). Hell, sometimes I just give up and use `any`. I mean, this is a web-first language that has no concept of sending objects over the wire.. okay then.

TypeScript's generics system is cute, but I think it's mostly academic. And did you look at the toolchain? To get TS working, you need babel or ts-node or webpack, and like 3 different .json config files. Importing a package without TS support? You need to write some stubs yourself in types.d.ts. In fact, the best parts of TypeScript are actually JS (await/async, arrow notation, spread operator, etc.).

This biggest "aha" benefit I get from TypeScript is that it is structurally typed, while Java is nominally typed. In my experience it has proven much easier to refactor in TS because I just need to ensure my objects have all the right properties. With Java if I have a Thing1, but a library is updated to add just a single new property so now there is a Thing2 type, well now then all the places I need a Thing2 I have to completely copy over from Thing1 - I can't just add the property and be on my merry way. This happened to me many times in my Java career - I still think I have PTSD having to do a Jersey 1.x upgrade to a Jersey 2.x version across a large codebase. It was a nightmare I've never had anything come close to with Typescript.

> I mean, this is a web-first language that has no concept of sending objects over the wire.. okay then.

I have no idea what you're talking about here. I use GraphQL with auto typegen of my TS types and I get typed data objects everywhere.

> TypeScript's generics system is cute, but I think it's mostly academic.

TBH this remark just makes me thing you really don't know much about TS. I use generics extensively, find them very helpful and are easy to use.

I'll give you the point on initial TS setup being non-trivial. Hopefully advances in tooling (things like Deno, which I'm not actually a huge fan of, or other projects like Rome) will make this easier, but even then I found this to be a "one and done" cost.

Note that the upgrade pain with Java was not due to typing; rather, it was due to using a library directly instead of creating a class to interface with it. In other words, inadequate abstraction.

I find that making those classes is a pain in java, but really easy in typescript

> Note that the upgrade pain with Java was not due to typing; rather, it was due to using a library directly instead of creating a class to interface with it. In other words, inadequate abstraction.

I'd look into what Jersey actually is before you say something like this, because what you've said really doesn't make sense.

How so?

Yikes, is this really the expected way to do things in Java? That sounds frustratingly verbose. But I guess that is expected with Java.

There is a reason for nominal typing though, because nominal types represent an interface contract that generally goes beyond just having the right type signature, but instead it is also about semantics. It's about the parts not covered by the type system, which the compiler therefore can't check. It depends on the kind of objects you are generally working with, but beyond pure data I find nominal typing preferable, because it makes it explicit that an implementation X conforming to interface contract Y is not just a matter of type signatures.

The shock wave that TS sends through a JS stack is hard to ignore. It's really annoying. Every tool added TS support in a slightly different way and you always have to keep it in mind no matter what you're doing. Sadly it's just the reality we gotta face. I'm hoping Rome can live up to the hype and be helpful here.

Oh man, so true, between TS mangling and whatever framework you're using (Vue/React/etc.), the stack trace ends up being literally worthless. It's kind of funny to think about: when something goes wrong, I don't even look at the trace (which is 100% what you'd do in any sane language), but rather I just go back and look at the "last thing I changed."

Ah that is true as well. When I said stack I meant like Babel, Storybook, Webpack, Jest, etc. But yeah JS stack traces aren't so fun these days.

You aren't using source maps to transform your stack traces then? I've had very little issue in understanding stack traces in any of the major JS frameworks.

I think esbuild is basically already doing most of what Rome promises

From Rome readme:

> Rome is designed to replace Babel, ESLint, webpack, Prettier, Jest, and others.

Afaik esbuild only intends to be a replacement for 2 out of 5 of those things. It does that well for sure, but if parent commenter's main issue is the amount of different tools, I don't think esbuild will help.

People are talking the other points to death but on the toolchain front, you might enjoy https://github.com/evanw/esbuild, which is rapidly gaining in popularity. Just 1 thing for bundling, transpilation etc. And its terrifically fast since its written in Go (ironic I know).

There is also swc which is fast because... its written in Rust https://swc.rs/

But there is also sucrase which is fast because.. its written in TypeScript? https://github.com/alangpierce/sucrase

This is just you not being familiar with the language

Reply on news.ycombinator.com