Lefting out, or an explanation I like more is: "an architect delays all the decisions as long as it can". And usually this means the technology/frameworks/languages are chosen among the last decisions, the advantages are many, but mainly when you have to take a decision later in t he design you have more details&info so it will be a better decision.
Speaking of angular, choosing a framework may have many factors (technical and business), including the team knowledge, how many devs can you hire on that technology, the community (a nice article about this , testability and tools ...
I was going to comment along these lines as well. To me the best software designs build in the idea of making decisions as late as possible. The reason being that this will be when you have the most information possible to make the decision. Another one is that you want to mitigate against bad decisions as much as possible.
Of course this then lends itself to talks of trade offs which I think are also important. To meet the 'late decisions' prerogative might mean abstractions that are harder than talking directly to a chosen framework. How to use a native RDBMS feature might provide 100x performance whilst still keeping the ORM flexible etc.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Lefting out, or an explanation I like more is: "an architect delays all the decisions as long as it can". And usually this means the technology/frameworks/languages are chosen among the last decisions, the advantages are many, but mainly when you have to take a decision later in t he design you have more details&info so it will be a better decision.
Speaking of angular, choosing a framework may have many factors (technical and business), including the team knowledge, how many devs can you hire on that technology, the community (a nice article about this , testability and tools ...
I was going to comment along these lines as well. To me the best software designs build in the idea of making decisions as late as possible. The reason being that this will be when you have the most information possible to make the decision. Another one is that you want to mitigate against bad decisions as much as possible.
Of course this then lends itself to talks of trade offs which I think are also important. To meet the 'late decisions' prerogative might mean abstractions that are harder than talking directly to a chosen framework. How to use a native RDBMS feature might provide 100x performance whilst still keeping the ORM flexible etc.