React is not a library, Angular generates wrappers, semantic HTML, defining UX
Finished Insanity Max 30
After a very stressful day on Tuesday I woke up early on the Wednesday feeling like shit. So I ended up missing day 3—booooo! But hey that’s life.
I got the rest of the final week done just fine and I can say for certain that I feel way fitter than I did and I’ve lost a bit of fat and my arms are more defined.
I didn’t temper my diet at all. That is, I ate loads of shit. No doubt I would have done a lot better weight wise if I focused on my diet properly.
I highly recommend this workout program because it’s challenging, fun and only 30 minutes making it hard to come up with excuses not to do it.
First week fail times: 7:01 9:49 7:51 10:42 8:35
Second week fail times: 9:17 10:43 10:01 10:48 11:45
Third week fail times: 17:15 7:14 12:01 8:15 11:43
Fourth week fail times: 19:14 10:44 12:12 11:10 12:15
Fifth week fail times: 8:20 5:55 4:52 6:01 5:58
Sixth week fail times: 12:50 12:21 7:52 7:52 6:20
Seventh week fail times: 14:40 11:41 10:48 12:20 6:26
Eighth week fail times: 16:10 12:21 --:-- 12:22 6:32
React is not a library
I’ve always questioned React being referred to as a library. But that’s wrong unless you change the definition of a framework to mean ‘something that only solves part of a problem.’
And this week I came across a great explanation by Eric Elliott in response to an article on Medium. So I’m jotting it down here to refer back to.
Another hallmark of a framework is Inversion of Control. Don’t call us. We’ll call you. Again, React satisfies that definition of Framework, because we don’t call React methods to do stuff — React calls the methods we create to do stuff. They define lifecycle methods, we fill in the details, and React calls our methods — not the other way around. We don’t even instantiate the views that are the building blocks of our app: React does.
Angular generates component wrappers (booo!)
We’re creating form components for our Angular app which are copies of the components in the GOV.UK Design System (built with Nunjucks).
We wanted to create an Angular version of the Label component from GOV.UK Frontend. So we did exactly that but this caused a problem for checkboxes and radio buttons—the styling was missing.
This is because the CSS uses the sibling selector. And by making the label a component, Angular wrapped it in another element so the sibling wasn’t actually the label element.
Quite possibly the CSS could be rewritten to just target a class on the label within the wrapper element. But then you can’t use
Either way, when I write HTML I like that HTML to be the thing that users get. Not a framework’s opinionated intepretation of my HTML. And that’s another reason I don’t like Angular.
So what to do about it? I raised this problem on Twitter and the cross government design channel on Slack and got some useful responses. The options were as follows:
- Change the CSS within GOV.UK Frontend—a package we’re not in control of.
- Change the way Angular works—another package we’re not in control of.
- Patch the CSS locally by duplicating CSS from GOV.UK Frontend into our application.
- Use a directive.
Lazar suggested we use an Angular directive instead of a Angular component. Unlike components, directives don’t generate wrappers. This is true but it also means you can’t have templates which are needed because the GOV.UK Frontend label component has display logic for things like
In the end we’ve actually used a directive and a component together. The directive is applied to the component and all it does is manually remove the generated wrapper. Nasty but we think it’s the easiest and quickest way to fix it.
Semantic HTML—why wouldn’t you?
I stumbled across Adam Rackis’ tweet which said:
Are there any benefits to writing semantic html besides accessibility? Even within accessibility, is it not true that attributes can achieve that?
I ended up responding with a number of tweets that I might even turn into an article one day so dumping them here for now:
It’s not true, no. You can’t turn a div into a button with attributes alone.
And you’ll need additional attributes to make it focusable.
More work, less robust.
You’ll need to give it a class attribute to style it as opposed to using the button’s unique element selector.
And all of the above to say it’s less performant as you’re writing stuff the browser gives you for free.
And thats code your dev team needs to maintain.
The question of course becomes, why not use semantic html?
And then there is interoperability you’ll lose. For example, viewing a web page in RSS feeders. A list (ul) will be shown as a list.
If you used ARIA to do that, only (supporting) screenreaders will recognise it as a list excluding sighted users.
When most people say “for accessibility” they mean “people not like me” and that mostly means “I can see and I use a mouse”.
So you’d be hurting yourself and people like yourself too.
And besides SEO, interoperability affects the way results show in Google too.
You also get some styling for free. Like
<b>makes things bold (and is semantic now btw).*
How to talk about UX
While I’m usually part of the UX team, often referred to as a UX designer and tasked to ‘do the UX’, I still find it hard to define what UX actually is and what’s involved.
Luckily, I stumbled across how to talk about user experience by Michael Schofield. He covers the practical side of the profession:
For me there are just 3 guiding principles to designing services. They should be:
- Useful. The service is valuable to people. It’s something they want or need.
- Usable. The service is easy to use.
- Delightful. The service exceeds users’ expectiations.
Most people think ‘delight’ means animation or something shallow like that. But that’s not really what it is. Delight happens when you exceed someone’s expectation.
The problem is that once you’ve exceed their expectation it becomes the norm. So in my head a particular slice of delight is ephemeral due to hedonic adaptation.
Definitely something I’d like to flesh out a little more for my own piece of mind.