The discussion revolves around the difference between plugins and theme components in Discourse. RGJ highlights that while a plugin can do everything a theme component can, the reverse is not true, as plugins consist of both server-side and client-side code, whereas theme components only have client-side code and rely on existing server-side code.
The general consensus is that if a feature requires changes to the backend or Rails, a plugin is necessary, whereas if the change only affects the frontend (Ember and CSS), a theme component is sufficient. pfaffman adds that if a feature can be accomplished in Ember only, a theme component is easier to install as it doesn’t require rebuilding the Docker image.
merefield shares examples of plugins that were converted into theme components, such as the Topic List Previews and Guest Gate, after some of their functionality was adopted by the core Discourse code. Canapin also shares an example of a plugin that was later recreated as a theme component, the Video Upload plugin.
In summary, the choice between a plugin and a theme component depends on the functionality required, with plugins being more powerful but more complex to install, and theme components being easier to install but limited to frontend changes.
Continuing the discussion from Thumbs up, twice:
Sorry, I didn’t try search — I’m a horrible person.
But if out there is a plugin and a theme component and those do (almost) same thing what is the most important difference between those two?
A plugin needs rebuilding, of course, but is there some other reasons why other is better choice than other?
First, the Reactions plugin and the change-like-icon theme component do not (almost) do the same thing.
Yes, you can use the Reactions plugin to change the like icon but its main purpose is to offer multiple possible reactions, so its functionality is much broader than only a cosmetic change.
A plugin can do everything a theme component can do, but a theme component can not do everything a plugin can do.
A plugin consists of server-side and client-side code,
and a theme component consists only on client-side code and has to rely on existing server-side code.
That’s true between those. I didn’t think that much, being reactive was my middle name today 
So — in real world plugins and components do never same things and then the only reason to use this or that is what it serves?
That is so abstractly worded that the answer is probably ‘yeah’.
That’s true, but it seemed from another topic that all he wanted to do was to do what the theme component does and just have a single 
rather than a 
.
If you need changes made to Rails (like you need to store or retrieve different data from the database) then you need a plugin.
If you’re changing only the front end (Ember and CSS) then a theme component will do the trick. (A while back, the difference was more nuanced.)
If what you’re doing can be accomplished in Ember only, then a theme component is easier to install since it doesn’t require rebuilding the docker image.
I took this to its logical conclusion with Topic List Previews (TLP).
This used to be a plugin, until some of its functionality was adopted by Core (thumbnails) at which point I was able to put most of its functionality into a Theme Component to give it a bigger audience and an easier install.
I’ve added and kept some advanced features that require changes to the back end in a complimentary plugin.
Another good example here is Guest Gate Theme Component. This started life as a plugin, but turns out you don’t need it to be, so was reborn as a new Theme Component (plugins predate Theme Components).
There are probably still one or two plugins that could be converted into a Theme Component (I can think of one of the top of my head) … and there are likely to be more candidates as more functionality is added to the core API …
This plugin:
Was made as a theme component later as well: