Hacker News Reader

Comment by pestaa | Hacker News Reader

What is your take on TypeScript, what is it you don't like?

I come from a C# background, but to list out a few hurdles that I have already deal with with TypeScript/NodeJs.

  1. C#'s AsyncLocal has made a few things simpler to trace SQL queries to a request. 
  2. We chose to use hapi.js some 2 years ago, because we found the interface superior to Express, but I did not expect the sole developer of hapi.js to decide stop working on the project [1], and left my head scratching on what I am going to do about that. 
  3. TypeScript's interface sometimes feels too much like just "suggestions", and every once in a while run across scenarios that are not fully supported. One that I really dislike is that Sequelize's "where" options has no type support for the model. [2]
  4. Sometimes libraries does not use async correctly, and breaks stack traces.
  5. Sometimes TypeScript's generic errors can be as bad as C++.

My favorite feature of TypeScript is being able to just define types/objects in-line, but I actually like to stay on the side of caution and stability on a large project with many people.

[1] https://github.com/hapijs/hapi/issues/4111 [2] (GitHub is down, or I would grab the link)

I can feel the pain on all 5 points. One thing I did notice though is that NodeJS has such a huge breadth of packages that its _very_ hard to actually pick something good. But there is almost always an alternative that's maybe not as popular, but is a lot more "solid" alternative.

For example we used SOHU-Co/kafka-node for a while as a kafka client, until we hit some bugs that made us dig through its internals and we realised it had some deep issues. We then switched to kafkajs which turned out to be much more mature and polished, even though it was less "popular".

Sequalize in particular I think was developed in an era before TypeScript was a thing so it follows the ideals of that time, more in line with Ruby and being easy to use and malleable. We switched to using slonik for our query needs, with a more declarative and static approach, skipping ORMs and query builders altogether - just raw strictly typed queries. I think in the end its a better approach for our needs.

I guess what I'm trying to say is that TypeScript was built to be able to handle _all_ of the weird and wonderful world of JS from its most amateurish and fun, to its most solemn and strict. And it's just a matter of picking up where on the spectrum you want to operate and make your dependencies match that vibe. It's limiting and freeing at the same time.

I will have to take a look Slonik.

I feel like I have been to hell and back with ORMs, between Sequelize, Entity Framework, Hibernate, SQLAlchemy, etc.. and frankly, I think they just cause more headaches than solve problems.

I would love to have strongly typed SQL queries, but I have found that Dapper [1] fills a special place in my heart.

[1] https://github.com/StackExchange/Dapper

I've been following https://github.com/adelsz/pgtyped for awhile. It should give you TS types from sql files (and even sql template literals) directly. Though I haven't used it in prod. Might be worth a look.

Not the OP but my take is that Typescript has done great things for improving JS but it's still JS and carries a lot of it's baggage with it. There is only so far you can take it while maintaining compatibility and the type system is overly complicated in places because of this. It also doesn't really give you the same guarantees that something like Rust does, I don't believe the two type systems are that comparable. On top of that unless you use all TS packages types are maintained and installed separately adding to an already tricky to maintain dependency graph that comes with Node development.

Reply on news.ycombinator.com