DEV Community: Lazar Nikolov

Low effort image optimization tips

Lazar Nikolov — Tue, 26 Mar 2024 19:12:22 +0000

“A picture is worth a thousand words”. So if a picture takes more than 4 seconds to load, does it mean that your website’s content fails to communicate a thousand words? In this blog post, we’ll learn how to identify unoptimized images, how to fix them, and how to validate the fix — so your website can speak volumes with highly-optimized images.

The problem

I wish loading images was as simple as <img src=”...”>, but it ain’t. Loading images is a tricky thing, and it involves more than an img tag with a source attribute. Loading images in an unoptimized way can really hurt your page’s performance. See for yourself (screenshots are from Sentry):

Some of those images take a lot of time to load. Let’s see what actually we’re loading on that page:

This is what a plain <img src=””> page looks like under the hood. Here are all the red flags we can see from the first screenshot:

The images are JPEGs (not the most website-friendly format nowadays)
They’re immediately loaded (not letting the browser display text content first)
They’re too heavy, so they take quite some time to load
The page took about 6 seconds to load

These three things caused the LCP to jump to ~4.2 seconds, the FP/FCP to 813ms, and also put too much work on the browser, which we can see from the many “Main UI thread blocked” spans (profiling revealed a connection between decoding images and long-running tasks on the main thread). Final verdict - the website takes too long to load and it freezes up.

Let’s now see how we can use image optimization to improve performance.

Ditch JPEG for AVIF + WebP

As mentioned, JPEG is not the most website-friendly format nowadays. It produces larger files, doesn’t support transparency, and has visible blocky artifacts when exported with a lower quality. It’s not a modern image format.

Enter AVIF and WebP. Both AVIF and WebP are modern image formats. Compared to JPEG, they both produce smaller file sizes, have less visible blocky artifacts, and support transparency. Additionally, AVIF has support for higher color depth, so color accuracy is better. WebP on the other hand has much better browser support. At the time of writing this article, only Internet Explorer does not have support for WebP.

How you can get to these formats varies by usage. If your images are static, you can use any of the image manipulation apps to re-export the JPEGs you might already have as AVIFs and WebPs. There are also web apps you can use to save yourself some storage space.

If your images are dynamic, or your website has a lot of images, then you have a few options.

Generate images at build time

This approach is useful if you have all the images upfront and you would like to convert all of them before deploying your website. Bear in mind that it won’t work for dynamic images, since you won’t have them at build-time. You can use a Node library like sharp to achieve this. Write a JS script that reads all the images in your project, converts them to AVIF and WebP, and puts them in a different folder in your project. (Tweet me at @NikolovLazar if you’re interested in seeing a more in-depth guide on this).

Generate images on demand

In a similar fashion as build time, but instead move the logic into an API endpoint and perform the conversion on demand. This could be an endpoint that accepts the static image name/path (/assets/lazar.jpg), converts it on request and returns back the correct format. This approach allows you to generate only an AVIF image if the requesting client supports it, otherwise you can default to WebP. Make sure to cache the results! If you have the time, you could also upload the generated images to a CDN and serve those from that point on.

Use a third-party service

Of course, if you don’t want to do all of this work above, you can opt-in and pay for a third-party service, like, imgix, Cloudinary, Vercel’s Image Optimization (if you’re using Next.js), or others. Using these services in your app is a matter of implementing their SDKs and using their components instead of plain img tags

Properly size images

Those “Main UI thread blocked” spans are nasty. Those are moments when the website is frozen. They happen because the intrinsic size of the images is a lot bigger than their rendered size, so the browser needs to spend time rescaling them on the fly. There are a couple of ways to go about this, and it involves tapping into the previous section’s mechanism.

If you know the rendered dimensions of the image, you can modify your generation mechanism (or image request) to scale up/down the image to the right dimensions.

If you don’t know the rendered dimensions, the easiest way to go about this is to simply make sure your images’ dimensions are within the ballpark of what’s possible. Let’s say your layout doesn’t span more than 768px horizontally, and that the images can be full width. The least you can do is to make sure that the images aren’t more than 768px wide. If the majority of your website’s traffic comes from mobile phones, figure out the largest width in that category and generate another set of images for it.

Either way, you’ll see improvements over using original images that are too large for your website.

Use a `<picture>` element instead of just `<img>`

In the previous sections we mentioned generating multiple image formats and multiple image resolutions, but how do you put all of that together? Out with the <img>, in with the <picture>.

The <picture> element allows us to specify “image resources”. It still renders a single image, but it allows us to specify all the formats and resolutions we support, and leaves it to the browser to pick the best option.

<picture>
  <source media="(min-width: 1024px)" type="image/avif" srcset="/optimized/large.avif" />
  <source media="(min-width: 350px)" type="image/avif" srcset="/optimized/small.avif" />
  <img alt="A photo" src="/optimized/fallback.webp" />
</picture>

This is how you can define a picture element that renders two AVIF images based on the viewport’s width, but also provides a fallback WebP image in case the browser does not support the AVIF format. This ensures that the browser will download the smallest possible image, which will improve the time to fetch the image and the time to render it.

If you opted-in to use a third-party service, look at its documentation to see if the platform itself supports automatic format/resolution, and if not, how you can specify the format and resolution.

Choose lazy loading

When you’re loading your images directly impacts the LCP core web vital. You can change the way you’re loading your images through the loading attribute. There is no silver bullet solution, so when you should render your images will depend on a few factors.

If you know the LCP element - for example, a static image that you add to the page manually - you’re better off with loading=”eager” (which is the default btw). This tells the browser to start loading the image immediately, even before the First Paint event. The earlier the browser starts to load the image, the earlier it will finish loading, and the earlier the LCP event happens.

If you don’t know the LCP element (dynamic content), or for any images below the fold, you’re better off with loading=”async”. This tells the browser to defer loading the image until it’s in the viewport. For images below the fold, the LCP score won’t be affected since they don’t count, but also the browser won’t spend any time downloading them. For above the fold images that you can’t predict (dynamic content), you’re still better off loading them lazily. Here’s why:

Dynamic content can cause multiple images to be loaded above the fold
Dynamic content images can also mean different sizes and aspect ratios, which makes the LCP element inconsistent too
Loading all of those images eagerly will slow down the page load, hurting your LCP score

If we were to add lazy loading to the <picture> element above, it would be like this:

<picture>
  <source media="(min-width: 1024px)" type="image/avif" srcset="/optimized/large.avif" />
  <source media="(min-width: 350px)" type="image/avif" srcset="/optimized/small.avif" />
  <img alt="A photo" src="/optimized/fallback.webp" loading="lazy" />
</picture>                                          ^ set it on the img element

The end result

So, if you apply all of the image optimizations above, you get a totally different picture:

Night and day! Here’s what you can see from the screenshot:

Images load significantly faster (AVIF + scaled down + lazy loaded)
LCP brought down to 363ms, while FP/FCP to 98ms
Significantly fewer UI thread blocks
The whole page load finished in 873ms

Converting the images to AVIF and downscaling them also means that the whole page will take a lot less bandwidth to load, which also means your page will be “cheaper” to load. If you’re a mobile user living in a country where data plans are expensive, this can be especially helpful.

So there you go. Four easy image optimization tips that can really make a difference in your website’s performance.

Fixing Fetch Waterfalls in React

Lazar Nikolov — Fri, 22 Dec 2023 19:54:19 +0000

Have you seen this problem?

Or maybe this one?

You’ve most likely seen this:

export const Component = () => {
  const [data, setData] = useState()
  const [loading, setLoading] = useState(true)

  useEffect(() => {
    const fetchData = async () => {
      const res = await fetch(api)
      const json = await res.json()
      setData(json)
      setLoading(false)
    }

    fetchData()
  }, [])

  if (loading) {
    return <Spinner />
  }

  return <> ... <AnotherComponent /> ... </>;
}

Hint: they’re all the same. The first image is Sentry’s Event Details page, the second is Chrome’s Network tab, and the code snippet is what causes it.

If you can answer yes to any of these, then you need to keep reading. If not, you still need to keep reading, so your future self can thank you.

This is called “fetch waterfall” and it’s a common data fetching issue in React. It happens when you create a hierarchy of components that fetch their own data and show a “Loading” state before rendering their child component, which then does the same etc.

A fetches its data and then renders B
B fetches its data and then renders C
C fetches its data

This would be fine if each component’s data depends on its parent’s, but that’s not always the case. If each fetch takes at least a second, then you’re looking at 3+ seconds of page load, which is considered slow by today’s standards. But why wait for 3+ seconds for data that you can get in 1 second if it’s fetched in parallel? Here’s a CodeSandbox of this issue so you can see for yourself.

Let’s explore three ways to maintain good performance and scenarios when you would want to use each solution.

Using “Suspense” to avoid a fetch waterfall

Suspense is oftentimes mentioned as one possible solution to avoid fetch waterfall. And, yes, it does solve the issue. It triggers the whole component tree’s fetches in parallel, so the data gets fetched much faster. But, it’s still not production ready.

React’s docsite explains that only Suspense-enabled data sources will activate the Suspense component, and those are frameworks (like Relay and Next.js), or lazy-loading components with lazy, or reading the promise value with use.

Lazy-loading and the use hook are still not necessarily good solutions. Lazy-loading components won’t eliminate the fetch waterfall. It’ll behave the same way, with just the “loading” fallback from the suspense as the bonus. The use hook is only available in React’s canary version, so it hasn’t been released as stable just yet.

So, if unless you’re using either Next.js or Relay, I wouldn’t advise you to use Suspense as a solution just yet.

