On Twitter, I noticed this interesting tweet:
It makes me curious. This is not the first time I have heard of people wanting to leave the WordPress ecosystem.
It’s partly my case too. I am a bit tired of WordPress sometimes, especially now, as I feel that WordPress is in a big transition towards a very good product. I am convinced that going to “full-blocks”, from the posts themselves to the page and the full theme, is the correct approach.
But it takes time.
If you try the last default theme,”Twenty-twenty three”, it’s a nice evolution, but it’s still a bit simplistic without additional plugins. The road towards block-based themes is slow.
Between Twenty-twenty three, GeneratePress/GenerateBlocks, and Elementor, I feel that Elementor still has an edge: their page builder is much more user-friendly while allowing so many features.
So this tweet makes me think again. Is it possible to leave the WordPress ecosystem easily?
This is why I decided to try Filament PHP.
The issue with WordPress
This is obvious, but Filament is not a turn-key CMS: you’ll have to code! I knew it since the start, so it’s not an issue. I was curious about two things:
- Is Filament suitable for developing SaaS applications quickly?
- Does it provide some facilities to replace everything for a typical product: the application itself and the website, blog, contact form, etc.
It’s always boring to develop an app and then build the website promoting it with another product instead of having one code base for everything.
For many projects, the backend application must provide data to the frontend website, which is difficult to do if both are separated. In this case, you’ll need either to:
- Develop a connector within your application to upload everything on WordPress using its API ;
- Develop something on the WordPress side to pull the data from your application.
Problem: plugins allowing to pull external data from WordPress suck. So you will choose the first solution: push and sync the data from your app to your website. And therefore, if you have additional fields to store, you’ll need to add Custom Fields on the WordPress side.
So boring.
Could Filament fill this gap?
This is what I wanted to know. I tested it for a scraping project where I needed to scrap some job offers from a website. I did that with Laravel Splade, which I discovered only a few days ago.
I created a new Filament project and copied my classes, migrations and models.
My project had two needs:
- Visualize and modify the scraped data manually,
- Display them on a nice table or cards on my public-facing website.
I allocated one day in my free time to make my assessment on Filament.
Verdict: Is Laravel Filament good?
Honestly, this is an extremely good product for developing a SaaS application.
Filament will probably be my first choice for newly developed applications
Developing the application in itself was a dream. I tried many, many boilerplates and various admin panels, and I was astonished. Usually, when I test a new framework, I quickly meet some limitations, either due to the product or due to the learning curve that it requires.
And I tried and used many products:
- Laravel Backpack
- Laravel Jetstream
- Laravel Breeze
- Laravel Nova
- Laravel Splade
- and probably some others I forget.
During my tests, everything I tried with Filament was smooth. The docs are clear, everything is working, and there is no surprise. It’s a well-conceived product: I quickly noticed the care of details.
It’s anecdotical, but when you have a config parameter to set the width of the content of pages, it’s a clear sign of maturity. I say that because this has always been one of the first steps I do after Laravel Jetstream installation, except that with Jetstream, you need to modify the code 😉
And have a look at these small UI details:
This care of details is the same for all features. This is a very clever product. I have plenty of examples where I said to myself: “Wow, they planned that”.
They even planned the possibility of setting a badge directly in a cell, which is a common thing that most of the other frameworks leave to the developer.
And this is the same for everything. Filament smells the care of the quality. The last time I said that to myself was with Laravel Backpack. Unfortunately, Backpack missed – in my eyes – the road of client-side features. They still use jQuery, this has been a no-go for me for a few years.
I have been also astonished by the automatic generation of the datatable and edit form of a complex table. I really liked this feature, so powerful to go fast!
The drawbacks
Initially, I expected that the plugins would be the same quality. But it’s far to be the case.
Filament plugins are not plugins
The plugin infrastructure is a nightmare. You can install a plugin that creates the “pages” table. Ah ah ah! This made me laugh. It’s an unsustainable system.
The plugins do not have the same maturity as the Filament — a polite way to say that most of them are pure shit.
I initially put a lot of expectations on the following plugins:
- GrapesJS
- EditorJS
- Fabricator
In my mind, I had the question: “how can I build a page builder with Filament to do my public-facing website?” These plugins seemed appropriate.
But after a few hours, I felt discouraged. No, Filament is not mature enough to build a website.
I played a bit with the GrapesJS plugin, as it would be a good fit for a visual page builder. But I didn’t even find how to customize the options used to launch the instance of GrapesJS.
This is my fault. Sometimes, you should read the fucking manual.
Oops, there is nothing. The fact that Filament accepts such a plugin is so weird compared to the quality of what they did!
No blocks-based editor = No CMS
Blocks-based editors are powerful. Nobody wants a Textarea with some buttons above. They want to put the image where they want, they want to add custom-formatted blocks, they want to reorder their paragraph, etc.
Personally, I cannot live without that, and WordPress opened the way with Gutenberg.
Everything on a website should be a reusable block. No more, no less.
This is clearly what is missing in Filament in my eyes. They implemented forms, data tables, but they didn’t implement blocks. Therefore, some plugins tried to fill the gap, but it goes nowhere.
But what is a block?
A block is a template – associated with potential dynamic variables – that could go in your view, in your admin panel, in your public-facing website, and even in the content of a post or a text.
Building that with the current version of Filament and plugins is near to impossible.
Hey Filament, where is the Word counter?
I will be short on this. Even Filament’s default “Rich Editor” (so old school to still use a “rich editor”) does not have a word counter.
Game over to implement a CMS.
I guess that Filament’s team need to implement a native block-based editor quickly. A “rich text editor” is not enough, and there is so much need for a ready-to-use good text editor in almost all projects!
Overall feedback on Filament
Clearly, I now have some expectations from this project. I would put some $$ on this one as I have been baffled by the quality of all native features. Congrats to the team!
What I would expect:
- Conquer the world of front-end now and quickly: a good block-based editor, a good block-based system for templates, themes or examples ;
- A real plugin system with guidelines and quality controls.
It could be a fork to develop a CMS based on Filament. And if I say that, it’s because I feel we are not so far away from disrupting WordPress hegemony, at least for developers.
Feedbacks received after publication of this blog post
Discussion with a part of the Team of contributors
I receive a few feedbacks from contributors of Filament regarding this blog post. It was an incredible and interesting discussion, notably around WordPress and Filament.
- They underlined that I should not dismiss “all plugins” as they are made on a voluntary basis. This is true. Some plugins are good, others less good. They underlined also that they are just Composer packages, so anyone can make anything.
- They are not convinced by block-based editors and by the direction taken by WordPress. I disagree with this statement.
It was a very good discussion and I thank them for that. Great team!
The road took by Statamic
Statamic is a Laravel-based CMS. Despite their strange and obscure homepage, it’s probably the leading CMS based on Laravel.
I never tried it, discouraged by their price plan, which is very costly:
Someone told me that they have support for “blocks” in the editor. It’s called “Bard”:
Checking the docs, Bard filetypes seem great indeed. Statamic editor is based on TipTap, which is based on ProseMirror. It allows to define new node types. The system seem great, despite qualified as “complicated” by the Statamic team:
It could be a good first step, even if it does not allow a full convergence between blocks for the theme/page builder and blocks for the text.
EditorJS
I had also a look on EditorJS. I didn’t try it, but at a first sight, this is the typical editor I would love to see in Filament.
They support new blocks. This seems not very easy, but I suppose it could be simplified for the end-user. However, this does not solve the need to implement one block concept for everything (for templates, page builder, forms, and text/content!).
What about Shortcodes?
Instead of dealing with the core features of available text editors, it would be possible to do what WordPress did: implement shortcodes.
- This is “easy” to implement, as you’ll need to get the full text, and render the shortcodes;
- It allows a unified block concept, as it can also be implemented in the front-end site, admin section, tables, etc.
The advantage is that it would work with all editors. It could be a nice short-term solution.
Leave a Reply