For the last few years I’ve been strongly swaying from “monolith tools” to “plugin everything”. I don’t think either approach is actually sustainable. Likely need something that’s a mix. Not sure what it would look like though.
-
-
Replying to @sebmck
What if the monolith has a plug-in system with caveats made obvious to the end user, and plugins that work especially well are from time to time brought in as first-party?
2 replies 0 retweets 7 likes -
Replying to @jdan
Yeah that's a model I think could work. Another problem comes with exposing plugins in a monolith. The API surface can be massive and prevents being able to make large changes, which is one of the compelling reason for a monolith to begin with.
3 replies 0 retweets 3 likes -
Webpack does this and folks fault it for the massive API surface.
2 replies 0 retweets 6 likes -
Tapable just makes it too easy to add hooks
By far my favorite way of making a package pluggablehttps://github.com/webpack/tapable 2 replies 0 retweets 4 likes -
Neat! Not sure I’d use it though due to the fact it’s so imperative and provides so much flexibility with code execution. Makes it really hard to rely on it for predictable performance.
1 reply 0 retweets 1 like -
Replying to @sebmck @HipsterSmoothie and
Actually, tapable was hand-tuned for performance.
@wSokra and@TheLarkInn can say more.1 reply 0 retweets 0 likes
I'm sure it is. I'm referring to execution order and scheduling. Cooperative scheduling is a hard problem and one that a generic system makes difficult to get right.
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.
he/him 