But, if you really want to, check out this CodeSandbox example. When it is production-ready it could be a great way to maintain good performance and avoid the fetch waterfall.

Fetch data on server to avoid a fetch waterfall

I hear you, you’re saying the solution is obvious, just make that page server-side rendered, or if you use Next.js - use Server Components. Then the client receives the HTML along with the data and doesn’t have to make any data requests. No requests = no fetch waterfall!

Okay, but then would you fetch the data on the server-side like this?

const pokemon = await fetch(...)
const encounters = await fetch(...)

const locations = []
for (let encounter of encounters ) {
  const location = await fetchLocation(encounter.location)
  locations.push(location)
}

If that was your idea, you’re just passing the ball to the server. The server will still wait to fetch all of the data in series before serving everything back to the client. This is a concurrency problem, not a rendering problem. Just fetching the data on the server won’t automatically solve it.

Yeah, that definitely looks like a waterfall 😁

In fact, you actually made it worse. On a classic SSR (or Server Components without a “loading” component) the TTFB is now slower than the time it takes to fetch the data. And since TTFB has a larger value, all the other web vitals will too!

You could fix the TTFB in Next.js by also providing a loading component, but the waterfall will still keep on falling.

Another thing to consider is that when doing SSR/Server Components, you still render on the browser. The client still needs to display the DOM it got from the server, and then hydrate it so it can be able to “react 😉” to the user interactions. And now:

You have two computers (the browser and your server) performing rendering tasks.
The server has a lot more work to do on each request.
The browser is still showing a blank page to your users (when SSR), and still does some rendering when it gets the response back.

const [pokemon, encounters] = await Promise.all([
  fetchPokemon(),
  fetchEncounters(),
])
const locations = await Promise.all(
  encounters.map((encounter) => fetchLocation(encounter.location))
)

The three fetch methods can be anything - other API requests or database calls - but must return a Promise. Promise.all will trigger all input promises in parallel, and will return a new promise that gets resolved when the last of the input promises gets resolved.

Hoisting the data fetching to avoid a fetch waterfall

Another solution to the fetch waterfall issue is hoisting the data fetching to an upper level in the component hierarchy. Instead of fetching the data at the component level, you can fetch it at the topmost level in your component tree (the first component that starts to fetch the data), and pass it down to the component tree.

App
└── DataContext.Provider
    ├── PokemonPage (useContext -> pokemon)
    └── PokemonEncounters (useContext -> encounters)
        ├── LocationDetails (useContext -> otherPokemon)
        ├── LocationDetails (useContext -> otherPokemon)
        ├── LocationDetails (useContext -> otherPokemon)
        └── ...

Fetching the data in parallel is still important in this case, so make sure you do that.

So - fetch it when the first component mounts, and then pass the data down. Does it solve the problem? Yes. Does it couple the components and introduce prop drilling? Double yes. You can solve that with a Context Provider, so all of the children components can access the part of the data they’re interested in without prop drilling.

I’ve prepared a CodeSandbox example for you, if you want to see how you can implement a hoisted data fetching with a React Context. Here’s how the our requests look like now:

The /pikachu and /pikachu/encounters requests start at the same time, while the /location-area requests depend on the result of the /pikachu/encounters request, but they too start at the same time. We broke out the waterfall.

Hoisting the data fetching mechanism is probably the most universal approach you can take to eliminate the fetch waterfall. It happens on the client side, so your server does less work and your app’s web vitals are lower. It doesn’t rely on experimental features like Suspense, and it doesn’t work only in Next.js, or when using Relay.

Whether you fetch it in a React Context, or fetch it in the parent component and pass it down through the props, it’s up to you. It depends on how your component structure looks like, what you and your team are comfortable with, and what other libraries you use in your project.

For example, if you use TanStack Query, you can perform all the fetches and cache the results in a higher level of the component hierarchy, but then use the QueryClient in each of the components to read the data from the cache. It’s still considered as hoisting, and it can be an alternative if you don’t want to create a new Context. Simply make the fetches where you would put the Context Provider, and read the data from the cache instead of the provider in the components.

Conclusion

So what we can learn from this article is this - there are two things that you can do to cause a fetch waterfall:

Nest components that fetch their own data while conditionally rendering them.
Invoke the requests sequentially (await first, then await second, then await third and so on).

If you’re fetching the data on the client side, make sure you’re not fetching the data in each component while also conditionally rendering them. If each component fetches its own data, and you display them sequentially, then they’re going to sequentially trigger their data fetches -> waterfall.

Hoisting the data fetching mechanism to a more upper-level component is a good fix. It depends on your structure, but you can either fetch it in the parent component and pass it down through the props, create a React Context if passing down the data causes prop drilling, or if you already use a library like TanStack Query - perform the fetches at a higher level and use the QueryClient to read the results from the cache.

Just moving the data fetching to the server side doesn’t mean that you’ll fix the problem. If you’re await-ing each fetch request individually, you’ll still cause a fetch waterfall, but this time on the server-side. This way the TTFB web vital also suffers because the client needs to wait for the server to do all the data fetching before it starts to draw pixels. So not only you didn’t fix the problem, you introduced a new one.

Being mindful of how you build your app, and keeping an eye on its performance in production is how you win in this game.

What’s the difference between API Latency and API Response Time?

Lazar Nikolov — Mon, 13 Nov 2023 15:28:32 +0000

Your app’s networking directly affects the user experience of your app. Imagine having to wait a few seconds for the page to load. Or even worse, imagine waiting for a few seconds every time you perform an action. It would be infuriating! Before you go on a fixing adventure, it’s a good idea to understand what causes that waiting time. So let’s do that!

The difference between Latency vs Response Time

The total client-server communication time is called API Response Time. That’s from the moment the client makes a request, until it receives a response back. A slow request means a very long response time. Anything that contributes to the slowness affects the response time.
The response time consists of the latency and the processing time. The latency is how long it takes to transfer data between the client and the server, or the “processing component”. A few factors contribute to the latency:

the network speed
the server load
the performance of the load balancer
the size of the data we’re sending
and the API design

For example, the client sends a data request to the API and gets a response back in 3 seconds. The total response time is 3 seconds. The latency might be 300ms, which leaves 2500ms, or 2.5 seconds, for processing. Just to have a number in mind, high-performing APIs are considered to have between 0.1 and 1 second average response time. At 2 seconds the delay is noticeable. At 5 seconds the delay is so significant that the users are starting to abandon the application/website.

The response time is one of the most important metrics we need to keep our eyes on. If not, it can significantly hurt the user experience, and even the business itself. Back in 2008, Amazon reported that every 100ms latency costs 1% of their profit. Google also reported that in an experiment that increased the number of search results they noticed that half a second delay caused a 20% drop in traffic. These are significant numbers. Amazon makes $19.4 billion per month. 1% of those sales is $194 million. Add up that number for every 100ms latency and you’ll see the damage. As you can see, learning how to monitor and optimize your API response time is a very good investment.

Just like any other web performance metric, the response time should be measured and monitored in production. Your computer and internet speed might be fast, but your users’ computers and internet are probably not as fast. That results in much less favorable results than what you’ll see if you measured your API’s response time locally. But working with production data also means that you’re working with outliers. The Average Response Time is not always a good metric. Let’s learn how to properly measure the API response time.

Measuring response time

First let’s talk about why ART (Average Response Time) is not a good metric. There are always the edge cases where a small number of your users are reporting the worst response times imaginable. That could be because of a really outdated computer, or they’re trying to access your web app with a bad internet connection (subway, remote locations, etc…), or your API experienced a brief downtime because of a bug or your deployment. You don’t care about those cases because there is usually nothing you can do about them. Calculating an average on that data will take those outliers into account as well, and you don’t want that. You want to exclude those data points from your data. Enter: percentiles.
Percentiles provide you with a different view of your performance data. The data is sorted in a descending order and cut at specific % points. The most commonly used percentiles are p50, p75, p95, p99 and p100.

P50, also called the Median, is the value below which 50% of the data falls. This would be the typical performance of your API.
P75 is the value where 75% of the data falls. This percentile is good for frontend applications because it includes more variable data, which mirrors the variety of the user conditions.
P95 is more valuable for backend applications where the data is more uniform.
P99, also called Peak Response Time, is also more valuable for backend applications, and it marks the upper limit of the performance.
P100 is the maximum observed value. This is the worst measured performance.

If you want to get into more detail about percentiles, read our “Choosing the Right Metric” article.

Another important metric is the Error/Failure Rate of your API. The Error/Failure Rate is a value that indicates the % of requests that resulted with a non-200 status code. Having this data can also help you figure out if things are wrong with your API or documentation. If you’re seeing more “400s” status codes, it might mean that clients don’t use your API properly, or don’t understand it well. If you’re seeing more “500s” status codes then it means you have issues with your code.

Monitoring API response time in production

To monitor your API’s response time (and other metrics as well) in production, you need to implement a mechanism that will continuously take those measurements, save them in a database, and provide you with tools to query and visualize the data. Sentry is an application performance monitoring tool that you can use to monitor all of your frontend, backend, and mobile application projects—not just your API. And don’t worry, Sentry probably has an SDK for whatever framework you’re using.

Getting started is easy. After installing and configuring Sentry’s SDK for your framework of choice, you’ll get automatic instrumentation, which means a bigger part of your backend is already set up with performance monitoring. Depending on the size of your application, this could be enough to get started. If you need more detailed performance data, you can add custom instrumentations in certain places.

