While I agree with the arguments brought up by the others, let me play the devil's advocate here.
There's oftentimes drawbacks to these external libraries and those are rarely on the board when it comes to comparing solutions:
the maintenance effort of external libraries' inclusion is almost always underestimated
external libraries often have a lot more functionality than you need and are not always tree-shakeable, so they could inflate your app's bundle-size
this extra functionality might be inviting to over-complicate solutions because the external library makes it easy to model complexity (e.g. rxjs)
fixing errors in external libraries can be a hassle that can take much more time than doing the same for an internal library
external libraries can become orphaned, at which point you either need to switch to a different one or take it over yourself – this can even happen to much-used packages like lerna (which was luckily picked up by the team who develops nx)
external libraries might pose security risks that you need to handle
external libraries license requirements are rarely handled by developers
In any case, you should make your decisions and reasons transparent and document them, just in case you have to answer the question why something now takes longer than expected - especially if you are driven by deadlines rather than finished features.
Over 10 years of experience in Front-End Web Development:
Best of both worlds, design and development, I understand perfectly tech engineer mind and creative ideas of designers.
this extra functionality might be inviting to over-complicate solutions because the external library makes it easy to model complexity
This is a general problem these days. Our abstractions have become very good at hiding the complexities of the tasks but few developers have really kept up with keeping track of this.
This is primarily a performance issue, but it can also lead to (albeit less severe) over-complicated program design.
external libraries often have a lot more functionality than you need and are not always tree-shakeable, so they could inflate your app's bundle-size
Ideally, libraries wouldn't even need any DCE at all. In the case of JS, I think es6 modules are what will one day get us there.
I have seen production examples of abstraction overuse to hide unnecessary complexity, which became maintenance and performance hell rolled into one pandemonium. The key issue of unnecessary complexity is that it's hard to separate from necessary complexity.
Also, ES6 modules are really helpful, but to get all the way, we need libraries made up from composable primitives and wrappers and/or modifiers. I'm currently preparing a post about this exact topic, so stay tuned.
Decorators will offer some semantic sugar for wrappers, but that shouldn't stop us from employing the pattern already in order to get better tree shaking results.
Yea, I already saw that the other day. They had to get rid of the whole metainformation thing and put that into a different proposal, but tbh. that's probably for the best. And from the transcript of the presentation, it seems like there's going to be a bit more feedback from the browser side in the future as well. Who knows, a first implementation in chrome might be right around the corner :D
While I agree with the arguments brought up by the others, let me play the devil's advocate here.
There's oftentimes drawbacks to these external libraries and those are rarely on the board when it comes to comparing solutions:
In any case, you should make your decisions and reasons transparent and document them, just in case you have to answer the question why something now takes longer than expected - especially if you are driven by deadlines rather than finished features.
Very good points, thanks Alex! I'd say it's wise to consider all of those when you choose a lib to use, and not just pick a random one.
This is a general problem these days. Our abstractions have become very good at hiding the complexities of the tasks but few developers have really kept up with keeping track of this.
This is primarily a performance issue, but it can also lead to (albeit less severe) over-complicated program design.
Ideally, libraries wouldn't even need any DCE at all. In the case of JS, I think es6 modules are what will one day get us there.
I have seen production examples of abstraction overuse to hide unnecessary complexity, which became maintenance and performance hell rolled into one pandemonium. The key issue of unnecessary complexity is that it's hard to separate from necessary complexity.
Also, ES6 modules are really helpful, but to get all the way, we need libraries made up from composable primitives and wrappers and/or modifiers. I'm currently preparing a post about this exact topic, so stay tuned.
That will be a lot easier if and when decorators make it into the language.
Decorators will offer some semantic sugar for wrappers, but that shouldn't stop us from employing the pattern already in order to get better tree shaking results.
@darkwiiplayer decorators just reached Stage 3, reddit.com/r/javascript/comments/t... so we can you it already with babel, of course
Yea, I already saw that the other day. They had to get rid of the whole metainformation thing and put that into a different proposal, but tbh. that's probably for the best. And from the transcript of the presentation, it seems like there's going to be a bit more feedback from the browser side in the future as well. Who knows, a first implementation in chrome might be right around the corner :D
Use Typescript if you want to work with decorators already
There is also a babel plugin if you don't want to use TS for whatever reasons.
In any case, decorators are just semantic sugar around the wrapper pattern.