So if you don’t need to create routes, modify serializers, or store custom data, you can likely accomplish your outcome with just a theme.
The biggest challenge we see with custom plugins from a support perspective is site outages. This is usually because the plugin patches into a Rails class or method in core that’s changed and the plugin hasn’t been updated to account for it yet. If something changes on the Ember side and thus breaks the theme or theme component, the site may not render correctly but it can be quickly disabled using /safe-mode.
I can see your point here. I’d also say that gem enables you to develop on your theme locally and sync it to any Discourse site you have an API key to, including theme-creator.discourse.org. You don’t even need a local dev environment set up if you have that one gem running.
Wow the replies here are golden I have very little to add here.
The only thing I think is important to add is that internally at Discourse we are making strides to break some plugins now into “plugin for backend” and “theme for frontend”. We are thinking about this “distribution” challenge when stuff is mixed like this.
Overall my incredibly strong recommendation is only fallback to creating plugins if you absolutely need plugins. When you need to amend the Ruby backend you have no choice. A plugin that only makes changes to frontend is strongly discouraged. It is harder to keep up to date and far less flexible when it comes to usage.