When you start getting performance data in your Sentry account, identifying what makes your API slow is quick. Getting to the root cause of the slow performance is even quicker. Sentry’s tracing data makes the performance bottlenecks obvious. Here’s a short arcade that shows you how you can identify performance bottlenecks in your application and figure out what causes them:

Backend Performance Monitoring | Arcade

app.arcade.software

A good resource on improving the performance of your API using Sentry is Lincoln Loop’s “19x faster response time” article.

Conclusion

So, a quick recap. API latency is the time it takes for the data to be transmitted between the client and the backend. The API response time is the latency + the time it takes for the backend to process the request and return the result. Factors like network speed, load balancer, data size, server load, API design, and our code affect the response time.
To properly monitor the performance of your backend, you need to use a tool that will monitor your application while in production. Sentry can help you with that, head to https://sentry.io/signup to get started.

CSS Style Queries

Lazar Nikolov — Thu, 31 Aug 2023 02:02:23 +0000

Style Queries is a very cool feature in CSS, and they’re defined by the containment spec. Aside from being able to query a parent’s inline size (that’s container queries), the containment spec also includes the ability to query a parent’s style values (that’s style queries). Even though the container queries are available in all modern browsers, the style queries aren’t. Chrome and Edge have it. Opera’s working on it. Firefox and Safari, not so much. If you haven’t learned about container queries so far, check out our Container Queries article. Style queries are just slightly different than container queries, so I’d suggest to learn about container queries first. Alright, let’s play with some style queries!

Syntax

Here’s our first example:

The markup is simple. We have a list of collection of cards who have an image, a title and some text. We can see that the images have an overlay with different colors. We can call them different variants of the card, and it’s a really good example for demonstrating style queries. Let’s break down the example. In the markup, we can see that we’re defining a CSS variable on every <li> element: style='--variant: teal', and that’s all we need to do in our markup. Then in our CSS we define a container query, but instead of querying on its size, we’re querying on its specific style value, which is the variable we defined earlier: @container style(--variant: teal). This creates a containment context on the element that has the --variant: teal variable, and that’s the first <li> element. Just like the container queries, everything we put inside has to target a descendant of that <li> element. In our case we’re targeting the .poster element, which is the image, and we’re setting its ::after element’s content to a specific SVG image:

