You should pick what is best for the job and the people you have working for you. I get ask this question and I always tell people to get whatever works best for your team and the stuff you are building.
frameworks, languages and tools... just like clothes and they tend to go in and out of style on a regularly basis.
One Framework to rule them all, One Framework to find them,
One Framework to bring them all and in the darkness of the heap bind them
BTW I voted "a set of frameworks"
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
1st - Pick the right technology for the job
2nd - Validate the Team Velocity on that technology against your available time
3rd - Validate the team ramp-up (if needed) against cost/benefits and available time
Ideally you should be given time to ramp-up your team before the project starts but that never happens, so choosing the right tool for the job often depends heavily on the available time.
P.S.: "Whatever I already know" should never be the main criteria.
...and that is Windows API. Powerful, flexible, fast, and basically the very same thing that does the dirty work under the bloated .NET.
Wherever I can I use libraries and APIs because they do not force me to design according to the framework, I am free to design as my problem domain needs and to use only the feature I need with no overhead.
Agreed, and I never said you should.
But building a Windows App with a Node.js back-end using Maven to manage your Clojure packages because ReactJS is the popular kid on the block will end in tears
Ok, that's not even possible, but you get my drift.
New project, new frameworks. Old projects, be very careful.
Don't experiment too much, because each new framework has it quirks and you're going to make mistakes learning and implementing it.
If you're going to use AngularJS use AngularJS and don't use Ember for another page and Knockout for yet another page.
Sure, that's like the other edge of the problem:
Using everything you can just because you can.
Anyway, when I wrote that I was more thinking about the common problem between core technologies like .Net vs. Java or things alike. So-called "Architects" tend to stick with their own tribe instead of actually designing a proper performant and logic system.
I'll not even go into details related to product fanboys like SharePoint or CRM where at some point it looks like everything should be religiously stuffed into these resource eating monsters.
Just because one is used to a certain stack it doesn't mean that everything has to fit into that stack.
If one is serious about computer science, one should be as open minded as possible and include different stacks into his toolbelt.
Sure different stacks come with integration challenges but often integration is much easier to abstract (usually even at infrastructure level) when compared to force-fit a technology where it's not meant to be.
So-called "Architects" tend to stick with their own tribe instead of actually designing a proper performant and logic system
Yeah, I worked for such a company.
Well, they did call themselves a Microsoft company.
If you wanted our software you had to have Microsoft systems.
Nothing wrong with that, as long as you know it.
We never tried to run WinForms on Apple
Anyway, mentioning anything besides MS was a sin in the company, that's really the only thing that bothered me about it