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?
-
-
-
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.
- 5 more replies
New conversation -
-
-
What if you had a single tool with a whole bunch of features and a system of downloadable modules you could activate via run-time scripts?

-
Having to assemble JavaScript legos just to get basic tooling working is one of the pillars of JavaScript Fatigue and makes it less accessible.
- 9 more replies
New conversation -
-
-
Similarly, I'd like to see more officially endorsed "stacks" or "layers" of plugins/tools as a common, well-supported and featureful starting point, but keep a small core and ejection pathways for when people outgrow the official setup.
-
Yeah I think I agree. What’s hard is defining the point that a use case has “outgrown”. Ideally a tool should be able to scale.
- 2 more replies
New conversation -
-
-
"pluggable monolith core"
-
Sounds like a new metal genre :D
- 2 more replies
New conversation -
-
-
Plugin-based system with a default set of plugins that can be disabled individually.
Thanks. Twitter will use this to make your timeline better. UndoUndo
-
-
-
hapijs has done a

job providing a rich plugin experience on top of what some might call a monolith of a framework. Allowing plugins to express their order relative to each other is so useful at scale. Patchbay's plugin system "depject" is novel too!https://github.com/ssbc/patchbay Thanks. Twitter will use this to make your timeline better. UndoUndo
-
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 