SmashingConf 2023 – Front-end San Francisco

At the end of May, I travelled to San Francisco 🇺🇸 for my second ever SmashingConf, a 2-day web conference focused on cutting-edge front-end development. SmashingConf took place at the Fort Mason Center for Arts, a complex of repurposed ex-military buildings on the waterfront, with views of the Golden Gate Bridge and nearby Alcatraz. SmashingConf had one track across two days, crammed full of notable speakers and workshops. Oh, and it would only be a Smashing Conference with a party, fun community events and some surprises sprinkled throughout.

SmashingConfs are organised by Smashing Magazine, an online publication aimed at front-end developers. I first started frequenting Smashing Magazine in the early days of my web career: I came for their monthly roundups of cool desktop wallpapers — a big deal back then —, but I stayed for the informative articles, tutorials and books on all things web UI.

SmashingConf Day One

After my ten-hour flight from the UK, I woke up on my first full day in San Francisco in the early hours. Jet lagged and wide awake, I headed for a stack of pancakes with syrup and several cups of coffee before venturing out. I decided to take the scenic route to the conference, checking out some of the interesting houses along the way and stopping to take photos.

Upon arrival at Fort Mason, we were greeted by the Smashing team, who handled registration and gave us our swag bags and lanyards. Prior to the conference starting, we had the opportunity to chat with the conference’s sponsors and graze on the breakfast buffet provided. I made sure to raid for stickers speak with Netlify and Storyblok, both of whom have products with which I’d love to work more.

The conference started with opening remarks from Vitaly Friedman, Smashing Magazine co-founder and conference host. Vitaly also returned to the stage after each talk to host a Q&A with the speaker, for which we, the audience, could submit questions via a collaborative Google doc.

Una Kravets – The Best JavaScript is No JavaScript

SmashingConf kicked off with Una Kravets who heads up the Developer Relations Team at Google Chrome. Una’s talk was centred around what’s now possible thanks to innovation within browsers – specifically, all the exciting things we can now do natively without the need for JavaScript. Any front-end developer who’s been around for a while will be used to having to use JavaScript to style certain elements, or build modules like modals. It’s easy, therefore, to fall into bad habits: leveraging JavaScript unnecessarily and forgetting to keep a close eye on what’s happening with browsers (as previously innovation in terms of browsers was extremely slow 🐌).

But that’s all in the past thanks to the Open UI working group and Chromium and Mozilla browsers, who are pushing forwards with regular updates which extend what’s possible for us to create for the web.

Container queries and container style queries

Una told us about container queries. These essentially allow us to create a micro UI — responsive design on steroids 🤯 —, adjusting to the space it has rather than specified breakpoints. Whilst digging deeper into container queries, Una also spoke about container style queries (@container). These give us the ability to query conditions on an ancestor element, in the same way that media queries allow us to query the size of the viewport or the user’s browser preferences.

Custom CSS Properties

Another exciting CSS advancement Una discussed was custom CSS properties with @property. These give superpowers to CSS variables, enabling them to contain more information than just a string. This lets us transition them and set fallback values, which will be useful for creating colour themes and writing DRYer CSS.

:has() parent selector

Una’s talk also took a look at relational CSS selector :has and how she has been using it. Whilst there isn’t full support for :has yet, there should be soon and it’s already making its way into frameworks, so watch this space 👀.

:has is essentially a parent selector, which will enable us to conditionally target the parent of a given element. In CSS you can only style down the tree, targeting children of elements only. The :has selector changes that (without causing a performance nightmare, which is why true parent selectors aren’t a thing in CSS), making it easier than ever to write DRY CSS for our components.

CSS Trig functions

CSS trigonometric functions let us calculate the sine, cosine and tangent in CSS. Without getting too mathematical, when used with calc() these new — newish, they are now supported by all major browsers 🎉 — CSS functions allow us to create more interesting visualisations in our work.

If you’re also a self-taught developer without a computer science background and a tenuous-at-best understanding of trigonometry, fear not! It’s actually a lot easier to wrap your head around when you start playing with it.

Popovers

