For sure. I remember a discussion at a previous company that I worked for.
What frontend library should we use for development: Angular, (then still in beta) Aurelia, React was just in its early stage.
By using the questions I mentioned, an intern got to work with it.
He built a small project for all three libraries and tested what worked the fastest.
✅does it connect to the in-house knowledge that I / the company have?
✅how difficult is it to master it? (can we build something quickly with it?)
✅will it speed up development of products?
Using a knowledge matrix that I had been setting up for the team in addition to an inquiry he did about expertise, goals etc. the intern managed to answer a couple of answers more.
✅will it increase the quality and/or maintainability of the product/project?
✅does it have a vision/roadmap that makes it future proof? > for us, as the team that was going to use it...
He also performed an online (desk)research between the options, anwering these questions:
✅does it have enough support from the community and/or the company behind it?
✅is it updated regularly and recently?
✅does it have a vision/roadmap that makes it future proof?
✅what are its biggest competitors/alternatives?
And asking the community and/or the companies behind the frameworks for the last:
✅no hidden costs / efforts?
I believe this was done in a week or two. I agree on your part that this is not easy peasy. It's more than just a matter of Googling during lunchbreak and doing it all within the hour.
I love it. This is a great process to determine which framework/library to choose from. I wonder, how would you modify the process and the questions, if you also wanted to evaluate the possibility of not using a framework at all?
For many of the questions, I would think that vanilla HTML/CSS/JS would be the clear winner, by a long shot, for instance:
does it have enough support from the community and/or the company behind it?
is it updated regularly and recently?
does it have a vision/roadmap that makes it future proof?
If we agree on this, the determination of when to use a framework then depends on the weight we give to the other questions and the way we answer them.
I'm curious, do you see situations where the quality / maintanability of a project would actually be increased by NOT using a framework? Or where the hidden costs / efforts of using a framework would be too great compared to using a vanilla solution.
What I'm especially interested in getting at is the sets of conditions / contexts, that make people decide to use a framework or not.
For example, if the project I'm working on has X views / pages, necessitates X functionality, has X requirements, is expected to last for X amount of time, will have X amount of people working on it, with X amount of experience etc... then I would consider using / not using a framework. You get the idea.
Well, most of the time I use 3-point-estimation to make visible the amount of work that's needed to implement a solution. And an estimation of how many hours it would take to maintain it (rough expert guess).
When looking at frameworks I need to be able to check off enough items of the requirements estimation to make it worthwhile for those hours. If there's more work into it than it saves and there aren't any other obvious benefits (it be on the short- or long term) I'm done with the framework.
Another criterium to bounce off frameworks is:
a bad reputation (ie: bad reviews from others who have used it)
bad security implemented or bad quality code
If I'm in a 5 person company and only 1 knows the language/architecture in which the framework takes a seat, it needs discussion if the team will invest into learning the framework. Often it isn't worth the deal.
But TBH: the critera are more experience based than actual hard figures. No excel sheet that I can sling up for you else I would.
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.
For sure. I remember a discussion at a previous company that I worked for.
What frontend library should we use for development: Angular, (then still in beta) Aurelia, React was just in its early stage.
By using the questions I mentioned, an intern got to work with it.
He built a small project for all three libraries and tested what worked the fastest.
✅does it connect to the in-house knowledge that I / the company have?
✅how difficult is it to master it? (can we build something quickly with it?)
✅will it speed up development of products?
Using a knowledge matrix that I had been setting up for the team in addition to an inquiry he did about expertise, goals etc. the intern managed to answer a couple of answers more.
✅will it increase the quality and/or maintainability of the product/project?
✅does it have a vision/roadmap that makes it future proof? > for us, as the team that was going to use it...
He also performed an online (desk)research between the options, anwering these questions:
✅does it have enough support from the community and/or the company behind it?
✅is it updated regularly and recently?
✅does it have a vision/roadmap that makes it future proof?
✅what are its biggest competitors/alternatives?
And asking the community and/or the companies behind the frameworks for the last:
✅no hidden costs / efforts?
I believe this was done in a week or two. I agree on your part that this is not easy peasy. It's more than just a matter of Googling during lunchbreak and doing it all within the hour.
I love it. This is a great process to determine which framework/library to choose from. I wonder, how would you modify the process and the questions, if you also wanted to evaluate the possibility of not using a framework at all?
For many of the questions, I would think that vanilla HTML/CSS/JS would be the clear winner, by a long shot, for instance:
If we agree on this, the determination of when to use a framework then depends on the weight we give to the other questions and the way we answer them.
I'm curious, do you see situations where the quality / maintanability of a project would actually be increased by NOT using a framework? Or where the hidden costs / efforts of using a framework would be too great compared to using a vanilla solution.
What I'm especially interested in getting at is the sets of conditions / contexts, that make people decide to use a framework or not.
For example, if the project I'm working on has X views / pages, necessitates X functionality, has X requirements, is expected to last for X amount of time, will have X amount of people working on it, with X amount of experience etc... then I would consider using / not using a framework. You get the idea.
Well, most of the time I use 3-point-estimation to make visible the amount of work that's needed to implement a solution. And an estimation of how many hours it would take to maintain it (rough expert guess).
When looking at frameworks I need to be able to check off enough items of the requirements estimation to make it worthwhile for those hours. If there's more work into it than it saves and there aren't any other obvious benefits (it be on the short- or long term) I'm done with the framework.
Another criterium to bounce off frameworks is:
If I'm in a 5 person company and only 1 knows the language/architecture in which the framework takes a seat, it needs discussion if the team will invest into learning the framework. Often it isn't worth the deal.
But TBH: the critera are more experience based than actual hard figures. No excel sheet that I can sling up for you else I would.