The debate between using Drag & Drop builders like Gutenberg Blocks and custom coding for website creation is a common one. This analysis delves into the advantages and disadvantages of each method, providing insights on when to use each for optimal results.
Often we get asked – and stand ourselves in front of the question – whether to use Page Builders, or Gutenberg Blocks, or to use custom Code like HTML, CSS, JS (and PHP). Or in other words, how do you create a website and make it look good, while retaining all the custom functionalities required, and not impacting performance.
It depends. TukuToi’s services target mainly logic implementations, so, often we don’t have to deal with the “pretty” aspect. Our estimated Clients will design independently (using one of the plethoras of builders or blocks), or they employ designers doing it for them, and when they get stuck on “this can’t be done with CSS/HTML/DnD”, that is where TukuToi comes in. So, often we have to add “only” PHP functionality to projects.
However, when it comes to design aspects on our own websites, or projects where the client hires us for “the whole thing”, not just Logic, we try to evaluate – before the project starts – how complex it will be.
If we hear “If/Else, Maybe/Then, Should Show this when that happens, Selectable Images instead of radio boxes”, etc., then we know this can’t be done quickly and easily with visual builders and right from scratch, we suggest a classic approach. This means no builders or Drag & Drop will be involved.
In those cases, we look at sites and designs the client likes (or perhaps they have designs made in the form of PSD or Figma mockups already), and of course, we’ll be implementing those with classic HTML and CSS around the PHP logic.
Using Custom HTML or/and CSS/JS is not that difficult or time consuming for three main reasons:
- our library of designs and how to’s already implemented to code grows with the time
- there are usually tons of already made “examples” online that we can use as a “starting point”
- ultimately, knowledge about those languages (CSS, JS and HTML) will enable us to make designs almost as fast as a DnD can while allowing any customisation required afterwards.
The last point is the core reason we do not “like” or suggest Visual Builders in general: Visual Builders tend to make the user not learn anything, while locking them (and us developers) into the builder’s restrictions and custom elements.
One drags and drops and thinks this is what it is all about. But it’s not. Actual knowledge about the underlying used languages counts and will enable us to develop in the future independently, and make amendments as we like, without restrictions of any plugin or App.
In a few years, we fear that the knowledge about these things will fade due to all the visual solutions.
While it is excellent to enable anyone to design a website or content, it also means that users get less savvy and knowledge is not any more “open source”.
Instead, only specialised people will “own” this knowledge.
This might be surprising, but it is directly opposed to TukuToi’s core Business Philosophy (on mobile click here). We believe, not only code but also knowledge and know-how should be accessible to anyone and “learnable” by anyone.
Why use custom code, if we can just use an App or Plugin?
Well, once the knowledge is assimilated, one has no limitations because you can now write code for everything.
You won’t depend on an App or a Plugin and also understand what you’re doing.
It both adds to self-esteem and personal growth to learn something instead of “blindly” using a ready-to-go solution, and of course, keeps a project lean and light, while allowing for any sort of follow up customisation.
It is a bit like this example: in the past, anyone knew where milk comes from. Nowadays, some think it comes from a square carton pack with a violet cow on it. No joke, it is the sad reality.
And that happened because with the “ease” introduced by tetra packs, the knowledge about where milk comes from faded. No one needs to know anymore. We can grab it from the supermarket scaffold, and that’s it.
Or take bread-baking, spaghetti cooking or anything alike. As soon it is “easy to do with a pre-made tool”, knowledge about the “real stuff” fades. And we humans become reacting robots.
Back on topic, to assist during this learning and developing process, one can also use tons of generators for hover effects, shadows, and complex CSS aspects.
There are even code generators like https://generatewp.com that allow to create full-fledged queries and whatnot; without extensive prior knowledge, the curious mind then can learn by looking at what it produces and re-use that.
Visual builders often hide this process from us by generating either custom elements that you can’t re-use anywhere or an unnecessary mess of nested HTML that, again, won’t/should not be used anywhere.
When to use a Builder, or Gutenberg Blocks
When the project is predictably simple, perhaps a simple blog with a simple layout and no conditions, no logic etc. behind it, we opt for Gutenberg Blocks. Blocks over all other builders because
- it is native to WP
- there’s no way we would force an HTML plunder like Elementor forces upon a client (Elementor is an example, and no offence is intended, however it is truth that the HTML produced by Elementor is rather… messy).
- it will be editable by a non-savvy client as well.
- it meanwhile has several plugins following the lead (Such as Toolset, Kadence, and else) that add lots of pretty advanced things to the native WordPress Blocks.
As said, to use Blocks, the site (still) needs to be “standard simple”.
Why do we say that?
For example, these tickets opened by us in Toolset Forum are some reasons why we more often than not need to resort to a complete custom approach for relatively simple things:
- https://toolset.com/forums/topic/1994427/
- https://toolset.com/forums/topic/cred-delete-post-acting-weird-on-rfg-views/#post-1993067 (everything after “Just to make a few examples,”)
- https://toolset.com/forums/topic/any-reason-why-html-comments-are-removed-in-cred-forms/ (the part about labels).
As we can see, relatively simple things can become impossible to achieve even when using advanced tools like Toolset. If you started the project using only visual features, at these points you either will have to ditch the special requirements, create a “hybrid” of visual and code (which is by definition messy), or fully go back to the scratchboard and start afresh with Custom Code.
When not to use Builders or Gutenberg Blocks
An example (which is possible in Toolset for example, meanwhile) was that one couldn’t have inline text next to a block in Gutenberg.
For example, the trivial “33.- CHF” you’d see in any product catalogue wasn’t possible if the “33” was a dynamic block pulled from a field, and the “.- CHF” was static text.
On a certain project in past, we created the entire template for a product using Blocks, everything looked so lovely, and it was quick to implement with Blocks.
However, everything crumbled on that simple feature not existing. Additionally, in the same project, a link wrapping a block (container, in this case) was required. Also possible meanwhile with Toolset, wasn’t at the time. Being the entire Drag & Drop approach (whether Blocks or else) practically uneditable in “code”, these tiny hurdles can become show-stopping.
In the mentioned case, we needed to add Text and Fields block, and inside use ShortCodes + Text. Easy enough, but that’s where the issues started.
The whole idea of using Blocks on that particular site was, the user would be able to edit those on their own without “knowledge” and it would be fast to implement, hence inexpensive.
Or so we thought. Adding the Text and Fields blocks with ShortCodes and custom wrapping links around the items, took more time than the entire template created in Blocks.
Additionally, the client then saw this Text and Blocs field and didn’t know what to do with it.
Because they didn’t know what a ShortCode is, and weren’t savvy of HTML or CSS they started to “mess around” with the blocks visual settings, obviously ending up breaking the contents and referring back to us with a classic “it’s not working, I cannot make any changes to the content that was intended to be all visually editable” 😀
Even for someone who’s used to all the classic approaches, finding a semi-visual element in Blocks is confusing. It adds complexity when editing those elements compared to a plain HTML file (where there’s no preview interrupting the editing, etc.)
The above example gets worse if you have, let’s say, a grid of icons (another project of TukuToi required this).
These icons needed to be Custom made SVG icons with some wrapping href link. We needed to nest Text and Fields inside a Grid Block. That Grid was not extra-large, and we ended up with almost uneditable Text and Fields areas.
In Pure HTML, we would be able to edit the code at any time without hassle because it doesn’t generate previews and is “editable” by default. We could add custom IDs and classes where and how we like, wrap the SVG in links, and so on… When done with blocks (or any visual builder for that is), this kind of layouts become a real “mess”.
Unless, of course, we’d have used some “default” block of some plugin doing just what the client needed. But that’s often restrictive. Additionally, very quickly many (block) plugins would be installed because one does what the other doesn’t, and the third compliments the first, etc.
At that point, we regretted not having used HTML for everything, spending perhaps a couple of hours more on the styling and educating the user on how to make edits, but we wouldn’t have had the semi-visual edit result.
It would all be clean static and non-jumpy code, done with zero plugins.
While the client could perhaps not “do” anything with that the same quick way as when using visual builders, it would encourage him/her to learn CSS and HTML, and definitely keep the structure more editable than with Blocks.
We believe this is important. To allow anyone to understand the code. Visual Builders take that knowledge away from the masses, as previously elaborated.
How to determine if I can do something with Gutenberg Blocks?
Gutenberg Blocks amongst all Drag and Drop Builders is definitely a good choice as long you do not expect any complexity, no large conditional displays, custom elements and behaviour. As said we do not suggest other builders than Gutenberg Blocks based ones, if you are using a Drag & Drop Builder, Blocks is the way to go.
The good thing is, we can find out very quickly if things are possible to be done in Blocks, by jotting the page or content quickly in a Block Editor.
If we get – at any point – stuck, we know it is time to abort and implement in HTML, CSS and JS.
Thanks to the very fast and expedite editing features of Blocks, we won’t have lost a lot of time at this point. It is crucial however to recognise “when to stop trying”.
Our rule of thumb here has become very simple:
– As soon you can’t do it with blocks, abort.
– Do not resort to custom hacks or ShortCodes or text and fields Blocks.
– If you need them, you know your design and logic will likely require more advanced editing features, hence save yourself the time and hassle and move to Custom HTML.
If you can do it all with Blocks, using maximally 2 plugins (for example: Toolset and Kadence Blocks), then go for it.
It will be faster to develop and very easy to maintain, as well as Performant.
Do not – in any case – start installing 10 “Blocks” Plugins just because one has tabs block, the other has dynamic Links and the third has that beautiful hover effect.
This will end up in a nightmare of many plugins installed, eventually conflicting, and updating will become hard.
Are there other tools to visually build a website, without losing ownership of the code and knowledge, and without adding bloat?
Yes!
While this is good only for Mac users, lately we have been experimenting (to draft out things), with an app called “Blocs“. (No “k” – just Blocs).
It is like a bootstrap theme builder, where you can both visually and in code create a full-fledged WP Theme with dynamic content.
The App speeds up the creation of Theme (design) and Logic immensely – after creating the Theme, you can add the particular amendments required “by hand” and edit the generated code.
It mainly helps with things like Bootstrap Layouts done quickly, loops or forms and (the main reason we use it) headers and footers.
It does not use large amounts of custom elements.
It uses plain classic HTML/CSS/JS/PHP to create the themes, hence not hiding the “knowledgeable part” from the end-user.
What’s best? You don’t need any sort of plugin or app on your WP Install for that generated theme to work. There’s no lock in, and the price is a one-time purchase. This App has some real potential to become an alternative to the existing and established tools.
There are also tools like Pinegrow and Bootstrap Studio (cross platform and OS) which allow a large amount of design (always including headers and footers as well), which can help to both speed up visual development while retaining access to code and allowing you to edit, and learn from, the code.
Admittedly this is not as nice as having an editor like Gutenberg directly in the WP Admin, but as said, sometimes the Blocks Builder is just not enough, and we do not want to resort to “lock in” plugins or builders either. In these cases, the above mentioned apps can still help speed things up and avoiding the need of creating everything from scratch, also offering opportunities to see how things are done and learn.
Why is it so important to keep access to raw code, as opposed to just use a visual editor and forget about code?
As mentioned earlier and in other posts, we at TukuToi think it is a core responsibility of us WordPress developers: we shall never forget that WordPress is an Open Source tool, and the code is open to anyone, but without knowledge, open-source code isn’t any good!
It is deeply webbed into our work ethic – to always involve the client in understanding what “they get”.
We use to elaborate on how they can edit HTML, CSS, JS or even PHP independently, even knowing that it will perhaps “avoid them” hiring us again for simple edits.
We believe in this principle so much that we couldn’t stand “hiding” the knowledge we have and instead selling it for money. Or worse, offering our services as a “developer” and then using some drag and drop tool the client could just have installed and used on their own.
We like to share our knowledge, and think that it is good for the community.
It doesn’t destroy work opportunities – on the contrary, clients hire us again because we’re the ones “who take the time to explain” and do not just jot some code or plugin in “that makes it work” — knowing something more at the end as said increases also the client’s self-esteem and pride in their projects.
Conclusion
For simple sites, we suggest to use Blocks. It does not necessarily take away the requirement for a design mockup in Figma or PSD but allows the client or user to make changes on his/her own later and allows for impressively quick deployment.
For more complex projects, we use CSS and HTML and JS (and PHP, of course), which, just like the visual approach, may or may not require a previously made mockup. More often than not, designs “evolve” while creating them, and PSDs or Figma mockups serve as a “drafting board”.
We at TukuToi either make those mockups on our own (we have in-house designers as well, in case professional mockups are required) or “get” them from the client and transform to code, depending on the type of project.
Related to this topic, common questions are Where do we get our design ideas from? How do we decide what colours to use? How much padding should we give and how big should a front size be?
Stay tuned for our (soon to come) next blog post about for some cool ideas and answers on these questions!