Ruby on Rails Creator Removes TypeScript From Turbo Framework, Upsets Community (devclass.com) 54
Ruby on Rails creator David Heinemeier Hansson has removed TypeScript from the forthcoming version 8 of the Turbo framework, saying he has "never been a fan," but many Turbo users have protested that the decision was rushed and the change is unwelcome. From a report: A comment on the GitHub pull request that removes TypeScript states that this "is a step back, for both library users and contributors." This comment has -- at the time of writing -- 357 likes and just 8 downvotes, suggesting wide support. Turbo is a framework for delivering HTML pages intended to "dramatically reduce the amount of custom JavaScript," and is sponsored by Hannson's company 37signals, whose products include the Basecamp project management platform and the Hey messaging system. Turbo is the engine of Hotwire, short for "HTML over the wire," because it prefers sending HTML itself rather than JSON data and JavaScript code.
Although Turbo itself is not among the most popular frameworks, Ruby on Rails is well-known and used by major web sites including GitHub and Shopify. Hansson posted that TypeScript "pollutes the code with type gymnastics that add ever so little joy to my development experience, and quite frequently considerable grief. Things that should be easy become hard." The community around the open source Turbo project though is for the most part perplexed and disappointed, not only by the change itself, but also by the manner in which it was made.
Although Turbo itself is not among the most popular frameworks, Ruby on Rails is well-known and used by major web sites including GitHub and Shopify. Hansson posted that TypeScript "pollutes the code with type gymnastics that add ever so little joy to my development experience, and quite frequently considerable grief. Things that should be easy become hard." The community around the open source Turbo project though is for the most part perplexed and disappointed, not only by the change itself, but also by the manner in which it was made.
I guess... (Score:2)
I guess just install some third party library if you can't live without the typescript utilities? I haven't used rails so the ones who know it can comment on how hard that would be...
Re: (Score:2)
so ... (Score:4, Insightful)
"pollutes the code with type gymnastics that add ever so little joy to my development experience, and quite frequently considerable grief. Things that should be easy become hard."
i can relate, even if i would do with considerable less dramatism.
and i can also see why type addicts get upset, they get easily scared by their own code. and it still doesn't matter a bit.
Re: (Score:2)
and i can also see why type addicts get upset, they get easily scared by their own code. and it still doesn't matter a bit.
Well, there are huge reasons for picking Typescript, and the change is an Issue because it's a major impact users of the framework -- You don't just change things like that randomly - It's like what if MySQL decided to Drop SQL as a supported query language.
And DHH is Ludicrously arrogant here, as they won't even engage their fellow developers in a reasonable fashion. "All the lov
Re: (Score:1)
It's like what if MySQL decided to Drop SQL as a supported query language.
MySQL only ever supported a weird and broken subset of SQL.
Re: (Score:2)
I need to remind myself that '' is null more often than I'd like to admit using oracle.
Super annoying.
Re: (Score:1)
Re: (Score:2)
Length(null) and length('') are both null
Oracle treated an empty string as null from the very start.
They created a varchar2 type and defined it that way and in theory at some point could potentially make varchar behave to the standard, but I doubt it, but it's best practice to use varchar2 in Oracle so that it's clear it isn't standard SQL relying on '' and null being different. Currently varchar and varchar2 both behave this way though in Oracle.
An empty string/varchar/varchar2 is indistinguishable from nu
Re: (Score:1)
Re: (Score:2)
So, in Oracle with a not nullable varchar/varchar2
Insert into table1 (column1) values ('');
Gives cannot insert NULL into table1.column1
An empty string is treated exactly as NULL.
It's super annoying when treating NULL as a special value was so ingrained.
Re: (Score:1)
Re: (Score:2)
The only place I can think of where NULL (or '') act like an empty string is the || operator.
''||x = null||x = null
Re: (Score:2)
Ew, major typo.
Null || 'x' = '' || 'x' = 'x'
So at least one can include empty fields when concatenating.
Re: (Score:2)
It's like what if MySQL decided to Drop SQL as a supported query language.
MySQL only ever supported a weird and broken subset of SQL.
And, at times, only supported that by not failing - but ignoring the actual implementation of the constraint.
Re: so ... (Score:2)
There a few options (most notably --ansi) that get you pretty close to a standard SQL. Certainly closer than most other SQL vendors.
Re: (Score:3)
Rob Pike still takes the cake here when he wrote about why Go hadn't won over C++ developers. At the end of his post, he summarizes with a conclusion:
Re: (Score:3)
The advantag
Re:so ... (Score:4, Insightful)
I’m sorry but what the heck are you talking about? Static typing reduces the number of tests you write because the type system itself guarantees thing like a toString() call actually returns a string. Dynamic typing can help you test really untestable code due to its flexibility, but stubbing isn’t exactly an unsolved problem in static land.
Re: (Score:2)
but stubbing isn’t exactly an unsolved problem in static land.
Yeah but it sucks.
Re: so ... (Score:2)
So, you avoid writing trivial tests at the expense of making important tests a nightmare to write. Sounds like a big lose to me.
Re: (Score:1)
If "toString()" doesn't return a string, it's coded wrong, and I'd write my own wrapper around it if I needed it often.
Re: (Score:3)
"pollutes the code with type gymnastics that add ever so little joy to my development experience, and quite frequently considerable grief. Things that should be easy become hard."
i can relate, even if i would do with considerable less dramatism.
and i can also see why type addicts get upset, they get easily scared by their own code. and it still doesn't matter a bit.
Reminds me of all the BS I went through in school suffering through a class in Object Oriented Programming
Talk about a programming language that was filled with programming gymnastics and output such obscure and obtuse code that I'm surprised it actually compiled.
I will take the teeth-pulling of working in Assembly or the hassles of working C over the insanity of working in any object-oriented language.
Re: so ... (Score:2)
Most OO languages are multi-paradigm. Nothing stopping you from writing in a different style.
Re: (Score:2)
Type strictness aside, this was done wrong (Score:5, Insightful)
Even if we set aside any discussion about whether type strictness is good or bad, the PR in question was only open for 2-3 hours before it was approved and merged by David. Mind you, this was done over technical objections to the PR itself that were unrelated to type strictness, including from contributors to the project who are more prolific than he is (I saw it reported thatsome were even his coworkers, but I haven't confirmed that). Mind you, there are also dozens of existing PRs published by external contributors that are no longer able to be merged.
This is not how you run an open source project. This is not how you treat your coworkers. This is not how you communicate shifts in the direction of a project. This is not how you do a PR.
Reasonable minds can disagree on whether or not dumping Typescript was the right choice (even if you did want to do it, why not JS+JSDoc, as was pointed out in the PR comments?), but reasonable minds should all be in agreement that how he handled it was wrong.
Re: (Score:2)
Typically I'd say there's money behind unpopular decisions like this (.NET has had its own controversies in the rare cases where corp needs have apparently overridden what OSS community expects as healthy OSS), but DHH has displayed a bit of a "it's my ship, get on board or get off" mentality in the past -- would not be surprised if it's mostly just from him.
Re: (Score:2)
If you're working with Rails, then this is what you have to deal with. DHH is unapologetic about it
https://dhh.dk/2012/rails-is-o... [dhh.dk]
I'm surprised there are so many people using Rails, when his attitude is basically "you will use it how I built it and if you don't like it then go away". Which is entirely fair to him to be sure - it is his project after all. But anyone who's adopted Rails should already know what they signed up for and shouldn't at all be surprised at this turn of events
Even if he wasn't as c
Re: Type strictness aside, this was done wrong (Score:2)
His decisions and vision are what provide pretty much all the value of Rails. Building by consensus or trying to please everyone undermines the whole idea of having an opinionated streamlined framework for solving a specific set of problems.
Re: (Score:2)
It's fine to be a benevolent dictator over a system you created. Emphasis on "benevolent". My point above is that his actions here were not benevolent. They were actively hostile towards the community, the project's maintainers, his coworkers, and more, and while engaging in bullheaded actions is both his prerogative and right, that doesn't make it right.
Plenty of us are in leadership positions where we need to lead people in a direction without first building consensus. There are right ways to do that and
Re: Type strictness aside, this was done wrong (Score:2)
He was benevolent when he let the TS in in the first place, against his better judgement.
Re: (Score:2)
He was benevolent when he let the TS in in the first place, against his better judgement.
And? If a single act of benevolence was all it took to be a benevolent dictator, they'd all be benevolent. His actions here demonstrate his actual character.
Re: (Score:2)
Re: (Score:2)
the PR in question was only open for 2-3 hours before it was approved and merged by David
If the submitter of a PR has the power to do so, they will approve their own merges. Depending on the project's structure and practices, that could be a bad or a good thing. But length of time as a PR is rarely an indicator of a bad merge.
this was done over technical objections to the PR itself that were unrelated to type strictness, including from contributors to the project who are more prolific than he is (I saw it reported thatsome were even his coworkers, but I haven't confirmed that).
That part is troubling. If there are valid technical objections, then they should be worked out. That or it's time for a new major version number due to the breaking change. (Which seems to be the case here according to TFS.)
there are also dozens of existing PRs published by external contributors that are no longer able to be merged.
If the changes from one PR are accepted befor
your favorite framework sucks (Score:2)
and the benevolent dictator of Ruby agrees with me
DHH is a moron (Score:3)
This change might not affect your rockstar devs who know the project in and out, but it will absolutely reduce the quantity of new contributors, reduce the quality of contributions, increase time spent in PR, and make onboarding take longer for their paid devs.
It feels like this guy posts some contrarian bad take every year. I guess this is right on schedule.
Re: (Score:2)
True that. Mr. F1 driver can flip his hair and pose. Meanwhile, the rest of the civilized world will cooperate and balance concerns with at least a shred of egalitarianism.
And maybe Amazon should acquire Basecamp as they seem to share common values.
Re: Smart tbh (Score:2)
I'm waiting for the fad to be over and for those devs to move on so JavaScript can be left alone. TypeScript is a poison pill. Classic MS.
Good news, everyone! (Score:2)
fork away [github.com]
Types are spooky... (Score:3)
Honestly, the amount of people that seem completely allergic to typing is really odd to me. Yes, the code does take longer to write. Yes, that can seem just like "ceremony", but code is read and updated way, way more often than it is written. Strong typing is a useful tool to made code more understandable to others.
Re:Types are spooky... (Score:5, Insightful)
Re: (Score:2)
When I work in C++, occasionally the typing annoys me but mostly it's beneficial. When I'm working in PHP/JS I tend to look at the stuff I'm writing and realise that if it was typed this would have been really awkward. Horses for courses and all that. Weakly typed languages are beneficial when you're massaging data from one thing to another, when correctness is really not a big deal. Which describes a whole lot of web stuff which is usually taking back end data provided by a database and massaging it into a
Ruby on Rails Creator Is Opinionated? (Score:2)
Shocker. I'm glad there are vastly different frameworks out there to choose from, but so long as Mr Rails himself is dumping on non-Ruby languages, I'd just like to say:
There is no coding hell I've seen worse than using Rails for anything remotely challenging outside of a MVC style website (and even then, well, pretty much every language has a reasonable MVC framework you could use). Code by convention is just miserable, miserable awful stuff to me. "What is the Rails way to do this?" is not where I want to
Re: (Score:2)
Ahaha. So true. The problems with RoR are: lack of typing in Ruby (rbs and sorbet are shit), it's slow, it's dying so the communities are shrinking, lots of abandoned shit, Not-Invented-Here/Reinvent-the-Wheel syndrome, arbitrary/capricious churn, and some real jerk maintainers in Rails and in Ruby.
If you want job security, stick to Elixir/Erlang, Rust, Go, TypeScript, Clojure/Java/Kotlin, and Swift. PureScript, typed Python 3, and Haskell as honorable mentions.
Re: Ruby on Rails Creator Is Opinionated? (Score:2)
You seriously saying performance is an issue in Ruby, and then recommending Python?
Re: Ruby on Rails Creator Is Opinionated? (Score:2)
Re: (Score:2)
it was made worse by a general attitude in the Ruby community of "that version of that gem is *six months old*, why would anyone still be using that garbage?"
That same general attitude is applicable to most software projects these days (proprietary or OSS)....If you're not using their latest bleeding edge code they want nothing to do with you. Unfortunately, they also have a tenancy to make this demand of constant upgrades while also throwing breaking changes in to the same "upgrades" haphazardly. Leading to many end-users having to make a hobson's choice of upgrading to a version that breaks / removes support for something they need, or be stuck using vulnerab
Stupid, arrogant, and wrongly opinionated (Score:4, Informative)
TypeScript has been proven to be one of the most reliable and productive languages. https://web.cs.ucdavis.edu/~fi... [ucdavis.edu] [pdf]
Furthermore, TS can be reduced to JS simply by removing annotations. It's a strict superset of JS.
Oh well, the Basecamp people will always be medium-sized fish in a tiny fishbowl, not listening to users, and toiling away in obscurity on that which doesn't matter.
Re: Stupid, arrogant, and wrongly opinionated (Score:3)
If anyone cared what academics think, we'd all be writing in Haskell.
Re: Stupid, arrogant, and wrongly opinionated (Score:2)
TS is not a strict superset of JS. That's a lie.
Typescript is hugely helpful (Score:4, Informative)