The new Popover API allows us to create menus, tooltips, dialogues and modals without having to write lots of JavaScript. Using the new popover attribute, we can define our popover element and its target and just worry about populating and styling it. The browser, then, does the rest, handling the focusing and accessibility, and promoting it to the top layer — removing the need to mess around with z-index.

This is a huge win for page speed, standardisation, accessibility and developer experience 😍. I love that we’re getting things like this natively, as I can remember in the not-so-distant past needing several third-party scripts to achieve something like this.

Coming soon to a Chromium browser near you

And realistically, this is just the start. Una filled us in on lots of exciting upcoming things in the Chrome pipeline, with a couple that are not yet supported, but which will be coming to us soon, like Selectmenu 🙏🏻 and anchor positioning. These will be a game changer when used in conjunction with the popover API.

The best thing is, you don’t have to wait for full browser support before you can try these new advancements – just download Canary and start experimenting 🧪.

Josh W Comeau – The Whimsy Potential of JavaScript Frameworks

Dare I say it, my favourite talk of the conference? It’s a tough call, but I really enjoyed what Josh had to share about React and his approach to front-end. I’m so late with my SmashingConf write-up, that Josh’s course The Joy of React is live! I’ve already signed up. I can’t wait to get stuck into the course.

React and JavaScript frameworks

I’m not afraid to admit that React used to scare me 😬. I know from speaking to other developers, that this isn’t a unique experience, especially for us UI-focused developers. Seemingly overnight, being a front-end dev meant keeping up with the numerous and ever changing JavaScript frameworks. No longer just using JavaScript for adding interactivity to a site, but instead using it to build single page applications and having to understand concepts which to me felt very back-end.

I came back from maternity leave and essentially a year of not writing code to WordPress 5.0 shipping, with its Gutenberg blocks written in React. Rather than immerse myself in React and embrace the challenge, I installed a plugin to use the old editor and internally screamed. Fast forward to now and I’d take working with React over WordPress and PHP any day, the difference in terms of developer experience is night and day and I wish I’d realised that a lot sooner 🤦🏻‍♀️.

Smashing Magazine has always done an excellent job of differentiating between areas of front-end and valuing and speaking to the UI / web developers like me. Josh spoke about this and how he had moved around the different disciplines within the front-end, but nowadays enjoys being somewhere in the middle, fully immersed in all things JavaScript and React, whilst still being extremely creative.

More whimsy please!

Josh spoke about how JavaScript frameworks give us powerful tools for building creative interfaces and adding whimsey through interactive elements and micro interactions on the web. Josh’s blog is full of whimsy and he gave us a high-level talk through how he built some of those fun elements, such as his animated heart like-counter — from whom you can retract your likes with a control + click, but why would you? 💔 —, and his avatar background which follows your cursor.

Using React Spring physics and Three Fibre (a React renderer for Three.js), Josh took a 3D egg he had created and showed us how he animated with Blender and exported it as an SVG for the web. These pieces of whimsical UI enhance the user experience so much and with React, the possibilities are infinite.

I loved that Una’s talk reminded us what we don’t need JavaScript for and Josh’s gave us a whole host of new fun things to think about. Modern front-end / JavaScript is so exciting.

Lee Robinson – Optimism for the Web

Lee is a front-end developer and VP of developer experience at Vercel, where he leads the community for Next.js 🤍. In his talk, Lee looked back at 10 years of front-end and forward to all the great things we have to be excited about. The tools, frameworks, community and opportunities we have at our disposal nowadays are awesome. The first website I ever made was coded in Notepad++ using tables and without CSS) and rendered – horribly – in IE6… To say things have come a long way is an understatement.

As well as encouraging us all to be more optimistic and reflecting on where we came from a little, Lee also spoke about a handful of things he’s particularly excited about. With far better browser engine alignment (thanks Interop) and things like the launch of Baseline, the future of JavaScript and Typescript is bright and I think Lee is absolutely right to be optimistic for the future. There’s never been a better time to be a front-end developer.

Tammy Everts – Performance Budgets

