When I’m choosing a new technology, it’s almost always for a specific project, and I’m almost always choosing between 2-3 fairly similar options (Django or Rails? React or Vue or Angular? Swift or React Native? Redis or RabbitMQ? Java or Scala? Etc.)
There are few cases where one technology is objectively and universally better than another. Most of the time, each has strengths and weaknesses. Often there is overlap between use cases but one is better for one type of usage and the other for another type (such as Redis/Rabbit). In other cases they’re pretty much interchangeable, but one may match more closely to my particular mental model (my experience with React/Vue/Angular); or one may be easier to get started with.
With that in mind, I’m usually looking for balanced information about specific trade-offs. What is this technology good at that the most similar alternatives aren’t as good at? Where do the alternatives excel that this tool struggles. How do the philosophies of the tools differ? What’s the learning curve like? What limitations did you stumble over only after using them for a while? How do the ecosystems compare?
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
When I’m choosing a new technology, it’s almost always for a specific project, and I’m almost always choosing between 2-3 fairly similar options (Django or Rails? React or Vue or Angular? Swift or React Native? Redis or RabbitMQ? Java or Scala? Etc.)
There are few cases where one technology is objectively and universally better than another. Most of the time, each has strengths and weaknesses. Often there is overlap between use cases but one is better for one type of usage and the other for another type (such as Redis/Rabbit). In other cases they’re pretty much interchangeable, but one may match more closely to my particular mental model (my experience with React/Vue/Angular); or one may be easier to get started with.
With that in mind, I’m usually looking for balanced information about specific trade-offs. What is this technology good at that the most similar alternatives aren’t as good at? Where do the alternatives excel that this tool struggles. How do the philosophies of the tools differ? What’s the learning curve like? What limitations did you stumble over only after using them for a while? How do the ecosystems compare?
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.