Remove TypeScript(github.com)
github.com
Remove TypeScript
https://github.com/hotwired/turbo/pull/971
126 comments
> After years of being resistant to “extra layers of complexity that slows me down” I adopted TS and now I can’t live without it.
TS isn't an extra layer of complexity.
Walking through the entire path an object takes through a library's source code to find out what fields the object has is an extra layer of complexity.
Having to rely on looking at unit tests to have some idea of what to pass to a function is an extra layer of complexity.
Hoping documentation is kept up to date (hint: it isn't) is an extra layer of complexity.
Having code break after updating to a point release because some field got renamed or removed and there is no safety mechanism to keep chaos from happening, is an extra layer of complexity.
Typescript makes you pay up front to remove a LOT of complexity down the line.
TS isn't an extra layer of complexity.
Walking through the entire path an object takes through a library's source code to find out what fields the object has is an extra layer of complexity.
Having to rely on looking at unit tests to have some idea of what to pass to a function is an extra layer of complexity.
Hoping documentation is kept up to date (hint: it isn't) is an extra layer of complexity.
Having code break after updating to a point release because some field got renamed or removed and there is no safety mechanism to keep chaos from happening, is an extra layer of complexity.
Typescript makes you pay up front to remove a LOT of complexity down the line.
I had the great joy of learning a massive "legacy" nodejs project a few years ago. The author had used function "arguments" as a bucket all over the place mixed with named parameters. Lots of indirection and "facade" patterns. A few high level integration tests. And to top it all off, none of it worked in isolation, lots of very loose coupling with no documentation that the coupling existed. Took me months to digest it all.
TypeScript hurts to write for people who write code like that. But also, these days, it enables it: you can write that, you just need to leave an actual trail outlining the shape of those dependencies. And if you REALLY like writing lots of flexible dynamic code, typescript can enable that too, and have fun defining those complex generics. You won't.
I understand the pain of typescript. It's the pain that you can either eat yourself in working through exactly what you want the shape of your dynamic things to be; it's the pain that every other developer following you will need to eat if you do the same thing in js without types.
OR- You could just write your code without those "clever" features in the first place, and get the job done in less time to boot.
TypeScript hurts to write for people who write code like that. But also, these days, it enables it: you can write that, you just need to leave an actual trail outlining the shape of those dependencies. And if you REALLY like writing lots of flexible dynamic code, typescript can enable that too, and have fun defining those complex generics. You won't.
I understand the pain of typescript. It's the pain that you can either eat yourself in working through exactly what you want the shape of your dynamic things to be; it's the pain that every other developer following you will need to eat if you do the same thing in js without types.
OR- You could just write your code without those "clever" features in the first place, and get the job done in less time to boot.
I mostly agree with the general trend of your post but TypeScript is definitely an extra layer of complexity. You no longer edit the code which your browser runs, you have another toolchain to maintain, and you need to deal with things like source maps everywhere.
Now, there’s a strong argument that this is more than balanced out by the things you mentioned. I personally agree with some of them but I do think that’s a legitimate point. I’ve seen every mitigating factor for TypeScript’s complexity fail so I’m not going to say it doesn’t happen.
Now, there’s a strong argument that this is more than balanced out by the things you mentioned. I personally agree with some of them but I do think that’s a legitimate point. I’ve seen every mitigating factor for TypeScript’s complexity fail so I’m not going to say it doesn’t happen.
Also you don't write code that your processor executes and, at best, you use a layer of complexity known as assembly language. That's a shame!
… and that's why decades of work went into things like making better debugging and analysis tools, things like symbol files, etc. One of the appeals of the web was that you didn't need to deal with that but using a compiler of some sort makes that necessary again. It mostly works, most of the time, but it's never been that hard to run into some case where it doesn't. I don't think it's a deal breaker but I do consider it legitimate for someone to say they don't get enough benefit to be worth it.
Modern web requires compiler/bundler/minimizer for js code any way, whether you use typescript or not. And this will probably never change. Rather, the web will move to use of something like webassembly.
That’s not true in general: the modern web is quite capable with native browser functionality and many apps don’t need more. Tools like React do but that’s because they’re designed around IE6, which was a very different era.
Can you show me few examples of production apps in wild web which use only native js?
I could copy and paste JS code into a REPL/browser console to find bugs/REPL-basee development, but that won't work for Typescript. Debuggers take some more time to set up too. More complex than other typed OOP languages like C# or Java which don't have these steps.
I got sick and tired of running code in the debugger just so I could see what fields an object even has.
Or even worse, what fields an object has, at what points in time, as fields can of course be added and removed whenever.
Just, like, no.
Also Typescript debugging is no harder than JS debugging, setup the source maps once and it works, same as setting up debugging symbols in C#, except Visual Studio typically does that for you. If you want to debug C# code running on a web server (which you can totally do! It is an amazing feature!) you'll need to provide Visual Studio with a link to the symbol files yourself, no different than Typescript and source mappings.
Or even worse, what fields an object has, at what points in time, as fields can of course be added and removed whenever.
Just, like, no.
Also Typescript debugging is no harder than JS debugging, setup the source maps once and it works, same as setting up debugging symbols in C#, except Visual Studio typically does that for you. If you want to debug C# code running on a web server (which you can totally do! It is an amazing feature!) you'll need to provide Visual Studio with a link to the symbol files yourself, no different than Typescript and source mappings.
Merging this PR honestly just seems like a 'political move' in terms of forcing their opinion about TS on everyone else as the "best decision".
If they actually cared they would have at least addressed the comments, and added written documentation/jsdoc comments in places where literally theres no way to know what is going on without the types that were given.
If they actually cared they would have at least addressed the comments, and added written documentation/jsdoc comments in places where literally theres no way to know what is going on without the types that were given.
What I found ironic was this part from the reasoning post:
> [V]ery 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.
Feels like projecting. I think very few programmers would feel this strongly about typing that they would break things by rushing a PR within hours, despite plenty of negative responses and barely any positive ones.
> [V]ery 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.
Feels like projecting. I think very few programmers would feel this strongly about typing that they would break things by rushing a PR within hours, despite plenty of negative responses and barely any positive ones.
I mean it’s also simply not true. Most JS developers who have been doing JS for at least ten years have explicitly gone from not caring that much about types to being thankful for them.
To be fair, open source is not a democracy. The project owners/authors/maintainers can do things because they feel like it or prefer it, without having to justify it to anyone - even if everyone else openly hates it and the project loses users or contributors as a result.
Some big projects have governance rules and committees where you could expect more through some bylaws or similar, but that is not the norm. The only right given to others in traditional open source is the ability to fork if you feel enough for it.
Also note that many of the votes and comments are from HN, which might distort the view of the original disagreement.
(I like neither JS nor TS, so eh.)
Some big projects have governance rules and committees where you could expect more through some bylaws or similar, but that is not the norm. The only right given to others in traditional open source is the ability to fork if you feel enough for it.
Also note that many of the votes and comments are from HN, which might distort the view of the original disagreement.
(I like neither JS nor TS, so eh.)
Javascript and type annotations in comments go a long way, too. Not the whole way, a bit annoying to write at times, but 95% of the value is there.
Just getting rid of types after you already authored your software with them in mind just seems like the worst of both worlds. I have trouble making any sense of it.
Just getting rid of types after you already authored your software with them in mind just seems like the worst of both worlds. I have trouble making any sense of it.
> Javascript and type annotations in comments go a long way, too. Not the whole way, a bit annoying to write at times, but 95% of the value is there.
I'd say that "5%" is where some really nasty devils lay though. Plus, if you're going through the effort of documenting types in comments, why not use TS and prove that they're correct + up-to-date?
I'd say that "5%" is where some really nasty devils lay though. Plus, if you're going through the effort of documenting types in comments, why not use TS and prove that they're correct + up-to-date?
You are using Typescript to prove that they're correct.
https://www.typescriptlang.org/docs/handbook/jsdoc-supported...
https://www.typescriptlang.org/docs/handbook/jsdoc-supported...
That’s true. For Python I add them as needed. It’s not all or nothing. You can change tsconfig to be fine with implicit any.
One advantage of going to JsDoc type annotations for some libraries is that you don't need to deal with sourcemaps. People can use the source code as-is and they can bundle and minify it if they like.
That doesn't seem to be what this is about, though.
That doesn't seem to be what this is about, though.
Hmmm you got me thinking. I wonder if there’s a sensible story for ts to “compile” to JS with jsdoc annotations.
I know you can make it emit perfectly legible, formatted JS, but I’m not aware of the docs.
I know you can make it emit perfectly legible, formatted JS, but I’m not aware of the docs.
> Fully recognize that TypeScript offers some people some advantages, but to my eyes, the benefits are evident in this PR. The code not only reads much better, it's also freed of the type wrangling and gymnastics needed to please the TS compiler.
This is such a terrible take. The same could be said about removing tests. It does simplify things, and not having to please the damn test suite is indeed a boon for productivity. You get to drive at full speed towards the cliff.
Strong typing is a hill I'm willing to die on, and at Svix we encode everything we humanly can in the type system. Let the compiler catch our mistakes...
This is such a terrible take. The same could be said about removing tests. It does simplify things, and not having to please the damn test suite is indeed a boon for productivity. You get to drive at full speed towards the cliff.
Strong typing is a hill I'm willing to die on, and at Svix we encode everything we humanly can in the type system. Let the compiler catch our mistakes...
This is a great analogy and succinctly summarizes my feelings on the matter. Just like you don't need tests for a quick prototype or for every last little bit of code, the same goes for static type checking, but past a certain point it's a must have.
I'll join you on that hill. I'd rather "fight" my IDE/the compiler than have runtime errors. Also writing code in a dynamic language is painful after you used a statically typed language in combination with a good IDE
> Strong typing is a hill I'm willing to die on, and at Svix we encode everything we humanly can in the type system. Let the compiler catch our mistakes...
After years of writing Julia (dynamic) and C++ (static), I'm willing to die on that hill too. But I've encountered more people who disagree with me than agree, so I'm not surprised by seeing a PR like this.
After years of writing Julia (dynamic) and C++ (static), I'm willing to die on that hill too. But I've encountered more people who disagree with me than agree, so I'm not surprised by seeing a PR like this.
[deleted]
Disclaimer: I agree with you.
Devil's Advocate: I actually can't, absolutely **** take.
Devil's Advocate: I actually can't, absolutely **** take.
Hi all, I work on the TypeScript team. There's already a lot of feedback on the issue itself from users urging the authors not to make this decision, so I will hold back from adding to the noise on that issue. Every team is entitled to make the decisions that they feel are best for them, and I don't think it'd be productive to change anyone's mind in this case.
Instead I'll just mention that I always welcome thoughts on some of the challenges teams encounter when writing in TypeScript. It helps make the language better. If there's anything you often hit, you can comment here, create an issue on the issue tracker, or reach out to me at Daniel <dot> Mylastname <at> microsoft <dot-com>
Instead I'll just mention that I always welcome thoughts on some of the challenges teams encounter when writing in TypeScript. It helps make the language better. If there's anything you often hit, you can comment here, create an issue on the issue tracker, or reach out to me at Daniel <dot> Mylastname <at> microsoft <dot-com>
In our team it's causing a lot of confusion an inconsistency that types and interfaces overlap 90% in functionality, but have different syntaxes.
You can find many articles trying to explain which is best under which circumstances, but there are no correct answers.
I would wish for TS to deprecate one of the syntaxes (probably interfaces because they read as statements rather than expressions), and instead extend the other with the 10% functionality that would be lost.
For instance a type could be declared as open, to make it possible to reopen and extend it.
You can find many articles trying to explain which is best under which circumstances, but there are no correct answers.
I would wish for TS to deprecate one of the syntaxes (probably interfaces because they read as statements rather than expressions), and instead extend the other with the 10% functionality that would be lost.
For instance a type could be declared as open, to make it possible to reopen and extend it.
I even saw a Youtube video recently making a strong case that types are almost always the better option unless you run into a few niche use cases like needing interface merging.
I’d just like to say thank you for your team’s hard work on TypeScript. I can’t imagine writing JavaScript without TypeScript.
Y'all have been ignoring the largest DX issue in TypeScript for years: https://stackoverflow.com/questions/57683303/how-can-i-see-t...
Even as someone who is very proficient in TypeScript, and an advocate, it's a huge PITA having to constantly ctrl+click through large type hierarchies trying to build a mental model of fully resolved types.
Even as someone who is very proficient in TypeScript, and an advocate, it's a huge PITA having to constantly ctrl+click through large type hierarchies trying to build a mental model of fully resolved types.
Typescript has been revolutionary and made me love doing frontend work. It’s solved so many issues with reliability that I’d never suggest using an untyped framework like rails for a new project.
I'm going to be a bit of a naysayer here and comment that while I fully appreciate and endorse TypeScript... there are certainly situations where Javascript would be preferred. EG: Deno also dropped TypeScript internally.
What they've done seems a bit rough around the edges and a types file of some sort for external facing customers is a critical follow-up PR, but I would not blindly trash these guys for switching to Javascript. I suspect they did it so quickly because it would have sat in committee for eternity otherwise.
I probably wouldn't write anything in pure JavaScript today when TypeScript is such an enormous boon... but I'm also not working in the space that this project is working in.
What they've done seems a bit rough around the edges and a types file of some sort for external facing customers is a critical follow-up PR, but I would not blindly trash these guys for switching to Javascript. I suspect they did it so quickly because it would have sat in committee for eternity otherwise.
I probably wouldn't write anything in pure JavaScript today when TypeScript is such an enormous boon... but I'm also not working in the space that this project is working in.
Meh, this debate is already long over. Every TypeScript alternative/competitor is dead. Most developers who are staunchly against TS types and compile steps for their JS code still probably end up relying on TypeScript via their editor's intellisense/language support even if they don't know it.
TS feels like a fever dream. It's as if a concentrated group of people were so convinced of a solution, that despite all available "parol" or academic evidence, they foisted it upon the ecosystem doing untold amounts of damage for years to come.
And if you don't use it, well it's because you simply don't understand types and your code base will be riddled with bugs! (lol)
The best, most testable, falsifiable argument I have heard for typescript is that helps with certain IDE's; but personally I haven't noticed a difference. In fact, TS causes me to go into dead ends with VS Code trying to hunt for the actual implementation of something in sizable code bases to the point where I'll just look at even the minified code to figure out what's actually going on.
Because at the end of the day, TS isn't an actual type system. It's a bunch of macros that sit on type of a jazz'd up linter (yes I am being editorial here). I have been coding for a long time, and personally I have never jumped into a TS code base and gone "oh thank god they decided to abstract this correctly!" These days it's met with a sigh and knowing a simple task is going to take me 10x as long to do than it would with any other tech stack.
Don't even get me started on the bugs TS itself has caused over the years.
People have often and loudly pointed out how awful web development can be (and was) over the last 20+ years but honestly, TS has been pretty pointlessly painful. The pain in yesteryear's was due to competing interests and the fact that many aspects of web development were just brand new.
It's a mistake we just need to fess up to as an industry.
And if you don't use it, well it's because you simply don't understand types and your code base will be riddled with bugs! (lol)
The best, most testable, falsifiable argument I have heard for typescript is that helps with certain IDE's; but personally I haven't noticed a difference. In fact, TS causes me to go into dead ends with VS Code trying to hunt for the actual implementation of something in sizable code bases to the point where I'll just look at even the minified code to figure out what's actually going on.
Because at the end of the day, TS isn't an actual type system. It's a bunch of macros that sit on type of a jazz'd up linter (yes I am being editorial here). I have been coding for a long time, and personally I have never jumped into a TS code base and gone "oh thank god they decided to abstract this correctly!" These days it's met with a sigh and knowing a simple task is going to take me 10x as long to do than it would with any other tech stack.
Don't even get me started on the bugs TS itself has caused over the years.
People have often and loudly pointed out how awful web development can be (and was) over the last 20+ years but honestly, TS has been pretty pointlessly painful. The pain in yesteryear's was due to competing interests and the fact that many aspects of web development were just brand new.
It's a mistake we just need to fess up to as an industry.
Well that’s certainly a hot take. I’d say TypeScript is the best thing to happen to JS, but that’s just my opinion. It’s not perfect, but it makes working on a large codebase tolerable. To each their own.
> untold damage
> 10x dev time
> bugs
> pointlessly painful
> it’s a mistake
Your comment seems very emotional and doesn’t add any concrete counterarguments.
> 10x dev time
> bugs
> pointlessly painful
> it’s a mistake
Your comment seems very emotional and doesn’t add any concrete counterarguments.
Counter arguments to what exactly? What arguments are being proposed? Where? By Whom? Can you quote them?
The burden of proof is not on anyone else to prove that TS is making a beneficial difference. The fact that more and more experienced teams are moving _away_ from TS and not towards it certainly cannot and should not be ignored.
This is just a repeat of the "Surely OOP will solve all these different class of problems, trust me!" conversation the industry already had and I thought we had matured past.
Making a drive by dismissal comment that has quite grandful stands isn't really driving the conversation anywhere. You could have at least disagreed in detail.
The burden of proof is not on anyone else to prove that TS is making a beneficial difference. The fact that more and more experienced teams are moving _away_ from TS and not towards it certainly cannot and should not be ignored.
This is just a repeat of the "Surely OOP will solve all these different class of problems, trust me!" conversation the industry already had and I thought we had matured past.
Making a drive by dismissal comment that has quite grandful stands isn't really driving the conversation anywhere. You could have at least disagreed in detail.
> The fact that more and more experienced teams are moving _away_ from TS and not towards it certainly cannot and should not be ignored.
I highly doubt that this is the case. I also doubt that you can back this up.
I highly doubt that this is the case. I also doubt that you can back this up.
I know you said don't get me started on the bugs TS caused, but I would like to hear about them if you don't mind.
I personally only had one bug that was caused by TS itself (https://github.com/microsoft/TypeScript/issues/40726) so I'm curious to hear about the issues you encountered.
I personally only had one bug that was caused by TS itself (https://github.com/microsoft/TypeScript/issues/40726) so I'm curious to hear about the issues you encountered.
Here is my take..
The arrival of TypeScript has coincided with a massive, massive increase in code quality and engineering robustness within the Javascript library ecosystem.
Sure Javascript itself has increased in popularity and brought a new breed of software engineer into the mix, but it's probably not a coincidence that the people leading a lot of these modern and now ubiquitous library/framework efforts are drawn to TypeScript; people who probably wouldn't have touched Javascript with a 10 foot pole otherwise.
The arrival of TypeScript has coincided with a massive, massive increase in code quality and engineering robustness within the Javascript library ecosystem.
Sure Javascript itself has increased in popularity and brought a new breed of software engineer into the mix, but it's probably not a coincidence that the people leading a lot of these modern and now ubiquitous library/framework efforts are drawn to TypeScript; people who probably wouldn't have touched Javascript with a 10 foot pole otherwise.
> The fact is that I actually rather like JavaScript. I'd go so far as to say it's my second favorite language after Ruby.
Tells this haskeller / TSer everything I need to know.
Tells this haskeller / TSer everything I need to know.
> it's also freed of the type wrangling and gymnastics needed to please the TS compiler.
If you're fighting typescript that much, then what's the point?
The point of using things like types is correctness that can be statically checked. Imagine writing java (or any static typed lang) code where you just pass around a base class( e.g. "Object") and explicitly cast up to what you want, there'd be no point in using that language.
If you're fighting typescript that much, then what's the point?
The point of using things like types is correctness that can be statically checked. Imagine writing java (or any static typed lang) code where you just pass around a base class( e.g. "Object") and explicitly cast up to what you want, there'd be no point in using that language.
> If you're fighting typescript that much, then what's the point?
Agreed - I find these "wrangling" situations to be uncommon, and roughly half of the time they happen because our code is bad and we need to change it. The other half - well, sure, it can be a pain in the ass, but there's no such thing as code so elegant that it never has some irritating high-effort corner cases. I'll take deterministic type wrangling over raw untyped JS.
Agreed - I find these "wrangling" situations to be uncommon, and roughly half of the time they happen because our code is bad and we need to change it. The other half - well, sure, it can be a pain in the ass, but there's no such thing as code so elegant that it never has some irritating high-effort corner cases. I'll take deterministic type wrangling over raw untyped JS.
Every time I’ve had to “wrangle typescript” it’s been converting old JS files where someone has done something that neither me nor typescript can work out what is going on.
Except that most code actually isn't passing around random unnamed objects of unknown type or contents. Their meaning and type are implied clearly enough in many if not most cases by their name and usage.
Hence, the downside is doing a lot of work to describe things we already know whilst making code less readable (or at least longer).
I'm still largely in favor of Typescript, I'm just suggesting to not misrepresent the situation of not having Typescript.
Hence, the downside is doing a lot of work to describe things we already know whilst making code less readable (or at least longer).
I'm still largely in favor of Typescript, I'm just suggesting to not misrepresent the situation of not having Typescript.
I've worked in that place.
(And ran.)
(And ran.)
I've been seeing a lot of talk about htmx but I've been blissfully ignoring it as I've been reasonably successfully using Turbo and Hotwire. This move is a sign for me to take a deeper look into htmx as a potential replacement in the future.
Does anyone happen to have any good resources bookmarked for replacing Hotwire / Turbo with htmx? I'm also open to hearing about other similar tools in the area.
Does anyone happen to have any good resources bookmarked for replacing Hotwire / Turbo with htmx? I'm also open to hearing about other similar tools in the area.
The analogy I like to use for this is JS is like your first car and TS is like your car ten or twenty years later. When you’re driving in your current car, fiddling with the settings, you might look back with nostalgia at your first car and how simple and fun it was and how free you felt. Then if you ever get an opportunity to drive that car or one like it again, you quickly realise that no, actually it was pretty shit, broke down more, didn’t warn you about things that needed checking or refilling and that it’s missing all the luxury comforts you’ve become accustomed to. Once you’re back in that banger you very quickly realise the higher end vehicle is infinitely better and you never want to go back to driving a heap of shit again.
> very quickly realise the higher end vehicle is infinitely better and you never want to go back to driving a heap of shit again.
I fixed our 2006 Saturn Ion lots of times and it runs very well. It's generally simple and the parts are relatively cheap.
I've been tempted to get a fancy Land Rover, Audi, BMW, Telsa. I want shiny things like lane positioning assistance, blind spot monitoring and even self-driving etc.
But they always seems to need a lot of maintenance, need fancy high grade fuels and when they break down, it's rarely fixable for the average person.
I fixed our 2006 Saturn Ion lots of times and it runs very well. It's generally simple and the parts are relatively cheap.
I've been tempted to get a fancy Land Rover, Audi, BMW, Telsa. I want shiny things like lane positioning assistance, blind spot monitoring and even self-driving etc.
But they always seems to need a lot of maintenance, need fancy high grade fuels and when they break down, it's rarely fixable for the average person.
You do make some valid points but I wouldn't want to work on any kind of large scale codebase that used Javascript over Typescript. Even working in a Typescript codebase of hundreds of thousands of lines I've seen poorly named functions returning data types you wouldn't expect and poorly named variables. I can only imagine the hell if it was a pure javascript codebase and the actual types these things were returning weren't defined somewhere and you had to rely on the debugger for everything or delve through the codebase. Now your IDE catches it before you even run the code. I suppose if we were trying to extend this to the analogy, it's more productive and economical for any company with a substantial fleet of vehicles to run the newer models than it is trying to keep the old ones on the road.
I've found the TypeScript tooling story to be a bit clunky (protip: use tsc --noEmit for type checking in CI, but don't use tsc for anything else).
But TypeScript the language is great – I spent 3+ years each working with C++ and Java, and TS's type system is much more expressive and useful.
I wish people would distinguish whether or not they object to the tooling, or the language.
But TypeScript the language is great – I spent 3+ years each working with C++ and Java, and TS's type system is much more expressive and useful.
I wish people would distinguish whether or not they object to the tooling, or the language.
What do you use for type checking in dev - tsserver? https://github.com/microsoft/TypeScript/wiki/Standalone-Serv...
Regarding this, it's a pity there's no officially maintained support for the language server protocol in TypeScript, and the last update from MS on the issue is from two years ago ("We've had personnel changes"): https://github.com/microsoft/TypeScript/issues/39459#issueco...
Regarding this, it's a pity there's no officially maintained support for the language server protocol in TypeScript, and the last update from MS on the issue is from two years ago ("We've had personnel changes"): https://github.com/microsoft/TypeScript/issues/39459#issueco...
Yeah I use LSP-typescript in Sublime Text, which uses typescript-language-server, which is backed by tsserver.
What’s wrong with tsc on local?
I think TypeScript is more useful for guiding the IDE than checking the types. And that might be enough value to adopt it.
It's just my feeling. But I don't feel like TS is preventing me to shoot my foot. The bugs that I write, even when the language doesn't support types, are rarely the kind that type checking would prevent.
It's just my feeling. But I don't feel like TS is preventing me to shoot my foot. The bugs that I write, even when the language doesn't support types, are rarely the kind that type checking would prevent.
I often find that types in typescript are bolted on and the whole thing gets pretty messy. I like typed languages like Java where the type system is more built into the language.
Typescript errors are also very annoying to read.
This is TS code - and I think it's crazy.
type DeepPartial<T> = { [P in keyof T]?: T[P] extends (infer U)[] ? DeepPartial<U>[] : T[P] extends ReadonlyArray<infer U> ? ReadonlyArray<DeepPartial<U>> : T[P] extends object ? DeepPartial<T[P]> : T[P]; };
Typescript errors are also very annoying to read.
This is TS code - and I think it's crazy.
type DeepPartial<T> = { [P in keyof T]?: T[P] extends (infer U)[] ? DeepPartial<U>[] : T[P] extends ReadonlyArray<infer U> ? ReadonlyArray<DeepPartial<U>> : T[P] extends object ? DeepPartial<T[P]> : T[P]; };
If seen a lot of code like this and I f.hate it. Devs try and be too clever. With great power... etc
Even if you don't like TS that much, nobody would have that much of a problem (IMHO) with having 'simple' types on function parameters or objects. It's not really that hard to understand that it helps the IDE let you know when you're missing a mandatory attribute or misspelled it. Attribute completion is nice. I love anything that makes me lazy.
However when something like the above generates a huge error which takes significant effort to debug and derails all the delicate logic in my head, I generally reach for my notebook of significant harsh swear words/insults to throw at TS. It makes Java full page exception errors trivial in comparison.
Back in the day when I was doing Java, it was pretty much like this and with a good IDE (like IntelliJ) it was awesome and I coded like a bat out of hell. You couldn't do all this fancy stuff of picking just the keys of types/interfaces, making them optional and changing the type something wierd. Madness.
The approach of TS preaches (AFAIK) is to generate derivative types from previous types/interfaces, so when you screw around with a type in the hierarchy (e.g. rename an attribute), child types know immediate that something is wrong and an error is thrown. You really can't do this with raw Javascript and for it to be picked up by the compiler.
I personally use TS now (most jobs require it) and I do see the benefits, but man can it be a PITA sometimes. (I just got through a painful process of using TS w/ d3 in a non trivial graph).
Even if you don't like TS that much, nobody would have that much of a problem (IMHO) with having 'simple' types on function parameters or objects. It's not really that hard to understand that it helps the IDE let you know when you're missing a mandatory attribute or misspelled it. Attribute completion is nice. I love anything that makes me lazy.
However when something like the above generates a huge error which takes significant effort to debug and derails all the delicate logic in my head, I generally reach for my notebook of significant harsh swear words/insults to throw at TS. It makes Java full page exception errors trivial in comparison.
Back in the day when I was doing Java, it was pretty much like this and with a good IDE (like IntelliJ) it was awesome and I coded like a bat out of hell. You couldn't do all this fancy stuff of picking just the keys of types/interfaces, making them optional and changing the type something wierd. Madness.
The approach of TS preaches (AFAIK) is to generate derivative types from previous types/interfaces, so when you screw around with a type in the hierarchy (e.g. rename an attribute), child types know immediate that something is wrong and an error is thrown. You really can't do this with raw Javascript and for it to be picked up by the compiler.
I personally use TS now (most jobs require it) and I do see the benefits, but man can it be a PITA sometimes. (I just got through a painful process of using TS w/ d3 in a non trivial graph).
That’s not good TypeScript but I’ll note that I’ve seen a ton of nasty Java where everything is declared as taking “object”, and they’re abusing ternary operators just as badly (I remember this dude who had an allergy to if statements even if his ternararies wrapped into more lines), and lots of errors caught & ignored to avoid the “inconvenience” of handling them.
This doesn’t mean that Java is a bad language, only that it can be used badly.
This doesn’t mean that Java is a bad language, only that it can be used badly.
Yes that's valid TypeScript, but is it good TypeScript? One should take a ternary nested that deep as a sign that refactoring is needed. You can write terrible code in any language, that doesn't make the language problematic.
>Yes that's valid TypeScript, but is it good TypeScript?
If the implication is that this code should be refactored, then how would you refactor it and why does this class of code show up across many different teams?
If the implication is that this code should be refactored, then how would you refactor it and why does this class of code show up across many different teams?
Some combination of:
* Javascript devs tend not to be good Typescript devs, and don't always know how to build tasteful or easy-to-type interfaces.
* ...or maybe they're perfectly fine Typescript devs, and they've made the deliberate choice to have a nasty type in order to have a particular interface. For better or for worse Typescript offers that flexibility.
* Types were added after the fact and it was deemed better to have some kind of gross type for the existing difficult-to-type interface than rebuild the interface and/or implementation.
* Javascript devs tend not to be good Typescript devs, and don't always know how to build tasteful or easy-to-type interfaces.
* ...or maybe they're perfectly fine Typescript devs, and they've made the deliberate choice to have a nasty type in order to have a particular interface. For better or for worse Typescript offers that flexibility.
* Types were added after the fact and it was deemed better to have some kind of gross type for the existing difficult-to-type interface than rebuild the interface and/or implementation.
I don't actually know off the top of my head how to refactor it - I've never had to write or deal with a type that complicated. It might actually be the best way of writing that specific type, in which case yes that kind of sucks, but I feel like it's probably not based on how hard it is to parse.
Agreed that terrible code can show up in any language. For some reason, I notice it more with TS. Here's a random example too (not saying this is terrible, just confusing to me):
https://github.com/prisma/prisma/blob/main/helpers/blaze/uti...
https://github.com/prisma/prisma/blob/main/helpers/blaze/uti...
But we can hide those utility types in a deep dark util.ts hole and never look at them ever again
Many people in the PR mentioned the complexity that Typescript brings. But wasn't it an over simplification from the language from the beginning?
I mean, in the context of JS 10 years ago, Typescript in indeed overly complex, but in the context of today's JS running servers and very complex apps at scale, it just seems sane to back up the code with types, just as most other languages would do..
In my opinion it's now a required complexity to build up a lib with some stability and a safe DX for contributors
I mean, in the context of JS 10 years ago, Typescript in indeed overly complex, but in the context of today's JS running servers and very complex apps at scale, it just seems sane to back up the code with types, just as most other languages would do..
In my opinion it's now a required complexity to build up a lib with some stability and a safe DX for contributors
[deleted]
No one could accuse DHH of being an amateur, and it's true that static typing is an obstacle if it's not a vehicle.
It took me years to "get on the other side" of typing, and wield it productively instead of battling against it. I have heard several developers express the same way about testing, ie when one learns to test first, one no longer resents the tests (or whoever mandates them). Resentment and frustration give way gratitude and elation--but admittedly, it takes more than "five minutes".
Static typing has a similar feel for me (although I am no expert): type-driven design often unfolds fantastically, easily, and beautifully. It has certainly replaced a few categories of unit test. Inability to appreciate static typing as a tool is, for most developers, a "skill issue." It certainly took me more than five years to come around to static typing, although as I explore it deeper (perhaps after another five years), I'll undoubtedly discover areas in which the emperor's showing a little skin.
Again, however, no one could accuse DHH of a skill issue. Perhaps he is looking out for the little guy? Perhaps he's simply invested in an alternate idiom. Perhaps he really is a whole five years of static typing grief ahead of us. I think that's certifiable.
It took me years to "get on the other side" of typing, and wield it productively instead of battling against it. I have heard several developers express the same way about testing, ie when one learns to test first, one no longer resents the tests (or whoever mandates them). Resentment and frustration give way gratitude and elation--but admittedly, it takes more than "five minutes".
Static typing has a similar feel for me (although I am no expert): type-driven design often unfolds fantastically, easily, and beautifully. It has certainly replaced a few categories of unit test. Inability to appreciate static typing as a tool is, for most developers, a "skill issue." It certainly took me more than five years to come around to static typing, although as I explore it deeper (perhaps after another five years), I'll undoubtedly discover areas in which the emperor's showing a little skin.
Again, however, no one could accuse DHH of a skill issue. Perhaps he is looking out for the little guy? Perhaps he's simply invested in an alternate idiom. Perhaps he really is a whole five years of static typing grief ahead of us. I think that's certifiable.
He does say that he started at 'hate it' and never left so it may just be a preference thing. I think it's fair that a maintainer makes choices that make the project easier to maintain (for them), but I wonder if it's really just that they picked up TS unwillingly and simply never really came around to it.
They sure do like to be contrarian.
The collective meltdown, bullying, pile-on and emotional responses over a team's decision to drop a layer of tooling is strange.
Yes, I get it, for most usecases, most people today prefer TS, but in the end, the team weighed their options and they made a decision they are happy with.
Open source, as strange as it sounds, doesn't mean that the maintainers need to ask for the approval of everybody who read some tweets and join the pile on.
For those who disagree with their decision and are actually affected, vote with your feet, and don't rely on anything hey or dhh related. If you don't have a choice but to keep using them and you hate this change, I feel your pain.
I don't know enough about turbo to know if it's a bad decision or not, but I don't mind people going against the grain. If people like that wouldn't exist, I'd still need to work with Scrum (in the end, how dare you challenge the collective wisdom that scrum is the greatest thing since slice bread).
They may succeed or fail, but at least they fail in their own terms and enjoy their work on their product with the language they like.
Yes, I get it, for most usecases, most people today prefer TS, but in the end, the team weighed their options and they made a decision they are happy with.
Open source, as strange as it sounds, doesn't mean that the maintainers need to ask for the approval of everybody who read some tweets and join the pile on.
For those who disagree with their decision and are actually affected, vote with your feet, and don't rely on anything hey or dhh related. If you don't have a choice but to keep using them and you hate this change, I feel your pain.
I don't know enough about turbo to know if it's a bad decision or not, but I don't mind people going against the grain. If people like that wouldn't exist, I'd still need to work with Scrum (in the end, how dare you challenge the collective wisdom that scrum is the greatest thing since slice bread).
They may succeed or fail, but at least they fail in their own terms and enjoy their work on their product with the language they like.
> The collective meltdown, bullying, pile-on and emotional responses over a team's decision to drop a layer of tooling is strange.
It should seem strange - that's not what's happening.
People are upset about the decision to drop a layer of tooling, yes. People are also upset about a rush job of ripping out that layer, losing information and deleting documentation. People are also upset about a total disregard of feedback and extremely quick decision merging. These are all very normal things to be upset about.
It should seem strange - that's not what's happening.
People are upset about the decision to drop a layer of tooling, yes. People are also upset about a rush job of ripping out that layer, losing information and deleting documentation. People are also upset about a total disregard of feedback and extremely quick decision merging. These are all very normal things to be upset about.
The majority of people complaining are not contributors to the project at all, or for the one or two I saw that are, had a handful of commits.
Just like in this thread -- lots of people whinging about how something they don't contribute to is built, by the team that builds it. Which is both obnoxious and arrogant.
Glance at the contributors page and you'll see who has earned the right to have an opinion on how turbo is built.
Just like in this thread -- lots of people whinging about how something they don't contribute to is built, by the team that builds it. Which is both obnoxious and arrogant.
Glance at the contributors page and you'll see who has earned the right to have an opinion on how turbo is built.
Not all contributors contribute code. There were also code contributors complaining. Further, there were project consumers complaining as the types were part of the project API previously.
>It should seem strange - that's not what's happening.
I just went through the thread and I classified 93% of the comments as snarky, editorial, and abrasive to the maintainers. The others are just memes.
Presumptuous is a word that comes to mind.
The majority of the commenters there have never contributed anything to the project (or any other project for that matter).
I just went through the thread and I classified 93% of the comments as snarky, editorial, and abrasive to the maintainers. The others are just memes.
Presumptuous is a word that comes to mind.
The majority of the commenters there have never contributed anything to the project (or any other project for that matter).
> I just went through the thread and I classified 93% of the comments as snarky, editorial, and abrasive to the maintainers. The others are just memes.
But, they're responding to the behavior and the intentions as much as the decision itself. That's my point. It's disingenuous and pretentious to insult the lot for simply reacting to the decision to remove a tool because that's not what they're reacting to, not entirely.
> The majority of the commenters there have never contributed anything to the project (or any other project for that matter).
Fair, but a totally separate point.
But, they're responding to the behavior and the intentions as much as the decision itself. That's my point. It's disingenuous and pretentious to insult the lot for simply reacting to the decision to remove a tool because that's not what they're reacting to, not entirely.
> The majority of the commenters there have never contributed anything to the project (or any other project for that matter).
Fair, but a totally separate point.
I think dropping Typescript the way they did was silly, but you are absolutely correct that they should be able to do so, even if it’s unpopular.
> letting the rest of us enjoy JavaScript in the glorious spirit it was originally designed
Pretty funny, considering one of Eich's regrets about JavaScript is allowing things like `1 == "1"`
Pretty funny, considering one of Eich's regrets about JavaScript is allowing things like `1 == "1"`
If "originally designed" refers to the ten-days-in-May Mocha then == on unlike type operands evaluated to false. I've told why this changed later many times, e.g., https://twitter.com/BrendanEich/status/1440088359473324036.
Typescript is divisive. People are passionate in loving it or hating it, not to forget a silent majority that never even tried it.
Typescript is totalitarian. It consumes you whole. It makes no sense to partially adapt it as its supposed benefits will then never materialize. The deeper you're in, the more motivated you'll get to go even deeper.
This is entirely opposite from writing unit tests. Everybody hates to do that, you'll never have coverage to match real world complexity and it easily breaks under time pressure. The more you try to get it to work, the more you hate it and just want to give up on it. Typescript is different, it has a point of no return.
That being said, we should check our passion. Tech discussions have a high degree of confirmation bias coming from a small very vocal minority. This same minority that would advance React, Tailwind, and similar choices as the one and only industry standard.
It's not representative of the wider developer community, most of which are silent. Nor is it representative of every use case one can build on the web, every project size, team size, etc.
As for DHH, it's an unsurprising move. He craves the simpler times we once knew, where web/front-end development wasn't such a hot mess. I think the general point has merit, as to whether the specific point of Typescript fits into that narrative, is debatable. Personally, I think project size/complexity and team size/skill levels are big factors.
Typescript is totalitarian. It consumes you whole. It makes no sense to partially adapt it as its supposed benefits will then never materialize. The deeper you're in, the more motivated you'll get to go even deeper.
This is entirely opposite from writing unit tests. Everybody hates to do that, you'll never have coverage to match real world complexity and it easily breaks under time pressure. The more you try to get it to work, the more you hate it and just want to give up on it. Typescript is different, it has a point of no return.
That being said, we should check our passion. Tech discussions have a high degree of confirmation bias coming from a small very vocal minority. This same minority that would advance React, Tailwind, and similar choices as the one and only industry standard.
It's not representative of the wider developer community, most of which are silent. Nor is it representative of every use case one can build on the web, every project size, team size, etc.
As for DHH, it's an unsurprising move. He craves the simpler times we once knew, where web/front-end development wasn't such a hot mess. I think the general point has merit, as to whether the specific point of Typescript fits into that narrative, is debatable. Personally, I think project size/complexity and team size/skill levels are big factors.
> He craves the simpler times we once knew, where web/front-end development wasn't such a hot mess.
I strongly disagree. Web/front-end development was always a hot mess. It's just that when we were using Perl to write CGI.pm pages, we didn't have good tooling to tell us all the terrible things we were doing.
Modern tooling just shines a light on our mistakes. It didn't make them for us. Those simpler times only existed in the sense that we were blissfully ignorant of our sins.
I strongly disagree. Web/front-end development was always a hot mess. It's just that when we were using Perl to write CGI.pm pages, we didn't have good tooling to tell us all the terrible things we were doing.
Modern tooling just shines a light on our mistakes. It didn't make them for us. Those simpler times only existed in the sense that we were blissfully ignorant of our sins.
I was looking at the bigger picture, and didn't clarify that point enough.
What I mean to say is that web development was more accessible during simpler times. People from all walks of life would develop websites, flash stuff, and even dynamic sites, i.e. LAMP. They could do that because it was simple enough to learn.
Front-end development as we typically do it today has turned into a hardcore engineering discipline of staggering complexity.
It is in fact so engineering-heavy that even within the world of professional front-end development it has caused a split where there's a "front of the front-end" (CSS, UX, accessibility) and a "back of the front-end" (the engineering part).
You may be able to justify every single tool, command line, pattern or best practice and it's not my point to talk you out of it. My point is to zoom out and consider this larger pattern.
What I mean to say is that web development was more accessible during simpler times. People from all walks of life would develop websites, flash stuff, and even dynamic sites, i.e. LAMP. They could do that because it was simple enough to learn.
Front-end development as we typically do it today has turned into a hardcore engineering discipline of staggering complexity.
It is in fact so engineering-heavy that even within the world of professional front-end development it has caused a split where there's a "front of the front-end" (CSS, UX, accessibility) and a "back of the front-end" (the engineering part).
You may be able to justify every single tool, command line, pattern or best practice and it's not my point to talk you out of it. My point is to zoom out and consider this larger pattern.
Those are very fair points! You use to be able to write a credible site with a text editor and an FTP client, but that's a long time gone.
(Bystanders, don't "correct" me with "technically you still can...", etc. I know. It's all just text, right? But the parent poster is absolutely right about the general state of things.)
(Bystanders, don't "correct" me with "technically you still can...", etc. I know. It's all just text, right? But the parent poster is absolutely right about the general state of things.)
Thanks for a reasonable discussion.
Whilst hobbyists can still use whatever they want, including simple options, I in particular empathize with those new to the field or looking to turn a hobby into a job.
You need to know React/Typescript/CLIs/Docker/Git/Unit testing/IDEs/CSS/5 million other things. Or there's simply not going to be a job for you at all.
So "just don't use it" doesn't apply.
On the upside, once you do master the unwarranted complexity, pay is great. Fiddling around with toys and a Frankenstein tech stack whilst continuing to produce outcomes with worse UX than 15 years ago is somehow richly rewarded. It paid for my quality of life so let's add some more "absolutely essential" tools.
Whilst hobbyists can still use whatever they want, including simple options, I in particular empathize with those new to the field or looking to turn a hobby into a job.
You need to know React/Typescript/CLIs/Docker/Git/Unit testing/IDEs/CSS/5 million other things. Or there's simply not going to be a job for you at all.
So "just don't use it" doesn't apply.
On the upside, once you do master the unwarranted complexity, pay is great. Fiddling around with toys and a Frankenstein tech stack whilst continuing to produce outcomes with worse UX than 15 years ago is somehow richly rewarded. It paid for my quality of life so let's add some more "absolutely essential" tools.
Regardless of if you like TS or not, merging this changeset without addressing a single concern/comment in less than 2 hours shows that obviously DHH doesn't give a shit about contributors.
Not to mention adding 0 comments or written documentation in places where the types were literally the only documentation on what the arguments should have been. (For example string literal typed arguments ('on' | 'off'), places where only certain types of elements were expected, etc)
If I were a contributor to this, this would be my last day as one.
Not to mention adding 0 comments or written documentation in places where the types were literally the only documentation on what the arguments should have been. (For example string literal typed arguments ('on' | 'off'), places where only certain types of elements were expected, etc)
If I were a contributor to this, this would be my last day as one.
I don’t know what to say except “DHH gonna be DHH”. Decades of experience shows this sort of thing is what you buy into when you build on 37signals code (which isn’t necessarily bad).
Talk about move fast and break things!
It's easy to hate typescript if you're trying to write it as javascript with types bolted on. All you'll see is restrictions and arcane complexity which exists solely to assuage the compiler. If you instead write types first and go from there, the value becomes evident really fast - and you avoid writing untypeable code which likely would've grown into a difficult to reason about api.
I'm a Rubyist at heart like DHH so I get not liking types, but after being involved in a pretty large Rust codebase where everything was typed and having my editor be able to know exactly what I'm trying to do in 99% of cases, I find it hard to go back to Ruby, especially if we're talking about a team setting where you're working with other devs. If I'm doing something solo I still prefer Ruby since I can just write the code and forget about it.
I've also had the pleasure of working on a JS-only project, and I would've killed to have typescript there. It was anyone's guess what any method call would be doing, what arguments were being passed around etc. I can't imagine working in a large JS codebase, especially with other contributors, without types to back you up.
I've also had the pleasure of working on a JS-only project, and I would've killed to have typescript there. It was anyone's guess what any method call would be doing, what arguments were being passed around etc. I can't imagine working in a large JS codebase, especially with other contributors, without types to back you up.
This is the correct move. A hot take I recently posted that has caused me zero issues over the past few years: [1].
[1] https://twitter.com/cheatcodetuts/status/1692256529628512667
[1] https://twitter.com/cheatcodetuts/status/1692256529628512667
Do you have multiple people collaborating with you? If I’m writing code that only I need to understand then yes, typescript may be overkill (though I prefer types even then), but working on any meaningful codebase without types is… challenging. Types aren’t that hard are they?
I have, yes. From a team perspective, there's zero technical difference between TypeScript types and a combination of default args and type checker functions. The same ends are achieved, but in a far less kludgy way that's overt. In the event a type checker is missing, it can be added/documented quickly with zero time wasted on trying to answer "what's the TypeScript way to do this?"
Types aren't the difficult part, it's TypeScript that's difficult. The documentation is a nightmare and in my experience I saw "any" types being used far too often (which literally defeats the purpose of using TypeScript).
Types aren't the difficult part, it's TypeScript that's difficult. The documentation is a nightmare and in my experience I saw "any" types being used far too often (which literally defeats the purpose of using TypeScript).
>there's zero technical difference between TypeScript types and a combination of default args and type checker functions
I may be missing something, but aren't your type checker functions called at runtime whereas Typescript would be doing static type checking at compile time?
I may be missing something, but aren't your type checker functions called at runtime whereas Typescript would be doing static type checking at compile time?
They are, but in practice there's little difference in the ends because you're getting the same feedback (did I pass the right type, yes or no). Like calling someone on a cell phone vs. a land line.
If the type of data you're passing around is erratic beyond development (where, just like TypeScript, a function-based approach illuminates incorrect data being passed around), you're writing bad code and TypeScript is nothing more than a crutch.
I expect most hardline TypeScript people to disagree, but type errors are the least of my concerns thanks to the above approach. It's not just an opinion; it's based on experience/evidence [1].
[1] https://github.com/cheatcode/joystick
If the type of data you're passing around is erratic beyond development (where, just like TypeScript, a function-based approach illuminates incorrect data being passed around), you're writing bad code and TypeScript is nothing more than a crutch.
I expect most hardline TypeScript people to disagree, but type errors are the least of my concerns thanks to the above approach. It's not just an opinion; it's based on experience/evidence [1].
[1] https://github.com/cheatcode/joystick
Fair enough if you have another way that works!
Remove TypeScript, change linting rules, remove Prettier, breaks all PRs ... seemingly with no discussion and merged within 2 hours of the PR.
Sounds like a project I'd stay away from.
With comments like "Also, TypeScript hurts to write. Good riddance."
What exactly is the problem here? Do we have too many developers who grew up on JavaScript and aren't seeing the benefits of static typing? Is a tiny compiler (transpiler) step on the front-end simply too much to ask?
I say this as a lead on an enterprise Angular project who used to loathe front-end development (for 20+ years). TypeScript has brought back some sanity.
Sounds like a project I'd stay away from.
With comments like "Also, TypeScript hurts to write. Good riddance."
What exactly is the problem here? Do we have too many developers who grew up on JavaScript and aren't seeing the benefits of static typing? Is a tiny compiler (transpiler) step on the front-end simply too much to ask?
I say this as a lead on an enterprise Angular project who used to loathe front-end development (for 20+ years). TypeScript has brought back some sanity.
I've written maybe a couple thousand lines of TypeScript. I'm an utter neophyte there. I didn't hate the experience, though.
I've written maybe a few hundred thousand lines of Python. I didn't use type annotations until recently because they didn't exist. My first forays into playing with them were painful: it revealed a whole lot of unfound bugs in my code. In most cases they were minor and probably wouldn't have caused a real-life problem. Fixing them was often challenging because changing a function frequently meant breaking an internal API and having to also tweak every bit of code that called it. And yet, I powered through it because typing found bugs that none of my tests had.
I'm not going to say that everyone who dislikes type annotations in Python (or TypeScript) writes crummy code. I will suggest that at least some of the people who complain that types make it harder to write a program are actually annoyed that it makes them write more-correct code.
I've written maybe a few hundred thousand lines of Python. I didn't use type annotations until recently because they didn't exist. My first forays into playing with them were painful: it revealed a whole lot of unfound bugs in my code. In most cases they were minor and probably wouldn't have caused a real-life problem. Fixing them was often challenging because changing a function frequently meant breaking an internal API and having to also tweak every bit of code that called it. And yet, I powered through it because typing found bugs that none of my tests had.
I'm not going to say that everyone who dislikes type annotations in Python (or TypeScript) writes crummy code. I will suggest that at least some of the people who complain that types make it harder to write a program are actually annoyed that it makes them write more-correct code.
> I will suggest that at least some of the people who complain that types make it harder to write a program are actually annoyed that it makes them write more-correct code.
I think this is the honest answer!
I think this is the honest answer!
I can relate to this when it comes to Python. Type annotations & mypy have undeniably caught bugs and forced me to write better & more correct Python. However, it's also true that I've felt a lot of frustration with them at times when I was nagged about something that was impossible, and fixing the mypy error felt like makework that didn't actually improve anything. I'd argue the result in those cases was worse.
So is it worth it in the end? Probably, and I'd use them in personal projects and run mypy as well, but I feel that the Python community could be taking it too far. Type annotations were supposed to be gradual opt in (and they still can be), but nowadays it doesn't feel that way, and while I appreciate the benefits brought by using them, I can't help lamenting what I see as a reduction of what I saw as the beauty of Python. Perhaps switching to a statically typed language is preferable to bolting on types to a dynamic language.
So is it worth it in the end? Probably, and I'd use them in personal projects and run mypy as well, but I feel that the Python community could be taking it too far. Type annotations were supposed to be gradual opt in (and they still can be), but nowadays it doesn't feel that way, and while I appreciate the benefits brought by using them, I can't help lamenting what I see as a reduction of what I saw as the beauty of Python. Perhaps switching to a statically typed language is preferable to bolting on types to a dynamic language.
That’s valid. I’m pretty rigorous about typing new code, but don’t make any heroic efforts to go back and retrofit old, well-tested code. `mypy --check-untyped-defs` gives a lot of bang for the buck for checking existing code without going all-in.
I’m also OK with liberal use of Any for things like returning JSON fetched from an API. How should I know what it’s going to return this time? I’ll deal with that mess in the function that parses those results, not the one fetching them.
One way I think typing has made my code better is that I tend to use more dataclasses and namedtuples now. It’s easier to say List[Person] than List[dict[str,Union[str,float,int,Email]] etc. That also makes IDEs a lot happier because now I can say Person.bir and tab-complete it to .birthday. It’s a little more effort to set up, but a lot nicer in the long run.
But again, I find that fun and productive on new code. Darned if I wanna jump through those hoops on stuff that’s been running in production for a decade. I’m more of a fan of “type it as you touch it”.
I’m also OK with liberal use of Any for things like returning JSON fetched from an API. How should I know what it’s going to return this time? I’ll deal with that mess in the function that parses those results, not the one fetching them.
One way I think typing has made my code better is that I tend to use more dataclasses and namedtuples now. It’s easier to say List[Person] than List[dict[str,Union[str,float,int,Email]] etc. That also makes IDEs a lot happier because now I can say Person.bir and tab-complete it to .birthday. It’s a little more effort to set up, but a lot nicer in the long run.
But again, I find that fun and productive on new code. Darned if I wanna jump through those hoops on stuff that’s been running in production for a decade. I’m more of a fan of “type it as you touch it”.
I grew up on JavaScript and usually enjoy it, and also adopted TypeScript and usually get along with it.
I'd find it difficult to contribute to an enterprise Angular project without static typing, and definitely found the refactor to static typing/react from a legacy Angular 1.x project quite challenging. But, I don't know that it's ever truly helped me move faster, and does often get in the way. It's a formality, and formality adds latency. When you go out for dinner, you can go casually and all you have is transit time. When you go out formally, you need to dress up, put on a tie perhaps, do your makeup, hair, all this extra stuff. You might find it's worth it, maybe you enjoy the whole production, and otherwise they'd not let you into a fancy place. Likewise with static typing, you might get the benefit if someone changing your code or integrating finds that the path is more clear because of the type hints. Maybe you introduce less bugs because you've been alerted to missing null checks. But not necessarily, you trade time for a hopefully more consistent experience.
I'd find it difficult to contribute to an enterprise Angular project without static typing, and definitely found the refactor to static typing/react from a legacy Angular 1.x project quite challenging. But, I don't know that it's ever truly helped me move faster, and does often get in the way. It's a formality, and formality adds latency. When you go out for dinner, you can go casually and all you have is transit time. When you go out formally, you need to dress up, put on a tie perhaps, do your makeup, hair, all this extra stuff. You might find it's worth it, maybe you enjoy the whole production, and otherwise they'd not let you into a fancy place. Likewise with static typing, you might get the benefit if someone changing your code or integrating finds that the path is more clear because of the type hints. Maybe you introduce less bugs because you've been alerted to missing null checks. But not necessarily, you trade time for a hopefully more consistent experience.
> But, I don't know that it's ever truly helped me move faster
It's incredibly helpful to move fast on large projects.
It's not about missing null checks and other simple things. If you change code in one place, that happens to affect code in some far off other place, it won't compile. In JavaScript you would end up with a runtime error and be wondering what is going on. With TypeScript the compiler will tell you right away what the issue is.
I found it incredibly helpful today when we had to completely refactor an Angular service method. I wanted to remove a parameter. It was called in various places, and all I had to do was run the compiler and get back "can't do it, go check XyzComponent.ts line 51" and give me a link to it. I'd click, go right to it, change the call site and repeat. After a few minutes it was compiling again and it was clean.
Sure, you can change function signatures in JavaScript and go and manually find all the places that function is called, but what if you miss one? A really good IDE can probably figure it out, much like they can sort of handle intellisense for raw JavaScript code. But with the compiler you are ensured that you got them all and everything checks out.
That's just one simple example.
It's incredibly helpful to move fast on large projects.
It's not about missing null checks and other simple things. If you change code in one place, that happens to affect code in some far off other place, it won't compile. In JavaScript you would end up with a runtime error and be wondering what is going on. With TypeScript the compiler will tell you right away what the issue is.
I found it incredibly helpful today when we had to completely refactor an Angular service method. I wanted to remove a parameter. It was called in various places, and all I had to do was run the compiler and get back "can't do it, go check XyzComponent.ts line 51" and give me a link to it. I'd click, go right to it, change the call site and repeat. After a few minutes it was compiling again and it was clean.
Sure, you can change function signatures in JavaScript and go and manually find all the places that function is called, but what if you miss one? A really good IDE can probably figure it out, much like they can sort of handle intellisense for raw JavaScript code. But with the compiler you are ensured that you got them all and everything checks out.
That's just one simple example.
Ya that's sort of what I meant by the rest of the comment, and I agree, in theory, but haven't personally encountered this because I've never come onto a project that's already had a well-established TS implementation. I'm always doing the implementation, and then lose my job before getting to the point where the benefits were realized, and it's quite a slow path to getting to a place where the full codebase of sufficient size is typed, simply because most huge cosebases have evolved over time and aren't completely JS or TS.
Thinking about this one step further, I've actually never revisited my own code on any project I've been employed to work on, it all might as well have never existed, and the only difference would be a lack of perspective that's changed as a result of doing some incremental feature work. Way she goes I guess, but I still agree.
Thinking about this one step further, I've actually never revisited my own code on any project I've been employed to work on, it all might as well have never existed, and the only difference would be a lack of perspective that's changed as a result of doing some incremental feature work. Way she goes I guess, but I still agree.
> Do we have too many developers who grew up on JavaScript and aren't seeing the benefits of static typing?
This was often the case ~10 years ago when TS was first introduced. A lot of JS developers at the time liked that static type checking was impossible.
This was often the case ~10 years ago when TS was first introduced. A lot of JS developers at the time liked that static type checking was impossible.
On the contrary. Most Rails apps with Turbo and Stimulus enabled only need a sprinkle of JS. It's so minuscule that you don't even need an IDE, even less TS either on the client or the library side. Thus, this PR both makes sense and most users won't even notice something changed. So the reasoning is good.
I see much hate on DHH for doing this, but I sincerely support him on many levels. And I am glad someone was bold enough to do this so publicly. Go team JS!
I see much hate on DHH for doing this, but I sincerely support him on many levels. And I am glad someone was bold enough to do this so publicly. Go team JS!
I've had to deal with a couple other unilateral decisions that DHH drove into the Rails ecosystem (e.g. getting rid of Webpacker) and I think that staying away from his projects is a good idea.
I just can’t imagine an organisation taking a project that has DHH part of it seriously. You’d never know whether something you’ve vested engineering time into might just all of sudden just do a huge 180 and decide the tool your using should completely change
[deleted]
The key thing from David's blog post:
> things that are hard become `any`.
It's a hard problem to solve.
TypeScript excels at informing IDE's and developers. Typing improves my ability to understand APIs both as a library user and contributor. So I see the benefit exceeds the issues of TypeScript.
A better approach would be a more gradual. Perhaps keep the .ts files (or at least develop .d.ts files) for the public API and main components.
> things that are hard become `any`.
It's a hard problem to solve.
TypeScript excels at informing IDE's and developers. Typing improves my ability to understand APIs both as a library user and contributor. So I see the benefit exceeds the issues of TypeScript.
A better approach would be a more gradual. Perhaps keep the .ts files (or at least develop .d.ts files) for the public API and main components.
It would be interesting to track the bug rate after this commit and compare it to the bug rate in the Typescript version of the code base.
I expect they have a very large unit/integration test suite. Rails was the first (or very early pioneers) of doing TDD.
A very cursory internet search shows that your history is entirely wrong:
https://agileforall.com/history-of-tdd-as-told-in-quotes/
Djikstra proposed the idea in the 1970s. Rails did not in any way pioneer TDD. They were very vocal about it but “[stood] on the shoulders of giants.”
https://agileforall.com/history-of-tdd-as-told-in-quotes/
Djikstra proposed the idea in the 1970s. Rails did not in any way pioneer TDD. They were very vocal about it but “[stood] on the shoulders of giants.”
Sure, everything could probably be tracked back to the good golden years, but who was really doing TDD before Rails?
I was doing Java back (during Kent Beck days of XP etc) and although I had heard of JUnit (and even heard Kent Beck preach about this at a conference) and it sounded cool, no team or company I knew was using it seriously.
It's only when Rails came around where if (I believe if memory serves me right) the default controller/views generators created tests automatically. Ruby being a dynamic language and no compile step, you couldn't prove correctness before running it, meant you were skating on thin ice if you didn't write tests.
I was doing Java back (during Kent Beck days of XP etc) and although I had heard of JUnit (and even heard Kent Beck preach about this at a conference) and it sounded cool, no team or company I knew was using it seriously.
It's only when Rails came around where if (I believe if memory serves me right) the default controller/views generators created tests automatically. Ruby being a dynamic language and no compile step, you couldn't prove correctness before running it, meant you were skating on thin ice if you didn't write tests.
> “[stood] on the shoulders of giants.”
That's pretty much a given.
I know someone people that worked at Xerox (when Steve Jobs visited) and they pretty much invented everything. lol.
I've been told stories that pretty much technology after Xerox is a derivative from that time. Sure, I take that with a pinch of salt, but I half/mostly believe it.
That's pretty much a given.
I know someone people that worked at Xerox (when Steve Jobs visited) and they pretty much invented everything. lol.
I've been told stories that pretty much technology after Xerox is a derivative from that time. Sure, I take that with a pinch of salt, but I half/mostly believe it.
Associated blog post:
https://world.hey.com/dhh/turbo-8-is-dropping-typescript-701...
https://world.hey.com/dhh/turbo-8-is-dropping-typescript-701...
[deleted]
[deleted]
Another bad decision from the desk of DHH. I'm glad he's actively ruining his projects – it's time for people to move onto better software.
It's spiteful comments like this that actually convince me he's making great bold decisions
So as a fanboy, when I read things like this I try my darnedest to have empathy and try to understand it from their point of view. And I’m just really struggling to in this case.
I get that it adds some complexity. But what are you actually getting without it? It’s not like types go away. They don’t. They just become implicit. It takes something a computer is really good at, and shoves it into your brain. And as many point out: the types are, more than anything, documentation.
But beyond any of that (and I feel this is the most important lesson): when there’s like a 100:1 ratio in favour of something, you’re probably wrong. Not always. But probably. And it’s your ball. You can take it and go home if you want. People can fork. But sometimes you need to, at best, say, “I simply do not understand you people, but you’re the overwhelming majority, so whether I like it or not, I need to leave things as-is.”