6 ms·

That PR is great. Not only do they get rid of TypeScript, they get rid of prettier and some gratuitous trailing commas. https://github.com/hotwired/turbo/pull/9

That PR is great. Not only do they get rid of TypeScript, they get rid of prettier and some gratuitous trailing commas. https://github.com/hotwired/turbo/pull/971/files#diff-865b8f8ec486a7b449d8d47d9666c452d234fab19927dc49af9439d5d5b00744L172 https://github.com/hotwired/turbo/pull/971/files#diff-865b8f... I’m not joking. I prefer the after. Edit: thanks. Yes, commas, not comments.

lofenfew 2y ago
s/ent/a
vallode 2y ago
I could not disagree more, but I am obviously open to it being a personal preference. I've spent months updating JavaScript codebases that are between 3 and 5 years old, most of them written with vanilla JavaScript. A _few_ of them were written with TypeScript at least partially and those files were the least mentally taxing to upgrade. Some of the codebases had tests, a good chunk of which could (and were) eliminated simply by using TSC as part of the build process. I think allowing the compiler and tooling like prettier to make choices for you leaves more space for you to think about the problem, not the myriad of problems _around_ it.
Shacklz 2y ago
Funny, I have exactly the opposite feelings. I've worked on dynamically typed code-bases in the past, and also on code-bases without formatters like prettier... and I'm not going back there. So many odd bugs can be avoided simply by taking a little bit of time and declaring some types. It doesn't have to be a super fancy type-system (I actually prefer if it isn't), but I really want to know whether something is expected to be a string or a number, or what properties an object can be expected to have, or what values a literal can accept, and so on. It's just so frustratingly time-consuming to figure out in hindsight. And all for some person's odd perception of simplicity. Same for formatters - all the squabbling over some personal preferences on how code should be formatted. Hell no. Let's install some opinionated formatter and let it do its job, I want to tackle more interesting problems than yet another narrow-minded discussion about necessity of semicolons, placement of whitespace or line-length. I'm at a point where I straight-up refuse to work with people who prefer to work that way; or at least require them to be a few departments away from me. They can be programming gods; if they can't be arsed to type their code so I can immediately grok it, they can program elsewhere.
- n144q 2y ago
  Same. I sometimes write TypeScript for 2 hours straight without actually running the code or any unit test, and it would just work -- the return value is exactly what you want. I don't think I can do that for JavaScript for more than 15 minutes even though they are the "same language".
PittleyDunkin 2y ago
What's the benefit of removing the explicit typing? It strikes me as hamstringing readability of the code. This just feels like giving up and calling the status quo "beautiful" or something.
- bnetd 2y ago
  To reinvent it.
  - benatkin 2y ago
    People tried to argue that in the PR, suggesting to change variable names. This one: https://github.com/hotwired/turbo/pull/971/files#r1317386731 https://github.com/hotwired/turbo/pull/971/files#r1317386731 > function buildFormData(formElement: HTMLFormElement, submitter?: HTMLElement): FormData { > It might be useful to know that submitter is optional argument here. > How would one express that? The variable now needs to be renamed? And two lines later: > const name = submitter?.getAttribute("name") It's already easy to see that submitter is optional.
    - lelandbatey 2y ago
      Only easy to see that it's optional if you read the source code vs. looking at the auto definition in your IDE/in autogenerated documentation.
    - seanwilson 2y ago
      > It's already easy to see that submitter is optional. Why force yourself to read inside function implementations like this for every function you might use when fool-proof automated assistance is right there? What if the function was tens of lines long? What if the optional value only appeared inside a chain of 5 nested functions? How would you easily fix/update your code if the value isn't optional now but got changed to be optional in the future? Manual effort like this is error-prone, not scalable, and a huge distraction. Why would avoiding type annotations be worth this?
      - 2y ago
superb_dev 2y ago
Even with the find/replace errors that seemingly got merged? This PR feels like it was so rushed
madeofpalk 2y ago
I can't imagine caring that much about trailing commas. The point of a tool like prettier is to not sweat such irrelevant details.
- slooonz 2y ago
  Trailing commas actually have an important role. Let’s say you have some code : const foo = { x: 1, y: 2, }; and you want to add a field : const foo = { x: 1, y: 2, z: 3, }; Without trailing commas, the diff is - y: 2 + y: 2, + z: 3 With trailing commas : + z: 3, The second diff is actually much clearer at what’s happening. This is why it irritates me when people forget the trailing comma. It’s not a problem in the moment. But I know it will be a small but avoidable cognitive burden on the next PR (wait, why did "y" changed ? Oh, right, it didn’t).
  - fire_lake 2y ago
    Maybe diff should change to suit programs, rather than programs change to suit diff.
    - benatkin 2y ago
      Indeed. That’s why prettier ain’t pretty.
    - slooonz 2y ago
      You want diff to know the syntax and semantics of every programming language out there ?
      - benatkin 2y ago
        It would be like a syntax highlighter. It’s doable.
        slooonz 2y ago
        But diff does not exists in a vacuum. It would need to be integrated to IDEs, editor, merge tools, PR tools. You now have to have `patch` understand and depend on the details of the syntax of your language. In a way that may break between different versions of diff and patch. Not even starting with variants of a language, different interpretations of how to handle the preprocessor/macros system, different editions of the same language. All that, just to not have to add a trailing comma ?
