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
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.