Tammy’s talk on website performance and how to set a performance budget was one I was looking forward to, as I’m a performance nerd 🤓. Tammy is the CXO at Speed Curve – a website performance monitoring tool –, and an author / expert on all things perf. Tammy introduced us to the concept of performance budgets, a way to set measurable goals for your site, which can be monitored over time and understood by people outside the team. Rather than viewing performance metrics as simply passing or failing at a given point in time, a performance budget allows for nuance and allows the team to better demonstrate the impact of changes over time.

RUM vs Synthetic monitoring

RUM stands for real user monitoring, not the thing you drink because you’re sad the marketing team have tanked the Lighthouse score again.

In an ideal world, both RUM and Synthetic monitoring would be utilised. RUM helps us understand long term trends by looking at real traffic, whereas synthetic monitoring helps you detect issues immediately, before user traffic data is available.

Creating a performance budget

Tammy gave us some solid advice for getting started with performance budgets: 1) Start small – even just monitoring a single metric initially. 2) Focus on the pages which matter most, not just the homepage. 3) Regularly revisit your budgets, ideally every 2-4 weeks to ensure they’re realistic. 4) Remember that metrics are always evolving and to never-stop-measuring.

Time for lunch

After a morning packed full of informative talks, my jet-lagged brain was very much in need of food. SmashingConf was fully catered, so I grabbed my veggie sandwich and refuelled with coffee whilst looking out over the sea to Alcatraz, wondering if I could swim back from it in a potential prisoner-escape-scenario (spoiler alert, I absolutely could not).

Not wanting to miss out on anything during my time in San Francisco, I had signed up for the lunchtime sessions and the first one was with a now familiar face, Tammy Everts.

SpeedCurve lunch session

Now clued up on all things performance budgets, I was interested to hear more about SpeedCurve ⚡. The lunch session was also a nice opportunity to chat with other attendees, who in our lunch session were almost all developers.

Whilst the session wasn’t intended as a product demo, it was good to see what SpeedCurve can do and how it could be useful for our work. Tammy took us through a high level performance audit of Amazon and then opened it up to the room to see if any of us were brave enough to volunteer our sites for an example audit.

Looking at a real-world site that isn’t working with a FAANG budget was really interesting. We spoke a lot about which metrics to focus on to make incremental, meaningful improvements, rather than arbitrarily monitoring all core web vitals at once.

SpeedCurve even allows you to make performance part of your CI/CD pipeline, – optionally – breaking the build if a chosen metric goes out of budget.

It was clear from what I saw that a tool like SpeedCurve would make monitoring your website’s performance a lot easier (not to knock my tried-and-tested method of saving Lighthouse screenshots to my desktop, without any context as to which site is which).

The key takeaway from this session was to use something to monitor changes over time, to be realistic about what metrics you focus on and what success looks like for those scores. I think too often we are reactive with performance work, but it pays to be proactive and make performance a key area of focus.

Miriam Suzanne – Container Queries

Having heard about container queries from Una, we were then treated to an entire talk dedicated to them. And who better to deliver such a talk than Miriam, who was heavily involved in drafting the container queries spec.

The conversation around container queries has been going for fifteen years. Fifteen whole years of devs asking for them and being told it was impossible. But finally, in 2023, container queries and units have shipped in Chrome/Edge, with Firefox not far behind 🥳.

Container queries are going to change responsive design drastically for the better. When working on a component or block-based UI, we often don’t know where our component will be used or what will be used alongside them. So, using traditional methods like media queries and parent classes go out the window. This is where container queries will come in; they allow us to create components which have their own responsive design, which don’t rely on viewport dimensions.

I cannot put into words how excited I am about container queries. At the time of writing they have support in 86.15% of browsers and, they’re cautiously being integrated into frameworks (such as Tailwind, with the plugin: @tailwindcss/container-queries).

Adam Argyle – View transitions

Speaking of futuristic features we can now use, Adam Argyle did a whole talk dedicated to view transitions. Adam did an incredible job standing in for Jake Archibald (the writer for the view transitions spec, originally scheduled to give the talk) – successfully getting everyone excited about this new API.  I think Adam could have stood on stage and delivered a talk about algae and I’d still have been entertained. His energy-levels and humour were very much needed, as it had been an intense day with lots of information to absorb.

