I really think that if you want to make a simple website that doesn’t need like a store or elearning area or that types of things you are better off with no CSS framework.
For example:
Use a simple css file with the utopia.fyi for fluid typography and responsive spacing.
Use bricks classes.
If you need something like a advanced grid for like a blog carousel or a blog archive that can be used as a template in bricks, you can use a little custom css grid and done.
I repeat, this is only for simple websites or like landing pages that a CSS framework might be overkill
With “Bricks classes” you mean, when we create our own classes, or do you refer to any prewritten classes Im not aware of in Bricks? I now see that I have 16 classes in Bricks, I guess they came because of some templates I imported, since I did not created those classes.
Thanks for the hint for utopia.fyi it looks a good idea to have spaces and typography responsive.
I see, a framework is not needed for simple websites.
Is this fluid type and space from utopia, included in frameworks, i.e. tailwind?
I couldnt find any tutorial yet of using utopia with wordpress, but I will give a try and test it, since its free ^^
but you dont need winden so you can use it in bricks, you can just create a css snippet in codebox or in the bricks header with the css variables it gives you and just use them in bricks as a font size variable:
Far away from the problem.
Winden solves no problem for me and others with the same problem.
TW makes no sense in my workflows I manage for my teams.
The TW topic itself is repeated again and again.
My personal opinion is that this is useless for page/theme builders and sites that use this will go into maintenance hell.
If you like it - use it. I’m a big fan of the “learn through pain” method.
The problem here is acss or oxyprops as frameworks (at least that is the current assumption).
There could be some serious problems with Bricks and ACSS, well its looking like an ACSS problem… For example this is a screen shot from a css test for the acss site, my sites get the same errors, but perfect 100 no errors with no acss.
the link to the test that was done on the acss home page is Yellow Lab Tools - Page Speed audit but you can run one your self on any site,
was posted in the acss group today… wow… does not look good for kevin hope fixes this crap…
actually we have now tested this on multiple sites, including the actual acss site which is not as bad as frames but still has hundreds errors. Hopefully Kevin fixes the problem, clearly this cant be by design. And I was only reposting what I saw in the inner circle…
Disabling sections of the frameworks and using some tools and like Perfmatter or WP Rocket that can remove unused CSS will help in these type of tests.
Unfortunately, your arguments are just mucking up this feature request. The feature request is about the Bricks Editor performance issues in handling a large number of classes that are available to use.
It’s not about the performance of the pages in the front end. Create a new post for your complaints about what the frameworks are doing wrong.
I have just bought a copy of ACSS+Frames LTD, and these are my thoughts too! I don’t really want to be stuck with a pair of lemons after the 30-day refund period if it is something they cannot fix.
@sebastianberger and all those who have experienced it, what have ACSS and/or Oxyprops replied? Are they considering a CDN solution similar to Winden/TW to solve the CSS Delivery problem or any other solutions to fix it from their side? What’s been their feedback?
Thomas and his team are working on this and I know that Kevin has it also on his screen.
Thomas wrote me yesterday that I’m able to test 1.6 beta 2 and try if this run better. I hope this works out.
A CDN will not solve the problem at all. It only might speed up the load time for CSS. It will not reduce the amount of classes used.
In ACSS you can switch classes off that you don’t use, so they aren’t loaded. It’s a manual process.
As long as you what classes you’ve used, that’s an easy way to do.
As Frames also uses ACSS classes, it’s a little more challenging to turn off the right classes. And Frames also uses it’s own classes.
And if you use plugins that are front end related, they will also come with their own classes.
If you want ultrafast pure websites, you’ll have to write everything yourself and idealy use static html and no database.
I think it’s in generally a good to avoid any overhead, but you shouldn’t overdo it either. Ultra fast loading times are only one parameter of a lot parameters for a good website.
Ah, perhaps I should have been a bit more specific Markus; I meant for them to create their own JIT (Just in Time) delivery method (which comes via a CDN) just like their competitor.
This will only deliver the CSS and classes on demand instead of having one massive file of classes that needs to be parsed even if those classes are not or may never be used.
In essence, it does this for you what you mentioned below but probably a bit smarter and more efficiently :
I think the rest of your message is about frontend performance which is not the issue here. I was not talking about a CDN in terms of its more basic or traditional website delivery use cases, which you seem to be referring to.
It’s the backend performance that has led to this ticket being created which has been caused by the x thousands of classes being loaded into the builder.
But as Sebastian said it seems Thomas is working on something and Kevin has a screensaver so fingers crossed it amounts to something .
If it’s a complete automatic process, that’s OK. But to implement a JIT compiler for all possible plugins Bricks needs to write and define an API and document the whole process. And plugin designers need to follow that, otherwise a lot can break.
I’m not shure if i need that for small to medium projects.
Also ACSS (2.1.4) is at around 165 KB (compressed) at the moment, if everything is turned on. Shure there will be some overhead from overriding existing CSS with !important. But it’s far away from 10 to 30 MB or other “stupid” file sizes that tailwind can generate.
Oh, I agree for sure, It definitely won’t be a walk in the park where you could muster up a solution on the back of a cigarette packet.
The only reason I highlight the solution from TW is that they have a solution, and sometimes you don’t need to reinvent the wheel if a viable solution has already been sounded out (A lot of saved hours in investigatory work).
The issue that ACSS & Props will have is if they rely on the builder (whichever it may be) to fork out the dev work, then that will most likely lead to lower adoption and longer lead times to integrate, rather they should have the compiler and a fairly universal / Rest / easy-to use API to share with the builders to integrate (once they have amended it slightly to account for the difference in the controls for that specific builder).
Either way, it seems both are quite stum on the matter, so perhaps they are already having discussions about it and will let the masses know when a solution has been decided upon.
AIFAK there is a current discussion between Kevin and Thomas, beause a lot of CSS utility classes can slow down Bricks on slower machines. So i think they are aware of one part of the problem.
Shure the JIT solution Tailwind has is pretty smart. But at the same time i don’t see a need for that at the moment. As said, if you configure ACSS right, the additional CSS load might be 100 Kb in one file, which is nothing compared to some pics not compressed 100% properly or other mistake not so experienced devs make with their Bricks builds (like loading 20+ .woff files) - and than complaining the Builder is bad or badly designed.
I also thought about buying ACSS+Frames LTD before. But for me it does not make sense to buy a LTD plugin which can only be used if you pay yearly an additional plugin “ACSS” from the same company. Therefore Frames is not really a LTD product. You have to pay yearly to use Frames LTD.
.
