Tech Lead/Team Lead. Senior WebDev.
Intermediate Grade on Computer Systems-
High Grade on Web Application Development-
MBA (+Marketing+HHRR).
Studied a bit of law, economics and design
Location
Spain
Education
Higher Level Education Certificate on Web Application Development
When you import a lib just to achieve a goal you usually fit into this approach, otherwise you can either choose another one (and fit into it) or write down your approach and publish it as the new lib to do the same others do but on a different manner, then your lib will need to pass 2 filters:
Community (if it solves a real issue, it does it on a simple (no suggar needed) way, it's buggless, covers all possibilities that any project could need, a medium-big project is built with that as example of capabilities and it's well documented, you can get some fans and stars on github).
Us current engineers, tech leads and so will eventually take a look at it if the community growth enough to find devs who knows that lib or to share with the team to solve a current situation for a new or existing project. If you simply changed the way of doing things by stubbornness instead trying to understand how the things work and why they work this way, it'll simply be ditched off and it'll die along the other hundreds of js libs released every month that does not fit for real solutions.
I can understand your reasons to avoid using a lib or framework "as is" and in the end you can agree with me that is a try to avoid tech debt in a project, not less not more.
Then there reasons that counters this reinvented wheel. If you use react millions of devs out there will be available to work within your project in few hours, if you need higher performance and less included libs, you can simply pick preact and every react dev will be skilled to work with that as well.
If you create your own approach and build a project or even a company with that, the end result is that the world keeps rolling and new tech will appear anyway to solve other problems you don't even know about -yet- or to automate things you didn't even mind -yet- so people will like to use this "latest tech" (We know "latest" mean that it appeared 4-5 or 7 years ago and now it's popular and everyone works with that) so even if you figure out how to trick some dev to work in your company or project, they will eventually fly away to another company at the first sight of working on a non standard dinosaur. This will put you in need to increase the salary for your devs and new hires which is also costly and at this point, the life-cycle of your App will be near the end and needs a tech refresh regardless of your initial effort.
The end questions would be then, Is it worth? what do you prefer?
Everything has advantages and disadvantages but in long-term applications I think it makes more sense to uncouple and in the future it will be appreciated in my experience.
Tech Lead/Team Lead. Senior WebDev.
Intermediate Grade on Computer Systems-
High Grade on Web Application Development-
MBA (+Marketing+HHRR).
Studied a bit of law, economics and design
Location
Spain
Education
Higher Level Education Certificate on Web Application Development
Answering from non-work account
That's a really good answer. Yes even tho React has some sort of DI you can't really say it's extensible
When you import a lib just to achieve a goal you usually fit into this approach, otherwise you can either choose another one (and fit into it) or write down your approach and publish it as the new lib to do the same others do but on a different manner, then your lib will need to pass 2 filters:
I can understand your reasons to avoid using a lib or framework "as is" and in the end you can agree with me that is a try to avoid tech debt in a project, not less not more.
Then there reasons that counters this reinvented wheel. If you use react millions of devs out there will be available to work within your project in few hours, if you need higher performance and less included libs, you can simply pick preact and every react dev will be skilled to work with that as well.
If you create your own approach and build a project or even a company with that, the end result is that the world keeps rolling and new tech will appear anyway to solve other problems you don't even know about -yet- or to automate things you didn't even mind -yet- so people will like to use this "latest tech" (We know "latest" mean that it appeared 4-5 or 7 years ago and now it's popular and everyone works with that) so even if you figure out how to trick some dev to work in your company or project, they will eventually fly away to another company at the first sight of working on a non standard dinosaur. This will put you in need to increase the salary for your devs and new hires which is also costly and at this point, the life-cycle of your App will be near the end and needs a tech refresh regardless of your initial effort.
The end questions would be then, Is it worth? what do you prefer?
Hi, thanks for your comment.
Everything has advantages and disadvantages but in long-term applications I think it makes more sense to uncouple and in the future it will be appreciated in my experience.
Regards
Bet you don't pay the salaries so! 😁