@container style(--variant: teal) {
    .poster::after {
        content: url("data:image/svg+xml;base64,PHN2Zy.........)
    }
}

We can now repeat the same for the other variants cream, mint, pink, yellow and sky, and our card variants will be done!

You might’ve also noticed that even though the style queries are built on top of container queries, we didn’t define the container or container-name anywhere. CSS is smart enough to figure it out for you. But what if you have multiple components that use the --variant variable? In that case, you can explicitly define the container name, so your style queries don’t mix:

li {
   container-name: daily-mix-card;
    /* ... */
}

@container daily-mix-card style(--variant: teal) {
    /* ... */
}

Combining multiple styles

Let’s see another example:

In this example we’re using the variables to indicate whether certain things should be visible in the card. There are three variables: ---star-seller, ---order-soon, and ---free-delivery. All of them when set to true will make the “✪ Star Seller”, “Only X left - order soon” and “FREE delivery” (respectfully) elements visible. If you look at line 29 in the HTML you’ll see that we have two variables defined: --star-seller and --order-soon. And if you look at the “EWB Bench” item, you’ll see that both the purple “Star Seller” and the red “Only 1 left - order soon” labels are displayed. Or check out the vintage lamp item with the red border around its image. It has all three styles set to true. To define a style query that queries on multiple styles, use and to combine the style(...) functions like this:

@container style(--star-seller: true) and style(--free-delivery: true) and style(--order-soon: true) {
  img {
    border: 3px solid red;
  }
}

With this approach, we can create and combine as many styles as we like. The best thing about it is that everything is controlled just by the style attribute of the <li> element. If we want to dynamically control that using JavaScript, all we need to do is invoke the setProperty method of the element’s style property:

product.style.setProperty('--star-seller', true);

Conclusion

Just imagine what you can do with style queries. All that with just pure CSS! No JavaScript logic to show/hide or conditionally render certain elements. Style queries allow us to define variants of our components, or toggle the visibility of certain elements, all just by setting a single CSS variable at the root element. We can also dynamically add/remove/change the variables with JavaScript by using the style.setProperty() method.

Another benefit of this feature is the separation of data from design. The HTML and CSS define all the possible varieties, while the JavaScript only toggles them. And since we’re talking about plain JavaScript, we can use style queries to define our variants and togglable elements without being constrained to a specific UI framework! That’s why this CSS feature is a game changer, and I can’t wait for it to be supported by all modern browsers.

CSS Container Queries

Lazar Nikolov — Thu, 31 Aug 2023 01:59:52 +0000

Unlike Media Queries, which let you apply styles to an element based on the viewport size, Container Queries let you apply styles to an element based on its own size. Talk about next level responsive design! And the best thing is, it’s supported by all modern browsers! Let’s say you want a card’s layout to be horizontal if it has at least a certain width, and switch to vertical when it gets narrower. Here’s an example:

Containment context

Looking at the example, we can see that our article.post-card has a container property with a value of post-card / inline-size. This declares a containment context on our post card element. The container is a shorthand property that sets the container-name to post-card and the container-type to inline-size. The inline-size value declares the containment context on the inline axis of the container. This means that you can only define styles based on the width of the container. If you also want to define styles based on the height, you can use the size value.

Bear in mind that when you declare a container to a certain element, it will prevent it from being sized based on its contents. This goes for both size and inline-size. To provide size to the “containerized” element, you would need to either define it through its parent (flex and grid stretch by default) or its display (block also stretches by default), or set its width or height explicitly. Setting the container-type to size will collapse its height, while setting it to inline-size will collapse its width.

Another thing to have in mind is that you can’t use an inline element as a container. If you were to define a span as a container, you could, but you’d have to make it a non-inline display. Rule of thumb: any element that’s not inline can be made into a container.

Container query

Check out line 40. We set the .content element’s flex-direction to column. On smaller sizes we want the image and text to be one on top of the other, but if we have enough horizontal space we can actually put them one next to the other, or set the flex-direction to row. That’s a use case for a container query! Scroll down to line 96:

@container post-card (min-width: 512px) {
  ...
}

This is how we define a container query. With this line, we’re basically telling CSS “when the post-card container (not element with class) has at least 768px of width, apply these styles (…)”. The top level scope is the article.card element. We should take that in consideration when writing the selectors. On line 99 we redefine the .content element’s flex-direction to row. That’ll make the image and text to flow horizontally, and if we expand the viewport enough we’ll see that the card’s content changes direction. Notice that if we change the selector to article.post-card div.content it won’t work, even though it’s a perfectly valid selector, because it would expect to find an article.post-card inside of the article.post-card element and we both know that’s wrong. But following this example, we can redefine any property of any descendant of our article.post-card. That’s the beauty of it!

Container query units

Along with the new @container syntax, we also get brand new values that are relative to the container size. Here are they:

cqw is 1% of the container’s width
cqh is 1% of the container’s height
cqi is 1% of the container’s inline size
cqb is 1% of the container’s block size
cqmin and cqmax are the smallest and largest (respectfully) value of either cqi or cqb

So, if we wanted to set something to be the 3% of the container’s width for example, we would set it to 3cqw. Scroll all the way down to line 123, 128 and 133, and you’ll see that the text elements are being set to a certain percentage of the container’s inline size. Try changing the size of the card and you’ll see that the font size grows and shrinks with the card. This might not be a real-world use case, but you get the gist 😁.

Conclusion

So there you have it! Container Queries! How cool are they? You can use them to define responsive elements that react not based on the viewport’s size, but based on the space they’re given, regardless of the viewport size. That means that you can have two instances of the same component on a page, but because of the different space they’re given, they’ll appear differently. Check out the creatures.dev blog page. The featured post card is the same component as the post cards in the grid below. That card is the card from this example, but used in production. If you want to see more use cases, check out this article (takes you to CSS Tricks).

Getting started with CSS Nesting

Lazar Nikolov — Sat, 12 Aug 2023 21:48:34 +0000

CSS Nesting used to only be possible in CSS preprocessors like Sass and Less. But guess what, it's now built in native CSS and all modern browsers will support it after August 29th. Let's see what's CSS Nesting and how we can use it.

What is CSS Nesting?

CSS Nesting is a new feature that allows you to nest selectors inside other selectors. Nesting helps by reducing repetition, reducing the file size, better file organization and easier refactoring. Let's see an example without nesting:

/* No nesting */
article.card {
  border: 1px solid lightgrey;
  border-radius: 6px;
  overflow: hidden;
}

article.card header {
  border-bottom: 1px solid lightgrey;
  background: #f1f3f4;
  padding: 16px;
}

This example can be written with nesting like this:

/* With nesting */
article.card {
  border: 1px solid lightgrey;
  border-radius: 6px;
  overflow: hidden;

  & header {
    border-bottom: 1px solid lightgrey;
    background: #f1f3f4;
    padding: 16px;
  }
}

Nesting examples

To get a good feel of how nesting works, let's see some more examples.

Multi-level nesting

article.card {
  border: 1px solid lightgrey;
  border-radius: 6px;
  overflow: hidden;

  & header {
    border-bottom: 1px solid lightgrey;
    background: #f1f3f4;
    padding: 16px;

    & h2 {
      margin: 0;
    }
  }
}

In this example we can see that we can nest as many levels as we want. The first level is the article.card selector, which is the root selector. The second level is the & header selector, which is nested inside the root selector. The header styles will only be applied to header elements that are children of article.card elements.

Nesting without the `&` symbol

article.card {
  border: 1px solid lightgrey;
  border-radius: 6px;
  overflow: hidden;

  .content {
    border-bottom: 1px solid lightgrey;
  }
}

We don't always need to add the & symbol to indicate nesting. If we don't add it, CSS will add & + " " (space) in front of the nested selector. By explicitly placing the & symbol, we can control where the parent selector should be placed.

Nesting pseudo-classes

article.card {
  /* ... */

  :is(.content, footer) {
    padding: 16px;
  }
}

It's also possible to nest pseudo-classes like the :is() in this example. As we saw in the previous example, if we don't add the & symbol CSS is going to add that for us + an empty space, so this example will target all children of
the article.card element that are either .content or footer elements. The "compiled" selector will look like this:

article.card :is(.content, footer): {
  /* ... */
}

Nesting pseudo-elements

article.card {
  /* ... */

  & footer a {
    /* ... */

    &:hover {
      background: maroon;

      &::after {
        content: '>';
        margin-left: 12px;
      }
    }
  }
}

Just like the pseudo-classes, we can also nest pseudo-elements. In this example we're defining hover styles for the a element that's a child of the footer. We're also defining styles for the ::after pseudo-element of the a element while it's being hovered. Feel free to play around with the example above to see the result.

Nesting `@media` queries

article.card {
  /* ... */

  @media (min-width: 768px) {
    /* ... */
  }
}

We can also nest @media queries. This is a great way to keep the styles for a specific breakpoint in one place. This way we can easily find and update them if needed.

The `&` symbol

As mentioned in the previous examples, the & symbol is used to indicate where the parent selector should be placed. This gives us more control over the final selector, and if needed, we can also completely rearrange the whole context. Let's see some examples:

a {
  &:hover {
    /* a:hover */
  }

  :hover {
    /* a :hover */
  }
}

In this example we can see the different output when we use the & symbol and when we don't. In cases where we want to define pseudo-classes for the parent selector, we'd need to use the & symbol. Otherwise, CSS will add the parent selector in front of the pseudo-class.

Since the & symbol is just a placeholder for the parent selector, we can also use it multiple times in the same selector, and flip the context completely:

header {
  & h2 {
    /* header h2 */
  }

  h2 & & & {
    /* h2 header header header */
  }
}

Understanding the parser

The nesting parser is what's responsible for parsing the nested selectors. The way that the parser identifies if the selector is defining a nested style is by checking whether the selector contains one of the symbols below:

& @ : . > ~ + # [ *

You might recognize some of these symbols. Some of them are used for selectors, pseudo-classes and pseudo-elements, combinators, attribute selectors etc...

If the parser finds a nested selector that doesn't start with any of these symbols, it will fail to parse it, which will result in incorrect styles.

Conclusion

Nesting is a great feature that can help us write more maintainable CSS. It can also help us write less code since we don't need to repeat the parent selector over and over again. This is huge for CSS, and I'm excited to see all of the creative ways developers are going to come up with to use it.

Getting Started with Jetpack Compose

Lazar Nikolov — Fri, 03 Mar 2023 21:04:28 +0000

Recently, we wrote about the demonstrative move to declarative UI. With Jetpack Compose, Android is joining the declarative trends.

Jetpack Compose, a new declarative UI toolkit by Google made for building native Android apps, is rapidly gaining traction. In fact, as announced at the Android Dev Summit last year last year, 160 of the top 1,000 Android apps already use Jetpack Compose. In contrast to the traditional XML Views, Jetpack Compose allows you to build UIs using composable functions that describe how the UI should look and behave.

The main advantage of using Jetpack Compose is that it allows you to write UI code that is more concise and easier to understand. This leads to improved maintainability and reduced development time.

The main disadvantage of using Jetpack Compose is that it’s relatively new, so its ecosystem is limited and the number of available libraries, tools, and resources is lower than the traditional ecosystem.

Despite that, we believe that learning Jetpack Compose is worth the learning curve and challenges. Here are some tips we've found helpful as you are getting started.

How to start using Jetpack Compose

The recommended IDE for working with Jetpack Compose is Android Studio. After downloading and installing Android Studio, you’ll get the option to create a new project. To create a new Jetpack Compose application, you need to select either the Empty Compose Activity (which uses Material v2), or Empty Compose Activity (Material3) (which uses the Material v3 which is in version 1.0 as of last year). You can see both options in the top right of this screenshot:

This is the easiest way to get started with Jetpack Compose. If you’d like to enable Jetpack Compose into an existing Android application, here’s what you need to do:

1. Add the following build configurations in your app’s build.gradle file:

android {
  buildFeatures {
    // this flag enables Jetpack Compose
    compose true
  }

  composeOptions {
    // the compiler version should match
    // your project's Kotlin version
    kotlinCompilerExtensionVersion = "1.3.2"
  }
}

2. Add the Compose BOM (Bill of Materials) and the subset of Compose dependencies to your dependencies:

dependencies {
  def composeBom = platform('androidx.compose:compose-bom:2023.01.00')
  implementation composeBom
  androidTestImplementation composeBom

  // Choose one of the following:
  // Material Design 3
  implementation 'androidx.compose.material3:material3'
  // or Material Design 2
  implementation 'androidx.compose.material:material'
  // or skip Material Design and build directly on top of foundational components
  implementation 'androidx.compose.foundation:foundation'
  // or only import the main APIs for the underlying toolkit systems,
  // such as input and measurement/layout
  implementation 'androidx.compose.ui:ui'       

  // Android Studio Preview support
  implementation 'androidx.compose.ui:ui-tooling-preview'
  debugImplementation 'androidx.compose.ui:ui-tooling'

  // UI Tests
  androidTestImplementation 'androidx.compose.ui:ui-test-junit4'
  debugImplementation 'androidx.compose.ui:ui-test-manifest'

  // Optional - Included automatically by material, only add when you need
  // the icons but not the material library (e.g. when using Material3 or a
  // custom design system based on Foundation)
  implementation 'androidx.compose.material:material-icons-core'
  // Optional - Add full set of material icons
  implementation 'androidx.compose.material:material-icons-extended'
  // Optional - Add window size utils
  implementation 'androidx.compose.material3:material3-window-size-class'

  // Optional - Integration with activities
  implementation 'androidx.activity:activity-compose:1.5.1'
  // Optional - Integration with ViewModels
  implementation 'androidx.lifecycle:lifecycle-viewmodel-compose:2.5.1'
  // Optional - Integration with LiveData
  implementation 'androidx.compose.runtime:runtime-livedata'
  // Optional - Integration with RxJava
  implementation 'androidx.compose.runtime:runtime-rxjava2'
}

How do you build UI in Jetpack Compose?

Jetpack Compose uses Composables to define the view hierarchy, and modifier to apply visual appearance and behavior changes to the composables they’re added to.

Composable functions

Composable functions (or just Composables) are ordinary Kotlin functions that are annotated with @Composable, can be nested within another composable functions, and return a hierarchy of other composables in order to define their UI. Let’s see a simple composable that defines a contact row UI that contains a user photo, and a name and phone number:

@Composable
fun ContactRow(user: User) {
  Row {
    Image (
      painter = painterResource(id = R.drawable.user),
      contentDescription = "A photo of a user"
    )

    Column {
      Text(user.name)
      Text(user.phone)
    }
  }
}

The Row composable is a layout composable that renders its children one next to another. The Image composable is the first child which is going to render the user drawable. Then we have the Column composable which, similar to the Row, is a layout composable, but it renders its children one below another. The children of the Column composable are two Text composables that render the user’s name and phone number.

Modifiers

Modifiers are used to change the visual appearance and behavior of the composables they’re added to. We use modifiers when we want to change UI elements such as the size of the composable (width, height), the padding, background, or alignment.

Modifiers can also be stacked on top of each other, allowing us to modify multiple visual properties. Here’s an example of how we can set the padding and max width of the Contact row from the previous snippet:

@Composable
fun ContactRow(user: User) {
  Row(modifier = Modifier.fillMaxWidth().padding(16.dp)) {
    ...
  }
}

How do you interact with data in Jetpack Compose?

There are multiple ways to keep data within your Jetpack Compose app: MutableState, LiveData, and StateFlow.

MutableState

In Jetpack Compose, state management can be accomplished by using the remember API to store an object in memory, and the mutableStateOf to declare a state variable. We can store both mutable and immutable objects. The mutableStateOf creates an observable MutableState<T>, which is an observable type.

interface MutableState<T> : State<T> {
  override var value: T
}

Any changes to value schedules a recomposition (re-rendering) of any composable functions that read it.
There are three ways to declare a MutableState object:

val mutableState = remember { mutableStateOf(0) }
var value by remember { mutableStateOf(false) }
val (value, setValue) = remember { mutableStateOf("Hello, Compose!") }

LiveData

LiveData is a data holder class that can be observed within a given lifecycle, meaning it respects the lifecycle of other app components, such as activities, fragments, or services. This ensures LiveData only updates observers that are in an active lifecycle state, which also ensures no memory leaks happen within your app.

Let’s see an example of working with LiveData:
1. You need to create an instance of the LiveData class to hold a certain type of data, which is usually done within your ViewModel class (use MutableLiveData if you’d like to update the value at some point):

class HomeViewModel : ViewModel() {
  // Create a MutableLiveData instance that keeps a string
  val userName = MutableLiveData<String>()
}

2. Obtain the value in your composable by calling the observeAsState method:

@Composable
fun HomeScreen (viewModel: HomeViewModel = viewModel())   {
  // Create an observer of the state of userName
  val userName = viewModel.userName.observeAsState()

  // Use the value in your UI
  Column {
    Text(userName)
  }
}

3. To update userName's value (also usually done in the view model), create a function that sets the new value to its value property:

fun updateUserName(newName: String) {
  userName.value = newName
}

4. You’d use the new function in your Compose file as viewModel.updateUserName("...").

StateFlow

StateFlow is a newer alternative to LiveData. Both have similarities, and both are observable. Here’s how you can work with StateFlow in Jetpack Compose:
1. Create an instance of StateFlow to hold a certain type of data (use MutableStateFlow if you’d like to update the value at some point)

class HomeViewModel : ViewModel() {
  // Create a MutableStateFlow instance that keeps a string
  val userName = MutableStateFlow<String>()
}

2. Obtain the value in your composable by calling the collectAsState method:

@Composable
fun HomeScreen (viewModel: HomeViewModel = viewModel())   {
  // Create an observer to collect the state of userName
  val userName = viewModel.userName.collectAsState()

  // Use the value in your UI
  Column {
    Text(userName)
  }
}

3. To update userName's value (also usually done in the view model), create a function that sets the new value to its value property:

fun updateUserName(newName: String) {
  userName.value = newName
}

4. You’d use the new function in your Compose file as viewModel.updateUserName("...").

What are the best practices for Jetpack Compose?

Aside from the official best practices documentation, we’ve got a few additional tips that would make your codebase safer and easier to work in.

Code organization

Every developer or organization has their own opinions on how a project should be structured. There is no “right” or “wrong” way to do it. Okay, maybe it’s wrong to put every file in one single directory 😅. Here’s an example structure to help you get started, which you can modify and evolve as your project grows:

.
├─ 📁 **ui** (to keep all your UI related things)
|  ├─ 📁 **screens** (where you define your screens composables and their corresponding view models)
|  |  └─ 📁 **home**
|  |     ├─ 📝 **HomeScreen.kt** (the UI for the Home screen)
|  |     └─ 📝 **HomeViewModel.kt** (the view model for the Home screen)
|  ├─ 📁 **components** (where you define components that are shared across multiple screens)
|  |  └─ 📝 **UserList.kt**
|  └─ 📁 **theme** (where you keep your theme definition and design tokens)
|     ├─ 📝 **Colors.kt**
|     ├─ 📝 **Shapes.kt**
|     ├─ 📝 **Theme.kt**
|     └─ 📝 **Typography.kt**
├─ 📁 **utils** (where you keep your various utility functions, like data converters etc...)
|  └─ 📝 **DateUtils.kt** 
└─ 📝 **MainActivity.kt** (this is your default MainActivity)

Avoid creating “god” files

“God” files are a big no-no. They’re files that contain all code associated with them: UI, domain, business logic, utility functions etc… It might be easier putting everything into one file, but maintaining that would get harder and harder as you add functionalities. The solution to this is using a proper architecture in your Jetpack Compose app.

There are multiple architectures that you can use, all with their own pros and cons. The most common one in Jetpack Compose is MVVM, abbreviated from Model-View-ViewModel, because Jetpack Compose has a first-class ViewModel implementation.

Stay true to the MVVM

As you saw from the previous examples, Jetpack Compose has a first-class ViewModel implementation. The MVVM, or Model-View-ViewModel, is a software design pattern that is structured to separate business logic from the UI. That means, your UI should not handle state updates, but it should let the view model do that by sending it user actions.

Let’s explore that with an example. Remember the MutableStateFlow example from before? That example was oversimplified on purpose, but in a real-world project you would never expose a MutableStateFlow from your ViewModel, but just a StateFlow. In order to make that work, you should define a private MutableStateFlow variable and a public StateFlow variable that returns the mutable flow by invoking the asStateFlow() method.

class HomeViewModel : ViewModel() {
  // Create a private MutableStateFlow instance that keeps a string
  private val _userName = MutableStateFlow<String>()

  // Create a public StateFlow that returns the MutableStateFlow as immutable
  val userName: StateFlow<String> = _userName.asStateFlow()
}

With this simple change, we’re preventing the UI from being able to change the state. But, how do we actually change the state? We’ll expose a function from the view model that does that!

class HomeViewModel : ViewModel() {
  private val _userName = MutableStateFlow<String>()
  val userName: StateFlow<String> = _userName.asStateFlow()

  // Create a public function that updates the private MutableStateFlow value
  fun setUserName(newName: String) {
    _userName.value = newName
  }
}

So now the UI has an immutable StateFlow that it can observe, and a function to update its value. The business logic lives inside of the view model, while the Composable is only responsible to react to state changes and send user actions to the view model.

Don’t create a thousand flows

So you’ve learned how to create state flows. Great! Would you repeat the same for every state variable you need in your UI? Please don’t 😅 To avoid that, you can create a data class that keeps all of the values of your state, and create a single flow that uses it.

Let’s learn this with an example. If we wanted to also keep the user’s phone number, email and address, we can create a data class called HomeScreenState that contains all those values:

data class HomeScreenState(
  val userName: String = ""
  val userPhone: String = ""
  val userEmail: String = ""
  val userAddress: String = ""
)

Then we would refactor our view model to use the new HomeScreenState instead of a String:

class HomeViewModel : ViewModel() {
  private val _uiState = MutableStateFlow<HomeScreenState>()
  val uiState: StateFlow<HomeScreenState> = _uiState.asStateFlow()

  // ...
}

And then we can use all of the values in our composable by viewModel.uiState.userName. If we also wanted to be able to update all those values, we would create functions for each of them in our view model:

class HomeViewModel : ViewModel() {
  private val _uiState = MutableStateFlow<HomeScreenState>()
  val uiState: StateFlow<HomeScreenState> = _uiState.asStateFlow()

  fun updateUserName(newName: String) {
    _uiState.update {
      it.copy(
        userName = newName
      )
    }
  }

  fun updateUserEmail(newEmail: String) {
      _uiState.update {
        it.copy(
          userEmail = newEmail
        )
      }
    }
  }

  // ...

}