There are two types of view transitions: same page and across page. The browser takes a snapshot of the DOM before and after the transition, and handles transitioning between the two states. You can name your view transition and use new pseudo elements (::view–transition-old and ::view-transition-new) to gain access to both states and customise them with CSS. You have the option to only run the animation when exiting or entering the stage and you can use blend modes to customise how the two snapshots blend together. The snapshots crossfade by default.

The result? Smooth morphing of elements between two DOM states, even between page loads 😮.

Across page transitions are still under active development, but can be enabled in Canary with a flag. You can opt-in your page by adding a meta tag, which will allow you to start experimenting with view transitions right now. It’s a progress enhancement which won’t negatively impact users who can’t yet see your transitions.

My first night in SF

By the end of the first day of the conference, having travelled 5000 miles and had very little sleep, I was shattered and decided to skip the party, which was a shame as I know SmashingConf parties are always fun. The fog which had engulfed the Golden Gate Bridge 🌁 and Alcatraz had now burned off and I got to experience a bit of Californian sunshine on my walk back to the hotel.

I figured I’d fall asleep if I didn’t keep moving, so I went for a wander around nearby Pier 39, home to a colony of — extremely loud and extremely smelly — sea lions 🦭. Pier 39 is a lively albeit very touristy area, with lots of shops and street food vendors. As my bodyclock was all over the place, I couldn’t decide on a sensible dinner and instead settled on a ridiculous amount of fudge and a giant fudge covered apple from The Fudgery. I had every intention of going back through my notes and writing up day one that evening, however I realised that was over ambitious and instead watched a couple of episodes of Vanderpump Rules – because of the #scandoval –, before giving up and going to bed.

SmashingConf Day Two

After filling up on pancakes and coffee, I took a slightly longer route to the conference centre in the hope of both seeing more of San Fran and catching some Tauruses to bring back to the Pokemon Go gang. SmashingConf day two was underway and I felt like a new person after a decent night’s sleep.

Vitality continued to pelt us with delicious German chocolate and make us laugh with his bad developer jokes. “What do you do with a bad JS dev? Console them” was my favourite.

The first talk of the day was a secret and I was curious to discover who the speaker was.

Mathias Biilmann – The Jamstack 6 Years On

The mystery speaker was none other than Matt Biilman, the CEO of Netlify who we can thank for Jamstack architecture 🤍.  Having coined the term at a SmashingConf in 2016, Matt was back 6 years later to talk about Jamstack and its evolution.

Jamstack architecture decouples the front-end from the back-end, allowing web experiences to be built at speed.

The first two commercial front-end frameworks for Jamstack were Gatsby and Next.js and now, we have countless tools and libraries. Matt commented that whilst modern tooling is complex, it’s extremely powerful. In his words: ‘the path to doing something impactful as a new developer, is shorter than it used to be’.

Matt talked about how Jamstack is moving towards the idea of composable architecture, a business concept which doesn’t depend on one big monolithic stack. Aimed at enterprise companies, Gartner estimates that 79% of enterprise architects will start building composable applications in 2023. This will help with their challenges of decentralised content, unreliable and hard to scale CMS APIs, multi-framework requirements and the need to progressively modernise. Matt was clear that whilst Jamstack has received widespread support from the developer community and startups, the aim now is to get wider adoption from large companies who build enterprise software of composable architecture.

Headless WordPress

During the Q&A, Matt was asked a question specifically about headless WordPress and if WordPress could conceivably ever work on the Jamstack. This is something I’ve thought about extensively. As a developer who has worked with WordPress heavily, I often worry think about what the future of WordPress looks like.

Matt pointed out that WordPress turned 20 this year, but that last year was the first year its user base stopped increasing. The stat that WordPress powers one third of the internet is frequently shared, but could that be changing?

Whilst headless WordPress is becoming more common, I personally don’t see it becoming standard. Matt pointed out that one of WordPress’ unrivalled features is its huge plugin library and that the plugin ecosystem would be particularly difficult to adapt. Some of the big plugins, such as Yoast, leverage the Rest API to work headlessly. However the vast majority would not work at present and you would be hard pressed to find a WordPress site which doesn’t use several of those plugins.

