FYI

I’m the co-chair of the W3C WebDX Community Group, which maintains the data and the definition that powers Baseline. Today, I want to take a step back and talk about what Baseline is starting to mean to web developers, what it is, and what it isn’t.

Baseline has become hard to miss these days. There are banners at the top of most MDN reference pages and on caniuse.com. It also shows up in various coding editors and developer tools as tooltips, and people have started to mention it in blogs, social media, or conferences. It's definitely out there!

After a couple of years of existence, it's fair to say that awareness of Baseline has grown pretty significantly among web developers. People seem to know about the term and have a (sometimes vague) idea about what it means.

Baseline fills a gap but is also imperfect

For most people, Baseline is filling a gap. To them, the term acts as a simple way to say: this feature is supported across browsers. Even if they don't always know which browsers are included and for how long the feature has been supported in them, the term acts as a useful shortcut that conveys a sense of stability and broad availability.

For some other people though, the concept can sometimes be imperfect, for a few different reasons:

• Baseline doesn't take all the browsers they need to support into account
• The safest Baseline stage — Baseline Widely Available — doesn't cover old enough browser versions, which they still support
• Baseline says nothing about whether a web feature comes with accessibility challenges or not
• Baseline doesn’t tell web developers if it is OK to use a feature that’s not Baseline yet, perhaps as a progressive enhancement, or by using a polyfill

Those are all fair concerns which we’re aware of on the WebDX group. In fact, we knew this from the beginning, when the Chrome team first pitched the Baseline idea to our group.

Indeed, the way Baseline is defined: a status of not Baseline, Newly Available, and Widely Available doesn’t allow us to convey all the things that developers must consider before deciding to use a feature. However, talking to web developers when the Baseline definition was first being created showed that a too nuanced status would be confusing too. The goal was to come up with a traffic light-like of status which would, in most cases and for most people, speed up the decision process.

What, really, is Baseline?

Of course, there can never be a simple traffic light-style status that summarizes all the factors that go into deciding if a web feature can be used. Baseline is inherently too simplistic and categorizes features in three buckets:

• Not Baseline, if a feature is not yet supported on Chrome (desktop and Android), Safari (macOS and iOS), Edge, Firefox (desktop and Android)
• Baseline Newly Available, if it's supported on the above browsers
• Baseline Widely Available, if it's been supported on the above browsers for more than 2.5 years

This is a proxy to availability that can't replace careful consideration of factors such as: is the feature supported on all browsers (and browser versions) your customers use? Can the feature be a progressive enhancement? Is the feature accessible? And more.

Baseline is one more data point in your decision matrix. And that's OK! Baseline isn't trying to replace these other factors. It’s a starting point. It helps get a quick sense of availability, and it can be perfected.

A term that stuck, and an interconnected catalog of features

To me, the best things that happened thanks to Baseline are:

• The term itself stuck. It seems to now be part of web developers’ vocabulary. I didn’t know we did, but it seems like we needed a simple way to refer to broad support, and now we have one.
• For the first time, we now have a definitive list of web features, at a level of granularity that makes sense to web developers. Indeed, for Baseline to exist, we first needed to create a list of all the features of the web platform. And we did! Thanks to this, we now have a common catalog of features, which we can use across multiple places and be sure about what we're talking about. This allows us to link web-related data together in meaningful ways: features to docs, survey data, usage metrics, bug trackers, Interop, etc.

Perfecting Baseline

Baseline can definitely be perfected. Now that we have an initial definition, and now that adoption has grown, we can improve Baseline based on real user feedback and have even greater impact.

Here are some of the things the WebDX group is actively trying to improve:

Accessibility

If a web feature suffers from known accessibility issues, its Baseline status should take that into account. However, this requires having access to a reliable data source which, so far, has been missing.

We’re hoping to fill that gap by collaborating with Lola Odelola on the Accessibility Compat Data project.

Progressive enhancement, polyfills, and best practices

Because a feature isn’t Widely Available yet doesn’t mean you can’t use it, and we definitely don’t want to delay adoptions of features. That’s why we’re looking at ways in which we could map the catalog of web-features to polyfills, best practices, or ways to progressively enhance them.

