trot
Working on this project is great but ten minutes into it and I already miss the resilience of the web. I miss how you have to really fuck things up to make a browser yell at you or implode.
Working on this project is great but ten minutes into it and I already miss the resilience of the web. I miss how you have to really fuck things up to make a browser yell at you or implode.
Want to use all those great features that have been in landing in browsers over the past year or two? View transitions! Scroll-driven animations! So much more!
Well, your coding co-pilot is not going to going to be of any help.
Large language models, especially those on the scale of many of the most accessible, popular hosted options, take humongous datasets and long periods to train. By the time everything has been scraped and a dataset has been built, the set is on some level already obsolete. Then, before a model can reach the hands of consumers, time must be taken to train and evaluate it, and then even more to finally deploy it.
Once it has finally released, it usually remains stagnant in terms of having its knowledge updated. This creates an AI knowledge gap. A period between the present and AI’s training cutoff. This gap creates a time between when a new technology emerges and when AI systems can effectively support user needs regarding its adoption, meaning that models will not be able to service users requesting assistance with new technologies, thus disincentivising their use.
So we get this instead:
I’ve anecdotally noticed that many AI tools have a ‘preference’ for React and Tailwind when asked to tackle a web-based task, or even to create any app involving an interface at all.
Detective stories and tales of bughunting in software and hardware.
Sometimes bugs have symptoms beyond belief. This is a collection of such stories from around the web.
LLMs are good at transforming text into less text
Laurie is really onto something with this:
This is the biggest and most fundamental thing about LLMs, and a great rule of thumb for what’s going to be an effective LLM application. Is what you’re doing taking a large amount of text and asking the LLM to convert it into a smaller amount of text? Then it’s probably going to be great at it. If you’re asking it to convert into a roughly equal amount of text it will be so-so. If you’re asking it to create more text than you gave it, forget about it.
Depending how much of the hype around AI you’ve taken on board, the idea that they “take text and turn it into less text” might seem gigantic back-pedal away from previous claims of what AI can do. But taking text and turning it into less text is still an enormous field of endeavour, and a huge market. It’s still very exciting, all the more exciting because it’s got clear boundaries and isn’t hype-driven over-reaching, or dependent on LLMs overnight becoming way better than they currently are.
When haters deny HTML’s status as a programming language, they’re showing they don’t understand what a language really is. Language is not instructing an interlocutor what to do in a way that leaves no room for other interpretations; it is better and richer than that. Like human language, HTML is conversational. It is remarkably adept at adapting to context. It can take a different shape on any machine, from a desktop browser or an e-reader screen to a mobile app or a screen reader for the blind (so long as that device is built to present hypertext).
Hell, yeah!
Ultimately, even as HTML has become the province of professionals, it cannot be gatekept. This is what makes so many programmers so anxious about the web, and sometimes pathetically desperate to maintain the all-too-real walls they’ve erected between software engineers and web developers.
Hell, yeeeeaaaaahhh!!!
What other programmers might say dismissively is something HTML lovers embrace: Anyone can do it. Whether we’re using complex frameworks or very simple tools, HTML’s promise is that we can build, make, code, and do anything we want.
CSS wants you to build a system with it. It wants styles to build up, not flatten down.
Truth!
Tabloid is a turing-complete programming language for writing programs in the style of clickbait news headlines.
React is a non-transferable skill.
React proponents might claim that React will teach you modern UI, but from what I’ve seen it barely copes with modern UI.
autofocu
s is broken, custom elements don’t work in all but the experimental version, using any “modern” features likedialog
or popovers requiresuseEffect
, and the synthetic event system teaches you so little about how DOM actually works. This isn’t modern UI, it’s UI from 2013 at its inception. I don’t have the time left in my career to pick up UI paradigms that haven’t evolved much beyond from when Barack Obama was in office.When I mentor early career developers and they ask me what they should learn, I can’t say React, they don’t have time. I mean sure, pick up enough React to land you the inevitable job doing it, but it’s not going to level up your career.
Logical properties, container queries, :has
, :is
, :where
, min()
, max()
, clamp()
, nesting, cascade layers, subgrid, and more.
I really like the way that the thinking here is tied back to Bert Bos’s original design principles for CSS.
This is a deep dive into the future of CSS layout—make a cup of tea and settle in for some good nerdiness!
I love the way that Claire L. Evans writes.
At this point, it really does seem like “AI” is “bullshit you don’t need or is done better in other ways, but we’ve just spent literally billions on this so we really need you to use it, even though it’s nowhere as good as what we were already doing,” and everything else is just unsexy functionality that makes what you do marginally easier or better. I’m sorry we live in a world where enshittification is being marketed as The Hot And Sexy Thing, but just because we’re in that world, doesn’t mean you have to accept it.
The goal isn’t to write less code.
It’s to ship less code to users. Better code. Faster code. More resilient code.
THIS!
Sooooo many front-end developers don’t grasp this fundamental principle: it’s not about you!
The show itself was an unbelievable outpouring of energy and love. I couldn’t help but imagine if anyone in the audience had decided to go on a lark, not knowing anything about it. I would think they would have been pretty damn impressed. This wasn’t just a couple of nerds poking around at instruments (except me), these were some serious musicians giving it their all.
People act like writing code is the hard part of software. It is not. It never has been, it never will be. Writing code is the easiest part of software engineering, and it’s getting easier by the day. The hard parts are what you do with that code—operating it, understanding it, extending it, and governing it over its entire lifecycle.
The present wave of generative AI tools has done a lot to help us generate lots of code, very fast. The easy parts are becoming even easier, at a truly remarkable pace. But it has not done a thing to aid in the work of managing, understanding, or operating that code. If anything, it has only made the hard jobs harder.
A very thought-provoking presentation from Maggie on how software development might be democratised.
A depressing but accurate description of the economics of web development.
A proposal to retroactively classify additions to CSS in order to put more meat on the bones of the term “modern CSS”.
Rachel responds to Jen’s recent post with the counter-argument; why masonry should be separate from grid.
I’m not entirely convinced. We heard performance issues as a reason why we could never have container queries or :has, but here we are. And the syntax for a separate masonry spec borrows so heavily from grid that it smells of redundancy.
More thoughts on naming web components.