Consider converting some features as optional add-on plugins

[eliot-akira]

Consider converting heavy or unused modules (like Chart, Mermaid, and Mobile Detect) as separate add-ons.

[GabrielGallagher]

By add-ons do you mean a setting you can toggle or a separate plugin you would have to install? I think the main thing we want to be careful about is the ease of eventual block portability. We wouldn't want to have a more complex dependency situation than pro vs non-pro in terms of block requirements, so if you import a block that depends on a module like Mermaid, it can just auto-toggle Mermaid on instead of you having a broken block until you go install an add-on plugin.

[eliot-akira]

Good point about plugin dependencies of templates and blocks.. I've been thinking about it, and I agree the complexity is not worth it - I'll try to find other ways to keep the Template System slimmer.

The initial motivation that got me thinking about "add-ons", is that soon the Fields module will be shipped with L&L (currently only Tangible Blocks includes it). And there are several other features planned that will likely grow to become fairly big.

If we can only add features to the Template System but never remove them, either to deprecate or maintain as optional extensions - it will have to ship with possibly many unused features. I thought about having a "lite" variant with only the core of the template system (and everything else as add-on modules); and a "normal" variant like L&L that bundles all add-ons by default.

Sounds complex to have such optional features as plugins, but eventually I think we'll need to solve a similar question in general, about blocks or loop types that depend on third-party plugins like LearnDash and WooCommerce. Like solving how templates should define such dependencies, and what they should do when their dependency plugin is not active.

---

This also relates to how we can deprecate an older version of a feature.

For example, recently I started a new Pager module for more flexible pagination; and moved the existing one as "version 1" to be replaced eventually. But it will be bundled with L&L for the foreseeable future (maybe forever) until there's a smooth path to removing it.

Another example is the Glider/Slider feature. They work OK, but to make it more flexible for templating, improve their accessibility, and remove jQuery dependency - we'll need a new major version that's based on a different JS library. Ideally this "version 1" can be moved to an add-on module for those who need backward compatibility.

Or the HyperDB module - it's small, but was a kind of a one-off feature that's only being used on one or few sites. It seems better suited as an optional extension.

---

As another way to keep plugin releases slim, recently I added a new feature in Tangible Roller to generate a zip package based on the same tangible.config.js, so L&L/Blocks plugins can be more selective about what files to include and exclude.

I'm considering removing JS and CSS source maps (which can get to multiple megabytes) since they're mostly used during development - though they can be useful for better debug messages in case of errors in production. I checked now and WordPress itself does not ship source maps for their JS/CSS bundles (core and many vendor libraries).

[GabrielGallagher]

In the pro version, we may have some flexibility to be able to download additional "addons" from our servers automatically when a feature is needed, but the free one would not be able to do this due to the repo ToS around that. Overall we'll have a lot more leeway with how the pro version works, so I think the version in the repo can functionally be the "lite" version and ideally only have things we intend to support long term, while we try to keep more of the extra modules in the pro version. Of course if we go the route of JIT downloads of extra features we'll need to be very careful with the security implications of that.

Some of them, like the HyperDB one, do indeed make more sense as an addon regardless. It's unlikely we'd ship blocks that use that to the public given how few people would know what that is.

Another thing I've noticed is that there's a very strong bias among power users that aren't also coders (our main audience) that more plugins is inherently worse than fewer plugins, so plugin ecosystems that wind up splitting their features into dozens of add-on plugins can make people more skeptical / reluctant to use them. Of course it's quality not quantity that matters, but I've spoken to enough people to know that most users are more concerned with quantity than quality, since they can't really evaluate quality anyway.

[eliot-akira]

we'll have a lot more leeway with how the pro version works, so I think the version in the repo can functionally be the "lite" version and ideally only have things we intend to support long term, while we try to keep more of the extra modules in the pro version.

That makes sense, as a general approach to all features.

power users that aren't also coders (our main audience) that more plugins is inherently worse

I can imagine that too. It's true in a way that more plugins are often problematic in terms of performance, compatibility, etc.

OK, so I'll close the issue with the conclusion that separating features into add-on plugins is not suitable. If there's an exception, it can be dealt with per individual module. (For the HyperDB extension, it's so small that I think it's not worth the effort of separating it out.)