Keep a close eye on your errors and performance in production

As you're getting acclimated to Jetpack Compose, an error and performance monitoring tool can be really helpful to reduce your learning curve and ensure that your app is bug-free. Jetpack Compose does a lot of heavy lifting for developers – as a declarative toolkit, developers need to write less code to describe their UI, and Jetpack Compose takes care of the rest. But it does abstract away a lot of code, making it difficult to identify errors.

Sentry offers an out-of-the-box integration that can help you build a better Jetpack Compose app. The integration gives precise context to reduce troubleshooting time with transactions and breadcrumbs. Keep an eye on all the issues and crashes your app is experiencing in production, with a lot of context as to why the issue happened, the exact line of code that triggered it, and all sorts of hardware and software info of the device it ran.

Conclusion

I’d totally understand if you’re feeling overwhelmed by now, but let’s do a quick recap! We’ve learned how to create a new Jetpack Compose project, and that Jetpack Compose uses Composables and Modifiers to define the view hierarchy and apply visual changes. Data in Jetpack Compose can be handled either with a MutableState, LiveData, or StateFlow, which make the composables that observe it re-render when the value changes, making our UI dynamic. We also learned how to keep our projects tidy, and how to write maintainable composables and view models.

Even though it’s a relatively new technology, Jetpack Compose’s ecosystem is steadily growing, so we can expect to see a lot of libraries pop up that make it easier to create Jetpack Compose apps. With companies like Lyft, Twitter, Airbnb, Square, Reddit, and Firefox putting their trust into it, more and more developers will follow along and create apps, libraries and resources for Jetpack Compose.

Mobile: The Future is Declarative

Lazar Nikolov — Fri, 30 Dec 2022 10:55:05 +0000

The mobile development ecosystem has always been very diverse, arguably more diverse than the web development ecosystem. While it seems like every day there are more frameworks and tools for web developers, a lot of them are built on top of JavaScript and implement similar patterns to each other. The mobile ecosystem, on the other hand, has a core set of languages that make the differences between mobile tools and frameworks much easier to identify.

Two of the leading native mobile platforms are native Android and iOS, both of which have had interesting innovations recently. With the introductions of Jetpack Compose and SwiftUI, developing native apps looks very similar to developing React Native or Flutter apps. Both React Native and Flutter have a declarative approach from the start, but with Android and iOS now joining the declarative bandwagon, we can see that the future of mobile development is declarative.

A little history

While React Native and Flutter have always taken a declarative approach, Android and iOS started completely different.

Android utilized (and still does) Views. Views are XML files where we define our user interfaces using widgets like Button, TextView, LinearLayout and where we assign IDs to those widgets. Those IDs are then used to reference widgets in our Java files where we develop the functionality and behavior. Here’s an example View file:

<LinearLayout
  xmlns:android="http://schemas.android.com/apk/res/android"
  android:layout_width="match_parent"
  android:layout_height="match_parent">
  <TextView
    android:id="@+id/text_view_id"
    android:layout_height="wrap_content"
    android:layout_width="wrap_content"
    android:text="@string/hello" />
</LinearLayout>

And we would create a reference to the widget like this:

public class MainActivity extends Activity {
  protected void onCreate(Bundle savedInstanceState) {
    super.onCreate(savedInstanceState);
    setContentView(R.layout.activity_main);

    // Create a reference to the TextView using its ID
    final TextView helloTextView = (TextView) findViewById(R.id.text_view_id);

    // Change the TextView's text
    helloTextView.setText(R.string.user_greeting);
  }
}

