Tags: work

653

sparkline

FOREVERYONE.NET

I linked to this a while back but now this great half hour documentary by Jessica Yu is ready and you can watch the whole thing online: Tim Berners-Lee, the birth of the web, and where the web has gone since.

In the scenes describing the early web, there’s footage of the recreated Line Mode Browser—how cool is that‽

Weeknotes #5 — Paul Robert Lloyd

A nice counterpoint to the last time I linked to Paul’s weeknotes:

However, there’s another portion of the industry, primarily but not exclusively within the public sector, where traditional development approaches (progressive enhancement, server-side rendering) remain prevalent, or less likely to be dismissed, at least. Because accessibility isn’t optional when your audience is everyone, these organisations tend to attract those with a pragmatic outlook who like to work more diligently and deliberately.

Weeknotes #4 — Paul Robert Lloyd

So far I’ve been drawn towards developer-orientated roles; working with HTML, CSS and JavaScript (in that order) to implement designs and ensure products are accessible and performant. However, it seems such work no longer exists. People talk about full-stack development, but nearly every job I’ve seen containing the words ‘front-end’ has React as a requirement. The gatekeeping is real.

Frustrating on a personal level, but also infuriating when you consider how such gatekeeping is limiting welcome attempts to diversify our industry.

1969 & 70 - Bell Labs

PIctures of computers (of the human and machine varieties).

New Adventures 2019 | Part Two: Progressive Web | Abstrakt

Here’s a thorough blow-by-blow account of the workshop I ran in Nottingham last week:

Jeremy’s workshop was a fascinating insight into resilience and how to approach a web project with ubiquity and consistency in mind from both a design and development point of view.

HTML, CSS and our vanishing industry entry points

This!

When we talk about HTML and CSS these discussions impact the entry point into this profession. Whether front or backend, many of us without a computer science background are here because of the ease of starting to write HTML and CSS. The magic of seeing our code do stuff on a real live webpage! We have already lost many of the entry points that we had. We don’t have the forums of parents teaching each other HTML and CSS, in order to make a family album. Those people now use Facebook, or perhaps run a blog on wordpress.com or SquareSpace with a standard template. We don’t have people customising their MySpace profile, or learning HTML via Neopets. We don’t have the people, usually women, entering the industry because they needed to learn HTML during that period when an organisation’s website was deemed part of the duties of the administrator.

I agree with every single word Rachel has written.

I care not a whit what tools or frameworks, or languages you use to build something on the web. But I really care deeply when particular tools, frameworks, or languages become mandatory for even getting a foot in the door.

This is for everyone.

I might be the “old guard” but if you think I’m incapable of learning React, or another framework, and am defending my way of working because of this, please get over yourself. However, 22 year old me would have looked at those things and run away. If we make it so that you have to understand programming to even start, then we take something open and enabling, and place it back in the hands of those who are already privileged. I have plenty of fight left in me to stand up against that.

The Return of New Adventures

Westley came along to my workshop at New Adventures …and liked it! (phew!)

I have long been a proponent of progressive enhancement on the web, perhaps before I knew the true value of it to the people that use the things we build for the web, but Jeremy has always been able to expand my understanding of its importance in the wider scope of things, how it inherently builds resilience into your products, and how it makes it more widely available to people across the world, in vastly different scenarios. The workshop itself was fluid enough to cater to the topics that the attendees were interested in; from over-arching philosophy to technical detail around service workers and new APIs. It has helped me to understand that learning in this kind of environment doesn’t have to be rigorously structured, and can be shaped as the day progresses.

Read on to discover how I incorporated time travel into the day’s activities.

I’m a Web Designer - Andy Bell

Something that I am increasingly uncomfortable with is our industry’s obsession with job titles. I understand that the landscape has gotten a lot more complex than when I started out in 2009, but I do think the sheer volume and variation in titles isn’t overly helpful in communicating what people actually do.

I share Andy’s concern. I kinda wish that the title for this open job role at Clearleft could’ve just said “Person”.

The Great Divide | CSS-Tricks

An excellent thorough analysis by Chris of the growing divide between front-end developers and …er, other front-end developers?

The divide is between people who self-identify as a (or have the job title of) front-end developer, yet have divergent skill sets.

On one side, an army of developers whose interests, responsibilities, and skill sets are heavily revolved around JavaScript.

On the other, an army of developers whose interests, responsibilities, and skill sets are focused on other areas of the front end, like HTML, CSS, design, interaction, patterns, accessibility, etc.

JournalBook

A small but perfectly formed progressive web app. It’s a private, offline-first personal journal with no log-in and no server-stored data. You can read about the tech stack behind it:

Your notes are only stored on your device — they’re never sent to a server. You don’t even need to sign-in to use it! It works offline, so you can reflect upon your day on the slow train journey home.

The Ethics of Performance - TimKadlec.com

When you stop to consider all the implications of poor performance, it’s hard not to come to the conclusion that poor performance is an ethical issue.

Angular, Autoprefixer, IE11, and CSS Grid Walk into a Bar… - daverupert.com

Dave on the opaqueness of toolchains:

As toolchains grow and become more complex, unless you are expertly familiar with them, it’s very unclear what transformations are happening in our code. Tracking the differences between the input and output and the processes that code underwent can be overwhelming. When there’s a problem, it’s increasingly difficult to hop into the assembly line and diagnose the issue.

There’s a connection here to one of the biggest issues with what’s currently being labelled “AI”:

In the same way AI needs some design to show its work in how it came to its final answer, I feel that our automated build tools could use some help as well.

I really like this suggestion for making the invisble visible:

I sometimes wonder if Webpack or Gulp or [Insert Your Build Tool Here] could benefit from a Scratch-like interface for buildchains.

A declarative router for service workers - JakeArchibald.com

An interesting proposal from Jake on a different way of defining how service worker fetch events could be handled under various conditions. For now, I have no particular opinion on it. I’m going to let this stew in my mind for a while.

Welcome to the Silicon Seaside - PCMag UK

A profile of Brighton, featuring Clearleft’s own Chris How.

Performance Calendar » All about prefetching

A good roundup of techniques for responsible prefetching from Katie Hempenius.

Stop Learning Frameworks – Lifehacks for Developers by Eduards Sizovs

It’s a terribly clickbaity (and negatively phrased) title, but if you turn it around, there’s some good advcie in here for deciding where to focus when it comes to dev technology:

  • Programming languages are different, but design smells are alike.
  • Frameworks are different, but the same design patterns shine through.
  • Developers are different, but rules of dealing with people are uniform.

GitHub - GoogleChromeLabs/quicklink: ⚡️Faster subsequent page-loads by prefetching in-viewport links during idle time

This looks like a very handle little performance-enhancing script: it attempts to prefetch some links, but in a responsible way. It won’t do any prefetching on slow connections or where data saving is enabled, and it only prefetches when the browser is idle.

Learning to unlearn – The Sea of Ideas

This is the real challenge for service workers:

For 30 years, we taught billions of humans that you need to be connected to the internet to consume the web via a browser! This means web users need to unlearn that web sites can’t be used offline.

Big ol’ Ball o’ JavaScript | Brad Frost

Backend logic? JavaScript. Styles? We do that in JavaScript now. Markup? JavaScript. Anything else? JavaScript.

Historically, different languages suggested different roles. “This language does style.” “This language does structure.” But now it’s “This JavaScript does style.” “This JavaScript does structure.” “This JavaScript does database queries.”