Hire HTML and CSS People
robinrendle.com
robinrendle.com
I've noticed lately a huge "React-ification" in the past few years where the UI on apps are both getting overly designed, but also more confusing and worse. Bigger buttons, bigger text, overuse of whitespace, bad pagination and breadcrumbs, etc.
There are a lot of best practices that were "solved" a decade ago that now seem to be getting lost. And the explanation that I have is that React and Figma have made it so easy to spin up a web app without any prior experience or reliance on prior works. "Enough rope to hang themselves" as the saying goes.
I worked with an engineering team that was struggling with their UI. The buttons were all the wrong sizes, colors weren't consistent, placement wasn't consistent, etc. I asked them if they were using a CSS framework at all and the response was "we are using React, we don't need one".
This hurt my brain.
I recently saw a video where a guy was claiming that people who had gone through a web development bootcamp (using React and the whole nine), where unable to make a basic hello world HTML file.
When people don’t know the basics, it’s no wonder everything is over complicated. They were never taught how it could be simple.
Why? It's straight up correct.
Sure, you could still use a css framework, but you really don't need to once you're using any frontend library.
Each component comes with it's own styles, that makes the css framework redundant, as a component library gives you a better development experience with the same effect.
Add a few global vars for theme colorings, default spacing etc and it becomes pretty straightforward to maintain a coherent UI even across repositories/teams (or distribute a tailwind config,works even better imo)
CSS as simply a DSL for styling components and hooks into the layout engine like how other GUI frameworks work is fine, but you don't need a framework for that.
We all generally agree that inheritance is hard to keep clean but in CSS it's venerated for some reason.
Perhaps we expected that the lessons we collectively learned about good design would be self-evident to the next generation or that there would be a knowledge transfer, but that doesn't seem to be the case.
The web (and most software really) seems to go through such extreme cycles of destruction and rebirth for the sake of marketing—and resume building, if we are being honest—that it's sometimes hard to find a throughline from the designs of yesterday to today.
I think about it all the time when there is an OS update (mac) that moves the state of design off into a direction that is in conflict with the design ethos of the past. I realize then that the designers and engineers likely never even used a classic OS let alone read the work of Jef Raskin or the Macintosh HIG.
It's really weird that the industry casually sloughs off lessons of the past. I don't think we should be restricted to only designing as we did in the past, but I do think that it's beneficial to understand where we came from.
Can see why though, css has become very large and complex, and it's only getting worse.
The upside is that my simple fixes sometimes seem like a superpower to others.
Respectfully disagree. I think CSS is simpler than ever, and it’s only getting more streamlined and powerful. E.g. what used to be a complex blob of floats is now a simple grid layout.
There's a lot about it I like though. It seems like it's starting, or perhaps already has, made things like SASS obsolete.
I am working through now creating a Hugo theme for my blog using just CSS (no Sass, Tailwind, etc), trying to avoid needing to use Hugo extended.
Every browser comes with a built-in inspector and console tool. HTML + CSS is the lowest bar to entry of any skill.
I've been writing CSS since 1997, and I remember having to use invalid characters to fork CSS in the days of IE 6, and all the old school hacks involving floats, full-height content, etc. CSS in that era was hard, but it was hard in the sense of "there's stuff we just can't do in the browser, so let's design around that". Nowadays, it's hard in a different way, which is "oh, I guess there's an entire new hoard of CSS capabilities I've literally never heard of before, and I need to spend some time wrapping my brain around it, so I can add it to the massive and ever-growing pile of CSS things I need to know".
I just twitched a bit reading that
If you needed to work around them, you could either sniff user agents, or abuse parsing inconsistencies to hide rules from each.
Take "position: sticky" for example; a fairly simple feature, and it simplifies stuff because previously folks were doing that with JS.
But also: there are tons of cases where it doesn't work, or where it works in unexpected ways. A few years ago I compiled a issues with position:sticky, and the number of caveats and bugs in both Firefox and Chrome was absolutely bewildering (I'm not sure if I still have the list somewhere).
This is the sort of thing that makes CSS difficult and complex. Originally HTML/CSS was just a simple text rendering system. So much stuff has been slowly bolted on, not always in the best way.
Other than that I do agree with you. "Just align stuff with flexbox" is kind-of my go-to way of doing CSS these days (I never really got around to looking at grid), and it's a massive time-saver over using hacky float stuff. And having one box model for all browsers also saves a lot of headaches. Hell, I read we're finally getting vertical alignment!
But also: there is a lot of complexity that can really bite you in the arse and make life difficult.
And what used to be relatively simple static layouts designed for a 4:3 screen are now layouts that must accommodate a screen of any arbitrary aspect ratio and physical size. This means that most of your components will now have at least 2 layout states, one for desktop and one for mobile, usually horizontal and vertical respectively, accomplished by switching random layout related properties on and off. Arguably anything related to CSS layout comes with a ton of quirks and flex/grid are no exception. It's those quirks that put most people off CSS, because they're sometimes far from intuitive, hard to debug, and are just things you have to know.
You should, yeah – it’s not inherent to CSS, though. For example on Android, your app can be ran on phone or tablet. I’d argue that the tools CSS provides for this are pretty easy to use.
> accomplished by switching random layout related properties on and off
You don’t have to, but it’s easier to understand usually.
For example, you can make a sidebar layout without @media (or @container) queries but you have to understand flexbox pretty well: https://every-layout.dev/layouts/sidebar/
(Personally, I’d just use an @container query here.)
In a sense it's easier to use if you follow the happy path, and have a good resource of what's on that happy path.
It's harder to use if working with legacy software, or don't have a good guide to stay on the happy path.
There are also more concepts overall to learn from box model and stacking context to flow layout, flex, grid, compositing, and isolation than there were 15 years ago. Some of these can replace previous concepts like float and table based layouts, but overall I'd say the barrier to expertise is higher.
Not saying TW doesn't have some merits but probably the biggest reason for its adoption is people avoiding to learn CSS.
Reminds me of Mongo over a decade ago. There was a huge influx of devs getting into backend with Node who didn't want to learn SQL. So they went with Mongo because it was easier to get started. And for a couple of years now there's been a huge shift back into SQL with Postgres and SQLite.
I'm pretty sure we'll see the same with CSS in a couple of years. Heck, it might be already happening.
And native CSS is becoming so good that it will be impossible to ignore. With nesting and variables it made already SCSS unnecessary for most projects.
You can't use tailwind without either understanding CSS or learning it as you use it. I have to wonder if people who claim otherwise haven't used tailwind.
I've seen first hand people just brute forcing by copying and pasting random stuff they see online.
And let's not forget about TW UI which is basically a way to copy and paste stuff without understanding a thing.
Documentation is plentiful when a person needs to use an unfamiliar feature, so it's not like it is even necessary to keep everything you use at the top of your mind. And just like anything else, if you use is often, you'll naturally learn it.
Plus, things like flex and grid have made having to remember a ton of old hacks unnecessary, so it has actually gotten markedly easier to use.
Can’t tell you how many times I’ve had to tell experienced developers they should use anchors to link to other pages and not an onClick. Those same people are much better in architecting then I will ever be, yet technically we have the same job description.
That's beyond bizarre.
I started around 2000, when people were still using tables for layout and CSS was pretty new. If you wanted interactivity you relied on the built-in tools on the web because there was no other choice (apart from something more extreme like Java applets or Flash).
Today’s web developer starts with something like React, learns JSX instead of HTML and doesn’t need the form tag or checkboxes/radiobuttions/select because they have useState, onClick and className to highlight whatever they think is active. I’ve been working as a React consultant for +6 years now, and every PR I see has the same issues.
I wish I was lying about the onClick on anchor tags, and for primary navigation it’s usually done right. But once they see a block link that contains multiple components (a “card”) the mind always seems to jump to onClicks that call navigate.
A more advanced error is when something is an anchor, they correctly implement the a tag with an onClick and preventDedault, but they forget to check if the user is holding down shift, hyper or control or if they pressed any other than the primary mouse button to try and open the link in a different tab/window.
Semantics in general is a lost art as well. A Text component that only returns p or spans is used for titles, they don’t consider hierarchy at all.
To be fair, there is so much logic in the client now that I understand that people with different ambitions have taken an interest in it. The only problem is that companies just blindly hire for front end developers without considering the different expertises.
I think this is the root cause for a lot of the complaints HN has about JS. I want to build good UI and UX, but there’s so much other work and configuration that I’m expected to work on, in a limited timeframe to not ruin my velocity that I just never get to it.
Nowadays people cares only about closed stories. Performance? Usability? Usual response is: Not my job, don't care!
Any competent frontend dev can copy a good Figma, but not every HTML/CSS/Tailwind/JS dev can make a pretty, usable, accessible website.
If you think about your frontend primarily in terms of how "vanilla" to go... then you're writing a website by engineers, for engineers. It might have pretty source, but that doesn't in any way guarantee good usability or design. Regular users never see your source and don't care about it, but they will definitely see your UX work (or lack thereof).
I think that's part of the problem. If UX people don't know code and code people don't know UX, neither has the ability to validate each other's work.
Is was made by HTML+CSS people. That's why.
If you want your UX to improve, look for a skilled UX designer. Then agree and sign off on some designs, and let your HTML+CSS ppl hammer it out.
Usually HTML+CSS people are NOT the people that fix your UX (sure there are exceptions).
If you hire developers who know HTML and CSS please rotate in some more interesting work for them.
Also be careful not to elevate the design team above people doing the HTML / CSS. Too often the design people go back and forth with a higher up until an "approved final design" that makes no sense gets thrown in the laps of the devs.
So basically, I think you agree with the previous poster?
Today, by "design" people often mean "graphical design", which tends to attract more art-type people. But what is really needed is "UI design", which is a much broader discipline which involves art, technical stuff, and psychology. You need to think about "what looks good?", but also "what makes a good UI for our product", and "what can we reasonably implement without too much complexity?"
Certainly in my experience this confusion between "graphical design" and "UI design" seems to be a huge chunk of the problem.
Isn't HTML and CSS a base line, every programmer knows this?
"This UX is awful? "
But that doesn't make them good UX designers.
Yes, it isn't a baseline. I'm talking about what is, not what should be. In some (large) circles using HTML or CSS is regarded akin to writing machine instructions rather than python. It should be avoided because no one understands it and you'll create a maintenance problem.
So one could argue it's really hard to get really good at HTML and CSS and not care about UX at all.
But yes, a fool with a tool is still a fool - if that's the point you're trying to make.
Just that a lot of programmers aren't necessarily known for their design aesthetic.
So you could 'not be a fool', and be very good at HTML/CSS, and yet not really understand or care about color, flow, layout.
But, to your point, surely they will absorb something in the process. But it is far from a given.
Isn't this the entire argument between Apple-Microsoft, Jobs-Gates?
Gates isn't a fool, neither are MS programmers, but they aren't known for good 'ux designs'
There are a lot more technology experts than good Design experts.