Hire HTML and CSS People(robinrendle.com)
robinrendle.com
Hire HTML and CSS People
https://robinrendle.com/notes/hire-html-people/
53 comments
As an additional example: when I was first cutting my teeth on the web as an amateur in high school, I remember reading about the ills of "mystery meat" navigation and I can recall the hard fought battle to excise it from UIs. Now 20+ years later, it's back in force.
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.
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.
> 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.
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.
> This hurt my brain.
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)
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)
That’s assuming they are using a component library that has a common system for its styles. If their end result was an inconsistent UI, it doesn’t sound like they were. They could have been making their own components, or mixing component libraries, with inconsistent styles, based on whatever the first search result was for their need.
It's kinda right. React says manage complexity through encapsulation, CSS as intended to be used says impale straight through the layers via global namespace and a brittle rats nest of interdependency via the side-channel of selectors.
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.
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.
I know CSS quite well, as I've been working with it over 15 years. I've been surprised that new programmers hardly know it at all, and heavily lean on component libraries or css frameworks.
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.
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.
> css has become very large and complex
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.
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.
It's getting more powerful than ever, and it's easier to do things that used to be hard (vertically centering, etc.), but it's also got a lot more capabilities that have a learning curve (custom properties, color functions, container queries, etc.).
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'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 remember having to use invalid characters to fork CSS in the days of IE 6
I just twitched a bit reading that
I just twitched a bit reading that
There were differences between IE on Windows, IE for Mac (which had an entirely different engine), Netscape, Gecko, and Safari.
If you needed to work around them, you could either sniff user agents, or abuse parsing inconsistencies to hide rules from each.
If you needed to work around them, you could either sniff user agents, or abuse parsing inconsistencies to hide rules from each.
I used the parser inconsistencies myself. I created the first web app template that worked in IE 3/4 and Netscape 3/4 for a Fortune 500 back in the day.
The difficult part of CSS is that there is quite a lot of it, and that quite a lot of features have weird interactions, and browsers have real bugs surrounding all of that.
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.
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.
> what used to be a complex blob of floats is now a simple grid layout.
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.
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.
> 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.
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.)
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.)
Hear hear. The tools are also so much easier.
Every browser comes with a built-in inspector and console tool. HTML + CSS is the lowest bar to entry of any skill.
Every browser comes with a built-in inspector and console tool. HTML + CSS is the lowest bar to entry of any skill.
As a markup language I think it's getting more complex but there's a lot more functionality that makes it a lot easier to do things with it. Knowing when to use what functionality can be overwhelming and seem complex though.
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.
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.
Yup. Variables, imports, i think nested declarations are also available now, less browser specific prefixes, this semicolon ":" selectors, etc. CSS have only become easier and more powerful.
Easier to use well is not the same as easier to learn well.
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.
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.
I don't understand what people mean when they say things like CSS has gotten more complex. It's not like anyone is realistically expected to commit the entire spec to memory.
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.
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.
> I've been surprised that new programmers hardly know it at all
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.
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.
Tailwind doesn't prevent you from "learning css". It may prevent you from learning some legacy things which are best avoided these days, like float though.
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.
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 think you're overestimating how many (most?) TW users operate.
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.
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.
I wish! I love working with HTML and CSS, but every front end job is covered by the blanket term “front end” that considers you as much a JavaScript ‘architect’ as they do a UI developer. Not realising that this does not make the slightest sense.
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.
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.
> use anchors to link to other pages and not an onClick
That's beyond bizarre.
That's beyond bizarre.
Not if you consider that a lot of front end developers today started learning web development through JavaScript.
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.
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.
I don't agree. Hire people who cares about results, actual product.
Nowadays people cares only about closed stories. Performance? Usability? Usual response is: Not my job, don't care!
Nowadays people cares only about closed stories. Performance? Usability? Usual response is: Not my job, don't care!
I agree, building a good company culture will dictate a lot with people's feelings about doing their job and also hiring people that share the same feelings.
This has nothing to do with HTML or CSS vs any other language of the web. It should be "Prioritize frontend usability and design." For that you need good UX/UI people, who may or may not know HTML or CSS. It doesn't matter.
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).
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).
> Any competent frontend dev can copy a good Figma
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.
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.
That's never been a problem in my experience...? As a frontend dev, I routinely work with designers who can't code. They send me a Figma, maybe talk me through the highlights, and I implement an initial prototype that gets maybe 80-90% there. A little back and forth later and we have something that's like 99% there, with minor bugs we fix after release. They didn't need to know any HTML or CSS. Figma puts pretty good guardrails around their design possibilities already.
You can't hire what you can't find (at your budget), so if you agree with the principle the imperative becomes 'teach html & css', and try to explain to the students why the guy next to him on react is already three projects ahead and has two 'native' apps to boot.
The advent of technology has given rise to social media platforms and applications which have facilitated easy interaction and communication between individuals. However, such platforms remain vulnerable to misuse by individuals who are habitually unfaithful. In the case where you may need to monitor your boyfriend's phone, it may be advisable to seek the services of a proficient hacker, such as tomcyberghost @ gm a il com, who can provide a plethora of comprehensive details. Based on my experience, this hacker has demonstrated a track record of trustworthiness, reliability and dependability - even in situations where the individual under scrutiny is untrustworthy.
I have a different strategy: hire managers that are technically inclined.
I love the improvements to CSS over the past few years. Directly serving nested CSS rules with no build step feels awesome.
> This UX is awful? That UI looks old?
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).
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).
i’m liking htmx.org since that puts the cognitive focus back on HTML and CSS
I think the issue is that HTML and CSS are awful braindead work that are a career killer.
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.
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.
In general I think the "design team" should be the "HTML and CSS" people.
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.
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.
Writing consistent, concise and elegant HTML and CSS takes practice. Mastery of a language and discovery of its patterns requires thought.
I think the point that was being made is "if you hire HTML/CSS people, then don't make them monkeys that are only allowed to blindly follow instructions, but involve them in the process and treat them as professionals". Or at least, that's how I read it anyway.
So basically, I think you agree with the previous poster?
So basically, I think you agree with the previous poster?
I'm not seeing how that relates to my comment.
I don't get it.
"Every problem at every company I’ve ever worked at eventually boils down to “please dear god can we just hire people who know how to write HTML and CSS.”"
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.
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.
There are bunch of good UX principles baked into HTML and CSS. Plus to become good at HTML and CSS you will be exposed to a lot of UX talk as well.
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.
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.
Not directly making that point.
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.
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.
It seems building SPAs and using related frameworks unnecessarily is now the baseline. People who really know HTML and CSS are few and far between. Many are just copy-pasting.
> Isn't HTML and CSS a base line, every programmer knows this?
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.
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.
Wow. I wonder who are those people in those circles. They clearly have no clue about frontend development, because a decent abstraction layer on top of those “low-level” instructions has never materialized. 100% of frameworks and renderers do leak abstraction and you have to deal with HTML and CSS anyway at some point.
[deleted]
iykyk
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".