motorest 2y ago
> I’m not joking. I prefer the after. Everyone likes the simplicity that comes with removing guardrails, but when easily preventable problems happen that's glanced over as an unavoidable fact of life.
- knubie 2y ago
  > but when easily preventable problems happen easily preventable is doing a lot of work here. This is assuming the types are already written and never need to be maintained. How often does the type checker catch a problem with the code vs the type definitions themselves?
  - seanwilson 2y ago
    > How often does the type checker catch a problem with the code vs the type definitions themselves? All the time? I've worked on code bases with multiple people without types, and whenever there's a place that can produce e.g. "string or undefined" like when a key might not be found in a collection, it produces edge cases everywhere that don't get noticed outside of the happy path, including after the code has been merged. You're forced to simulate in your head all the code paths, and remember which values might be optional which is error-prone, isn't scalable and eats up brain cycles. Even typos like `object.detail.name` vs `object.details.name` cause runtime errors, or calling a function with the wrong number of arguments or in the wrong order, some of the most trivial bugs you can think of. I don't understand how someone can dislike writing type annotations so much that they're happy having their time wasted like this when automated assistance is right there. To me, it's like not wanting to use a spellchecker when writing an article, or opting out of syntax checking code before it's ran. I get that problems with type definitions can be frustrating but it's better than runtime errors (having to write more tests isn't better either), and often flags actual bugs, potential future bugs ("what if this was undefined sometimes?"), or overly dynamic code that's hard to reason about (e.g. conditionally adding/removing fields from objects, or having a field that changes type between string/array/undefined vs using an array of strings instead). I'd love a counter example here - often the examples I see has overly dynamic code because the coder hasn't had a strong incentive to avoid such code before. As in, I write type checker friendly code so I can benefit from type checking. 90% of type annotation stuff I work with is mundane and simple (e.g. strings, numbers, arrays, something optional, object with basic fields) and is well worth the minimal effort. The more complex stuff isn't needed often, usually optional, and gives you protection from tricky bugs too.

lofenfew 2y ago

s/ent/a

vallode 2y ago

I could not disagree more, but I am obviously open to it being a personal preference. I've spent months updating JavaScript codebases that are between 3 and 5 years old, most of them written with vanilla JavaScript. A _few_ of them were written with TypeScript at least partially and those files were the least mentally taxing to upgrade. Some of the codebases had tests, a good chunk of which could (and were) eliminated simply by using TSC as part of the build process. I think allowing the compiler and tooling like prettier to make choices for you leaves more space for you to think about the problem, not the myriad of problems _around_ it.

Shacklz 2y ago

Funny, I have exactly the opposite feelings. I've worked on dynamically typed code-bases in the past, and also on code-bases without formatters like prettier... and I'm not going back there. So many odd bugs can be avoided simply by taking a little bit of time and declaring some types. It doesn't have to be a super fancy type-system (I actually prefer if it isn't), but I really want to know whether something is expected to be a string or a number, or what properties an object can be expected to have, or what values a literal can accept, and so on. It's just so frustratingly time-consuming to figure out in hindsight. And all for some person's odd perception of simplicity. Same for formatters - all the squabbling over some personal preferences on how code should be formatted. Hell no. Let's install some opinionated formatter and let it do its job, I want to tackle more interesting problems than yet another narrow-minded discussion about necessity of semicolons, placement of whitespace or line-length. I'm at a point where I straight-up refuse to work with people who prefer to work that way; or at least require them to be a few departments away from me. They can be programming gods; if they can't be arsed to type their code so I can immediately grok it, they can program elsewhere.

n144q 2y ago
Same. I sometimes write TypeScript for 2 hours straight without actually running the code or any unit test, and it would just work -- the return value is exactly what you want. I don't think I can do that for JavaScript for more than 15 minutes even though they are the "same language".

PittleyDunkin 2y ago

What's the benefit of removing the explicit typing? It strikes me as hamstringing readability of the code. This just feels like giving up and calling the status quo "beautiful" or something.