iOS did have some declarative features, like Auto Layout, UIAppearance, the Objective-C @property declarations, KVC collection operators, and Combine, but it still required writing some level of imperative code.

For example, iOS had (and still has) Storyboards. Storyboards is a graphical tool we use to build our UIs. It is actually an XML file under the hood, but the developers almost never touch the XML code itself. Here’s how we added UI elements in our Storyboards, and created references and actions:

Becoming declarative

To refresh our memory, the imperative approach is when you provide step-by-step instructions until you achieve the desired UI. The declarative approach is when you describe how the final state of the desired UI should look.

Android’s new Jetpack Compose is written in Kotlin, which is a programming language as opposed to XML, which is a markup language. The previous XML View example would look something like this in Jetpack Compose:

class MainActivity: ComponentActivity() {
  override fun onCreate(savedInstanceState: Bundle?) {
    super.onCreate(savedInstanceState)

    // Start defining the UI
    setContent {
      BasicsCodelabTheme {
        // Add a Row (alternative to LinearLayout)
        Row(modifier = Modifier.fillMaxSize()) {
          // Add a Text (alternative to TextView)
          Text("Hello, Sentry!")
        }
      }
    }
  }
}

As you can see, building UIs with this approach requires a lot less code. And, since we stay in a programming language context, we can directly use variables and callbacks instead of creating references to widgets and attaching logic to those widgets. Any change in the values will trigger a recomposition (rerender), so our UI is always up to date.

iOS’s SwiftUI is pretty much the same, just built with Swift instead. The previous Storyboard example would look something like this in SwiftUI:

struct ContentView: View {
  var body: some View {
    Button {
      // handle onClick
    } label: {
      Text("Button")
    }
  }
}

Again, much less code. And we’re in a programming language, so we can directly define the Button’s label and provide an onClick callback without creating a reference.

One issue we stumbled upon when working with the imperative UIKit is activating constraints of a view before adding it to the view hierarchy:

let subview = UIView(frame: .zero)
subview.leadingAnchor.constraint(equalTo: view.leadingAnchor).isActive = true
// ^^^ it's going to crash on this line with the error:
//
// Unable to activate constraint with anchors *** because they have
// no common ancestor. Does the constraint or its anchors reference
// items in different view hierarchies?  That's illegal.

view.addSubview(subview)

Swapping the subview.leadingAnchor.constraint(...) line with the view.addSubview(view) line will work without an error. Admittedly, it took me a while to understand what was going on when I first encountered this error, and I triggered this error a few more times until it became a muscle memory for me. But with the new declarative approach we’re not going to encounter this issue. (Muscle memory in coding is good, but it’s better to improve the developer experience).

This shift towards declarative in Android and iOS is a huge step towards better developer experience and faster development. Defining your UI in a declarative way using a programming language solves a lot of the pain points that Android and iOS developers have.

Here are some of the benefits of the declarative approach:

Theming becomes easier and more dynamic.
State Management feels natural and actually plays a crucial role in the new declarative approach.
The composition approach allows us to compose our UI by nesting components, which is inferred from the nesting of the code’s block scope.
Dynamic layouts and conditional rendering are now straightforward because we’re building our UIs with programming languages that have control structures and branching logic.
It’s easier to grep through Swift/Kotlin code than through XML.
We can more uniformly refactor our code using the same tools that apply to the rest of the programming language.
The code diffs in PRs are easier to understand.
Since our UI elements are built with actual data structures (i.e. functions, classes, structs) as opposed to markup language, we have the possibility of doing unit tests on our Views as well (not available for Jetpack Compose at the time of writing this blog post).

Of course, there are always some drawbacks to be aware of. It’s worth mentioning that both SwiftUI and Jetpack Compose are only 2-3 years old. A short research on their drawbacks will reveal the lack of documentation, smaller community, some performance issues (for example Android’s lazy columns), not all components from the previous frameworks are supported, and there are limitations when it comes to building more complex UIs. Though they are still evolving and improving, be mindful of the pain points if you decide to start working with them today.

Example UI

Let’s look at how the same example UI is built in the declarative approach for both iOS and Android:

iOS (SwiftUI):

//: An example Modal UI built with SwiftUI

import SwiftUI
import PlaygroundSupport

struct ContentView: View {
    @State private var emailAddress = ""
    var body: some View {
        VStack(spacing: 16) {
            Image(systemName: "envelope.fill")
                .font(.largeTitle).foregroundColor(.blue)
            Text("Sign up to our newsletter!").font(.title).fontWeight(.bold)
            Text("Since you love our content so much, why not get them every day in your inbox?")
                .multilineTextAlignment(.center)
                .foregroundColor(.secondary)
                .frame(width: 400)
            HStack(spacing: 0) {
                TextField("john@doe.xyz", text: $emailAddress)
                    .frame(height: 40)
                    .padding(.leading, 12)
                    .border(.gray)
                Button(action: {
                    // Handle onClick logic
                }) {
                    Text("Subscribe")
                        .foregroundColor(.white)
                }
                .padding(.horizontal, 16)
                .padding(.vertical, 10)
                .background(.black)
            }
            .frame(width: 400)
        }
        .padding(40)
    }
}
// Present the view controller in the Live View window
PlaygroundPage.current.setLiveView(ContentView())

(View iOS gist here)

Android (Jetpack Compose):

@Composable
fun Modal() {
    Column(
        horizontalAlignment = Alignment.CenterHorizontally,
        modifier = Modifier.padding(40.dp),
    ) {
        Icon(
            Icons.Filled.Email,
            "icon",
            tint = Color(52, 120, 246), // similar to the iOS one
            modifier = Modifier.size(48.dp)
        )
        Text(
            "Sign up to our newsletter!",
            fontWeight = FontWeight.Black, fontSize = 24.sp,
            modifier = Modifier.padding(top = 16.dp)
        )
        Text(
            "Since you love our content so much, why not get them every day in your inbox?",
            textAlign = TextAlign.Center,
            color = Color.Gray,
            fontSize = 14.sp,
            modifier = Modifier.padding(top = 16.dp)
        )
        Row(
            verticalAlignment = Alignment.CenterVertically,
            modifier = Modifier
                .padding(top = 16.dp)
                .height(56.dp)
        ) {
            TextField(
                "",
                onValueChange = {},
                placeholder = { Text("john@doe.xyz") },
                colors = TextFieldDefaults.textFieldColors(
                    backgroundColor = Color.White,
                ),
                modifier = Modifier
                    .border(BorderStroke(1.dp, Color.Black))
                    .weight(1f)
                    .background(Color.White)
                    .fillMaxHeight()
            )
            Button(
                onClick = { /* handle onClick logic */ },
                colors = ButtonDefaults.buttonColors(
                    backgroundColor = Color.Black,
                    contentColor = Color.White,
                ),
                contentPadding = PaddingValues(horizontal = 16.dp, vertical = 10.dp),
                shape = RoundedCornerShape(0.dp),
                modifier = Modifier.fillMaxHeight()
            ) {
                Text("Subscribe")
            }
        }
    }
}

(View Android gist here)

Conclusion

The declarative approach of building UIs brings us a ton of benefits and eliminates a lot of the “pain points” we had in the imperative approach, but it also introduces new ones. Building UIs requires a lot less time with the declarative approach, and a lot less code. It’s also easier to achieve dynamic layouts and conditional rendering.

Since the native platforms are taking this approach, it also sets up the whole ecosystem for creating new frameworks on top of the native ones that will bring a lot more features and possibilities. It might be a bit early to call them “the industry standard” yet, but the mobile development world is about to get even more productive.

Measuring application performance in Swift using transactions

Lazar Nikolov — Tue, 22 Nov 2022 21:43:00 +0000

So you're building a mobile app that’s performing big data requests; or crunching big data. But now you're asking yourself:

How will my app perform in production?
How will it perform on a lower-tier phone?
Is there a scenario where the function's execution time is unbearably long?

With Sentry’s Custom Instrumentation you can keep an eye on those big data-handling functions. Let’s see how you can implement them in your Storyboard and SwiftUI projects.

Requirements

First, you need to setup performance monitoring. With performance monitoring, Sentry tracks application performance, measures metrics like throughput and latency, and displays the impact of errors across multiple services.

To get your app setup with performance monitoring, you need to configure the traces sample rate in your Swift.UI.App file's init() method:

import Sentry

// This should be in your SwiftUI.App file's init() method
SentrySDK.start { options in
  options.dsn = "[YOUR_DSN_HERE]"

  // Example uniform sample rate: capture 100% of transactions
  // In Production you will probably want a smaller number such as 0.5 for 50%
  options.tracesSampleRate = 1.0

  // OR if you prefer, determine traces sample rate based on the
  // sampling context
  options.tracesSampler = { context in
    // Don't miss any transactions for VIP users 
    if context?["vip"] as? Bool == true { 
      return 1.0 
    } else { 
      return 0.25 // 25% for everything else
    }
  }
}

Implementing custom transactions

Now that you’ve got performance monitoring enabled, you can start setting up custom transactions in the functions you’d like to measure. The measurement starts when you start a new transaction:

// don't forget to import Sentry's SDK at the top
import Sentry

// ...

func syncPersonDatabase() {
  let transaction = SentrySDK.startTransaction(
    // Give the transaction a descriptive name
    name: "transaction-name",

    // Give the operation a descriptive name
    operation: "transaction-operation"
  )

  // ...
  // perform the operation
  // ...
}

