What Typescript drama is there? It’s fantastic. It’s been an industry standard for years. In my anecdotal experience the only people that hate it are juniors who did pure JS at their bootcamp and seniors that have refused to learn anything for the last 5 years.
DHH (guy who founded Ruby on Rails) ripped typescript out of a supporting library and swapped it for JavaScript. He did it in his typical fashion of not allowing discussion and being a dick (PR only open for a couple hours and then merged disregarding all the negative feedback about the change) . So people are mad at him again.
He does stupid shit like this all the time because he’s a fucking knob.
RoR will always have a special place in my heart, but yeah… DHH sure does have opinions. What possible justification is there for removing it when it’s already there? Guess someone could just shift the types out to DT.
Edit:
So I read his blog post about it. He’s dropping it because he just doesn’t like it and he’s allowed to not like it. Okay then 🤷
You only have to read the PR comments with people asking how you know if something is optional when there is absolutely zero jsdoc to know it was idiotic.
While you may compile dialects into it, you still have to accept the fact that running code in the browser means running JavaScript. So being able to write that, free of any tooling, and free of any strong typing, is a blessing under the circumstances.
By his logic, JS linters are bad because they’re tooling that restricts your access to all of Javascript. But linters mean you don’t have to read PRs with a fine tooth comb to make sure there’s no footguns like using == instead of ===.
Also, you could use that same logic to advocate for writing JVM bytecode directly instead of Java/Kotlin/Scala/Clojure/etc.
The question is really whether tooling pays its way in terms of lower bug rates, code that’s easier for coworkers to read, and code that’s easier to reason about.
Some people think better with typing information explicitly written out. Some people don’t. In my opinion it is a creativity thing. Some people like to make art that is photo realistic, some people like to make abstract art.
I understand both viewpoints. In my free time I vastly prefer late bound, dynamically types languages with robust reflection engineers built into their interpreters. For work, I heavily prefer late bound, strictly typed with reflection optional or minimal.
I think that’s fine if that’s how you like to work on your own, but I’d challenge anyone to do that and write better documentation while also getting a team or whole business to do the same. A huge strength of TS is that it gives people no choice but to document their work.
I didn’t say JavaScript… and I certainly wouldn’t choose TS for a personal project because I personally feel that its organization is terrible but I would choose TS over vanilla js for work projects because it does produce better group work and is easier to maintain long term because of the structure imposed on it.
TS is amazingly powerful when it comes to refactoring. I swear it practically writes itself. Half the time by the time I fix all the compiler errors the refactoring is done. I barely need to think about it which means I can spend more time thinking about the best architecture. When people say they don’t see how TS makes you more productive it just makes me think they never refactor their code.
Svelte decided to ditch it because it became impractical due to the compilation step slowing down development and making debugging their compiler harder. I think for libraries it makes sense to go the jsdoc way as long as consumers can choose typescript.
For what? If they took it away, the source code would still be there if someone wanted to fork it. Not to mention removing TypeScript from an application is relatively trivial.
They’re not that dumb, to just pull it completely. That would obviously result in a successful fork.
Companies usually start with e.g. the BUSL, so source-available but proprietary restrictions.
For TypeScript/Microsoft, I could imagine some variation of their EEE playbook.
But really, the whole point of avoiding Microsoft et al, is that I don’t want to think about, how they could fuck this whole thing up. They’ve proven quite creative in this regard for as long as they’ve existed.
I feel like there’s no typescript drama, just JavaScript drama. Things are pretty happy in the TS community. I’ve been writing js code since it literally first came out. I’m definitely no js hater. In the early days js code bases quickly turned to spaghetti code, but I genuinely think the js community has done miracles turning what was essentially a super simplistic toy language into a seriously good production quality language. I’ve seen first hand how much work has gone into it, and while most of the js community has been great with embracing change for the better, there’s always been the niche of detractors against any change that adds complexity even when it makes coding safer and more productive.
I’ve always had a love hate relationship with JavaScript, but with typescript it’s really been just straight up love. Pretty much all the trouble I have with typescript has been due to external libraries that use types lazily or incorrectly, and even then there are solutions to add safety to your own codebase. Sometimes I run into some trouble with the type system itself, but it’s pretty much always because I’m doing something really complicated that would be hard in any type system. I’ve been working with typescript for years now and my code bases are some of the most solid ones in my company. Typescript is really safe as long as you’re actually using it and not telling the compiler to ignore types through using any or making unsafe assertions.
It makes no difference to me if other people prefer JavaScript. Any important js library will get ts support anyways through definitely typed, and if a library is so sloppy it can’t be typed well then it’s not a good library to use anyways. Having people proudly announce they only want to use JavaScript is also great for hiring. It easily tips me off on who not to hire.
What Typescript drama is there? It’s fantastic. It’s been an industry standard for years. In my anecdotal experience the only people that hate it are juniors who did pure JS at their bootcamp and seniors that have refused to learn anything for the last 5 years.
DHH (guy who founded Ruby on Rails) ripped typescript out of a supporting library and swapped it for JavaScript. He did it in his typical fashion of not allowing discussion and being a dick (PR only open for a couple hours and then merged disregarding all the negative feedback about the change) . So people are mad at him again.
He does stupid shit like this all the time because he’s a fucking knob.
RoR will always have a special place in my heart, but yeah… DHH sure does have opinions. What possible justification is there for removing it when it’s already there? Guess someone could just shift the types out to DT.
Edit: So I read his blog post about it. He’s dropping it because he just doesn’t like it and he’s allowed to not like it. Okay then 🤷
His blog to me sounds like he did it because it was too difficult for him to understand a few errors. Says it all.
I wasn’t going to say it, but yes, 100% 😂
You only have to read the PR comments with people asking how you know if something is optional when there is absolutely zero jsdoc to know it was idiotic.
From his blog post:
By his logic, JS linters are bad because they’re tooling that restricts your access to all of Javascript. But linters mean you don’t have to read PRs with a fine tooth comb to make sure there’s no footguns like using == instead of ===.
Also, you could use that same logic to advocate for writing JVM bytecode directly instead of Java/Kotlin/Scala/Clojure/etc.
The question is really whether tooling pays its way in terms of lower bug rates, code that’s easier for coworkers to read, and code that’s easier to reason about.
As a general rule, if DHH says something, the opposite probably has some true merits.
or people used to work alone never having to go back to their code (e. g. bad consultancy jobs)
Even alone I find it indespensible. I find it’s mainly useful for writing code correctly the first time around.
Some people think better with typing information explicitly written out. Some people don’t. In my opinion it is a creativity thing. Some people like to make art that is photo realistic, some people like to make abstract art.
I understand both viewpoints. In my free time I vastly prefer late bound, dynamically types languages with robust reflection engineers built into their interpreters. For work, I heavily prefer late bound, strictly typed with reflection optional or minimal.
Different people think differently.
I think that’s fine if that’s how you like to work on your own, but I’d challenge anyone to do that and write better documentation while also getting a team or whole business to do the same. A huge strength of TS is that it gives people no choice but to document their work.
I didn’t say JavaScript… and I certainly wouldn’t choose TS for a personal project because I personally feel that its organization is terrible but I would choose TS over vanilla js for work projects because it does produce better group work and is easier to maintain long term because of the structure imposed on it.
Haha well that’s fair enough then!
TS is amazingly powerful when it comes to refactoring. I swear it practically writes itself. Half the time by the time I fix all the compiler errors the refactoring is done. I barely need to think about it which means I can spend more time thinking about the best architecture. When people say they don’t see how TS makes you more productive it just makes me think they never refactor their code.
Svelte decided to ditch it because it became impractical due to the compilation step slowing down development and making debugging their compiler harder. I think for libraries it makes sense to go the jsdoc way as long as consumers can choose typescript.
Am I the only one scratching my head trying to understand why Svelte supported it at the first place?
The TS type system is not a good match for the project.
I refuse to use it because it is backed by Microsoft.
I can understand that. Does it’s open source status not change anything for you?
If it’s dumped under an open-source license, but still developed exclusively by one corporation, they can swap out that license pretty easily.
For what? If they took it away, the source code would still be there if someone wanted to fork it. Not to mention removing TypeScript from an application is relatively trivial.
They’re not that dumb, to just pull it completely. That would obviously result in a successful fork.
Companies usually start with e.g. the BUSL, so source-available but proprietary restrictions.
For TypeScript/Microsoft, I could imagine some variation of their EEE playbook.
But really, the whole point of avoiding Microsoft et al, is that I don’t want to think about, how they could fuck this whole thing up. They’ve proven quite creative in this regard for as long as they’ve existed.
They have a vert high chance of pulling slack.
I feel like there’s no typescript drama, just JavaScript drama. Things are pretty happy in the TS community. I’ve been writing js code since it literally first came out. I’m definitely no js hater. In the early days js code bases quickly turned to spaghetti code, but I genuinely think the js community has done miracles turning what was essentially a super simplistic toy language into a seriously good production quality language. I’ve seen first hand how much work has gone into it, and while most of the js community has been great with embracing change for the better, there’s always been the niche of detractors against any change that adds complexity even when it makes coding safer and more productive.
I’ve always had a love hate relationship with JavaScript, but with typescript it’s really been just straight up love. Pretty much all the trouble I have with typescript has been due to external libraries that use types lazily or incorrectly, and even then there are solutions to add safety to your own codebase. Sometimes I run into some trouble with the type system itself, but it’s pretty much always because I’m doing something really complicated that would be hard in any type system. I’ve been working with typescript for years now and my code bases are some of the most solid ones in my company. Typescript is really safe as long as you’re actually using it and not telling the compiler to ignore types through using any or making unsafe assertions.
It makes no difference to me if other people prefer JavaScript. Any important js library will get ts support anyways through definitely typed, and if a library is so sloppy it can’t be typed well then it’s not a good library to use anyways. Having people proudly announce they only want to use JavaScript is also great for hiring. It easily tips me off on who not to hire.