Hacker News Reader

Comment by quickthrower2 | Hacker News Reader

So I have been musing on TS this for a while. I put my self in the rare “open minded about types” camp.

My biggest beef with TS is you need to compile it, and JS development has enough complexity with module systems and stuff as it is. Compile to JS languages IMO should take the entire burden away like Elm does, otherwise they add a lot of troubleshooting work.

I wonder if type annotations on plain JS could be the way to go. Lint, but don’t compile. This should work seamlessly with NPM modules etc.

Even with such a system I am sure DHH might still want to forego and that is fair enough. But a little sprinkling of simple types such as “this is a string” goes a long way towards documenting the code.

View on HN

He basically had this option, and it's the way that Rich Harris and the Svelte team went a few months back by adopting JSDoc, and honestly his reasoning for dropping typescript in favor of another typing system is pretty sound and did result in clear benefits for both users and maintainers.

DHH has something specific against types in general which I really don't understand. And that's fine, I'm happy to let him and 37 signals do whatever they want. I probably won't be super duper interested in applying to work on basecamp/hey, but that's his choice and I'm sure there are devs there who do prefer it. It sounds like they've been doing it for a while.

But this is an open source project with users and contributors outside the company. It absolutely can and will impact those people. Types supercharge your IDE with better linking, docs, and error detection. It will be harder to work on and around this project, and many current open PRs now will need to be refactored, and the way people build things will need to change.

And that wouldn't even be so bad if the proposal had come out more than a few hours before the merge. It's clear that no community engagement was even considered.

Nothing is stopping people from using JSDoc, your arguments here don't make any sense.

With ts-node or Deno there is no compile step you have to do yourself. For frontend, bundlers can be setup where it is pretty transparent.

I have found practically with ts-node or bundlers ... you can get knocked off the happy path, have problems, you need to fiddle with tsconfig.json and you need to spend ages in StackOverflow posts to fix it. This sometimes happen if you want to use a certain library, or doing a mass upgrade of a 2 year old project. I have no experience with Deno.

This. Pseudo-runtimes can't guarantee anything.

Are you doing full stack or backend development? On the browser a build step is needed anyways as you need transpilation to be able to use new ecmascript features, and you need a bundler for module management. Node is kept more up to date so I can see skipping compilation for that. I was already used to needing a build step before switching to typescript so it didn't matter much to me.

Reply on news.ycombinator.com