For example, let’s say you want to measure how long it takes to sync a database of all people within a company; the “person database”. The name and operation could be "Sync person database" and "data.update" respectfully.

When you’re done with the operation you want to measure, you can call the finish() method of the transaction. Finishing the transaction will stop the measurement and send it to your Sentry project.

The final structure of your function should look like this:

// don't forget to import Sentry's SDK at the top
import Sentry

// ...

func syncPersonDatabase() {
  let transaction = SentrySDK.startTransaction(
    name: "Sync person database", // give it a name
    operation: "data.update" // and a name for the operation
  )

  // ...
  // perform the operation
  // ...

  transaction.finish() // stop the measurement and report it to Sentry
}

Monitoring the performance

So far you’ve set up the performance measuring mechanism of your syncPersonDatabase function. Now you run your app...

You run it again...

Maybe you run it one more time for good measure...

Okay, that should have kicked off a transaction. You visit your Sentry dashboard and open the Performance tab and see the new custom transaction appear at the bottom:

Clicking on the transaction and then into the “Suspect Span” found in the second table, you will see a detailed representation of the span operation:

Let's break this view down a bit.

The first thing that you’ll see is the Self Time Breakdown chart.

This chart visualises the p50, p75, p95 and p99 metrics, which are called “latency percentiles”. p50 means that 50% of the function executions are faster than the p50 value (let’s say 0.47ms). To learn more about the latency percentiles, check out the Latency section in the Metrics documentation.

In the top right corner you can see the Self Time Percentiles widgets.

If you don’t want to look at the chart, these values will give you an insight on the average “p” values.

Below the chart is the events table.

Here if you notice an event that took longer than you anticipated, you can click on it to get more details about it, like:

The device that the user was using when the transaction occurred
The device’s memory at the time of the transaction
How long the user had been using the app prior to the transaction
The version of the app
The breadcrumbs (bits of events and interactions that led up to that transaction)

This gives you enough information on the context and environment to be able to discover potential ways to refactor the function to improve its performance. And, you can get even more granular if your function has multiple steps of execution. You can measure each steps individually and still keep them under the umbrella of the main function transaction.

Enter: child spans

More granular measurement with child spans

Child spans are like mini transactions that are attached to the main transaction. And child spans can have their own child spans as well. This feature allows you to measure your function’s performance in a greater detail, by starting a child span for every step of the function.

Let’s say your function performs the following steps:

1. Gather changed person properties
2. Pass each of them through a validation mechanism
3. Perform the updates to the database
4. Save the current timestamp as the "lastUpdated"

You can measure each step individually using child spans like this:

// don't forget to import Sentry's SDK at the top
import Sentry

// ...

func syncPersonDatabase() {
  let transaction = SentrySDK.startTransaction(
    name: "Sync person database", // give it a name
    operation: "data.update" // and a name for the operation
  )

  // span the first child
  let gatherSpan = transaction.startChild(operation: "gather-changed")
  // perform the gather operation
  gatherSpan.finish()

  // span the second child
  let validationSpan = transaction.startChild(operation: "validate-changed")
  // perform the validation
  validationSpan.finish()

  // span the third child
  let updateSpan = transaction.startChild(operation: "update-database")
  // perform the update
  updateSpan.finish()

  // span the last child
  let timestampSpan = transaction.startChild(operation: "update-timestamp")
  // perform the timestamp update
  timestampSpan.finish()

  transaction.finish()
}

Remember: Only finished spans will be sent along with the transaction. So you need to make sure that you’re finishing each child span before finishing the main transaction.

Monitoring the performance of child spans

Alright, you have set up child spans and you're ready to run your app again with the latest changes...

You run it again...

Maybe you run it one more time for good measure...

Done! You head back to your Sentry dashboard and notice that the Suspect Spans table provides more information now. You can see the child spans, and how long they took to execute.

Clicking on the “View All Spans” button you can see and sort all of them.

But you realize that your function has conditional steps that don’t always execute. Or maybe you have dynamically generated child spans whose name contains a unique id. To see the actual order of the child spans, you have to pick a specific event from the Events Table above and a new page will open with more details around that specific event.

You can see from the Gantt chart the order of execution of the child spans.

Here you can see that:

The data.update encapsulates all child spans
The gather-changed started executing first and took 16.02ms
Then the validate-changed ran for 5.64ms
Then the update-database took its 121.02ms to run
And finally the update-timestamp flashed for 5.63ms.

You can identify which step contributes the most to the performance of your function with this. You can now turn our whole focus to improving the performance of your update-database function.

Using a transaction in multiple functions

Now that you have a hang of measuring straightforward functions, you're ready to tackle something a bit more complex. You realize that you want to measure performance on multiple nested functions. You do not need to pass the transaction as an argument. Instead, you can bind the transaction to the current scope:

let transaction = SentrySDK.startTransaction(
  name: "Sync person database", // give it a name
  operation: "data.update", // and a name for the operation
  bindToScope: true // bind the transaction to the curent scope
)

Now you can access this transaction without having to pass it as an argument while you're in the current scope. You could have a function gatherChangedProperties, that calls another function filterProperties. And to gain access to the transaction within the filterProperties, you can directly reference SentrySDK.span, and if no transaction exists yet, you can create it. Your structure should look something like this:

let transaction = SentrySDK.startTransaction(
  name: "Sync person database", // give it a name
  operation: "data.update", // and a name for the operation
  bindToScope: true // bind the transaction to the curent scope
)

let properties = gatherChangedProperties()

// ...

transaction.finish()

func gatherChangedProperties() {
  // ...
  let filteredProperties = filterProperties();
  // ...
}

func filterProperties() {
  // obtain the transaction
  var span = SentrySDK.span

  // if non existing, recreate it
  if span == nil {
    span = SentrySDK.startTransaction(...)
  }

  // use it like a normal transaction
  let filterSpan = span.startChild(operation: "filter-properties")

  //...
}

Recap

You can now create custom transactions to measure long running functions in your app with SentrySDK.startTransaction(...).
You can measure more granularly by starting child spans to our transaction for each logical step in our function with transaction.startChild(...) to zero in on the slowest part of the function and improve it.
If you’re measuring a more complex function with multiple branches, you can bind the transaction to the current scope by setting the bindToScope property to true.

Time to measure all the things! 🙌

Generating blurDataURL for remote images in Next.js

Lazar Nikolov — Sun, 19 Dec 2021 12:18:14 +0000

Originally posted at: nikolovlazar.com/blog/generating-blur-for-dynamic-images-nextjs

The Next.js Image Component is IMO the best tool that you can use to ensure the images
on your Next.js website are optimized, and your page loads quicker. One interesting feature that the next/image component
provides is the placeholder prop, whose values can be either blur or empty.

When the placeholder is set to blur, we need to provide the blurDataURL. If we're importing local images statically, Next.js
can access the resource and generate the blurDataURL for us. But, when we want to add the blur effect to remote images there
are a few things that we need to do:

Register the provider's domain in next.config.js
Generate the blurDataURL and pass it to the NextImage component

I'm using MDX for the content of my website (this one!), so in this article I'll explain the blurDataURL
generation integrated with MDX, but the functionality is generic and not tied with MDX in any way. So let's begin!

Registering provider domains

First things first, you need to register the provider's domain in order to render remote images with next/image. In my case,
I'm loading the og:image from GitHub, and the URL looks like this:

https://opengraph.githubassets.com/f4a95bd3aa5113a1f599f5a810edeb16b885f3364b0443dc3c34a02c3290a5d8/chakra-ui/chakra-ui-docs/pull/154

By looking at the URL, we know that we need to register the opengraph.githubassets.com domain, so let's jump in the next.config.js
and do that:

// next.config.js

module.exports = {
  images: {
    domains: ['opengraph.githubassets.com'],
  },
};

And that's it! Now that we've got out of the way, let's start generating the blurDataURL prop.

Generate blurDataURL

Since I'm using MDX and I'm rendering the pages statically, I've added a simple plugin that filters out all of
the images from the markdown, calculates their width, height, and blurDataURL and passes them as props:

// src/utils/plugins/image-metadata.ts

import imageSize from 'image-size';
import { ISizeCalculationResult } from 'image-size/dist/types/interface';
import path from 'path';
import { getPlaiceholder } from 'plaiceholder';
import { Node } from 'unist';
import { visit } from 'unist-util-visit';
import { promisify } from 'util';

// Convert the imageSize method from callback-based to a Promise-based
// promisify is a built-in nodejs utility function btw
const sizeOf = promisify(imageSize);

// The ImageNode type, because we're using TypeScript
type ImageNode = {
  type: 'element';
  tagName: 'img';
  properties: {
    src: string;
    height?: number;
    width?: number;
    blurDataURL?: string;
    placeholder?: 'blur' | 'empty';
  };
};

// Just to check if the node is an image node
function isImageNode(node: Node): node is ImageNode {
  const img = node as ImageNode;
  return (
    img.type === 'element' &&
    img.tagName === 'img' &&
    img.properties &&
    typeof img.properties.src === 'string'
  );
}