Carie Fisher – Accessibility Choices

Next up was Carie Fisher, who spoke to us about accessibility and how browsers are offering more configurable settings to improve our experiences when browsing the web. Working in much the same way as user-focused CSS media queries, such as @prefers-reduced-motion, as developers we can use these options to tailor the experience we’re creating to the user’s needs and preferences.

In addition to @prefers-color-scheme, we now have @forced-colors and @inverted-colors (Safari only currently), @prefers-contrast and @prefers-reduced-transparency. These can be combined with existing queries such as @prefers-color-scheme to give the user new ways to make your site more accessible. Carie pointed out that it would be impossible to create a one-size fits all for every user with a sight impairment, as there are so many different conditions and each person is different. Accessibility choices, therefore, set at OS level and optimised for by developers feels like a really positive step forwards.

Also coming is @prefers-reduced-data, which like @prefers-reduced-motion gives the user further control over on-page movement. A question was asked in the Q&A about when to use each and Carrie explained that she felt @prefers-reduced-motion should stop all movement, besides things fading into place, whereas @prefers-reduced-data would mean no movement at all.

These accessibility choices are fairly new and not rolled out in stable versions of our OS yet, but I’m looking forward to seeing their adoption in future updates.

Mark Robbins – How I Learned to Stop Worrying and Love Email

Mark Robbins works at Parcel, where he works on tools to help developers build better emails. And, he achieved the impossible: leaving me with an urge to work on a newsletter template (a job which normally fills devs with dread 😬).

Mark talked about all of the exciting things possible in email templates with progressive enhancement and a little help from Word Art (yep, you read that right). He also gave us a date to mark in the calendar, the 13th Oct 2026, when Outlook 2021 goes end of life 🎉. Until then, we will have to work around the challenges, but that doesn’t have to mean boring templates or frustrating coding sessions.

One nugget Mark gave us was how we can make our email newsletters more accessible with a tiny bit of code: wrap your email’s content in a div and set lang and dir… And that’s it! The Email Markup Consortium accessibility report 2023 found that 99.97% failed basic accessibility tests and by a long way, the most common issue was the lang and dir not being set. So make sure to check that on your next newsletter 👀.

Addy Osmani – Chrome DevTools State of the Union

Engineering lead at Chrome Addy Osmani came to talk at SmashingConf about all the things now possible with Dev Tools. Addy’s team work on the tools we use daily, like Chrome DevTools, Lighthouse and PageSpeed Insights 🤍. Having both followed Addy Osmani on Twitter for forever and read a couple of his books, it was great to finally get to one of his talks. Despite using DevTools constantly, I only hear about new features when I stumble across them, which means I’m missing out on updates which could make my life as a developer easier.

Under ‘more tools’ there is now ‘animation inspect’, which allows us to slow down animations to take a better look at what’s going on. It also allows us to play with the animation using the new cubic bezier editor and easing editor – which now has linear timing support. Dev Tools has two new ways to screenshot: a node screenshot and an easy way to get a screenshot of the mobile view. It’s now also easier than ever to work out why a particular CSS property isn’t impacting anything, thanks to a UI update which shows ineffectual properties as faded and provides more insight with a helpful Tooltip.

Accessibility features

There is now rich expanded info when inspecting an element with some helpful accessibility information available. Another accessibility update gives us help with colour contrast. Auto-fix colour contrast using the colour picker, or tweak values with guidelines showing if it’s contrasted enough. The Advance Perceptual Contrast Algorithm (ADPC) gives us a new way to compute contrast based on colour and it’s available as an experiment in Dev Tools. There’s also an opt in experiment, which lists all elements with colour issues.

Thinking back to Carie’s talk on accessibility choices, the new emulation features in Dev Tools will be super helpful to test these new media queries as they gain wider adoption. From within the rendering panel, we can emulate user settings such as @prefers-reduced-motion.

