I started this thread a few months ago because I was already questioning whether Core Framework was still necessary for Bricks.
Since then, the situation has changed. Core Framework is going open source, which is good in principle, but the developer also made it clear that his main direction is now his own CMS. He said that he no longer wants to keep building primarily inside other ecosystems such as Bricks, Oxygen and WordPress.
Because of that, I no longer feel completely comfortable using Core Framework as the foundation for every new Bricks project.
I have now removed Core Framework from my starter site.
The problem is that I built a large part of my workflow around it.
I use three different remote template libraries, and all three are based on Core Framework. One of the biggest advantages was that they all used the same variables and utility classes.
Typical examples are variables such as:
var(--space-m)
var(--space-l)
var(--text-m)
var(--primary)
var(--secondary)
They also used common utility classes for columns, spacing, responsive layouts and so on.
That made templates from different providers reasonably consistent. I could import a section, change a few variables, adjust some classes and continue working.
After removing Core Framework, the structure of the imported templates is still there, but many styles no longer work because the variables and utility CSS were supplied by Core Framework.
Bricks now has a much better native Style Manager. It can create spacing variables, typography variables, colors, classes and Theme Styles. My current Bricks installation has already generated native spacing and text variables.
However, Bricks does not seem to provide a complete utility framework comparable to Core Framework. It gives us the tools to build one, but not a complete set of layout, grid, spacing, button, width and responsive helper classes without spending much time creating them by yourself.
I also deleted all old Core Framework variables, so the imported templates currently need significant repair.
At the moment, I see the following options.
Option 1: Reinstall Core Framework
This would be the easiest solution. My existing template libraries would work again, and I could continue with the workflow I already know.
However, I would still be using Core Framework as a critical dependency in new client projects, even though the main development focus appears to be shifting away from Bricks and WordPress.
Open source reduces the risk of the code disappearing, but it does not necessarily guarantee long-term Bricks maintenance.
Option 2: Keep Core Framework removed and recreate compatibility in Bricks
I could recreate the relevant Core Framework variables and utility classes as native Bricks variables and global classes.
I could also temporarily install Core Framework on a test site, export its generated CSS and import that CSS into the Bricks Style Manager.
Then I could delete what I do not need and keep only a smaller compatibility layer.
The result would be native Bricks variables and classes, but with Core Framework-compatible names and without the Core Framework plugin dependency.
The problem is that I do not know how much of Core Framework I would realistically need to reproduce.
Would a small set of common variables and utility classes be enough, or would I gradually end up rebuilding most of the framework?
There is also the issue of future templates. A newly imported section might use a variable or utility class that I have not added yet. That could mean repairing every new template again.
Option 3: Build my own small native Bricks system
I could ignore Core Framework compatibility and create my own naming conventions directly in Bricks.
That would give me full control and remove the external framework dependency.
The disadvantage is that my purchased Core Framework template libraries would no longer be plug-and-play. Every imported template would need to be converted to my own system.
At that point, I would lose much of the reason why I bought those libraries.
Option 4: Move to Automatic.css
Another option would be to switch to ACSS.
ACSS appears to be actively developed, has strong Bricks integration and seems to have a larger ecosystem of template and component libraries.
However, that would mean paying for ACSS and probably buying new ACSS-compatible libraries.
My existing Core Framework libraries would still not become compatible automatically.
I would also replace one framework dependency with another.
That may still be worthwhile if the ACSS ecosystem is larger, more stable and better supported, but it would essentially mean starting over.
Option 5: Use framework-independent libraries
Framework-independent Bricks libraries sound attractive, but I am concerned that every library will bring its own class names, variables, spacing conventions and component structures.
One library might use --space-md, another --spacing-m and another --section-gap.
The same problem could occur with buttons, grids, containers and breakpoints.
Without a shared framework, importing from multiple libraries may result in even more inconsistency than before.
Bricks’ own wireframes also use their own brxw-prefixed classes and variables. They work independently, but they form another separate design system.
My main questions are:
- Are you continuing to use Core Framework in new Bricks projects?
- Do you consider the open-source announcement reassuring, or do you see the focus on Instatic (Core Framework developer’s own CMS) as a warning sign for future Bricks support?
- Has anyone migrated Core Framework variables and utility classes into the native Bricks Style Manager?
- Is there a practical way to import the generated Core Framework CSS and turn it into native Bricks variables and global classes?
- How much of Core Framework did you actually need to recreate to keep compatible template libraries working?
- Are Core Framework-based template libraries effectively useless without Core Framework, or can they realistically be converted once and then reused?
- Has anyone moved from Core Framework to ACSS? Was the switch worth the additional cost and the need to buy new libraries?
- Is the ACSS template ecosystem significantly larger or better than the Core Framework ecosystem?
- Is it better to commit to one framework ecosystem, or avoid frameworks and build a smaller native Bricks system?
- How do you handle framework-independent libraries without ending up with inconsistent variables and class naming from every provider?
- Would you keep the Core Framework variable names as a compatibility standard, even when the variables are managed natively in Bricks?
- Does anyone maintain a lightweight Core Framework compatibility layer for Bricks without running the actual Core Framework plugin?
- Are my existing Core Framework template purchases now effectively legacy assets, or is there a sensible long-term workflow for continuing to use them?
At the moment, I see three realistic outcomes:
A. Reinstall Core Framework and continue as before.
B. Import or recreate a smaller Core Framework-compatible system inside Bricks and remove the plugin dependency.
C. Start over with ACSS and move into a different template ecosystem.
The frustrating part is that the templates themselves are not bad. They saved me a lot of time, and the shared Core Framework conventions were probably their biggest advantage.
I am not necessarily trying to eliminate every dependency. I mainly want a setup that is maintainable for client projects and does not force me to rebuild or repair every imported section.