Link tags: frontend

How To Build Resilient JavaScript UIs — Smashing Magazine

The opening paragraphs of this article should be a mantra recited by every web developer before they begin their working day:

Things on the web can break — the odds are stacked against us. Lots can go wrong: a network request fails, a third-party library breaks, a JavaScript feature is unsupported (assuming JavaScript is even available), a CDN goes down, a user behaves unexpectedly (they double-click a submit button), the list goes on.

Fortunately, we as engineers can avoid, or at least mitigate the impact of breakages in the web apps we build. This however requires a conscious effort and mindset shift towards thinking about unhappy scenarios just as much as happy ones.

I love, love, love the emphasis on reducing assumptions:

Taking a more defensive approach when writing code helps reduce programmer errors arising from making assumptions. Pessimism over optimism favours resilience.

Hell, yeah!

Accepting the fragility of the web is a necessary step towards building resilient systems. A more reliable user experience is synonymous with happy customers. Being equipped for the worst (proactive) is better than putting out fires (reactive) from a business, customer, and developer standpoint (less bugs!).

For developers, Apple’s Safari is crap and outdated – Perry Sun | Blog

Apple dragged their feet in adding support for PWAs in Safari, and when they finally did, limited the capabilities of a PWA so that native-like app functionality wouldn’t be possible, like notifications or a home screen icon shortcut – to name just a few of the many restrictions imposed by Apple.

But it goes beyond that. On iOS, the only web rendering engine allowed is Apple’s own WebKit, which runs Safari. Third-party iOS browsers such as Chrome can only use WebKit, not their own engines (as would be permitted in Windows, Android, or macOS). And it’s WebKit that governs PWA capabilities.

Safari is very good web browser, delivering fast performance and solid privacy features.

But at the same time, the lack of support for key web technologies and APIs has been both perplexing and annoying at the same time.

The enormous popularity of iOS makes it all the more annoying that Apple continues to hold back developers from being able to create great experiences over the web that work across all platforms.

Safari isn’t protecting the web, it’s killing it | HTTP Toolkit

I do want to recognize that the Safari/WebKit team are working hard, and I do desperately want them to succeed! Chromium’s domination is bad for everybody, and building a popular browser that’s focused on privacy & security, as they appear to be trying to do, is a fantastic goal. That does not mean their current approach deserves our blind support.

I’m sure the Safari team are working on the issues below already, and I think it’s likely that the problems fundamentally derive from management decisions about company priorities rather than the team themselves.

In the past (the early 2010s) Apple was frequently leading the way on new features, as the very first browser to ship major JavaScript APIs like Web Workers, and the browser driving experimental prefixed features like CSS Canvas backgrounds. It’s exceedingly rare now to see a web feature primarily driven by Apple. Something has changed.

One-offs and low-expectations with Safari - daverupert.com

If I could ask for anything, it’d be that Apple loosen the purse strings and let Webkit be that warehouse for web innovation that it was a decade ago.

Bruce Lawson’s personal site  : prefers-reduced-motion and browser defaults

I think Bruce is onto something here:

It seems to me that browsers could do more to protect their users. Browsers are, after all, user agents that protect the visitor from pop-ups, malicious sites, autoplaying videos and other denizens of the underworld. They should also protect users against nausea and migraines, regardless of whether the developer thought to (or had the tools available to).

So, I propose that browsers should never respect scroll-behavior: smooth; if a user prefers reduced motion, regardless of whether a developer has set the media query.

Tabs in HTML?

I’ve been having some really interesting chats with Brian about tabs, markup, progressive enhancement and accessibility. Here’s a braindump of his current thinking which is well worth perusing.

petite-vue - npm

An interesting alternative to using the full Vue library, courtesy of Vue’s creator:

petite-vue is an alternative distribution of Vue optimized for progressive enhancement. It provides the same template syntax and reactivity mental model with standard Vue. However, it is specifically optimized for “sprinkling” small amount of interactions on an existing HTML page rendered by a server framework.