bnetd 2y ago
To reinvent it.
- benatkin 2y ago
  People tried to argue that in the PR, suggesting to change variable names. This one: https://github.com/hotwired/turbo/pull/971/files#r1317386731 https://github.com/hotwired/turbo/pull/971/files#r1317386731 > function buildFormData(formElement: HTMLFormElement, submitter?: HTMLElement): FormData { > It might be useful to know that submitter is optional argument here. > How would one express that? The variable now needs to be renamed? And two lines later: > const name = submitter?.getAttribute("name") It's already easy to see that submitter is optional.
  - lelandbatey 2y ago
    Only easy to see that it's optional if you read the source code vs. looking at the auto definition in your IDE/in autogenerated documentation.
  - seanwilson 2y ago
    > It's already easy to see that submitter is optional. Why force yourself to read inside function implementations like this for every function you might use when fool-proof automated assistance is right there? What if the function was tens of lines long? What if the optional value only appeared inside a chain of 5 nested functions? How would you easily fix/update your code if the value isn't optional now but got changed to be optional in the future? Manual effort like this is error-prone, not scalable, and a huge distraction. Why would avoiding type annotations be worth this?
    - 2y ago

superb_dev 2y ago

Even with the find/replace errors that seemingly got merged? This PR feels like it was so rushed

madeofpalk 2y ago

I can't imagine caring that much about trailing commas. The point of a tool like prettier is to not sweat such irrelevant details.

slooonz 2y ago
Trailing commas actually have an important role. Let’s say you have some code : const foo = { x: 1, y: 2, }; and you want to add a field : const foo = { x: 1, y: 2, z: 3, }; Without trailing commas, the diff is - y: 2 + y: 2, + z: 3 With trailing commas : + z: 3, The second diff is actually much clearer at what’s happening. This is why it irritates me when people forget the trailing comma. It’s not a problem in the moment. But I know it will be a small but avoidable cognitive burden on the next PR (wait, why did "y" changed ? Oh, right, it didn’t).
- fire_lake 2y ago
  Maybe diff should change to suit programs, rather than programs change to suit diff.
  - benatkin 2y ago
    Indeed. That’s why prettier ain’t pretty.
  - slooonz 2y ago
    You want diff to know the syntax and semantics of every programming language out there ?
    - benatkin 2y ago
      It would be like a syntax highlighter. It’s doable.
      - slooonz 2y ago
        But diff does not exists in a vacuum. It would need to be integrated to IDEs, editor, merge tools, PR tools. You now have to have `patch` understand and depend on the details of the syntax of your language. In a way that may break between different versions of diff and patch. Not even starting with variants of a language, different interpretations of how to handle the preprocessor/macros system, different editions of the same language. All that, just to not have to add a trailing comma ?

motorest 2y ago

> I’m not joking. I prefer the after. Everyone likes the simplicity that comes with removing guardrails, but when easily preventable problems happen that's glanced over as an unavoidable fact of life.

knubie 2y ago
> but when easily preventable problems happen easily preventable is doing a lot of work here. This is assuming the types are already written and never need to be maintained. How often does the type checker catch a problem with the code vs the type definitions themselves?
- seanwilson 2y ago
  > How often does the type checker catch a problem with the code vs the type definitions themselves? All the time? I've worked on code bases with multiple people without types, and whenever there's a place that can produce e.g. "string or undefined" like when a key might not be found in a collection, it produces edge cases everywhere that don't get noticed outside of the happy path, including after the code has been merged. You're forced to simulate in your head all the code paths, and remember which values might be optional which is error-prone, isn't scalable and eats up brain cycles. Even typos like `object.detail.name` vs `object.details.name` cause runtime errors, or calling a function with the wrong number of arguments or in the wrong order, some of the most trivial bugs you can think of. I don't understand how someone can dislike writing type annotations so much that they're happy having their time wasted like this when automated assistance is right there. To me, it's like not wanting to use a spellchecker when writing an article, or opting out of syntax checking code before it's ran. I get that problems with type definitions can be frustrating but it's better than runtime errors (having to write more tests isn't better either), and often flags actual bugs, potential future bugs ("what if this was undefined sometimes?"), or overly dynamic code that's hard to reason about (e.g. conditionally adding/removing fields from objects, or having a field that changes type between string/array/undefined vs using an array of strings instead). I'd love a counter example here - often the examples I see has overly dynamic code because the coder hasn't had a strong incentive to avoid such code before. As in, I write type checker friendly code so I can benefit from type checking. 90% of type annotation stuff I work with is mundane and simple (e.g. strings, numbers, arrays, something optional, object with basic fields) and is well worth the minimal effort. The more complex stuff isn't needed often, usually optional, and gives you protection from tricky bugs too.