DEV Community: Dušan Perković

What does StyleX solve?

Dušan Perković — Mon, 18 Dec 2023 00:30:40 +0000

Facebook/Meta recently released the StyleX library, and already there are many articles and youtube videos explaining how it's THE TAILWIND KILLER (ooh, spooky).

I'm going to go through some of the main points from this video by Web Dev Simplified to try and explain why I'm not convinced of the StyleX hype. If you're not familiar with the StyleX library, it's a nice way to get introduced to it. This channel has a lot of great videos, even though I don't agree with his take here.

So let's start with the first big StyleX feature:

Co-location

Co-location is the practice of closely grouping things that belong together. So why not keep styles in the same place where you define your component code?

I have nothing against this approach. In fact, I'm glad that we are embracing this principle more and more. But this implementation honestly seems like a step back from what Tailwind is doing. If we take a look at the example:

import { Button } from "./Button"
import * as stylex from "@stylexjs/stylex"

const styles = stylex.create({
  heading: {
    color: "blue",
  },
})

export default function App() {
  return (
    <>
      <h1 {...stylex.props(styles.heading)}>Heading</h1>
      <Button>Button</Button>
    </>
  )
}

Compared to how we would write it in Tailwind:

import { Button } from "./Button"

export default function App() {
  return (
    <>
      <h1 className="text-blue">Heading</h1>
      <Button>Button</Button>
    </>
  )
}

Seems like the Tailwind implementation is actually better with co-location. The classes that impact the element are written directly on the element, instead of somewhere above or below.

The difference in the example is small, but imagine defining styles for a more complex component. With StyleX, you would have a big chunk of CSS-like code at the beginning of your file (as is visible later in the video), in which case you would have to keep scrolling up-and-down to find and change the styling for a given element. With Tailwind this is never the case, because you only change the classes on the element you want to change itself.

At that point, it might actually be helpful to move the StyleX code to another file, so you can keep the styling code open side by side with the component code. And if you're doing that, you're basically just doing CSS Modules, so I'm not really sure how this is better?

Deterministic resolution

"The last style applied always wins."

Conflicting CSS selectors can be a pain, especially if you don't use a convention like BEM or something similar.
If you use Tailwind however, you never have these specificity selector issues, because the classes are atomic, and applied directly on the element in the HTML.

So unless you are just randomly creating selectors, without any convention or structure, and without scoping things with CSS Modules, I'm not really sure what this solves?
If you are, then I don't think StyleX is gonna help you much. You have an organizational problem, not a tooling one.

Bigger projects are easier to maintain with StyleX.

I don't really think this is the case. Actually I think on larger projects, StyleX will suffer from almost the same issues that CSS does.
One of the biggest issues with CSS on bigger projects, is knowing if a defined selector is still necessary, or if it can be removed from the stylesheet. Bigger projects tend to have a lot of selectors which get applied in multiple places, so knowing if a selector should or shouldn't be removed can be tricky.

Since "The last style applied always wins." (just like the selector with the most specificity wins in plain CSS), all the styles that are applied until the last one may or may not be partially needed. So on larger projects you will still have the issue described above, just with a different tool. It definitely helps a bit that these useless styles are stripped in production, but they still remain in the codebase and make maintenance harder.

Reusability

I really don't think styles should be shared between components, expect maybe in very specific cases. A components style is an integral and identifiable part of it. Trying to reuse it, or a part of it just creates extra dependencies which makes things weird, and long term project maintenance difficult.

Let me try to explain what I mean through this example: Let's say we have a simple button with a little bit of styling on our project:

import * as stylex from "@stylexjs/stylex"

export const styles = stylex.create({
  base: {
    backgroundColor: "blue",
    color: "white",
    borderRadius: ".25em",
  },
})

export default function Button(props) {
  return (
      <button
        onClick={props.onClick}
        {...stylex.props(styles.base)}
      >
        {props.children}
      </button>
  )
}

And let's say that at some point we need to define another button, which should be the same as the original button, but a little bit different.
So we might do something like this:

import * as stylex from "@stylexjs/stylex"
import {styles} from "./Button.jsx

const newStyles = stylex.create({
  base: {
    backgroundColor: "red",
  },
})

