In some ways, the pairs of options you presented are fairly similar in that they solve similar problems and the solutions take a similar approach One of the interesting properties of the pairs you presented though is that in many ways picking one vs. the other is not a single choice, but a swath of choices you make collectively.
Pick Django? You're also buying into the system of Django packages vs. those for Rails. Same with all the others. Although I think for the most part in the examples you selected, both choices could be equally valid for different projects which is why there are multiple strong choices for those application areas. I think that also means you probably won't go too far wrong picking one vs. the other. I find the choice is often made by how well the stack integrates with other stuff I'm already working on.
Agreed. And I find that with tools that similar often the trade-offs aren’t obvious until you’re fairly deep into the project.
Or that the trade-offs have to do with differences in project philosophy (Rails’ convention over configuration vs Django’s explicit over implicit), which in turn impacts in what ways they’re flexible vs rigid in subtle ways, or what sorts of ecosystems grow up around them.
Often there isn’t a right choice or a wrong choice, but there are still trade-offs. And you or your particular team may be able to more easily absorb certain trade-offs than others.
Even if two technologies are fully equivalent, you’ll need some basis on which to base your decision and to use to build consensus so that you don’t spend the next three years fielding “we should have gone with Laravel” complaints twice a week.
Which is why those in-depth comparisons up front can be so valuable — if you can find them.
Comments
In some ways, the pairs of options you presented are fairly similar in that they solve similar problems and the solutions take a similar approach One of the interesting properties of the pairs you presented though is that in many ways picking one vs. the other is not a single choice, but a swath of choices you make collectively.
Pick Django? You're also buying into the system of Django packages vs. those for Rails. Same with all the others. Although I think for the most part in the examples you selected, both choices could be equally valid for different projects which is why there are multiple strong choices for those application areas. I think that also means you probably won't go too far wrong picking one vs. the other. I find the choice is often made by how well the stack integrates with other stuff I'm already working on.
Agreed. And I find that with tools that similar often the trade-offs aren’t obvious until you’re fairly deep into the project.
Or that the trade-offs have to do with differences in project philosophy (Rails’ convention over configuration vs Django’s explicit over implicit), which in turn impacts in what ways they’re flexible vs rigid in subtle ways, or what sorts of ecosystems grow up around them.
Often there isn’t a right choice or a wrong choice, but there are still trade-offs. And you or your particular team may be able to more easily absorb certain trade-offs than others.
Even if two technologies are fully equivalent, you’ll need some basis on which to base your decision and to use to build consensus so that you don’t spend the next three years fielding “we should have gone with Laravel” complaints twice a week.
Which is why those in-depth comparisons up front can be so valuable — if you can find them.