Care

Using the Platform | TimKadlec.com

Tim ponders the hard work that goes into adding standards to browsers, giving us a system with remarkable longevity.

So much care and planning has gone into creating the web platform, to ensure that even as new features are added, they’re added in a way that doesn’t break the web for anyone using an older device or browser. Can you say the same for any framework out there?

His parting advice is perfect:

Use the platform until you can’t, then augment what’s missing. And when you augment, do so with care because the responsibility of ensuring the security, accessibility, and performance that the platform tries to give you by default now falls entirely on you.

Let’s reinvent the wheel ⚒ Nerd

Vasilis gives the gist of his excellent talk at the border:none event that just wrapped up in Nuremberg. The rant at the end chimed very much with my feelings on this topic:

I showed a little interaction experiment that one of my students made, with incredible attention to detail. Absolutely brilliant in so many ways. You would expect that all design agencies would be fighting to get someone like that into their design team. But to my amazement she now works as a react native developer.

I have more of these very talented, very creative designers who know how to code, who really understand how the web works, who can actually design things for the web, with the web as a medium, who understand the invisible details, who know about the UX of HTML, who know what’s possible with modern HTML and CSS. Yet when they start working they have to choose: you either join our design team and are forced to use a tool that doesn’t get it, or you join the development team and are forced to use a ridiculous framework and make crap.

When should you be using Web Workers? — DasSur.ma

Although this piece is ostensibly about why we should be using web workers more, there’s a much, much bigger point about the growing power gap between the devices we developers use and the typical device used by the rest of the planet.

While we are getting faster flagship phones every cycle, the vast majority of people can’t afford these. The more affordable phones are stuck in the past and have highly fluctuating performance metrics. These low-end phones will mostly likely be used by the massive number of people coming online in the next couple of years. The gap between the fastest and the slowest phone is getting wider, and the median is going down.

Build for the Web, Build on the Web, Build with the Web – Web Performance and Site Speed Consultant

If I was only able to give one bit of advice to any company: iterate quickly on a slow-moving platform.

Excellent advice from Harry (who first cast his pearls before the swine of LinkedIn but I talked him ‘round to posting this on his own site).

1. Opt into web platform features incrementally
2. Embrace progressive enhancement to build fast, reliable applications that adapt to your customers’ context
3. Write code that leans into the browser, not away from it

I’m not against front-end frameworks, and, believe me, I’m not naive enough to believe that the only thing a front-end framework provides is soft navigations, but if you’re going to use one, I shouldn’t be able to smell it.

If Not React, Then What? - Infrequently Noted

Put the kettle on; it’s another epic data-driven screed from Alex. The footnotes on this would be a regular post on any other blog (and yes, even the footnotes have footnotes).

This is a spot-on description of the difference between back-end development and front-end development:

Code that runs on the server can be fully costed. Performance and availability of server-side systems are under the control of the provisioning organisation, and latency can be actively managed by developers and DevOps engineers.

Code that runs on the client, by contrast, is running on The Devil’s Computer. Nothing about the experienced latency, client resources, or even available APIs are under the developer’s control.

Client-side web development is perhaps best conceived of as influence-oriented programming. Once code has left the datacenter, all a web developer can do is send thoughts and prayers.

As a result, an unreasonably effective strategy is to send less code. In practice, this means favouring HTML and CSS over JavaScript, as they degrade gracefully and feature higher compression ratios. Declarative forms generate more functional UI per byte sent. These improvements in resilience and reductions in costs are beneficial in compounding ways over a site’s lifetime.