Statement on Generative AI | Ben Myers
I endorse this statement.
I endorse this statement.
CSS is better now. It’s not perfect, but it’s better than its ever been, and it’s better than tailwind. Give it another try. Don’t reach for big globs of libraries to paper over the issues you think it has.
This is why it’s so important to re-evaluate technology decisions.
I’ve seen people, lead and principal engineers, who refuse to learn modern JS, insisting that since it was bad in 2006 its bad today. Worse still is some of these people have used their leadership positions to prevent the use of modern JS.
It looks like it will be a great tool for prototyping. A tool to help developers that don’t have experience with CSS and layout to have a starting point. As someone who spent some time building smoke and mirrors prototypes for UX research, I welcome tools like this.
What concerns me is the assertion that this is production-grade code when it simply is not.
I knew of most of these front-end development tools (like Utopia, obviously), but some were new to me.
The slides and transcript from a great talk by Maggie Appleton, including this perfect description of the vibes we get from large language models:
It feels like they’re either geniuses playing dumb or dumb machines playing genius, but we don’t know which.
Another great talk from Simon that explains large language models in a hype-free way.
Emily M. Bender:
I dislike the term because “artificial intelligence” suggests that there’s more going on than there is, that these things are autonomous thinking entities rather than tools and simply kinds of automation. If we focus on them as autonomous thinking entities or we spin out that fantasy, it is easier to lose track of the people in the picture, both the people who should be accountable for what the systems are doing and the people whose labor and data are being exploited to create them in the first place.
Alternative terms:
And this is worth shouting from the rooftops:
The threat is not the generative “AI” itself. It’s the way that management might choose to use it.
This is a really clear, practical, level-headed explanatory talk from Simon. You can read the transcript or watch the video.
CSS is now the most powerful design tool for the Web.
I think this is now true. It’ll be interesting to see how this will affect tools and processes:
What I expect to see overall is that the perception and thus the role of CSS in the design process will change from being mainly a presentational styling tool at the end of the waterfall to a tool that is being used at the heart of making design decisions early on.
This is a very handy tip if you’re adding view transitions to your website!
AI is great anything quantity-related and bad and anything quality-related.
Sensible thinking from Dan here, that mirrors what we’re thinking at Clearleft.
In other words, it leans heavily on averages; the closer the training data matches an average, the higher degree of confidence that the result is more “correct,” or at least desirable.
The problem is that this is the polar opposite of what we consider creativity to be. Creativity isn’t about averages. It’s about the outliers, sometimes the one thing that’s different than all the rest.
- Start with mostly static HTML.
- Progressively enhance the dynamic parts.
- Pick small, focused tools.
This is the kind of press release I like.
The pros and cons of dependencies in your toolchain.
Of course, users can learn over time what prompts work well and which don’t, but the burden to learn what works still lies with every single user. When it could instead be baked into the interface.
Stéphanie has gathered a goldmine of goodies:
Articles, resources, checklists, tools, plugins and books to design accessible products
I’ve been using Copilot for over a year now, and this is more or less how I use it: To help me quickly blast through boilerplate code so I can more quickly get to the tricky bits.
There’s a more subtle problem with ChatGPT’s code generation, which is that it suffers from ChatGPT’s general “bullshit” problem.
For me, a complicated Javascript build system just doesn’t seem worth it for small 500-line projects – it means giving up being able to easily update the project in the future in exchange for some pretty marginal benefits.
This! Also, this:
I’m writing this because most of the writing I see about JS assumes that you’re using a build system, and it can be hard to navigate for folks like me who write very simple small Javascript projects that don’t require a build system.
I think some tools are a good idea. But as few as possible, and the easier they are to stop using, the better.
Now Michelle asks:
Suppose we want to stop using Tailwind one day?
Turns out it’s a bit of a roach motel, much like most JavaScript frameworks: you can get in but you can’t easily get out.
So whenever possible, the safest, and most future-proof bet is to use the native features of the web platform.