Oh, absolutely. I am saying that we should to better than WP if we attempt any form of competition. We can’t just proclaim victory because we are using Elixir and thus the BEAM VM. That’s not good enough.
dimitarvp
mayel
It’s worth mentioning the work that BeaconCMS has been doing in this space, not only creating a widget/component-based CMS with WYSIWYG drag-and-drop UI but also with mixing markdown, HTML, and HEEX in these dynamic widgets (hence doing runtime compilation).
And there’s our work on Bonfire (a federated app framework rather than a CMS) which is fully modular (every piece of code lives in an extension/plugin meaning it has its own repo and can be included as a mix dependency) and allows admins and even users to toggle extensions (using something like feature flags that checks if extensions or even individual modules are enabled or not). But we’ve chosen to not try for installing new extensions at runtime, instead you can define which extensions should be available in config (including some you don’t want enabled by default) and then let CI build a release that includes all necessary code.
0
LostKobrakai
venkatd
I think it really depends on what examples of extensibility you would want. I would start with writing down what plugins you would implement and work backwards from there.
For example, certain types of plugins could be purely frontend-driven.
I think Shopify has some stuff you might take inspiration from:
They are moving in the direction of Shopify being headless. Then many plugins can provide different frontends to the core headless Shopify store.
0
venkatd
I agree with you it’s not a technical issue. My worry is that if the plugin system is in Elixir, there would be a barrier to contributing. The Elixir community is relatively small vs the JS community.
1
the_wildgoose
I had always thought Surface UI had the potential to kickstart a bunch of CMS opportunities. To explain that thought, it’s the pre-cursor to current Live View and their components. However, whilst many of those features made their way into current liveview, the remaining differences are that in Surface, all components look like HTML entities! So from the point of view of an end user programming stuff, there is very little gap between writing a <p> tag and a <customYoutubeComponent> tag. Also whilst the components are extremely similar to current liveview components, they are a little bit more rigid and it’s simpler to communicate between them. End result would be that you could package your plugins as these style of components much more easily and use more off the shelf HTML WYSIWYG editors, or a Wiki alike system
Anyway, it seems like interest in Surface massively dropped off with the creation of current Liveview, (which is understandable as for a developer you have everything you need in current Liveview), However, I think if you wanted to make a CMS system which is usable by non-programmers (or less IT geeky users), then there are significant wins for Surface
Just my 2p
1
Zurga
Really agree with these points. I am still a very happy user of Surface.
To add my 2p, I think Surface Contexts can also provide great value within a plugin ecosystem. This way components can extract the data they need from their environment.
1