With such a mapping, we’d be able to enhance Baseline with useful information that helps developers use features earlier or more safely. But we’d also be able to let developers know when it’s safe to stop using polyfills too.

Other browsers and browser versions

The list of browsers Baseline considers is: Chrome (desktop and Android), Firefox (desktop and Android), Safari (macOS and iOS), and Edge. This can be too limiting for some projects, so here are a couple of things that could help:

• baseline-browser-mapping, which provides the list of other browsers, and their versions, which are based on the engines of the core browsers listed above. This includes Opera, Samsung Internet, KaiOS, and more. And, if you want something even simpler to use, we’re also maintaining browserslist-config-baseline, which lets you target Baseline stages via the popular browserslist tool.
• On the WebDX group, we also have an owners group, which is tasked with re-evaluating the Baseline definition and the browsers that are taken into account. We meet at least once a year to discuss any important developments that might need to impact Baseline. So Baseline can, and will, evolve over time.
• The Google Analytics Baseline Checker tool might also be interesting to you. If you use Google Analytics in your project, you can upload your analytics data to get a sense for the portion of your customer base you’d include depending on the Baseline target you choose.

So what should you do then?

Baseline is a starting point, a shortcut that gets you started on decision making. Please don’t treat it as a checkbox. I suggest the following reasoning:

If a feature is Baseline Widely Available

Cool, it means it’s been in all major browser engines for long enough that most of the browsers your customers use probably have it already.

If the feature is useful to you, for example to remove a dependency on a costly JavaScript library, then you should mostly be able to use it right away.

It’s always a good idea, however, to check resources such as MDN for more information about detailed browser support and accessibility considerations.

When a feature is Baseline Newly Available

Great, it's in all the latest versions of major browser engines.

Now is a great time to be aware of that feature and the use cases it can unlock. It might help you get rid of custom or third-party libraries you will soon no longer need, or let you implement new product features you haven’t been able so far. You might even be able to start using the feature now, with the right fallbacks or polyfill for non-supporting browsers.

When a feature is not Baseline (AKA Limited Availability)

There are hundreds of really powerful and useful features on the web that don’t have broad browser support yet. Some of them might be very important to your projects. It would be a pitty not to learn about these newer features simply because they’re not Baseline.

Treating Baseline as a yes or no status can slow down adoption, and therefore also slow down developer feedback, which can help pressure browser vendors into implementing features.

If you can afford it, take the time to keep track of what’s coming. The Web platform features explorer is another tool the WebDX community group maintains which can help get quick information about new features.

Join the community group!

If you want to go further and take an active part in Baseline and the data it’s based upon, you can also join the WebDX community group. The group is opened to anyone who wants to get involved, and we value any and all points of view on the topic.

WebDX is a group that hopes to create tools and resources that are valuable to web developers, it’s so much easier to do this when actual web developers are involved in it!

To join the group, go to the website and click the join button!

I want to support that stance with some conversations I've had with people actually doing the work and their mostly less than favourable experiences.

I asked this across question social media:

Is your boss encouraging you to/making you use AI tools for development?

I’m thinking about working on a piece about that on Piccalilli.

It’s sensitive for sure, so more than happy for people to be anonymised.

The reason I asked was because — as you can imagine — I speak with a lot of developers on a day-to-day basis. A lot of the time in my personal network, these are very experienced, senior developers, but I'm hearing the same stories from juniors too. It boils down to:

My boss is making/encouraging me to use AI every day and during every part of my work.

I had an urge to explore this further — making sure I wasn't in an echo chamber — and, yeh, you're probably not going to enjoy what I discovered.

Before we dig in, allow me to set some ground rules and facts

1. If you're a fan of AI companies/tools, this article is not a personal attack on your preference
2. This article does not de-value the good stuff you might feel like you’re doing with AI
3. All participants are completely anonymised for their privacy and protection
4. I have re-worked some of the responses to assist with point 3
5. Any opinions are mine unless specified

What I learned from my conversations

I've had several conversations with developers and designers working across the industry for this piece, all with varying experience levels.

I spoke with a developer working in the science industry who told me, "I saw your post on Bluesky about bosses encouraging AI use. Mine does but in a really weird way. We’re supposed to paste code into ChatGPT and have it make suggestions about structure, performance optimisations"