export default function DeleteButton(props) {
  return (
      <button
        onClick={() => {
          if (confirm("Are you sure?") {
            props.onClick()
          }
        }}
        {...stylex.props(styles.base, newStyles.base)}
      > 
         {props.children}
      </button>
  )
}

This works, but puts the DeleteButton component in a weird spot. Co-location is effectively broken, because the styling for DeleteButton depends on the styling from the Button component. A dependency is also introduced, which means that any future style changes to the Button will also impact the DeleteButton. So your boss and QA are gonna love you, for making their job twice as difficult.

We could also extract the styling to a separate file like a button-styles.js:

import {styles} from "./Button.jsx

export const styles = stylex.create({
  base: {
    backgroundColor: "blue",
    color: "white",
    borderRadius: ".25em",
  },
  delete: {
    backgroundColor: "red",
  },
})

But at this point we are just writing CSS with extra steps, so I don't really see the benefit?

A simpler approach would be to just keep the styles unique to each component, but at that point we have no need to share the styles, so reusability becomes a moot point. And since Tailwind is better with co-location as discussed above, it could look something like this:

export default function Button(props) {
  return (
      <button
        onClick={props.onClick}
        className="bg-blue text-white rounded"
      >
        {props.children}
      </button>
  )
}

export default function DeleteButton(props) {
  return (
      <button
        onClick={() => {
          if (confirm("Are you sure?") {
            props.onClick()
          }
        }}
        className="bg-red text-white rounded"
      > 
         {props.children}
      </button>
  )
}

This is my preferred approach, as it keeps things simple, and components contained and independent of each other. And your boss and QA not hating you is a nice bonus.

Conditionally applying styles

This feature is nice, but libraries like classnames, and clsx already solved this a long time ago.
If you are using Tailwind, you might be worried that your code won't look as nice if you have a bunch of classes on your element tags.

We are not in the business of making code look pretty, and satisfying your aesthetic wants for numbers of characters on screen per file.

We are in the business of building maintainable solutions that are as simple as possible, and easy to maintain.

Stop trying to "make code pretty". It doesn't have to be pretty, but it should always be expressive.

Overriding styles from parent components.

Do not do this. Do not pass random styles around to components.

Not even once.

Unless you are making a component library akin to headlessui you should never just pass random styles to components.

A better solution is to create an interface from the child component via props, where you can specify which version of the child component you want. If we use the button example from above, and the classnames library:

import classnames from "classnames"

export default function Button(props) {
  return (
      <button
        onClick={() => {
          if (confirm("Are you sure?") {
            props.onClick()
          }
        }}
        className={classnames(
          {
            "bg-blue": !props.variant
            "bg-red": props.variant === "delete"
          }
          "text-white rounded"
       )}
      > 
         {props.children}
      </button>
  )
}

This way the styling stays internal to the child component, consistent across the application, but still flexible based on the variant property.

Final Thoughts

As the title says, I am not sure what StyleX is supposed to solve, since most of the things that it solves have better solutions in other places.

If you're starting a new project, just use Tailwind, and you're already winning.

If you already have a codebase in CSS, I don't see the need to switch to StyleX, or how it would "evolve" your styling. If you have some of the issues described above, try adopting a methodology like BEM, and using CSS Modules for scope isolation. It's easier then rewriting everything in StyleX, and you'll have more maintainable code.

If you have an existing large codebase using CSS-in-JS:

You are suffering more than any of us.
StyleX might actually make sense for you, but I still wouldn't recommend it.

You would definitely see some perf improvements, and the syntax seems quite similar so transition should be easy. But StyleX is quite young, so you will probably experience some issues with the transition.

Even though I crapped on StyleX throught this article, I always think it's cool when people are trying something new. And I think it's great that people behind StyleX are trying to make something to make our professional lives easier.

I'm keeping an open mind about this topic, so feel free to try to change it in the comments!

You're not missing out

Dušan Perković — Wed, 13 Sep 2023 14:28:59 +0000

Recently Bun 1.0 came out to much fanfare. And rightly so! It is a very ambitious project that aims to be a drop-in replacement for your JavaScript package manager, transpiler, bundler, testing library, and even NodeJS itself. While this is all indeed very exciting, and I am really interested to see how Bun grows and evolves, this is not the first time I've noticed everyone rush to try out the new thing in web development. I'm here to tell you that you don't need to do that. In fact, it can be a big determent to your project.

The Temptation of FOMO

Whenever a new JS tool comes out, and I see all the bombastic articles being written about it, I start getting feeling the FOMO (Fear Of Missing Out). It seems like everyone else is jumping on this new cool bandwagon, and since I am not doing it right away, I might get left behind. But the truth is that this never happens, because all the early adopters usually end up being beta testers, breaking their apps/build systems by trying to fit the new shiny thing in their codebase.

When to Experiment with New Tools

I'm not saying that you should never try anything new. But there is a time and a place for testing new tools out. Like hobby projects, or smaller/"younger" projects that have less dependencies to manage. Anything where you can move fast and break things, or where the impact of things breaking is low, should be fine to play around with and give new things a shot. However, if you have an enterprise level app with a bunch of people working on it, please do not rush to adopt the newest JavaScript thing that reached version x.0.

Prioritizing Stability in Enterprise Projects

Any major version jumps (like from 2.x to 3.0), usually contain a lot of breaking changes. Migrations like this can be a pain to do, but are usually necessary for security/compatibility reasons. I recommend setting up and using something like dependabot, since it's very helpful in keeping things up to date.

In addition to that, in case of it being a new library (like finally reaching 1.0), it means that not many people are using it, and you probably won't find answers online to the issues you encounter specific to your project. You will have a bad time, and your co-workers will dislike you when things inevitably break.

You're not missing out

In the ever-evolving world of web development, it's easy to get swept up in the excitement of new tools and frameworks. However, it's essential to remember that the race to adopt the latest and greatest doesn't always lead to success. Whether you're working on a hobby project or a massive enterprise application, take your time, carefully evaluate the impact of new tools, and prioritize the stability of your projects over the allure of the 'next big thing.' After all, you're not missing out – you're ensuring that your work stands the test of time.

Creating the project in Google Console

Dušan Perković — Thu, 07 Sep 2023 11:15:52 +0000

In the first article of the series, we have set up our frontend project, created some basic components, and added some base styling.

If we want that Sign In With Google button to actually do something, we have to connect it to Google services. This means we need to tell Google some details about our project, like the project name, who's going to be using it and what information from the Google profile we want to use.

So we have to set up a project in Google Console, and this is what we'll be doing in this article!

First, we need to create and setup the project. To do that, we simply go to https://console.cloud.google.com/ click the Select Project dropdown at the top of the screen, and create a new project. For the Project Name we will pick Next Google Auth, and in the Organization field pick No Organization*.

After the project is created, we need to configure it, starting with the OAuth Consent Screen.

Setting up the OAuth Consent Screen

After your project is created, select it, and navigate to the APIs & Services -> OAuth Consent Screen.

We need to define certain OAuth consent parameters, like if the app will be for internal or external use, what the app name will be, etc.

We will select certain options for the purposes of this demo, but feel free to change your selection to however you see fit depending on your needs.

A note on Google Cloud project configuration: Initially, when the Google Cloud project is created, it is put in TESTING mode, and you can change the settings as much as you want until you decide to publish your project. However, please note that after you PUBLISH the project, you will need to submit your app for verification, before you can change the project settings again!

In the OAuth consent screen step we just need to provide some basic info about the app, and who is going to support it. So choose the following:

Our User Type will be External.
Our App name will be Next Google Auth.
Our User support email and Developer contact information email will be the same (you can use your own google email address here).

In the next step Scopes, we define what user info we want to grab from google services. There's a lot of info we can get, but we are only interested in the users email and some profile info for this specific app, so:

Select ADD OR REMOVE SCOPES
Select ../auth/userinfo.email and ../auth/userinfo.profile.
Hit UPDATE and continue to the next step.

Finally, go ahead and add your email as a Test Users for now.

That's it! We've finished with the consent screen configuration. The final screen is just an overview of the things we selected/entered, so make sure everything is correct.

After we're done with our consent screen configuration, we can continue and create our Credentials.

Setting up our OAuth Credentials:

We need to setup our OAuth Client ID and Client Secret, so we can connect our frontend app with our newly created Google Cloud Project.
To create these credentials, go to Credentials -> CREATE CREDENTIALS -> OAuth client ID

Under Application Type make sure you select Web Application.
Make sure to define an entry under Authorised redirect URIs as http://localhost:3000/api/auth/callback/google.
Click Create.

Why do we have to specify a redirect URI?

After Google has verified that the user signing into your app is in fact a Google user, it needs to know where it can safely send the information we requested in the Selected Scopes (in our case we only requested the user email and profile information).
This token can contain sensitive data, so we have to make sure that we are redirecting to a safe URI.

We now have our Client ID and Client Secret! With these 2 strings, we can finally connect our frontend app with our freshly created Google Cloud Project, and put those Sign in/Sign out buttons to good use!

Setup your NextJS app

Dušan Perković — Thu, 31 Aug 2023 14:08:57 +0000

If you're looking to setup easy authentication for your users in NextJS, you're in the right place!

In this guide, I will show you all the steps necessary to setup your NextJS app, add google authentication to it (the Sign In With Google button), and deploy the application to production (using Vercel).

This is the first part of the guide, which will focus on just setting up your NextJS environment.

Generating the boilerplate

To setup our app, we're gonna use the tried and true method from the official documentation. NextJS has a great CLI tool, which you don't even need to install separately.
If you already have node installed, simply run npx create-next-app@latest in your projects directory, and answer the following questions as you please. Since I'm a big fan of Tailwind and TypeScript, this is the setup I used:

Creating the pages

Let's personalize our app a bit. We can start by adding our sign in, and sign out buttons.

app/components/SignInButton.tsx

"use client"

import { useRouter } from "next/navigation"

export const SignInButton = () => {
  const { push } = useRouter();

  return (
  <button 
    onClick={() => push("/")}
    type="button" className="text-white w-full bg-[#4285F4] hover:bg-[#4285F4]/90 focus:ring-4 focus:outline-none focus:ring-[#4285F4]/50 font-medium rounded-lg text-sm px-5 py-2.5 text-center inline-flex items-center justify-center dark:focus:ring-[#4285F4]/55">
    <GoogleIcon />
    Sign in with Google
  </button>
  )
}

const GoogleIcon = () => (
  <svg
    xmlns="http://www.w3.org/2000/svg"
    aria-hidden="true"
    className="mr-2 -ml-1 w-4 h-4"
    data-icon="google"
    data-prefix="fab"
    viewBox="0 0 488 512"
  >
    <path
      fill="currentColor"
      d="M488 261.8C488 403.3 391.1 504 248 504 110.8 504 0 393.2 0 256S110.8 8 248 8c66.8 0 123 24.5 166.3 64.9l-67.5 64.9C258.5 52.6 94.3 116.6 94.3 256c0 86.5 69.1 156.6 153.7 156.6 98.2 0 135-70.4 140.8-106.9H248v-85.3h236.1c2.3 12.7 3.9 24.9 3.9 41.4z"
    />
  </svg>
)

app/components/SignOutButton.tsx

"use client"

import { useRouter } from "next/navigation"

export const SignOutButton = () => {
  const { push } = useRouter();
  return (
    <button className="text-black hover:text-sky-600"
      onClick={() => push("/signin")}
    >Sign out</button>
  )
}

For now, the only thing that should happen when clicking on these buttons is a redirect to the home page (/), or to the sign in page (/signin).

A note on "use client": This is a new syntax specific to using NextJS with the App router. It marks the component as a client component, which means it needs to load JavaScript on the client side.
Client components are different from server components, which render only on the server. If you would like a deeper explanation of server vs client components, you can check out the official documentation on server components and client components.

Next, let's create our Sign in page, so we can use our signin button!

app/signin/page.tsx

import { redirect } from "next/navigation";
import { Metadata } from "next";
import { SignInButton } from "../components/SignInButton";

export const metadata: Metadata = {
  title: 'Signin',
  description: 'Please sign in ',
}

export default async function SignInPage() {

  return (
    <>
      <div className="flex min-h-full flex-1 flex-col justify-center px-6 py-12 lg:px-8">
        <div className="sm:mx-auto sm:w-full sm:max-w-sm">
          <h2 className="mt-10 text-center text-2xl font-bold leading-9 tracking-tight text-gray-900">
            Sign in to your account
          </h2>
        </div>

        <div className="mt-10 sm:mx-auto sm:w-full sm:max-w-sm">
          <SignInButton />
        </div>
      </div>
    </>
  )
}

Regarding the global styling, we can remove almost everything from the global.css file, and leave only the following:

app/global.css

@tailwind base;
@tailwind components;
@tailwind utilities;

This will just apply the Tailwind CSS reset, and make it possible to use Tailwind classes inside our components.

For the home page itself, let's just make it as simple as possible and just leave some text indicating we're on the homepage, and also add our SignOutButton so we can navigate back to the sign in page:

app/page.tsx

import { SignOutButton } from './components/SignOutButton';

export default async function Home() {

  return (
    <>
      <header className="border-b border-gray-200 bg-white">
        <div className="mx-auto max-w-7xl px-4">
          <div className="flex gap-10 items-center w-full justify-between lg:justify-end my-2 px-4">
            <SignOutButton />
          </div>
        </div>
      </header>
      <main className="flex min-h-screen flex-col items-center justify-between p-24">
        <h1>Hello from the homepage!</h1>
      </main>
    </>
  )
}

Running our app now using npm run dev, and visiting http://localhost:3000 in the browser should show the following:

And clicking on Sign Out, should take you to the /signin page, which should look like this:

Here's a link to the acompanying github repo, which contains all the code from this blogpost.
I have also deployed this code snippet on Vercel, available here.

But what good are all these sign in and sign out buttons without some actual authentication logic behind them?

We will expand on that topic in the following chapter!

The best way to integrate in a new team

Dušan Perković — Mon, 21 Aug 2023 21:49:46 +0000

As someone who has either worked in distributed teams, or as a remote contractor, I know it can be difficult to integrate in a new team.

There are many challenges you have to face. Whether it's poor onboarding, lack of clear communication or direction, or a difference in time zones, it's hard to escape the feeling that you're not really part of the team. If not handled properly, this can lead to impostor syndrome, or a "us vs them mentality".

So what can you do to avoid this if you've just joined a team?

1. Avoid communicating through text only

This is especially important in the beginning.
Text is the worst form of communication, by far.

I know, I know, we all hate being stuck in meetings that seem to go nowhere, or have no value to us. But try to get as much face time with everyone as possible. Have a one-on-one introduction with everyone in the team, from the client(if possible) to the intern. Try and get to know the people you're working with, where they see the project going, what issues they are dealing with right now, or what problems they think might be coming in the future.

If you communicate only through text, there is a lack of context, tone, and body language. There are only words on the screen, and if the person you're talking to doesn't know you well enough, they can take things the wrong way.

I'm not saying that you should jump on a video call every time someone asks you to change a border color in CSS. But if requirements are unclear, or you need to explain something to another team member, you should use every tool at your disposal to make it easier to understand each other and push the project forward. Your team members will thank you for reaching out, and feel more connected to you.

2. Use screen recordings

I promise you, your clients love it when you keep them up to date on what you did. Creating a screen recording and walking them through a feature you just implemented is going to make everyone feel more included in the development process, give you quicker feedback, and make you more visible to the rest of the team.

As a bonus, you will also catch a lot more bugs before creating PR's, because you will basically be doing QA on yourself.

Your colleagues will also love it if they ask you to explain something, and instead of writing paragraphs of text, you just send them a screen recording, and all they have to do is press play.

This is especially useful if you are in separate timezones. I have actually gotten more higher quality feedback on screen recordings like this, then on live demos. Probably because people can watch and comment on it multiple times, at their own pace.

I use the scre.io chrome plugin, since it's the easiest to use, and convert the recording to .mp4 if necessary.

3. Take control of your tickets.

I know developers dislike managing tickets (almost as much as they dislike meetings that could've been emails). But if you can help your team organize the work better, they will be forever grateful to you, and you will be able to impact the project on a higher level.

If you can break features down into small tickets that are easy to implement, you can avoid merge queues, PR's being stuck in review hell for weeks because of unclear requirements, or implementing the same thing multiple times. Your project manager will like you because you'll be helping them out, and your QA team will love you even more if a clear Acceptance Criteria is provided with every ticket.
You are making everyone's life easier, and as a result everyone wins.

In conclusion

Remember, you are working with people. If you help make their lives easier, or if you at least try, they will appreciate it and help you out. Building trust may take some time, but a team that trusts and helps each other, is a great team to work in.

How to optimize your Storyblok app

Dušan Perković — Tue, 15 Aug 2023 15:56:42 +0000

If you are using @storyblokcom with NextJS, and following the official guides from Storyblok, you know that the usual way to start the project is:

Create a NextJS project using create-next-app
Install the necessary dependencies to integrate with Storyblok.
Create your Storyblok components.
Initialize the NextJS - Storyblok connection by adding the following code to your _app.jsx.

...

import { storyblokInit, apiPlugin } from "@storyblok/react";
import Feature from "../components/Feature";
import Grid from "../components/Grid";
import Page from "../components/Page";
import Teaser from "../components/Teaser";

const components = {
  feature: Feature,
  grid: Grid,
  teaser: Teaser,
  page: Page,
};

storyblokInit({
  accessToken: "your-preview-token",
  use: [apiPlugin],
  components,
});

...

The problem:

You are loading all of your components on each page load!

This is because the contents of _app.jsx get executed on every page. So all the JavaScript that is imported in the _app.jsx file, gets bundled and sent to the client on every page load.

Since the official guide recommends importing all of your components in the _app.jsx file, this means that all your component code get loaded on every page. Even if that page is completely static and doesn't use any StoryBlok components at all!

I ended up creating a Github issue, and implementing this feature via a PR, on the official @storyblok/react Github repo. I was a bit hesitent about contributing, but the good folks at the @storyblok/react repo were very kind and accepting of it, so a big thanks to them!

How to load only the stuff you need

Instead of loading all your components in the _app.jsx file, just initialize the connection, and remove any component imports you have, so it looks more like this:

...

import { storyblokInit, apiPlugin } from "@storyblok/react";

storyblokInit({
  accessToken: "your-preview-token",
  use: [apiPlugin],
});

...

Then, in your page components, use the new setComponents method, to set only the components you need on that page. So it would look something like this:

...

import { getStoryblokApi, StoryblokComponent, setComponents } from "@storyblok/react"
import Feature from "../components/Feature";
import Grid from "../components/Grid";
import Page from "../components/Page";
import Teaser from "../components/Teaser";

export default function Home(props) {
    const story = props.story
    setComponents({
      feature: Feature,
      grid: Grid,
      teaser: Teaser,
      page: Page,
    })

    return (
      <div className={styles.container}>
        <Head>
          <title>Create Next App</title>
          <link rel="icon" href="/favicon.ico" />
        </Head>

        <header>
          <h1>
            { story ? story.name : 'My Site' }
          </h1>
        </header>

         <StoryblokComponent blok={story.content} />
      </div>
    )
  }

...

That's it!

Now, when NextJS builds your page, it will only include the components imported directly on that page and reduce your JS bundle size per page, improving your SEO and speeding up your page load times.

Expressive code > Clean code

Dušan Perković — Wed, 09 Aug 2023 13:02:30 +0000

When people say "clean code", they usually mean "code that's easy to read." I know that the full definition is closer to "code that's easy to read, maintain, understand and change", but people usually get stuck at that first part.

As a result, "easy to read" usually ends up meaning "small files with only a few lines of code", since developers associate big files with a lot of complexity (and rightfully so). Getting away from this complexity is not as easy as it seems, and is not always the right thing to do.

Reducing complexity vs hiding complexity

Reducing complexity is a good thing. It means you are actually scaling down the complexity of your app. This can include removing some tech debt, or relying on a third-party library to solve your problem, instead of having a bunch of custom code you have to maintain yourself. Reducing complexity basically means you and your co-workers have less of your own code to worry about.

Hiding complexity is what usually happens. Big files do not look aesthetically pleasing to us, so we come up with excuses and abstractions based on personal feelings. We start moving things away from each other, that logically belong together, and as a result make the code less expressive, harder to understand and more difficult to maintain.

Do not be afraid of big files. If the feature you are building is a complex one, the code should reflect that.

Abstraction always increases complexity

Even though it might make the codebase "look" smaller, it is actually more complex. Think about what you are doing when you abstract things: you are moving a piece of code away from where it is needed. So now, to understand the full picture of what's going on inside your component, you need to jump back-and-forth between the abstracted piece of code, and the rest of your component, to understand how they work together.

To be clear: I am not saying that abstraction is always bad, and that you should inline everything. I am saying that you should be very careful with it, when you do it, and for what reason.

Expressive code is easier to maintain

Here's an example using Tailwind, taken from this blog post:

<figure class="md:flex bg-gray-100 rounded-xl p-8 md:p-0">
  <img class="w-32 h-32 md:w-48 md:h-auto md:rounded-none rounded-full mx-auto" src="/sarah-dayan.jpg" alt="" width="384" height="512">
  <div class="pt-6 md:p-8 text-center md:text-left space-y-4">
    <blockquote>
      <p class="text-lg font-semibold">
        “Tailwind CSS is the only framework that I've seen scale
        on large teams. It’s easy to customize, adapts to any design,
        and the build size is tiny.”
      </p>
    </blockquote>
    <figcaption class="font-medium">
      <div class="text-indigo-600">
        Sarah Dayan
      </div>
      <div class="text-gray-500">
        Staff Engineer, Algolia
      </div>
    </figcaption>
  </div>
</figure>

You might say:

Look at all those classes! That's too much, man.

But you only need to understand how tailwind works, to understand what's happening with this component.

If we want to change how this component looks, we just need to add/remove the corresponding class, and everything is done. Even though there's a lot of it, the code is easy to understand, maintain and extend, even for someone new to the codebase.

We can also try to abstract these classes to individual CSS selectors, and make the HTML "look pretty", and move all the classes to a separate scss file that looks like this:

figure {
    @extend .bg-gray-100;
    @extend .rounded-xl;
    @extend .p-8;
    @extend .md\:flex;
    @extend .md\:p-0;
    img {
        @extend .w-32;
        @extend .h-32;
        @extend .rounded-full;
        @extend .mx-auto;
        @extend .md\:w-48;
        @extend .md\:h-auto;
        @extend .md\:rounded-none;
    }
    & > div {
        @extend .pt-6;
        @extend .text-center;
        @extend .space-y-4;
        @extend .md\:p-8;
        @extend .md\:text-left;
        blockquote p {
            @extend .text-lg;
            @extend .font-semibold;
        }
        figcaption {
            @extend .font-medium;
        div.name {
                @extend .text-indigo-600;
            }
        div.work-role {
                @extend .text-gray-500;
            }
        }
    }
}

And change the HTML to this:

<figure>
  <img src="img/175062.png" alt="" width="384" height="512">
  <div>
    <blockquote>
      <p>
        “Tailwind CSS is the only framework that I've seen scale
        on large teams. It’s easy to customize, adapts to any design,
        and the build size is tiny.”
      </p>
    </blockquote>
    <figcaption>
      <div class="name">
        Sarah Dayan
      </div>
      <div class="work-role">
        Staff Engineer, Algolia
      </div>
    </figcaption>
  </div>
</figure>

But this makes it harder to understand the component:

The styling of each tag has been moved away from it, so you have to look through the scss selector to understand what affects what.
Extending this code is more difficult, because it has to be done in multiple places. And you have to be careful of styles from other selectors impacting each other.
Maintaining the code is more difficult as well, because you need to make sure you're not deleting/changing the wrong thing in each of the files.

Maintainable > Aesthetic

At the end of the day, we are building products, not competing for the worlds most visually pleasing component. Coding is not the end goal - it's a means to an end. The code that you write has to be maintained and extended by you and your colleagues. Be expressive with what you write, and don't make things more complicated then they have to be.

Further reading:
The Grug Brained Developer