async function addProps(node: ImageNode): Promise<void> {
  let res: ISizeCalculationResult;
  let blur64: string;

  // Check if the image is external (remote)
  const isExternal = node.properties.src.startsWith('http');

  // If it's local, we can use the sizeOf method directly, and pass the path of the image
  if (!isExternal) {
    // Calculate image resolution (width, height)
    res = await sizeOf(path.join(process.cwd(), 'public', node.properties.src));
    // Calculate base64 for the blur
    blur64 = (await getPlaiceholder(node.properties.src)).base64;
  } else {
    // If the image is external (remote), we'd want to fetch it first
    const imageRes = await fetch(node.properties.src);
    // Convert the HTTP result into a buffer
    const arrayBuffer = await imageRes.arrayBuffer();
    const buffer = Buffer.from(arrayBuffer);

    // Calculate the resolution using a buffer instead of a file path
    res = await imageSize(buffer);
    // Calculate the base64 for the blur using the same buffer
    blur64 = (await getPlaiceholder(buffer)).base64;
  }

  // If an error happened calculating the resolution, throw an error
  if (!res) throw Error(`Invalid image with src "${node.properties.src}"`);

  // add the props in the properties object of the node
  // the properties object later gets transformed as props
  node.properties.width = res.width;
  node.properties.height = res.height;

  node.properties.blurDataURL = blur64;
  node.properties.placeholder = 'blur';
}

const imageMetadata = () => {
  return async function transformer(tree: Node): Promise<Node> {
    // Create an array to hold all of the images from the markdown file
    const images: ImageNode[] = [];

    visit(tree, 'element', (node) => {
      // Visit every node in the tree, check if it's an image and push it in the images array
      if (isImageNode(node)) {
        images.push(node);
      }
    });

    for (const image of images) {
      // Loop through all of the images and add their props
      await addProps(image);
    }

    return tree;
  };
};

export default imageMetadata;

That's all we need to do to calculate the width, height, and blurDataURL props. In order to use this
plugin, let's jump to the pages/blog/[slug].tsx page that renders the blog post itself:

export const getStaticProps: GetStaticProps<Props> = async (ctx) => {
  // get the post slug from the params
  const slug = ctx.params.slug as string;

  // get the post content. readBlogPost just reads the file contents using fs.readFile(postPath, 'utf8')
  const postContent = await readBlogPost(slug);

  // Use the gray-matter package to isolate the markdown matter (title, description, date) from the content
  const {
    content,
    data: { title, description, date },
  } = matter(postContent);

  return {
    props: {
      // use the serialize method from the 'next-mdx-remote/serialize' package to compile the MDX
      source: await serialize(content, {
        mdxOptions: {
          // pass the imageMetadata utility function we just created
          rehypePlugins: [imageMetadata],
        },
      }),
      title,
      description,
      date,
      slug,
    },
  };
};

And that's it! To see this in action, put a console.log in your MDX Image component and check the props.
Here's my MDX Image component:

const Image = (props) => {
  return (
    <NextImage {...props} layout='responsive' loading='lazy' quality={100} />
  );
};

The props object is actually the node.properties object in the image-metadata.ts file.

If you've followed along the article, you should already see the blur effect happening.

This solution can also be applied in different scenarios other than MDX. Just bear in mind that obtaining
the image data (the !isExternal if statement in image-metadata.ts) is a server-side functionality,
because it uses Node.JS's fs package. If for some reason you need to do this on the client-side you
need to change the way you get the image data.

If you want to see the whole system in place, make sure to check out the source of my website: nikolovlazar/nikolovlazar.com

Note: if you're applying the blur effect on user submitted images, make sure you know where those images
will be stored, and don't forget to register the domain in the next.config.js file.

A simple change improved Chakra UI's PageSpeed significantly

Lazar Nikolov — Sat, 18 Dec 2021 18:57:50 +0000

Originally posted at nikolovlazar.com/blog/improving-chakra-ui-page-speed

I've noticed that the PageSpeed scores for https://chakra-ui.com were not that great. I know that
we've built the page using the best practices, but for some reason the scores weren't what we expected. I took some time
to analyze the metrics and noticed that the TTI (Time to Interactive) and TBT (Total Blocking Time) were crazy high!

Scrolling down in the Diagnostics section I noticed the "Avoid enormous network payloads" issue, notifying me that the total
size of the network payload was 7,053 KiB, and that's way too much! Clicking on the issue revealed that 9 out of 10 requests
are from CodeSandbox, because of the CodeSandbox embed that was on the page.

Then I remembered that CodeSandbox released their Sandpack component toolkit that you
can use to create live code editing blocks. Since that's an npm package that you install, I figured it will definitely be
more performant because its code will be compiled, optimized and shipped along with the page. So I decided to swap out
the old embedded iframe with the new Sandpack component. And the results were surprizing:

All of the metrics have been improved significantly:

CLS: 0.029 -> 0 🚀
FCP: 0.6s -> 0.4s 🚀
LCP: 0.6s -> 0.5s 🚀
SI: 1.7s -> 0.6s 🚀🚀
TTI: 9.8s -> 1.6s 🚀🚀🚀
TBR: 4.9s -> 0.3s 🚀🚀🚀
Overall Score: 58 -> 86 🚀🚀🚀

Let's walk through the changes. First, I installed the Sandpack package:

yarn add @codesandbox/sandpack-react

Then I created a simple and generic component that displays the Snowpack component, but allows the data to be provided
from the outside:

// src/components/sandpack-embed/index.tsx

import { Box, BoxProps } from '@chakra-ui/react';
import { Sandpack, SandpackProps } from '@codesandbox/sandpack-react';
import '@codesandbox/sandpack-react/dist/index.css';

const SandpackEmbed = (props: BoxProps & SandpackProps) => {
  return (
    <Box
      as={Sandpack}
      {...props}
      options={{
        ...props.options,
        showLineNumbers: true,
      }}
      theme='dark'
      template='react-ts'
      customSetup={{
        dependencies: {
          react: '17.0.2',
          'react-dom': '17.0.2',
          'react-scripts': '4.0.0',
          'react-icons': '3.11.0',
          '@chakra-ui/react': '1.7.3',
          '@chakra-ui/icons': '^1.1.1',
          '@emotion/react': '^11.7.0',
          '@emotion/styled': '^11.6.0',
          'framer-motion': '^4.1.17',
        },
      }}
    />
  );
};

export default SandpackEmbed;

It's basically a Box component, rendered as a Snowpack component, but its props are the BoxProps merged with SandpackProps.
That way we can pass Chakra style props, and Sandpack configuration props and reuse this component everywhere.

Then I simply replaced the iframe on the homepage with the new SandpackEmbed component:

<SandpackEmbed
  options={{
    editorHeight: 600,
    editorWidthPercentage: 60,
  }}
  files={{
    '/src/App.tsx': App,
    '/src/index.tsx': Index,
  }}
  zIndex={0}
  tabIndex={-1}
/>

The App and Index variables that you see on line 7 and 8 are simple strings. It's the code content that we want to have
inside of each file specifically:

export const Index = `import * as React from "react";
import { render } from "react-dom";
import { ChakraProvider } from "@chakra-ui/react";
import App from "./App";
const rootElement = document.getElementById("root");
render(
  <ChakraProvider>
    <App />
  </ChakraProvider>,
  rootElement
);`;

And that was it! A simple change drastically improved the page speed, and also opened up possibilities to reuse the
SandpackEmbed component throughout the whole website. I plan on swapping the react-live
package with the SandpackEmbed as well. I'm not sure about performance boost, but a bonus feature will be the ability
to create a CodeSandbox sandbox directly from the website.

Here's the PR if you're interested to see all of the details about it:

I've published the first official Chakra UI course

Lazar Nikolov — Thu, 09 Sep 2021 13:23:51 +0000

Hey everyone 👋

I've published the first official Chakra UI course on egghead! It's free and it'll get you up to speed with Chakra UI in 40 minutes.

Check it out and let me know what you think.

Thanks!

DEV Community: Lazar Nikolov

Low effort image optimization tips

The problem

Ditch JPEG for AVIF + WebP

Generate images at build time

Generate images on demand

Use a third-party service

Properly size images

Use a <picture> element instead of just <img>

Choose lazy loading

The end result

Further reading

Fixing Fetch Waterfalls in React

Using “Suspense” to avoid a fetch waterfall

Fetch data on server to avoid a fetch waterfall

Hoisting the data fetching to avoid a fetch waterfall

Conclusion

What’s the difference between API Latency and API Response Time?

The difference between Latency vs Response Time

Measuring response time

Monitoring API response time in production

Backend Performance Monitoring | Arcade

Conclusion

CSS Style Queries

Syntax

Combining multiple styles

Conclusion

CSS Container Queries

Containment context

Container query

Container query units

Conclusion

Getting started with CSS Nesting

What is CSS Nesting?

Nesting examples

Multi-level nesting

Nesting without the & symbol

Nesting pseudo-classes

Nesting pseudo-elements

Nesting @media queries

The & symbol

Understanding the parser

Conclusion

Getting Started with Jetpack Compose

How to start using Jetpack Compose

How do you build UI in Jetpack Compose?

Composable functions

Modifiers

How do you interact with data in Jetpack Compose?

MutableState

LiveData

StateFlow

What are the best practices for Jetpack Compose?

Code organization

Avoid creating “god” files

Stay true to the MVVM

Don’t create a thousand flows

Keep a close eye on your errors and performance in production

Conclusion

Mobile: The Future is Declarative

A little history

Becoming declarative

Example UI

Conclusion

Measuring application performance in Swift using transactions

Requirements

Implementing custom transactions

Monitoring the performance

More granular measurement with child spans

Monitoring the performance of child spans

Using a transaction in multiple functions

Recap

Generating blurDataURL for remote images in Next.js

Registering provider domains

Generate blurDataURL

A simple change improved Chakra UI's PageSpeed significantly

I've published the first official Chakra UI course

Use a `<picture>` element instead of just `<img>`

Nesting without the `&` symbol

Nesting `@media` queries

The `&` symbol