I built this apple iphone 17 pro design mockup using html and css. No vibe coding, fancy ai code editors. Just like how we used to build something before AI. Handcrafted pixel by pixel until it looked perfect. How's this ?

A lot of devs default to px, but that breaks accessibility and responsiveness. Quick breakdown:

px: fixed, ignores user zoom preferences.

em: relative to parent element's font-size. Great for padding/margins inside components.

rem: relative to root (html) font-size. Perfect for consistent typography across the app.

Rule of thumb :

Use rem for type and spacing across the layout.

Use em for component-level scaling (buttons, inputs).

Use px only when you truly need fixed precision (e.g., border-width).

Was working on a project recently where everything looked perfect on my end, Chrome, Firefox, mobile… no issues.

But then the client told me a section was just not showing up for them in Firefox. Took me way too long to figure it out.

Turns out, I had used a class name like .ad_div, and ad blockers were silently nuking the entire element.

So yeah, even if you're not actually building ads, avoid naming anything ad, ads, ad-banner, etc., unless you want to spend an hour pulling your hair out.

Curious, has anyone else run into little traps like this that you only learn the hard way?

u/medotgg posted this demo an hour ago but without any code. Here is my take on doing it with flexbox.

Tailwind is absolutely awful.

I used bootstrap back in the day and I did eventually come around to realising how awful that was too.

Littering your HTML with crap like this:

<div class="mx-auto flex max-w-sm items-center gap-x-4 rounded-xl bg-white p-6 shadow-lg outline outline-black/5 dark:bg-slate-800 dark:shadow-none dark:-outline-offset-1 dark:outline-white/10">

It's MASSIVELY inefficient - it's just lazy-ass utility first crud.

It may be super easy for people who cannot be bothered to learn CSS - so the lazy-ass bit - but for anyone who KNOWS css, it's fucking awful.

You have to learn an abstract construct cooked up by people who thought they knew what they were doing - who used bootstrap as a reference point.

Once upon a time, CSS developers who KNEW CSS figured that the bootstrap route was the bees-knees, the pinnacle of amazingness.

Then that house of cards fell on its ass - ridiculously hard to maintain, stupidly repetitive - throws the entire DRY methodology out the window. Horribly verbose. Actually incredibly restrictive.

This is from someone who drank the coolaid - heck, who was around BEFORE bootstrap, when this kind of flawed concept reared it's ugly head.

What you want is scoped css that is uglified, minified and tree shaken at build time - and what you want is a design system.

Something like this, in uncompiled code:

<Component atoms="{{ display: "flex", gap: "<variable>", backgroundColor: "<variable>"}} className={styles.WeCanHaveCustomCssToo}>...</Component>

When compiled down and treeshaken and uglified, it may end up being:

<div class="_16jmeqb13g _16jmeqb1bo _16klxqr15p"> ... </div>

It's scoped, on each build it's cache busted, it's hugely efficient and it's a pleasure to work with.

Most importantly, there's patten recognition in the compile process, where anything with the same atoms ends up with the same compiled classname, ditto for custom classes that could fall outside of a design system.

I'm not going to claim this concept is simple, it isn't, but it's for developers who understand CSS, who understand why CSS is important and who realise just how bloody awful tailwind is.

tailwind is ass.

Our team has defaulted to using Tailwind CSS for almost every web project over the last few years. It was great for moving fast early on, but on our latest project, the utility class bloat was getting completely out of hand. The HTML files looked unreadable, and managing long strings of responsive layout classes across reusable components was becoming a maintenance headache.

I decided to spin up a branch and rewrite a major dashboard interface using entirely vanilla native CSS. I hadn't built a pure CSS layout in a while, and I was genuinely shocked at how powerful native CSS has become over the last couple of years.

Features that used to require massive utility frameworks or preprocessors are now fully built-in. I heavily utilized native CSS nesting, CSS variables for theme management, and the newer container queries to handle complex responsive components based on their parent size rather than the entire viewport.

The results were surprisingly great. Removing the Tailwind processing step simplified our build pipeline, our final bundle size dropped, and the code felt vastly cleaner. Writing native styles inside modern semantic stylesheets made debugging layout bugs in the browser developer tools a hundred times easier because I wasn't digging through a wall of utility classes.

Tailwind is still an incredible tool for prototyping, but I realized I was using it out of habit rather than necessity. Modern native CSS has quietly caught up to the point where you can build incredibly complex, maintainable layout systems without adding a utility abstraction layer on top of it. If you haven't looked at native CSS features lately, it might be worth trying on a small feature branch.