Before we get started, I can’t stress the following enough: the choices we make at Set Studio don’t challenge your choices. You might also not agree with our choices and that’s fine, but we don’t need alternatives evangelising to us. To paraphrase Rachel Andrew:
If it works, it’s right
I do, however, get asked a lot about what technologies and frameworks we use at the studio, so I thought I’d note them down. This information is accurate as of January 2025.
HTML, CSS and JavaScriptpermalink
Sounds obvious, but even though we’re a design studio, our output — more often than not — is web-based, so we deliver HTML, CSS and JavaScript that is progressively enhanced, performant, and as user-optimised as possible, limited by the challenges of a project.
Regardless of what tools, frameworks and technologies we choose to use — or have to use — we always prioritise the end-user getting semantic HTML, flexible CSS and progressively enhanced JavaScript.
JSX-orientated libraries and frameworkspermalink
“JSX?!” I hear you scream or “don’t you hate React, Andy?!”. I don’t hate anything when it comes to code. I do prefer as little React as possible landing in the browser for the user which frameworks like Astro do a great job of with their islands architecture. This allows us to only send client-side React when it is absolutely needed, rather than by default. This is also why we always try to use Astro instead of Next JS, because the output bundles are a fraction of the size of the other when we use Astro.
We also find JSX to be a really powerful component/template option and boy have we tried the alternatives. Vue is great, and so are Nunjucks, Handlebars, Twig and even good old PHP. Nothing has been more efficient, powerful and easy to maintain than JSX in our experience. We’ve also used Typescript in this environment with mixed results. Piccalilli itself is built with Typescript, Astro and JSX, via React. We’re finding Typescript less useful than it is annoying a lot of the time recently (aside from our course system), so we’re looking at alternative routes for that.
I’m trying to not specifically link JSX to a particular library or framework because we’ve used it with Astro templates, React and in my case Eleventy. That’s what I personally like about JSX: it’s portable as hell as much as it is polarising as hell.
Web componentspermalink
Admittedly we’re quite split on web components internally and even though I’ve long been a fan — even building a site back in 2018 that logged my learning (don’t go to the current live site because I no longer own the domain 😬) — we do find them a bit of a faff to work with on large projects. It doesn’t mean we don’t believe in web components, but we’ve certainly felt pain when lots of web components are doing lots of related state and interactivity on large projects. That’s likely a skill issue though because web component-based design systems like Nord look like a dream to work with.
I do want us to spend time to work out how we can work more with web components because they’re a web standard. I like the idea of libraries like Stencil helping us with components, along with an option for global state. If we can find the sweet spot, that can only improve our output as an agency.
Static site generators (SSG)permalink
I’m especially an Eleventy super fan and we’ve had some great successes using it for both client projects, along with internal projects like Build Excellent Websites and The ideal viewport doesn’t exist. Heck, the custom pattern library we use to write CSS patterns in my CSS course — Complete CSS — is built with Eleventy.
Our stance on static site generators like Eleventy is they’re really useful for websites that only deliver content. As the complexity of a project goes beyond a website that only delivers content, it tends to get more problematic in our experience. The reason Piccalilli is built using Astro is because we needed a hybrid of SSG and server-side rendering (SSR) or it would almost certainly be on Eleventy as it has been for many years before last year’s redesign and replatforming.
Tailwind CSS, composable layouts and CUBE CSSpermalink
What I don’t like about Tailwind is the nonsensical marketing statements such as:
“Best practices” don’t actually work.
Of course best practices work. That’s why they’re called best practices!
Aside from that nonsense, we find Tailwind to be very useful as a utility class generator and only that. It generates utility classes on demand which I like a lot. I also like being able to plug in some JSON design tokens (with admittedly a bit of faffing around) and generating utility classes based on those. We use those utilities as part of the CUBE CSS methodology, in the lightest way possible.
CUBE CSS is the one constant in every project we work on. That’s because CUBE CSS is the result of years of me working on, and consulting on both enormous, complex user interfaces / design systems and small, simple websites. It works perfectly well at both ends of the complexity scale and we’re all very fluent in it, in the studio.
For composable layouts, we use Every Layout (which I co-authored). Again, it’s built out of the combined, years of experience of Heydon and I, and it Just Works™. In fact, we barely have to even think about layout on most projects, thanks to Every Layout.
Wrapping up with our preferred “stack” todaypermalink
- Semantic HTML
- CUBE CSS
- Astro
- JSX (often React)
- Storybook
I hope this insight is useful and for you and future folks asking about what we use at Set Studio. We have our preferences but because our ultimate focus is on HTML, CSS and JavaScript, we will happily work in most other technologies as long as those technologies don’t negatively affect the end-user experience.
If you like the look of our choices and reasons for those, we still have some availability for 2025, so check out our website and get in touch.
