Examples Templates Store Pricing Docs Turbo CSS Blog Boomla WishList Introducing Turbo UI Named buckets Turbo CSS is Tailwind CSS on steroids Introducing Turbo CSS, the most advanced web-design language Calculate how much storage you use Better login system Collaboration settings Filesystem and Database are not cutting the problem space right What I'm working on 64bit File node IDs New how-to videos Creating buttons gets easier Introducing reusable components HTTPS by default Introducing the Boomla Theme CDN for faster pageloads Write your own website builder on top of Boomla On On composition Shared admin access A fresh config editor Building a multi-purpose theme A filesystem to replace your CMS New file link type: scope Mobile editing support Inline file wrapping changed Package sandboxing New PHP-like JavaScript engine [sjs-4e] Send emails to the website owner New JavaScript engine [sjs-4] A better editing experience New email service provider Glossary and other changes New panel changes Improved registration flow Boomla goes multiplayer Using local dev tools Why Boomla doesn't need Git File Panel Let's build a community Automatic updates Improved sjs-3 API New Frontend CSS modules Work offline with Boomla Faster page loads via caching Drag & drop supercharged Supporting CommonJS modulesĀ  Paranoid about loosing data IDE usability improvements Simple App install flow Meetups in Budapest Goodbye broken links Flow control from user space Customizing apps Contextmenu support for apps Deprecating the .Class file Hello Changelog Embedding 3rd party plugins Introducing Tools Installing apps just got amazing Public beta Host on our servers Simple deploy with push/pull Version Control for the Web 350M files on a 1TB disk 2 weeks in review
Control Panel

Named buckets


This is a developer post.

The Boomla Filesystem has changed a bit. We used buckets in the past, then about a year ago we have replaced them with sections. This was a year focused on making Boomla websites look great and figuring out if sections are a good idea after all. We could say this was a large experiment. I knew that buckets were flawed, I suspected that sections are also flawed, I just didn't know how to do better. That's why there was almost no documentation on them as I expected them to change or retire.

The experiment is over, R.I.P. sections, welcome back buckets - with a twist.

What are sections?




Sections have been regular files used to group children of a file. For example, a file representing a two-column layout would contain a section child named left and a section child named right, which in turn would contain all the files in the left and right columns respectively.

Thus, sections show up in file paths and URLs. For example, an image in the left column of said container could have a path container/left/image.jpg.

This is fairly easy to understand, which is good. It also makes URLs incredibly long and hard to read, especially if you have a nested layout structure, which is super ugly. These section files need to be created within each app instance and they also may be accidentally removed, which may cause bugs.

We also thought it's a good idea to use files because all the features available for files are immediately available for sections, like file links, file types, etc. Sounds like a huge plus but we have never used them over a year.

What was wrong with buckets?




The biggest issue with buckets was that it was hard to learn them. I've explained it countless time to developers and it was the number one hardest concept to understand. Getting rid of the concept and using files instead seemed like the way to go.

But what exactly was hard in learning them? Well, there were 256 buckets, identified by bucketIds ranging from 0 to 255. These buckets would always exist everywhere in every file. Bucket 0 was for code and other assets, and the rest were app defined. For example, a two-column layout would use bucket 1 for the left column and bucket 2 for the right column.

You could also not see the buckets in the IDE. There was also no way to list them. So buckets were like a mystical thing.

Fixing buckets




Yet the way buckets worked internally was just perfect. It wasn't the concept that needed changing. It was the aesthetics. That's why we have moved to using named buckets, so that you can understand what the buckets do instead of having to guess them.

Buckets also became a first-class concept in Boomla. You can list all the available buckets in a file. You can also select the Bucket object itself and pass it around. It's not just a property for selecting files on the filesystem. It is an object in the filesystem tree.

You can also see them in the IDE as part of the hierarchy instead of a property of files, which helps in building up your mental model of it.

That was crucial because buckets do have their own special behavior. This has to be respected, or we will have to fight the consequences in workarounds. Trying to squeeze files into their place just didn't work well.

Elevating buckets to a first-class concept is the best approach if you believe in always using the best data structures for the job - which I absolutely do.

What is affected

Pretty much every layer had to be changed:

  • the Filesystem,

  • the way components work,

  • the sjs-4 engine,

  • the nocode editor,

  • the IDE,

  • the available building blocks in the uikit.boomla.net package.


I explained what I'm working on a couple of posts ago. This feature was required by the HTML/CSS UI-kit and the developer onboarding docs. Can't wait to release them!


you can follow me on Twitter