Chris’ Corner: A Little Back and Forth

Posted on by

I feel like y’all out there are like: ya know what I could use this week? A scattered collection of interesting links with light commentary about what is interesting about them or how they connect with the modern web zeitgeist. No worries gang, I got ya.

I like Josh’s take on all this coding + AI stuff and the fear of lost jobs. It’s terrible timing for all this because fricking tons of people are losing tech jobs in layoffs right now. But that isn’t because AI is taking their jobs, it’s economic fears, correcting overhiring mistakes, and some greedy “ooo look we can do mass layoffs and not get much flack for it because everyone is doing it”. Anyway here are some quotes from Josh’s article:

… since the beginning, there’s been a concern that web developers would be made redundant by some new technology. In the 2000s, it was WordPress. In the 2010s, it was Webflow. In the early 2020s, it was “no code” tools.

[on GPT-4 building simple website from napkin drawing] … we haven’t needed web developers to build these sorts of pages in decades. There is an enormous difference between this HTML document and the sorts of code front-end developers write today.

Code snippets are all over the internet, and are often generic. By contrast, every codebase is unique. There are very few large open-source codebases. How’s the AI supposed to learn how to build big real-world projects?

I actually think that this could increase the total # of developer jobs.

Certain tasks might be delegated to an AI, but not many jobs.

Normally I skip or roll my eyes at people’s hot takes on AI stuff since there is just so much of it right now, but again I think Josh’s takes here are smart. It’s also in agreement with most other takes I’ve read on this. Generally, people are writing articles trying to address people’s fear, but the fear seems a little invented.

A little accessibility back and forth!

I suppose the powers that be should listen to web accessibility experts over me, but I’m more inclined to agree with Ben here. The cowpaths are there, pave them.

Another back-and-forth took place last month between Alex Russell’s The Market for Lemons and Laurie Voss’ The case for frameworks. As much as I prefer to rate these arguments on the written word entirely, the fact is I know that both of these people are Very Big Web Personalities that both very much like to argue. Laurie for the most part brings baby-bear porridge to the party and I like that, but I also don’t mind Alex bringing down the hammer and taking hard-line stances on web performance, mostly because not a ton of other people do that and the web could use the pushback.

A good amount of web platform arguments end up being about JavaScript frameworks and the whole idea of SPAs. Probably no question we overdid it as an industry on the SPA thing. One side plot here though is that this was all happening during a time when the web was perhaps a bit more threatened by “native” apps than it is now. Native apps have a certain feel to them that is a bit different than web apps generally, and no small part of that is how they tend to animate their state and page transitions moreso than web apps do. SPAs made that far more possible than we were able to do on standard new-page-loading web apps.

Transitioning interfaces and page transitions in non-SPAs isn’t just sitting around waiting to be solved though. I think of three things:

  1. Swup is a JavaScript library just for this stuff which is being actively developed. There is also Taxi.
  2. Turbo looks still actively developed too, and while it’s not about transitions specifically, it’s about making a non-SPA behave like an SPA meaning you don’t need to change architectures but can still benefit from a page that never 100% reloads.
  3. The biggest deal is still the View Transitions API which has just landed now in stable Chrome. No libraries needed. No SPA needed. Just straight-up animations between state and page changes in native JavaScript.

I mentioned the other week that Firefox fixed this old bug a bit related to drop caps, but really, or I guess in addition to that, the best thing that can happen to drop caps is the CSS initial-letter property. I should have linked up Stephanie Stimac’s article Greater styling control over type with `initial-letter` which digs into that and strongly makes the case.

Ethan Marcotte has a wonderful video showing how to do drop caps well, but it’s frustratingly complicated. Really looks like initial-letter is the answer to all this.