Hacker News Reader

Comment by conmigo | Hacker News Reader

I've never increased my productivity by using Typescript, although I really tried very hard to like it. It just keeps bugging me. It's a constant stream of interruptions that force me to please the TS compiler, compared to having a rare type issue a once in a while in plain JS.

Besides that, I've never been a Microsoft fanboy(to say the least) and it's worrying me that almost the entire JS eco system falls in the hands of that company; Github, VSCode, Typescript, NPM, etc.. Am I alone in this?

There is so much good stuff in the JS world, but we seem to adhere to a few companies and a few systems more and more. Being a 'Javascript' developer today only has very little to do with Javascript. It's about React, Redux, Hooks, ESLint, Prettier, Typescript, etc.. Oh, and don't forget to do it Agile, another joy and productivity killer. And when you don't agree with this stack you're either not so smart or still need to learn to 'understand' it.

View on HN

Your comment is pretty much exactly the reason why I'm moving to Elm and PureScript as much as possible. As a specific point, function types for redux-thunk are just an absolutely miserable mess and that alone moved me to redux-saga. But personally I just want to dump the whole wretched thing. I'm glad people are waking up to this, because I felt like the odd one out disliking Typescript and preferring Javascript.

Typescript in my experience has felt like a collection of hacks more than a well thought out expansion of Javascript. Additionally, it concerns me that official solutions to some problems (e.g. iterating on an enum) require you to write around the code that the compiler will generate. That does not fill me with confidence at all.

As a personal point of contention, I really dislike that the types are useless beyond design-time. But since they don't want to go outside the EMCA spec, we'll likely not see anything like pattern matching on type or type-level destructuring anytime soon.

As it stands, some trivial things can become a nightmare very quickly. Maybe I'm just used to the ease at which ML-family languages can express some concepts.

What specific concerns did you have with the redux-thunk types?

I feel very similarly to you regarding the position that JS is moving in.

I can only surmise that things are moving in this direction to lower the barrier to entry. As more developers are working with JavaScript it's easier to subscribe to tools to manage consistency than it is to educate and rely on developers' standards to create working efficient code.

Thinking back I've worked on some massive 'Web app' projects over the last 20 years, and the biggest I worked on didn't use much in the way of frameworks or libraries, and standards were maintained by peer review and documentation.

Typescript I suppose automates a lot of this, but I don't think that makes it better.

Same. I have tried using it and enjoyed the IDE powers a bit more, but already knowing JS quite well, it wasn't a game changer.

Lately I have started using FastAPI in Python, which uses Pydantic to enforce type hints at runtime. This saves a lot of manual checking code (e.g. "if input_data["mykey"] == "unhappy path": raise ValidationError").

This was the same annoyance in Node.js because the types are so flimsy and manually checking is really boring. Tests are great but if you can have correctness while rapidly prototyping that would seem to be a win.

Is there a great TS lib to do runtime type reflection like Pydantic?

Self-reply: I found these two but haven't tried them.

https://github.com/pelotom/runtypes

https://github.com/ianstormtaylor/superstruct

I tend to agree with you. I've been working on the front-end side of web applications for a couple decades now. We have so many tools available to us now then ever before. It's interesting to observe how a select few end up as the go-to choices for so many projects and organizations.

At the end of the day, they are just tools and how we use them is what really matters.

The primary driver of Productivity isn’t how fast you type code, it’s how much time it takes that code to work correctly.

Reply on news.ycombinator.com