* 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.
> 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.
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!?
I actually don't relate to this statement at all. My college courses were filled with Python, Java, and C#. I loved python. I hated C# and Java even more. I learned PHP in my own free time. I then went on and happily cut my teeth on dynamic languages for the next decade.
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.
But dhh didn’t say that. He said that very few programmers, not all, don’t like having their opinions changed in typing. He didn’t say they don’t like it when it happens on their own, they don’t like it when others try to do it. At least that what dhh says. Not saying I agree.
You can’t just read something, change it’s meaning and then argue against it.
> 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.
I think typescript's type inference and structural typing is a big part of how it doesn't get in the way of writing code. I've always preferred the safety of static language, but understood the productivity benefits of dynamic languages. With typescript I feel I get the best of both worlds, as you only need to add types where they're vague, and structural types let you express more in objects without needing heavier class polymorphism all over the place.
My least favourite thing about vanilla JS is finding out at runtime that I made a typo. That's an annoying thing that TS completely solves, among many others. I really don't see how you could use TS for any amount of time and wish to revert back.
>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.
Yep, when I hear people say things like "I like $dynamic_language because I don't have to think about what types I'm supposed to put when I write my functions" or similar, I'm just thinking "how the hell can you write a function without knowing what types you want to receive and return?". I do love the "productivity benefits" of having to read entire function bodies to reverse-engineer what types I'm supposed to pass, because the docstring just used vague terms like "file" or "user"
I find that areas that are hard to type are a code smell indicating potentially unstable API design. It can be pretty tricky adding types to a JavaScript project as the lack of types can lead to some very side effecty apis that can be very difficult or impossible to add full type safety to.
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.
Learn to program [at a high level]. Which means being able to write code with a type checker in a way that makes you faster not slower at producing high quality, maintainable programs.
any (concept not keyword) is useful when you NPM install something without types and just do a define module in a local .d.ts. You are implicitly any-ifying that package.
Years of experience don't mean much, if you just repeat the same thing over and over again and aren't willing to learn new things and reevaluate your workflows.
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.
What languages have you written for 30 years? and what about TypeScript is so challenging for you? Especially if you’ve already spent time with other statically typed languages.
I felt similarly. But ultimately, TS is there to solve a particular set of problems, and if they're able to solve their problems without it, more power to them I guess.
The benefits of typescript when refactoring is immense. I have a really hard time understanding how someone could not see the net productivity gain if they've experienced refactoring in typescript vs JavaScript.
> I have a really hard time understanding how someone could not see the net productivity gain if they've experienced refactoring in typescript vs JavaScript.
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.
After using typescript I could never go back. The amount of times it's saved me or got me up to speed quickly is countless. It does come with a cost and god the error messages are just awful sometimes but I'd die before I ever work in a js only project again.
Typescript solved the "I spent hours debugging, only to find I misspelled a property" problem. FastAPI did the same for Python. I have noticed that untyped languages (or "dynamic" languages, if that makes it sound more advanced) have typing added to them by people who love the language, but hate 10x debugging.
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.
I'm not sure about "spending hours". In my experience it's more like "detect an error during compilation instead of an exception during execution". Once you see the exception, it's usually quite clear what exact property is misspelled. So strong typing saves a few second of execution and reduces the need for some types of unit tests.
It is always the thing you forget to unit test that causes the issue. Or the one code path that rarely runs, and causes a mysterious error once a month.
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.
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.
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.
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.
Personally, after working with barely typed Django and typed FastAPI it's not even a contest that typing wins. I get it that rapid delivery of the frontend may shift that, but I did Flutter development as well, and I loved it, because it was typed. Explicit types deliver an ability not to pull hairs off the forehead like nothing else does.
I would love to see the flawless code you've written over 20 years where static typing would have done nothing for you or anyone else maintaining your code.
Have an actual argument? Hopefully a better one than DHH’s, “it’s too hard to type things” Like how bad of a programmer do you need to be? It’s ok to call people out even if they’re popular. Like all the commenters on his PR.
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.
As someone who regularly writes both JS and TS, I'm fairly certain that this dichotomy is not real. There are places where TS makes more sense (eg large, trustless applications with many devs) and places where JS makes more sense (eg libraries that would otherwise need to have very abstract types).
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.
I don't think the dichotomy exists because the TS ecosystem is autonomous. You can use TS with any JS library through type declarations and the definitely typed repo. What the js community thinks about typescript honestly doesn't matter. The only practical difference it makes for me is having to do `npm add @types/{library_name} -D`
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.
Tests are literally type replacement in dynamic languages, only controlled.
It's always mentally easier to do what you are forced to instead of writing tests consciously. That is how the other side is looking at people who tell everyone that there is no coding without typing. People who surrender "think more, do less", instead doing more and thinking less - More is less sounds disgusting to me.
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.
Prototyping is fun but over fast - most programs spend much more time in the "maintenance" phase. Code is generally read more than it's written. Types make all that boring stuff safer and easier!
Going over the PR, this just seems horrible. Not even JSDoc typings. I would never ever want to work in this code base. Good luck to anyone that has to.
I think there is something to say for only having typed libraries. Using a decent code editor, you could write JavaScript with most of the Typescript benefits coming via typings and inference.
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.
Instead of acting like children, bullying/attacking others, and opening up bogus PRs, maybe those people should invest that effort into a @types/turbo package. Wouldn't take more than an afternoon to pull in the old types and call it a day.
I mean this guy unilaterally moved the whole repo off of typescript in the span of 3 hours because of some personal opinions he had. If anyone is acting like a child, it's dhh himself.
I don't think that's an entirely accurate portrayal of the situation. His team has, AFIAK, removed the compilation step from their workflow (or are trying to), deciding to ship unadulterated ES6 to the browser, so they 1) removed TypeScript, and 2) removed Prettier. Both of these require a build/compilation step, which they're moving away from. That's literally it.
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.
> ...very few programmers are typically interested in having their opinion on typing changed.
> Free of strong typing.
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).
Dynamic typed languages are perfect for the new programmer. Very forgiving, quick results. But as you get better, you start looking for tools to help you prevent mistakes, and even code faster. That is what static typing can do for an experienced developer. If you're getting frustrated then you're probably not ready yet - go back to learning the basics.
Not exactly, Prettier is a far more opinionated formatter than Eslin will ever be. As far as I know, Eslint can't format one line into multiple lines, and vice versa. Whether that's desirable or not is up to the you, of course.
Ruby on Rails is my least favorite framework by a large margin, so I guess I'm not surprised that the creator of it would make decisions that are diametrically opposed to ones I would with regards to TS.
The issue is not "typed vs untyped", because frankly there was zero discussion about the relative merits of that in the PR - or even in the project, it seems. This is just another shining example of "Things DHH Does".
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.