I pressed further and asked if overall this policy is causing problems with the PR processes.

In reference to their boss, "It’s mostly frustrating, because they completely externalise the review to ChatGPT. Sometimes they just paste hundreds of lines into a comment and tell the developer to check it. Especially the juniors hit problems because the code doesn’t work anymore and they have trouble debugging it."

“If you ask them technical questions it’s very likely you get a ChatGPT response. Not exactly what I expect from a tech lead.”

Immediately, I thought their boss has outsourced their role to ChatGPT, so I asked if that's the case.

“Sounds about right. Same with interview questions for new candidates and we can see a lot of the conversations because the company shares a single ChatGPT account.”

I asked for further details and they responded, “People learned to use the chats that disappear after a while.”

That's pretty horrifying, I've got to say. Not just some of it, but all of it. Maybe I'm sensitive because I am people's boss and couldn't fathom outsourcing my responsibilities to a technology that often gets things completely wrong.

Let's move on to another conversation I had with with a team lead in an agency. Something I have a lot of experience with!

“My company is pushing AI tools across the company in branding, copywriting, design, stock photo creation and of course development. They want to be the ‘first AI agency’ and are basically telling us to get on board or you're not a fit here any longer.”

Pretty harrowing stuff. This isn't much of a surprise to me though so far because unfortunately, a reasonable portion of agencies will do everything to cut corners on a project to increase profits.

It's been that way forever and it's fundamentally why — understandably — organisations don't trust agencies. A lot of my work is building that trust in the sales process to counter that.

I asked how their agency is currently billing clients and whether it's retainers or fixed-fees.

“We have production clients who are on an overall fixed fee and monthly retainer clients whose contracts are set by the number of hours they want to buy.”

Seems like a pretty standard agency setup to me. I wanted to dig deeper on the culture though, so I asked, in reference to “…telling us to get on board or you're not a fit here any longer” is causing fear amongst their colleagues.

They responded, “I would definitely say it's causing some fear that they aren't good enough / falling behind if they aren't using it regularly.”

“The managers like to quote ‘AI won't replace you, but a developer using AI would’ as a way to motivate certain team members to use the tools”

Sounds more like a threat to me than a motivation. I asked if their managers are effectively threatening to replace people, not on board with AI and if that worries them.

“In a way yeah but I don't think they could directly get rid of them for that reason, more potentially make it uncomfortable so they'd leave.”

“It's not a great feeling to have and to be honest, I think it's a wider worry about the industry as a whole, as I feel a lot of agencies will be jumping on the AI train.”

“…I do worry about some of my team members and the direction of the company overall — I'm struggling to find the same motivation I had 12-18 months ago”

AI use and a culture of encouraging staff to use it isn't isolated to this one agency. I spoke with a designer at another agency and they said, “Yes I work at a small digital agency and we're being encouraged to use tools. Not particularly for image generation (outside of ideation or mood-boarding), but more for summaries, research and some copywriting.”

“I was very vocal about it at the beginning and think I managed to get a bit of a reputation for being difficult for my views, so I've yielded a little bit on certain tools, but still [I'm] very clear about what I think is appropriate for clients and almost certainly make sure we disclose when we use it.”

Even though AI tools seemingly aren't directly used for the creative design output, they're being used during the creative ideation process which for me, as an agency founder is terrifying, especially with some of the non-disclosure agreements (NDAs) I've signed over the years.

I also can't fathom using AI for copywriting either.

I also spoke with a software engineer for a huge, global retailer whose organisation is conducting a big push to leverage AI. AI has now become a requirement there. I asked if the organisation has provided correspondence that people's jobs will be at risk if they're not on board.

“Thankfully I have not seen any wind of it. There is a lot of discussion about how to embrace it [AI] and how we can help the next wave of engineers coming in from colleges to be ready for the transformations that will happen to the way we work.”

“I’m sure as the tech matures and we adopt specific tools organisation-wide, those discussions may happen. Right now we are still piloting different tools and figuring out what does and doesn’t work for the organisation.”

I asked if this was more of a pragmatic process, rather than a rushed, reactive process.

