JavaScript dos and donts @ Mu-An Chiou
Straightforward smart sensible advice that you can apply to any feature on a website.
Straightforward smart sensible advice that you can apply to any feature on a website.
This makes sense:
Wrap everything in your CSS reset with a
@layer
rule.When you place any styles inside a layer, these styles automatically have lower priority compared to all unlayered styles on the page. Think of it like an
!unimportant
block. You don’t need to worry about specificity or order of stylesheets at all.
Logical properties, container queries, :has
, :is
, :where
, min()
, max()
, clamp()
, nesting, cascade layers, subgrid, and more.
I like the approach here: logical properties and sensible default type and spacing.
I really like the way that the thinking here is tied back to Bert Bos’s original design principles for CSS.
This is a deep dive into the future of CSS layout—make a cup of tea and settle in for some good nerdiness!
It’s pretty easy to write bad HTML, because for most developers there are no consequences. If you write some bad Javascript, your application will probably crash and you or your users will get a horrible error message. It’s like a flashing light above your head telling the world you’ve done something bad. At the very least you’ll feel like a prize chump. HTML fails silently. Write bad HTML and maybe it means someone who doesn’t browse the web in exactly the same way as you do doesn’t get access to the information they need. But maybe you still get your pay rise and bonus.
So it’s frustrating to see the importance of learning HTML dismissed time and time again.
Trys describes exactly the situation where you really do need to use the Shadow DOM in a web component—as opposed to just sticking to HTML web components—, and that’s when the component is going to be distributed and you have no idea where:
This component needed to be incredibly portable, looking great on any third-party website, in any position, at any viewport, with any amount of content. It had to be a “hyper-responsive” component.
“And so what we did is we started looking at, internally, all of the places where we’re using web technology — so all of our internal web UIs — and realized that they were just really unacceptably slow.”
Why were they slow? The answer: React.
“We realized that our performance, especially on low-end machines, was really terrible — and that was because we had adopted this React framework, and we had used React in probably one of the worst ways possible.”
This is excellent! A free web book (it’s a book! it’s a website!) that teaches you how to make a website from scratch:
I feel strongly that anyone should be able to make a website with HTML if they want. This book will teach you how to do just that. It doesn’t require any previous experience making websites or coding. I will cover everything you need to know to get started in an approachable and friendly way.
👏
React has become a bloated carcass of false promises, misleading claims, and unending layers of backwards compatibility – the wrong kind of backwards compatibility, as they still occasionally break your fucking code when updating.
Pretty much anything else is a better tool for pretty much any web development task.
Picture me holding Trys back and telling him, “Leave it alone, mate, it’s not worth it!”
This project, based on OpenStreetMap, looks great:
OpenFreeMap lets you display custom maps on your website and apps for free.
You can either self-host or use our public instance.
I’m going to try it out on The Session once there’s documentation for using this with Leaflet.
Oh, how I wish that every team building for the web would use this sensible approach!
In an earlier era, startups could build on the web and, if one browser didn’t provide the features they needed, they could just recommend that their users try a better one. But that’s not possible on iOS.
I’m extremly concerned about the newest bug in iOS 18:
Whaa? That’s just shockingly dreadful!
This is a very handy piece of work by Rich:
The idea is to set sensible typographic defaults for use on prose (a column of text), making particular use of the font features provided by OpenType. The main principle is that it can be used as starting point for all projects, so doesn’t include design-specific aspects such as font choice, type scale or layout (including how you might like to set the line-length).
Debating complexity is pointless because it’s a subjective metric. Every developer has a different gut feeling about simplicity, complexity and the appropriate amount of complexity for a given task. When people try to find an objective definition, they come to wildly different results. And that’s okay.
Instead, we should focus on hard metrics from a user perspective. Performance, efficiency, compatibility, accessibility and fault-tolerance can be measured, tested and evaluated, automatically and manually.
Any amount of complexity is fine as long as these goals are met.
Since the early days of the web, large corporations have seemingly always wanted more than the web platform or web standards could offer at any given moment. Whether they were aiming for cross-platform-compatibility, more advanced capabilities, or just to be the one runtime/framework/language to rule them all, there’s always been a company that believes they can “fix” it or “own” it.
Applets. ActiveX. Flash. Flex. Silverlight. Angular. React.
I’m very glad to see that work has moved away from a separate selectmenu
element to instead enhancing the existing select
element—I could never see an upgrade path for selectmenu
, but now there are plenty of opportunities for progressive enhancement.
This is grim:
If you look at the data below on how popular websites today are actually transpiling and deploying their code to production, it turns out that most sites on the internet ship code that is transpiled to ES5, yet still doesn’t work in IE 11—meaning the transpiler and polyfill bloat is being downloaded by 100% of their users, but benefiting none of them.
The goal isn’t to write less code.
It’s to ship less code to users. Better code. Faster code. More resilient code.
THIS!
Sooooo many front-end developers don’t grasp this fundamental principle: it’s not about you!