I continue to be baffled and amused by the complete meltdown of the typescript community over the actions of a single man on a single package. The only people who have legitimate gripes are those that had been actively contributing and whose work was erased. The rest of you are acting absurdly childish. The anger and vitriol being thrown at anyone who disagrees on how to write javascript would make me embarrassed if I was associated or involved in the ts community.
They not only removed typescript without implementing an alternative breaking many projects depending on that library but they did it without informing the open source community which means many people who invested their time in making PRs (there was 60+ open PRs) have to basically completely redo their work.
Yes, and the people directly contributing to the project have legitimate gripes. Although, the parable of dhh is if you get on an asshole scorpions back, don’t be surprised if you get stung. Dudes been an unreasonable prick for nearly 20 years now.
My comments directed at the manufactured outrage from the tooling zealots incapable of having a mature conversation. Or even accept a difference of opinion. The number of comments that start with, "never heard of Turbo, but let me weigh in on why you’re an idiot for not liking Typescript. " is very telling…
Which project is this? So, the project owner did this?
Ah, it’s Turbo
To be fair, how could you not believe that he was gonna go Turbo?
huh. what was the rationale for removing it in the first place? seems like a waste to throw away a whole codebase worth of perfectly good type annotations
JSDoc enjoyers:
They wanted to generate controversy to help market a new set of products they are announcing.
When I saw “dhh” on the post about this turbo decision that said it all really. Dhh is a tool.
Care to clue me in? I spend my time far, far away from the web dev sphere :p
He became a patron saint because he developed Rails, and he huffed too many of his own farts. His track record can be boiled down to thinking he knows what’s best and the evidence is damning
- https://world.hey.com/dhh/turbo-8-is-dropping-typescript-70165c01 The decision that made the spaghetti flow out of our collective pockets
- https://janeyang.org/2021/04/27/an-open-letter-to-jason-and-david/
- https://www.theverge.com/2021/4/27/22406673/basecamp-political-speech-policy-controversy
- https://tomstu.art/the-dhh-problem
- https://www.youtube.com/watch?v=FnmZhXWohP0&t=430s&pp=ygUJZGhoIHJhaWxz
- https://thenewstack.io/railsconf-and-dhh-go-their-separate-ways/
See also: https://en.wikipedia.org/wiki/Narcissistic_personality_disorder
People seems to be riled up by this, but turbo is mostly used with ruby on rails, right? I’m not familiar with ruby on rails, does it actually support some form of static typing it type hints? From the blog post, the dev (which is also the ruby on rails creator) doesn’t seem to be a fan of bolting static typing into dynamic typing language.
RoR is very… specific. Some love it because it comes with magic. Many hate it for the same reason.
You either knows the magic and love it, or you hate it with a passion. You never really know when (not if) your change will break the system because it’s supposed to name in a very specific way that work by, again, magic.
I recently made a small pure JS package at my company. It just fucking worked, can you believe it? No setting up compilation and CI/CD for build + release. Just put it in the repo and publish manually, and it just worked, it’s ridiculous
CI/CD is useful regardless of which language you’re using. Sooner or later some customer is going to yell at you because you didn’t discover the fatal error before deploying.
@magic_lobster_party @alphacyberranger @unsaid0415 CI/CD won’t prevent that. I wonder what it is for. Not using the CPU on my laptop for tests? And why would I want to commit before knowing the tests pass?
CICD isn’t an alternative to testing your own work locally. You should always validate your work before committing. But then once you do, the CICD pipeline runs to run the tests on the automation server and kicks off deployments to your dev environment. This shows everyone else that the change is good without everyone having to pull down your changes and validate it themselves. The CICD pipeline also provides operational readiness since a properly set up pipeline can be pointed to a new environment to recreate everything without manual setup. This is essential for timely disaster recovery.
If you’re just working on little projects by yourself, it’s usually not worth the time. But if you’re working in anything approaching enterprise grade software, CICD is a must.