“I think it’s being done with a sense of urgency to embrace new technologies and how they can help us but not to the point where the average engineer would feel overly pressured or threatened by the push.”

“I’ve been enjoying my journey into how to leverage AI but I think for newer engineers or engineers looking to climb the ladder, like myself, it inherently adds pressure to be an earlier adopter and be one to spread knowledge early.”

I asked if there had been any disasters.

“Thankfully nothing in my area and I’m sure any team would try to keep those slip ups under wraps. I will say that in my personal experience little edge case bugs are more prevalent and no matter how careful I am and reread all code over and over I still manage to miss stuff when I don’t manually type it.”

“I’m pretty proud of raising solid PRs with low rates of bugs reported, but these last two sprints, I’ve had a few things slip past me due to the change of workflow. I’m sure this is something a mindful engineer won’t struggle with for long as we adjust to the new way of working.”

Let's take a look at one more because I'm aware this article is getting very long. Sorry about that.

I had a developer reach out about AI very much being forced in their organisation.

“The CTO at my previous job tried Claude Code and really liked it so he said that all the devs had to use Claude Code in our work for generating code, generating tests, debugging, and validating design.”

“If we asked him a question on something he would tell us to ask Claude first. I never found Claude useful. It couldn't debug anything and I didn't like how carefully I'd have to comb through the code it generated to find the subtle bugs it would inject. The design validation was basically just telling us what we wanted to hear, which the CTO loved”

This is the thing about AI tools. They are by design going to honour your prompt, which often results in your AI tool agreeing with you, even if you're wrong.

I asked this person if their boss was effectively off-loading their responsibilities to AI too. I also asked about more information about design validation.

“He was trying to off-load responsibilities to Claude but Claude never gave us a good answer so it would just add an extra layer of back-and-forth to solving the problem.”

“Design validation is looking for possible performance, security, or concurrency issues in the design of our system. Claude would always have some generic answer that didn't fit our specific circumstances so it was taken as validation that our design was good”

Again, AI tools will validate you, even if you're wrong.

“I think the fact that Claude didn't have anything real to say about our designs was taken as validation that the design was good.”

“There was an assumption that if the design had an issue then Claude would catch that and say something relevant to it. I don't think he ever considered the possibility that Claude wasn't saying relevant things because it couldn't do that. It would only be able to regurgitate generic advice you find on the internet about good software design”

A lot of design critique is based in analytical, creative and soft skills, along with lots of experience. AI is completely incapable of doing all of that.

LLM is an acronym for large language model and that is exactly what these tools are — language processing systems. So am I surprised that Claude is just regurgitating generic design advice? No.

These tools are incapable of creating and analysing. They are only capable of pattern matching and regurgitating what has been fed into them during the training process.

Remember when Google's AI summaries were encouraging people to add glue to their pizza sauce, for example? Yeh, that was a Reddit joke comment which has now been removed but it's a good example of AI regurgitating what it has learned without to capability of determining the fact that comment was a joke.

Regurgitating, not creating. It's what these tools do.

Some advice for navigating all of this

I'd say my overarching advice, based on how difficult tech recruitment is right now, is to sadly play along. But — and I cannot stress this enough — make sure you document everything.

What I mean by that is every single time AI tools cause problems, slow-downs and other disappointing outcomes, document that outcome and who was responsible for that decision. Make sure you document your opposition and professional advice too.

In fact, away from AI, I'd recommend documenting this stuff in general. It'll be vital if you ever find yourself in a disciplinary and/or tribunal situation. You don't know where the code your tool spat out came from either. Documenting who is responsible helps to protect you, individually, if litigation is raised against your organisation. If it is not your decision to use these tools, make that known, officially.

It's quite clear we're in a bubble with AI, or at best, a hype cycle. For example 95% of generative AI pilots failed in a recent report from MIT and even when developers thought AI was making them faster, it was actually making them slower in another study.

Billions are being poured into this technology but big tech companies — the so-called "magnificent 7" (cringe) — can afford those losses, generally. Ethics from decision makers are clearly not even a factor any more in these organisations too.

My worry is that — as always — workers will be the ones to suffer as the bubble/hype cycle bursts. What I'm directly advising you to do is protect your interests right now.

