4 min read

A Bit of SaaS Weekly: The Best Website

A Bit of SaaS Weekly: The Best Website
Midjourney

This is a weekly newsletter on the Software as a Service world. Learning, building, and shipping. Written by Ethan Mick.

The biggest mistake engineers make is optimizing a component that shouldn't exist.

– Elon Musk

The Best Bits


Midjourney

What makes a great website?

A reader sent me this link for the Best ***** Website (⚠️ warning: lots of profanity⚠️). The site makes the case that it, in its simple form, is the best website.

The satire is amusing, and it makes a good point. Websites are much more complicated now than they were in the past.

But they also do a lot more now than they did in the past. What we can do on the modern web wasn't possible on native computers a decade ago.

Things like WebGL.

Is it necessary? No.

Does having it unlock possibilities that didn't exist before? Yes.

That being said, your product should provide value to the user in the fastest, simplest, way possible. That's good for you and the user.

The environment we're building in has gotten more complicated. There are mobile devices with limited bandwidth and web apps that show massive amounts of data to a user.

The exact look and feel of a site is not super important; it's the content on it. The value the site provides. I feel this is the lesson every CS professor takes to heart for their university website. It's all plain text.

However, usability changes over time with user expectations. As those expectations change, you'll need to adapt to the times. If you're building a SaaS product, your users will expect it to behave in a certain way. Why? Because all the others work that way.

What's said here is very true:

What I'm saying is that all the problems we have with websites are ones we create ourselves.

A great example of this is the <img /> tag. The tag wasn't even in the first spec of HTML. It came a little later. Images became more important over time, and then they became big. Bloated. So what do we do? We don't remove images. No, no, no, we add srcset and fetchPriority and <picture> elements. Now we've just made things more complicated.

The same could be set about things like React Server Components. They're solving a problem that we have now because we made that problem with client-side apps.

Instead of untangling ourselves, we dig deeper with ever more complex shovels.

The web is a large and complicated space. And the great joy is you can make simple sites still. But if your site requires a lot of interaction to solve the problem... you're going to be happy with those powerful techniques.

So use the tool you need to solve the problem.

And make sure the problem isn't one you've created for yourself. Don't optimize something that should be deleted instead.


Tech Tip

When using Tailwind to style your own components, you often want to leave room for the caller to apply their own styles. These styles may conflict with or override the default styles. Because of how CSS cascading works, the class names that come later in the definition don't override earlier ones.

To resolve this, you should use a library like Tailwind Merge:

GitHub - dcastil/tailwind-merge: Merge Tailwind CSS classes without style conflicts
Merge Tailwind CSS classes without style conflicts - GitHub - dcastil/tailwind-merge: Merge Tailwind CSS classes without style conflicts
twMerge('p-5 p-2 p-4') // → 'p-4'

You can check out the features page to see how it handles each case. But the short version is: Use this if you want to allow the caller to override your Tailwind classes!


Cloud Chronicles

  • 🎉 YouTube Subscribers: 1,119 (+78 in the last 7 days)
  • Newsletter Members: 209 (+27 in the last 7 days)

I can tell my YouTube subscribers are slowing down a little, and I can't blame the system. I haven't posted a video in a bit, and it's killing me. Partly, I've been busy finishing up some freelance work, but also, partly, I've been having trouble deciding what to focus on next.

I think it's time I set aside some time during the week to build out some actual SaaS, which will then allow me to prioritize the code I need to productize. Those chunks of code will become my content each week. I can't really sell teaching SaaS without building it. And knowing my first few will probably be a wash... well, better get started sooner rather than later.


Last Byte