Diana Ashktorab

This is my new favourite indie web site (super performant and responsive too).

Organize your CSS declarations alphabetically – Eric Bailey

Until there is movement on developers taking CSS more seriously and understanding its full capabilities, we are caught in an awkward loop where introducing too much complexity in your project’s CSS will do more harm than good.

Robin Rendle ･ The web is too damn complex

The modern web wouldn’t be possible without big ol’ JavaScript frameworks, but—but—much of the web today is held back because of these frameworks. There’s a lot of folks out there that think that every website must use their framework of choice even when it’s not necessary. And although those frameworks solve a great number of problems, they introduce a substantial number of trade-offs; performance issues you have to deal with, complex build processes you have to learn, and endless dependency updates that can introduce bugs.

Introducing Astro: Ship Less JavaScript

In Astro, you compose your website using UI components from your favorite JavaScript web framework (React, Svelte, Vue, etc). Astro renders your entire site to static HTML during the build. The result is a fully static website with all JavaScript removed from the final page.

YES!

When a component needs some JavaScript, Astro only loads that one component (and any dependencies). The rest of your site continues to exist as static, lightweight HTML.

That’s the way to do it! Make the default what’s best for users (unlike most JavaScript frameworks that prioritise developer convenience at the expense of the end user experience).

This is a tagline I can get behind:

Ship Less JavaScript

Real-world CSS vs. CSS-in-JS performance comparison - Tomas Pustelnik’s personal website

CSS-in-JS can have a noticeable impact on your webpage. Mainly for low-end devices and regions with a slower internet connection or more expensive data. So maybe we should think better about what and how we use our tooling. Great developer experience shouldn’t come at the expense of the user experience.

The right tag for the job: why you should use semantic HTML - localghost

A great introduction to structuring your content well:

Using semantic HTML as building blocks for a website will give you a lovely accessible foundation upon which to add your fancy CSS and whizzy JavaScript.

Ancestors and Descendants – Eric’s Archived Thoughts

Eric looks back on 25 years of CSS and remarks on how our hacks and workarounds have fallen away over time, thank goodness.

But this isn’t just a message of nostalgia about how much harder things were back in my day. Eric also shows how CSS very nearly didn’t make it. I’m not exaggerating when I say that Todd Fahrner and Tantek Çelik saved the day. If Tantek hadn’t implemented doctype switching, there’s no way that CSS would’ve been viable.

Beginner JavaScript Notes - Wes Bos

A very handy collection of organised notes on all things JavaScript.

Two articles on SPA or SPA-like sites vs alternatives — Piper Haywood

On framework-dependency and longevity:

So it’s not even so much about being wary of React or Vue, it’s about not making assumptions, being cautious and cognizant of future needs or restrictions when proposing a tech stack. Any tech stack you choose will ultimately become a ball-and-chain, not just those based on JavaScript frameworks. It’s just that the ball can sometimes be heavier than it needed to be, and you can anticipate that with a little foresight.

No, Utility Classes Aren’t the Same As Inline Styles | frontstuff

This is supposed to be a defence of utility classes …but it’s actually a great explanation of why classes in general are a great mechanism for styling.

I don’t think anyone has ever seriously suggested using inline styles—the actual disagreement is about how ludicrously rigid and wasteful the class names dictated by something like Tailwind are. When people criticise those classes they aren’t advocating for inline styles—they’re advocating for better class names and making more use of the power of the class selector in CSS, not less.

Anyway, if you removed every instance of the word “utility” from this article, it would still work.

Should DevTools teach the CSS cascade?

In a break with Betteridge’s law, I think the answer here is “yes.”

Learn CSS

This is a great (free!) course on learning CSS from the basics up. Nicely-pitched explanations with plenty of examples.

Faster Integration with Web Components - Cloud Four

It’s good to hear stories like this—makes me feel like the slow-burn of the theoretical benefits of web components is starting to spark and flame up.