Unionise.

Wrapping up

To everyone who I spoke to and haven't featured in this article, I'm sorry for excluding your input. This article is very long already. Just know, the conversation we had was incredibly useful in producing this article and I really enjoyed talking to you. Thank you.

This article has been really hard to write, I'm not going to lie. I really enjoyed my conversations but quietly, I was hoping I was wrong with my theory that AI tools were being forced, rather than being used on merit.

It's so typical of the tech industry to jump on a shiny new thing, completely forgetting how much harm it causes, such as ChatGPT teaching someone how to more effectively commit suicide (extreme content warning on that link). Let's not forget how much content was stolen in the first place — and continues to be "scraped" — to train models too. Legal cases have rightly been raised.

I would say I'm very much an AI-sceptic. That's not a position from refusing to try AI tools though. We've tried these tools for quite a while and after that extended period, found them to be more often than not, a complete hindrance, albeit quite useful in certain contexts. Your mileage may vary though! We know our position and that's what's important to us.

Regardless of your opinion of AI, forcing the usage of it is almost certainly going to end in disaster. Just be prepared for that disaster and protect yourself is my overall advice.

I just think it's important for you, the reader, to understand our position. This article serves as a canonical reference to our position ongoing.

Where we stand: our principles

1. We will never publish AI-generated content, be it words, code, video, audio and images
2. We won't boost content that we suspect has been wholly, or partially generated by AI
3. Content submitted by guest authors that is wholly or partially generated by AI will be immediately rejected

Humans writing for humans, always

That's what we do and what we will always do. We're not going to "optimise" for LLMs and crawlers. We'll continue to do everything to optimise for humans instead like hyper-focusing on the reading experience.

Let's be honest, AI-generated content generally reads like complete trash and is a disservice to human readers. It would be offensive of us to subject readers to content of such poor quality. Surely they'd rather just read the prompt!

We would never accept plagiarised and stolen work, regurgitated by a word shuffler on our publication that we invest so much into making great, either.

You can count on Piccalilli, as always, not to jump on the bandwagon and instead, take a pragmatic, measured approach. We've done that, we've tried AI tools — to assist with development on real world agency projects — and after all of that time and effort, our opinion is these tools are quite useful for some stuff but generally over-hyped, wasteful and were often responsible for a low quality output that we ended up throwing out.

That outcome doesn't come even close to the standards we hold here, so you can trust Piccalilli to continue to be focused on you, the human reader, and extremely high quality content, always.

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 JavaScript

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 frameworks

“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 components

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)

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 CSS

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” today

• 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.

FYI

A break from our usual type of article here but it is very important we do because WordPress powers nearly half of the web.

You may or may not be aware of the situation unfolding with Automattic and their CEO Matt Mullenweg against WP Engine. I recommend reading the following to get up to speed.

We’re not in the business of adding opinion to that, but I feel the need to write this because Piccalilli has such a vast reach and I’m genuinely concerned about the security of WordPress-powered websites.

As part of Matt’s increasing irresponsible and irrational behaviour, WordPress took over the extremely popular plugin, Advanced Custom Fields (ACF), renaming it “Secure Custom Fields” (SCF). With it, they stole years of reputation, good reviews and most importantly, trust from ACF.

If you update ACF via your wp-admin dashboard, it will be replaced with SCF. SCF does not have the ACF team behind it, so updating to SDF will potentially put your website at risk. It’s also important to note that this affects users of the free ACF plugin, not paid users who already get updates direct from ACF.

Thankfully, ACF are on top of this and have published an article explaining what you need to do if you are affected by these events. If you have already updated to SCF, you can reverse that with ACF’s published advice too.

I’ve long been a fan of WordPress and probably will continue to be. I want this situation resolved, but I fear we are beyond that being possible unless there are huge changes at the most senior level of WordPress — especially the open source project. My advice is to be aware of what’s going on and keep an extra keen eye on your WordPress projects.

To those whose businesses rely on WordPress, all I can do is send my deepest sympathies. You’re going through a tough time right now. My advice to you is to frequently keep your clients in the loop with what’s happening and your response to these extremely turbulent times. All the best to you, too!