Turbo 8 is dropping TypeScript
world.hey.com
world.hey.com
https://github.com/hotwired/turbo/pull/971
Some summary:
* forced through without any discussion
* many maintainers raising questions, but no answers
* random changes attached to the PR (formatters, etc)
Wherever you land on types, I think we can agree that this is not an ideal way to make a change to a larger open source project. This has all the hallmarks of an executive decision made on a whim, and forced through at the last minute. Lead maintainers certainly have the right to make big changes on a whim, but giving people some notice before breaking other projects and having good communication is true leadership.
He's certainly right about this. I can't wrap my head around why anyone wouldn't want types in their program*
The types still exist you just didn't write them down! Why won't you just write them down!?
*short scripts excepted
I dabbled occasionally with typed languages, but it wasn't until Typescript was forced upon me by a respected coworker that I was able to recognize type safety as a net-win for development speed. Seeing an entire class of problems disappear in a codebase rife with them was an eye opening experience.
I briefly took a ruby job a little over a year ago and I missed type safety quickly. Despite how much I love Ruby, I love tracing through code paths to understand what a variable is a lot less.
You can’t just read something, change it’s meaning and then argue against it.
DHH said:
> very few programmers are typically interested in having their opinion on typing changed. Most programmers find themselves drawn strongly to typing or not quite early in their career, and then spend the rest of it rationalizing The Correct Choice to themselves and others.
IME, my story doesn't seem to be that unique among typescript advocates thus I do not relate to DHH's statement.
>Things that should be easy become hard, and things that are hard become `any`. No thanks!
Denouncing a type system because you refuse to use it correctly seems short sighted to me, but I am of course biased as a TS fan.
My impression is that people running into these problems are trying to add declaration files to JavaScript code, but if you use typescript throughout I've not run into these problems.
Anything I find hard to type is simply a hard problem to solve in the first place and the type system helps me rethink the problem to find safer and more elegant API designs.
Meaning you could create most modern applications (including this very website) without really learning to program...
Fun perspective.
Thankfully you and Typescript are here to show me how to do it right.
I have seen people with decades of experience who remained stuck doing things the same way they first learned to do them and refusing to adapt.
cause I spend more time debugging other peoples typescript code that is usually a typescript problem and is obfuscated by the extra layer. If we used vanillaJS then it would save everyone so much time.
On the other hand, I can't think of a single example of a strongly typed language that has been "fixed" by someone* to get around typing. Like, "I love building enterprise systems in C++, but I just really miss all those runtime errors that could/should have been caught by the complier."
So maybe the trajectory of languages gives a clue as to which is better.
*I know that would be incredibly difficult, but we programmers are a resourceful bunch.
Dependency injection is exactly that.
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.
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.
Typescript has done nothing for me.
Just a religious battle at this point.
(I'm okay with it on the server, but client side is just something something)
No one is trying to kill your puppy or taking your types away.
Competent people can have different opinions.
You have something that works for you. Great.
The fact that you don't understand why others don't share your opinion doesn't make them wrong or "incompetent" as you said in a different comment.
dhh literally took people’s types away. People don’t like that.
I used to be pretty religious about it NOT being on the server, but nowadays I just say to myself: Who am I to say JavaScript can't be used on the server?
What about PHP on the client side? Why is suddenly Python a server-side language when it's a scripting language better suited for data analysis and manipulation? WASM? Is not ASM an applications language instead?
This line of thinking broke me of these thought-limiting shackles, and now I think: If there's a toolchain to make it run on your target (client side browser, server side app, at your OS as a service script, embedded devices, whatever), then go for it.
I'd understand opting for either JS or TS as a policy going forward, but it's hilarious that this dude probably worked himself up so intensely about this that he brazenly rug-pulled his own repo and invalidated all open PRs.
If your library is hard to type, it is a code smell. In my opinion, such libraries could benefit from TS a lot.
They should also remove tests from the projects as well. Such a burden on the developer to write test and worry about how to test when they just need to focus on implementing the logic.
Very few programmers are typically interested in having their opinion on writing test changed. Most programmers find themselves drawn strongly to testing or not quite early in their career, and then spend the rest of it rationalizing The Correct Choice to themselves and others.
A big part of development is prototyping, it sucks so much to use a language that doesn't support efficient prototyping. And no, jumping from Typescript concepts/style to pure Javascript is not an efficient solution, you have limited space in your brain.
I can continue, literally all Typescript code is horrible legacy in the making. In the future people would hate it is so much that comments like this would look ridiculous, remember my words.
It looks like Turbo is a solution where you don't have to write JavaScript. So Turbo maybe Turbo falls into that bucket as well?
But any JavaScript library has to have typings, even for the people who write JavaScript. Because otherwise their autocomplete does not work. I think libraries should have a higher bar anyways in general, for types, but also testing, documentation etcetera.
The Turbo library is not consumed like a normal package anyways, so these types were only used internally. Nobody relies on these types.
It's their library. And others have done the same recently.
Strong-typed languages can be a source of burn and frustration if you're not used to them, especially when starting your programming career (and I sense DHH comes from this standpoint on his last paragraph there).
I know many programmers that have chosen weakly-typed languages because they found it simpler, faster time-to-HelloWorld-success, rather than fighting the compiler for cryptic compiler and linking errors. I was burned like this when I first found C++ and Delphi back when I was 12 years old.
I consider strong-typing beautiful for two reasons:
- You get to be explicit on how you want the bits you're handling being interpreted. Some languages will even let you write your own typecasting functions and comparison operators, further extending the language capabilities (though they may tend to be more verbose).
- It helps code analyzers do their job, helping you to avoid a shoot in the foot (IntelliSense, IDEs with similar technologies).
In my argument I'm abiding to the "explicit is better than implicit" principle which is not only a Zen of Python thing; every programming language benefits from this approach (more control, more readability, explicit intention, less uncertainty).