3 ms·

> Pretty much all cases you might consider using Ruby, TypeScript is a better choice. Yeah no thanks, I don't want to deal with the npm madness. Not to mention

> Pretty much all cases you might consider using Ruby, TypeScript is a better choice. Yeah no thanks, I don't want to deal with the npm madness. Not to mention that there's nothing in the JavaScript world that is as good as Activerecord yet. I also don't think this argument makes sense, you don't like changes that are breaking stuff and recommend the JS ecosystem, probably the most churn-heavy ecosystem that exist? At my work we have a roughly half Rails / half React app, despite that, at least 80% of the updates are on the JS side and unlike Rails, those packages are usually poorly tested and often break functionality. Maintenance is much harder on the JS side.

Gigachad 3y ago
Breaking changes are not an issue, it’s the fact you can’t spot them before deploying. TS would warn you when compiling, but Ruby gives you nothing until that specific code gets run. I recently had an issue where updating ruby caused kernel#open to change its parameter list, but all of our tests has this call mocked out since it makes a web request. Then it blows up in production. Despite all my efforts I couldn’t even find the changelog or PR that caused this breakage.
- realusername 3y ago
  Sure but what's the point of types if none of the packages you use are using it or are even tested in the first place? I also have the same story on the JS side, we upgraded the package to open notifications, they broke the API and kept the types the same. Now we added a test that notifications are working (we're basically doing the package maintainer's job). Ruby's update story isn't prefect, far from it but I'll take it any day against npm. I worry at every package upgrade on the JS side. What's making it even worse is that the stdlib is very limited on the JS side, so this effect is compounded by the number of packages needed to fill the gap.

Gigachad 3y ago

Breaking changes are not an issue, it’s the fact you can’t spot them before deploying. TS would warn you when compiling, but Ruby gives you nothing until that specific code gets run. I recently had an issue where updating ruby caused kernel#open to change its parameter list, but all of our tests has this call mocked out since it makes a web request. Then it blows up in production. Despite all my efforts I couldn’t even find the changelog or PR that caused this breakage.

realusername 3y ago
Sure but what's the point of types if none of the packages you use are using it or are even tested in the first place? I also have the same story on the JS side, we upgraded the package to open notifications, they broke the API and kept the types the same. Now we added a test that notifications are working (we're basically doing the package maintainer's job). Ruby's update story isn't prefect, far from it but I'll take it any day against npm. I worry at every package upgrade on the JS side. What's making it even worse is that the stdlib is very limited on the JS side, so this effect is compounded by the number of packages needed to fill the gap.