4 ms·

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 pr

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.

Veuxdo 3y ago
> 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.
brailsafe 3y ago
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.
- EMM_386 3y ago
  > 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.
  - brailsafe 3y ago
    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.
mplewis 3y ago
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.
- aranw 3y ago
  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
bestest 3y ago
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!
kstrauser 3y ago
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.
- sibeliuss 3y ago
  > 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!
- happyraul 3y ago
  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.
  - kstrauser 3y ago
deleted 3y ago
[deleted]

Veuxdo 3y ago

> 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.

brailsafe 3y ago

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.

EMM_386 3y ago
> 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.
- brailsafe 3y ago
  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.

mplewis 3y ago

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.

aranw 3y ago
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

bestest 3y ago

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!

kstrauser 3y ago

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.

sibeliuss 3y ago
> 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!
happyraul 3y ago
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.
- kstrauser 3y ago

deleted 3y ago

[deleted]