⚠️ This article was written in and contains out of date information.
What is CODECABIN?
According to the CODECABIN website, it's "An Umbraco Event Like No Other".
CODECABIN is the premier, invite-only weekend away for Umbraco developers, providing time to code, learn and network in a completely relaxed and open environment away from the hustle and bustle of every day life.
Which is a pretty good summary.
We hacked on Umbraco related packages; played with new Umbraco features; discussed all things Umbraco past, present and future; played games; enjoyed the scenery; and, boy, did we eat well (thank you again Lucy!)
Food featured some fabulous local gelato
Photo by Owain JonesWhat happened this year?
This year's programme included 4 discussion slots (which worked a little differently to previous years), dedicated hacking time, a walk to the nearby Froggatt Edge viewpoint as well as a quiz and awards night!
What did we talk about?
This year the programme included slots to discuss items from our "discussion backlog" where in the weeks leading up to CODECABIN we has contributed suggested discussion topics to and voted on our favourites. In each slot, we'd discuss the most popular topic remaining to be discussed until it came to a logical conclusion before moving onto the next most popular topic on the list. This is different to previous years but seemed to work well with Matt and Lee's guidance setting up the next topic and suggesting when may be good to move on.
Here are my takeaways from each discussion we had.
(Please note: these are my takeaways from each topic, not necessarily the "correct" takeaways or what the group as a whole took from the discussion.)
Headless is the new black
Discussion centred around static site generation and single-page JavaScript applications (SPAs) using the new headless Umbraco Content Delivery API as well as non-web applications for the API, such as mobile apps.
Some had reservations about the application of headless sites being used for SPAs unnecessarily but the performance and sustainability benefits of static sites were also highlighted.
Segments
In this session we discussed some confusion and potential UI bugs for the non-language variant variants, segment variants. The experience feels less polished than the language variant journey and lack of up-to-date guide made things challenging for some developers. Although the 2022 24 Days article was still useful to help get things started, some cheese had been moved.
We looked at a sample implementation and discussed ways of improving it.
Segmentation seemed to be on many developers radar, but it seems to be underutilised except by uMarketingSuite so far.
Front-end frameworks for websites (not web apps)
The discussion began as a search for lighter-weight frontend frameworks than Angular, Vue or React and more in line with how we might've used jQuery, jQuery UI and jQuery plugins in the past. The consensus was that these larger frameworks are more suited to "JavaScript applications" and are too much for many "lighter sprinklings" of JavaScript.
Apline.js was discussed as a lightweight framework which allows for considerably less JS to be written since a lot of Alpine is applied by adding attributes to elements.
However, general consensus seemed to be that vanilla (frameworkless) JavaScript was incredibly capable these days, particularly for selecting elements by selector (document.querySelector and document.querySelectorAll) and fetch in place of AJAX.
For interactive components, people suggested finding vanilla, single-purpose libraries (e.g. one for a carousel and another for tabs) which should be checked for accessibility and maintainability on an individual basis. The use of these components is much easier using JS modules or compiling modules using a JS bundler like WebPack or Vite.
Vue was suggested as the lighter of the "full-fat" frameworks and it was highlighted that using these larger frameworks for a single module within a larger site may be appropriate - the whole site doesn't have to be Vue, perhaps just a smaller interactive component.
Deployment basics
We talked about the lack of documentation around deployment using Azure Pipelines and Github Actions. Although it's potentially something that sits outside the realms of the Umbraco Documentation, it was agreed it'd be helpful. I believe there is some draft documentation in the works, so we look forward to seeing that in the future.
Build a better back office
Discussion mostly lead to ways of improving the default dashboard to make it more easily customisable for users and developers. The concept of customisable widgets which a user can add and remove from their own dashboard was suggested by the group where these widgets could be more easily generated by developers. The widgets may also be able to be added to content apps with extra context. Although we believed this would be a fantastic addition to Core, Markus suggested he might add some of these improvements to his The Dashboard package.
Current state of package development
Concerns were raised by package developers about the skill gap and effort involved in converting packages for the new backoffice (expected in v14). Additional support for package developers from HQ would be welcomed.
The group suggested that the community as a whole wouldn't be "expecting" developers of free, open-source packages to be ready for v14 on release date and that a pace to suit developers is the most appropriate.
After CODECABIN, Lee announced that he was no longer planning to release any version of Contentment for Umbraco 14, instead choosing to aim for v15's release.
Another concern was that package development may have slowed in newer versions. Some suggested reasons for this included:
- developers don't want to build packages only to rebuild the frontend in v14 (see Web components, below)
- duplicate/similar packages are less commonplace than they used to in earlier versions, one package has come out on top and the similar packages have died off
- we've refined the set of packages we use as a community
Web Components
Web components were a running theme throughout a few sessions. Many developers were daunted by them and they were briefly explained within the context of the backoffice and packages (with Lit) as well as other uses for them.
I suggested that it's possible to develop a new package in current Umbraco versions as a web component, with only the Angular-to-web-component layer that would need replacing in the v14 backoffice. This is a subject Jason Elkin is planning to talk about at upcoming Umbraco events. I'll update this post when more information becomes available.
I also demo'd an obscure use case of web components and the shadow DOM as an example of how web components can be used which I will also be talking about at Upcoming Umbraco events and will update this post when more information becomes available.
Grading and categorising community blog posts
(originally "How can a 'best practice' Umbraco demo site be created?")
This one went a little off-topic! Although we were aware of many existing “best practice” starter kits and demo sites, we realised it was actually quite difficult to create a best practice site for all occasions - even taking opinion out of the equation, we don't have one way of building a site even for ourselves. If performance isn't a priority but being flashy is, we'll architect and code a site completely differently to one where performance is the be all and end all.
We then started to think that perhaps marking content as "beginner" and "advanced" may help to distinguish a generic "best practice" from a "best practice for lightning performance" or "best practice for [insert niche here]".
We also thought that standardising categories and hashtags would help with this problem, as well as discovery - another issue with the existing “best practice” sites.
A common set of categories would also allow the Umbraco Community Blog Posts page to be filterable, making it much more useful.
Discussed categories were "beginner", "advanced", "content editors", "developers", "accessibility" and "performance" as well as version-specific classifications. But no documentation has been generated as of yet. I'll update this blog post if something does.
Taming AI
This discussion was mostly about utilising generative AI (OpenAI's ChatGPT and GitHub CoPilot in particular) for software development purposes. Although many had not used AI much for software questions, those that had noted how the answers were often a good starting point but often needed correction. In fact, a study was referenced where the researchers found that 52% of ChatGPT's answers to code questions were incorrect.
Developers should use AI generated code with caution and check code samples even more thoroughly than those found on forums. It was, however, agreed that developers using AI would likely be more productive and that we should be embracing this technology.
I mentioned that my talk "How to Copy & Paste" at the Umbraco US Summit may be pertinent, and I will share a recording of it when I have one.
Umbraco Builds - LTS or STS?
Deciding which version to put a client on is never a straight answer!
Some newer STS (Short Term Support) releases go into the "security phase" of support at about the same time as their most recent LTS (Long Term Support) version, so is it worth sticking to the LTS version or providing the latest and greatest? For example, v12 (STS) enters its security phase on 29 March 2024, just 2.5 months before v10 (LTS) enters its security phase on 16 June.
"Does the client even require LTS support?" is the first question. If you have a client on retainer including regular upgrades, it may prove easier to always be on the latest.
If a build is going to last a long time, we generally start the client on the current latest (or even preview) and upgrade them as the project goes on - stopping at the LTS if nescessary.
Of course, if a client needs a new feature (Content Delivery API, for example), it's rarely worth them holding back to the previous LTS. You'd probably start on the latest STS and factor the upgrade to the next LTS into the cost, if an LTS version is even required.
It was understood that upgrades from LTS to LTS are possible (without upgrading to intermediate STS versions), but it was raised that community and even official Umbraco packages may not offer the same support. It was suggested to HQ employees that for consistency this should be the case for official packages, particularly those that come with Umbraco Cloud such as Forms and Deploy.
Multi-sites and shared content
This discussion was around the Reusable Content with Global Blocks RFC (Request For Comments) and having reusable content within an Umbraco site. In particular, consensus seemed to coincide with Matt's comments on the RFC that global content could be nodes in their own right, not just blocks.
Reusable nodes could include anything that does not logically fit into the tree structure, such as office locations or team members. This repository pattern is seen in other CMS'.
You could even have blog posts as repository items to more easily replicate a WordPress-style URL structure like /blog/2022/09/14/codecabin-23, since WordPress also has a repository structure for blog posts. Where some Umbraco blog solutions require blog posts to be manually sorted into a date-based folder structure.
We discussed that having multiple library tabs (/applications) in the navigation bar may be desirable (e.g. Blocks, Blog) similar to how Konstruct works.
It was also suggested that media should be a library type as well, since it's essentially the same thing.
Other sessions
There was also shorter sessions on "Optimising and caching Umbraco websites" and "Umbraco server beyond .NET" as well as a show & tell session but I have little to comment on from these.
What was I hacking on?
Matt, Rachel and I started work on an ActivityPub integration for Umbraco to allow for blog posts created in Umbraco sites to be pushed out to ActivityPub servers (like Mastodon) as posts to aid in their sharing. WordPress has a plugin to do this, and we'd like to release an Umbraco package in the future. ActivityPub comments could also be a future enhancement. We also realised this integration could generate RSS feeds and trigger IndexNow requests in the future. I'll update this post when something becomes public.
What else did we do?
It couldn't all be Umbraco-talk now could it!?
We were kept well fed and watered (of the regular, cola, hop and juniper-flavoured varieties) too, with some great discussions over the bar and dinner table (writing the script to Bloodswarm: Revenge of the Gnats comes to mind!)
A keen crew got up for a run every morning although I decided I ought to stick to my rule of one 5km run per year (at CodeGarden), as is tradition.
But I did attend the walk with a large group. Although only a few kilometers, the walk was spectacular and allowed us to see the cabin from the scenic Froggatt Edge on the other side of the valley, as pictured.
The view from the top
Photo by Richard JacksonKarl hosted us a fantastic children's birthday party pirate themed quiz, in which we came last but with a smile on our faces and a rather respectable score of 69.
Last place, but enjoying ourselves
Photo by Karl TynanInspired by the pirate music used in the quiz, there was also an impromptu "Pirates of the Carribean" movie night (can you believe Delia has never seen it?!)
Lotte hosted the fabulous CODECABIN Awards evening, the 6 awards I earned proudly displayed on my shelves behind my desk!
Lotte also provided entertainment throughout the weekend by providing homemade Umbraco-themed boardgames - CODECABIN Who? and UmbDobble, which were both fantastic!
Lotte's personalised Guess Who? board.
Photo by Mike MaceyNext CODECABIN
CODECABIN 24 is set to be from 20-23 September 2024.
I'll certainly be applying for next year, I had a fantastic time. Not only did I learn a load about the Umbraco ecosystem, I've had my enthusiasm for contributing reignited and I had a great laugh doing it.
CODECABIN isn't like a regular conference. It requires an application process which is starting "soon" for CODECABIN 24. Keep an eye on @codecabin on X and other community social channels around that time and get your applications in (applications usually close just after CodeGarden).
How do I get my boss to pay for all this?!
Although people do pay for themselves to attend CODECABIN, I find it's always worth a shot persuading your boss! It's great fun, but honestly, it is work. Just like I'd ask for other conference tickets, CODECABIN has reignited my passion for open source and taught me many lessons pertinent to upcoming and future projects. The event gives you time to network with people you might not otherwise meet but also code with Umbraco MVPs and HQ employees like you never would at a regular conference.
Considering it's a fraction of the cost of sending someone to CodeGarden (let alone a more expensive conference!) and includes all food and accommodation and just how much more I got out of it, CODECABIN is a bargain for employers.
Read more
More blog posts by other attendees:
Hero photo by Richard Jackson
"Nerds in the Woods" as dubbed by Richard Ockerby's wife.