There are a lot of modern CSS debugging support updates, such as: CSS layer view, CSS nesting and CSS color 4 support. And, CSS layout debugger will make identifying the troublesome element a lot easier. Goodbye 👋🏻 manually adding border: 1px solid aqua.

Persist Edits

This will be so handy! There are finally now global overrides which can be created from within the sources panel. This makes changes persist locally so you don’t lose your work when debugging and refreshing.

Spicy console logs

Run, don’t walk to Visual Studio, you can put gifs and memes images in console logs — we can, but probably shouldn’t —. It also offers console.group() for organising your logs and console.table() for tabular data within the console… Fancy 🤩.

Tim Kadlec – The Big Picture

Tim Kadlec is a web performance consultant whose SmashingConf talk centred around the Largest Contentful Paint (LCP) metric. Before getting into the technical details, Tim shared with us the photos he had taken for his kids back home with one of their beloved toys. As a parent myself also travelling with an allocated companion (shout out to Mr Dinkles, the weird worm thing), it was such a lovely moment when several other parents in the room laughed and held up the teddy they had been sent with. Lots of us had travelled to the conference, leaving children at home and had been given these toys as a way of feeling connected.

Always bet on the browser

Tim reinforced the reminder given to us by Una earlier (that the best JavaScript is no JavaScript when there’s a native browser alternative) when he spoke about JavaScript lazy loading of images, which he describes as an anti-pattern, now we have native lazy loading. Browser primitives will always be better than a workaround, so it’s important to ditch them when they’re no longer needed.

Fetchpriority

Tim talked to us about priority hints and how we can use them to improve our LCP – with just one HTML attribute! I’ve written about this in detail in my post on fetchpriority.

Jem Young – Things I Wish I Knew About Engineering Management

Jem Young is an engineering manager at Netflix and came to SmashingConf with an interesting topic: becoming a manager. It’s a crossroads that a lot of developers come to, where you make the choice to continue on the code, or take the management route and become more leadership focused and less hands-on with the code.

There were a lot of managers in the room, who nodded along in agreement with Jem’s experience and clearly found it relatable. But the vast majority of us were developers, who might be considering that career path but who definitely have more experience being managed than managing others. It was interesting to hear from Jem’s perspective, a relatively-recent developer turned manager, about how we could be getting more out of that relationship.

Jem spoke a lot about taking a collaborative approach to working relationships and gave us a light-hearted insight into his first year as a manager.

SmashingConf Photo Walk

On day two, we followed the conference with a photo walk around San Francisco. Armed with my new camera and lens, I couldn’t wait to see more of the city and hopefully get some good shots. That said, it was clearly a great social as I actually took very few photos. I found some fellow photography nerds and friendly fellow devs to chat with while San Francisco local/SmashingConf volunteer Ren took us on a scenic walk.

San Francisco is such an incredible city, but wow, were my legs tired. Wales isn’t exactly flat, but nothing could have prepared me for those inclines. And Ren didn’t go easy on us, taking us up Lyon Street — with it’s 300 steps 🥵 —, which were totally worth it for the views from the top.

After walking around some landmarks like the Palace of Fine Arts in the marina and drooling at the incredible homes — black Victorian town houses, adorned with black succulents outside, when can I move in? 🖤 —, our legs were aching. So, we decided to find somewhere to grab food. Much to my delight, the group voted for a nearby Mexican restaurant called Tacko. Over burritos, tacos and quesadillas 🌮, we spent the next few hours chatting about all things coding, photography, gaming and what life was like being a dev in our respective countries.

My Key Takeaways From SmashingConf

It’s difficult to sum up two jam packed days of fascinating talks but a few key points have stuck with me that I am excited to apply in my future work.

Firstly, always bet on the browser. It seemed a recurring theme of this year’s SmashingConf, but for good reason.

Secondly, ditch the out-dated workarounds. Instead, keep an eye on what’s happening with browsers and modern CSS/JavaScript. Progress is quick and constant, and there’s a lot happening that could be beneficial to front end developers.

Thirdly, make time for whimsey in your work. Not only is it fun, it’s a great way to show off your skills!

Oh, and don’t moan about hills in Wales ever again.