Tags: ev

2330

sparkline

“Never-Slow Mode” (a.k.a. “Slightly-Fast Mode”) Explained

I would very much like this to become a reality.

Never-Slow Mode (“NSM”) is a mode that sites can opt-into via HTTP header. For these sites, the browser imposes per-interaction resource limits, giving users a better user experience, potentially at the cost of extra developer work. We believe users are happier and more engaged on fast sites, and NSM attempts to make it easier for sites to guarantee speed to users. In addition to user experience benefits, sites might want to opt in because browsers could providing UI to users to indicate they are in “fast mode” (a TLS lock icon but for speed).

Plaidophile: So about that AMP-script thing

Reinventing the web the long way around, in a way that gives Google even more control of it. No thanks.

Taking shortcuts ・ Robin Rendle

How Robin really feels about Google AMP:

Here’s my hot take on this: fuck the algorithm, fuck the impressions, and fuck the king. I would rather trade those benefits and burn my website to the ground than be under the boot and heel and of some giant, uncaring corporation.

Is client side A/B testing always a bad idea in your experience? · Issue #53 · csswizardry/ama

Harry enumerates the reasons why client-side A/B testing is terrible:

  • It typically blocks rendering.
  • Providers are almost always off-site.
  • It happens on every page load.
  • No user-benefitting reuse.
  • They likely skip any governance process.

While your engineers are subject to linting, code-reviews, tests, auditors, and more, your marketing team have free rein of the front-end.

Note that the problem here is not A/B testing per se, it’s client-side A/B testing. For some reason, we seem to have collectively decided that A/B testing—like analytics—is something we should offload to the JavaScript parser in the user’s browser.

AccentDesign/Fractal-Atomic: An awesome starter point for your Fractal UI component library

If you want to use Brad’s Atomic Design naming convention—atoms, molecules, etc.—and you like using Fractal for making your components, this starter kit is just for you:

Keep what you need, delete what you don’t and add whatever you like on top of whats already there.

Jeremy Keith - Building The Web - View Source 2019 - YouTube

I had a chat with Vitaly for half an hour about all things webby. It was fun!

Accessibility and web performance are not features, they’re the baseline | CSS-Tricks

Performance and accessibility aren’t features that can linger at the bottom of a Jira board to be considered later when it’s convenient.

Instead we must start to see inaccessible and slow websites for what they are: a form of cruelty. And if we want to build a web that is truly a World Wide Web, a place for all and everyone, a web that is accessible and fast for as many people as possible, and one that will outlive us all, then first we must make our websites something else altogether; we must make them kind.

Amphora. — Ethan Marcotte

There’s no sugar-coating it—AMP components are dreadfully inaccessible:

We’ve reached a point where AMP may “solve” the web’s performance issues by supercharging the web’s accessibility problem, excluding even more people from accessing the content they deserve.

Meaning without markup: Accessibility Object Model

Hidde gives an in-depth explanation of the Accessibility Object Model, coming soon to browsers near you:

In a way, that’s a bit like what Service Workers do for the network and Houdini for style: give developers control over something that was previously done only by the browser.

Building an extensible app or library with vanilla JS | Go Make Things

This looks like a sensible approach to creating a modular architecture for a complex client-side JavaScript codebase.

I know a lot of people swear by ES6 imports, but this systems worked really well for us. It gave us a simple, modular, extensible framework we can easily build on in the future.

The 2019 Design Systems Survey by Sparkbox

The good folks at Sparkbox ran a survey on design systems. Here are the results, presented in a flagrantly anti-Tufte manner.

Redux: Lazy loading youtube embeds

Remy has an excellent improvement on that article I linked to yesterday on using srcdoc with iframes. Rather than using srcdoc instead of src, you can use srcdoc as well as src. That way you can support older browsers too!

Time to First Byte: What It Is and Why It Matters by Harry Roberts

Harry takes a deep dive into the performance metric of “time to first byte”, or TTFB if you using initialisms that take as long to say as the thing they’re abbreviating.

This makes a great companion piece to Drew’s article on server timing headers.

Lazy load embedded YouTube videos - DEV Community 👩‍💻👨‍💻

This is a clever use of the srcdoc attribute on iframes.

Native lazy-loading for the web  |  web.dev

The title is somewhat misleading—currently it’s about native lazy-loading for Chrome, which is not (yet) the web.

I’ve just been adding loading="lazy" to most of the iframes and many of the images on adactio.com, and it’s working a treat …in Chrome.

Form design: from zero to hero all in one blog post by Adam Silver

This is about designing forms that everyone can use and complete as quickly as possible. Because nobody actually wants to use your form. They just want the outcome of having used it.

The web without the web - DEV Community 👩‍💻👨‍💻

I love React. I love how server side rendering React apps is trivial because it all compiles down to vanilla HTML rather than web components, effectively turning it into a kickass template engine that can come alive. I love the way you can very effectively still do progressive enhancement by using completely semantic markup and then letting hydration do more to it.

I also hate React. I hate React because these behaviours are not defaults. React is not gonna warn you if you make a form using divs and unlabelled textboxes and send the whole thing to a server. I hate React because CSS-in-JS approaches by default encourage you to write completely self contained one off components rather than trying to build a website UI up as a whole. I hate the way server side rendering and progressive enhancement are not defaults, but rather things you have to go out of your way to do.

An absolutely brilliant post by Laura on how the priorites baked into JavaScript tools like React are really out of whack. They’ll make sure your behind-the-scenes code is super clean, but not give a rat’s ass for the quality of the output that users have to interact with.

And if you want to adjust the front-end code, you’ve got to set up all this tooling just to change a div to a button. That’s quite a barrier to entry.

In elevating frontend to the land of Serious Code we have not just made things incredibly over-engineered but we have also set fire to all the ladders that we used to get up here in the first place.

AMEN!

I love React because it lets me do my best work faster and more easily. I hate React because the culture around it more than the library itself actively prevents other people from doing their best work.

Ooops, I guess we’re full-stack developers now.

Chris broke both his arms just to avoid speaking at the JAMstack conference in London. Seems a bit extreme to me.

Anyway, to make up for not being there, he made a website of his talk. It’s good stuff, tackling the split.

It’s cool to see the tech around our job evolve to the point that we can reach our arms around the whole thing. It’s worthy of some concern when we feel like complication of web technology feels like it’s raising the barrier to entry

The Real Dark Web

Charlie’s thoughts on dev perception:

People speak about “the old guard” and “stupid backwards techniques”, forgetting that it’s real humans, with real constraints who are working on these solutions. Most of us are working in a “stupid backwards way” because that “backwardsness” WORKS. It is something that is proven and is clearly documented. We can implement it confident that it will not disappear from fashion within a couple of years.