During a Beam Dreamers meeting, I shared that I’m a PHP and Laravel developer, and someone jokingly referred to “PHP as a walking zombie.” They said the main reason it’s still popular is due to slow and bloated WordPress installations. They also jokingly, I assume, stated that if someone created WordPress in Elixir, that it would be awesome. I am wondering how difficult it would be to implement a simplistic version of it? From reading some threads, the biggest issue is implementing a plugin system. However I still would like to hear everyone’s input.
I always wondered if JS based plugins plus an API would be enough. As installable plugins that is. You won’t reach Wordpress level plugins where that can create whole tables and such but is that even necessary? Or perhaps the API can allow that?
This comes up every now and then.
Read some comments here: Use Elixir to create the next Wordpress?
3 Likes
I think it’s doable but not easy. By far what gives Wordpress such an advantage is the plugin ecosystem.
I think @hlx is spot on where plugins are probably best done in JS (typescript/react?) to tap into a larger community and reduce the learning curve for implementing something.
One should also not try to compete DIRECTLY with Wordpress. Better off having a smaller ecosystem of higher quality plugins and a smaller more focused product.
Think about Figma vs. Photoshop. Photoshop had a lot more features but Figma focused on doing a subset better – and just for web/app design.
2 Likes
How would I implement the plugin system in JS? I am halfway done with the course, and most of the remaining lessons deal with non-language stuff. So I would like to start practicing what I learned by doing small mini-projects to reinforce my learning. Here are exercises for Rust and here is Python’s version of that. I believe I saw others, but I can’t find them at the moment. Can anyone recommend some for Elixir?
I don’t see why Plugins would be an issue. BEAM got Hot Reloading and we can create new modules etc. So I don’t see why it would be hard to have plugins that are read in as new modules. The way plugins work and are designed would probably be a bit different since Elixir is a functional language etc.
I think the issue isn’t technical but rather that it would be almost impossible to compete with WP with thousands of plugins and themes since an elixir version would have a lot less. And most users won’t care about whether it is Elixir or PHP.
Security really. WordPress was and likely still is one of the most attacked software on the planet. It takes just one malicious addon and your instance is toast, because the BEAM VM runtime is quite trusting. Zero sandboxing or any other security inside the node itself.
Yep. That. Agreed.
2 Likes
That applies to everything that as MineCraft was even susceptible to malware in the png used for setting players skin. Also many WP themes that encrypt their source code have been found to have malicious JavaScript code.
The fact that most programmers are clueless as puppies when it comes to security does not mean that the rest of us must collectively give up. “It’s all frakked up anyway” is not a philosophy I subscribe under.
2 Likes
Security really. WordPress was and likely still is one of the most attacked software on the planet. It takes just one malicious addon and your instance is toast, because the BEAM VM runtime is quite trusting. Zero sandboxing or any other security inside the node itself.
Yes, but that risk you also got every time you install a library too. Part of reason WP is so targeted is because it is so widely used.
(For the record, I’m not a fan of WP)
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.
2 Likes
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.
It’s not exactly elixir, but there’s also zotonic as an erlang based cms.
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.
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 Like
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
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.
