[iansinnott]

Migration guide, if anyone is wondering: https://tailwindcss.com/docs/upgrade-guide

Some breaking changes in there. May want to hold off on upgrading until LLMs come around to writing v4 code with ease.

[koito17]

Renaming utilities like flex-shrink-* makes existing LLMs emit deprecated code today and broken code tomorrow. I wonder what the rationale is behind the renaming of various utilities (e.g. shadow-sm -> shadow-xs, flex-shrink -> shrink, decoration-slice -> box-decoration-slice, ...)

In new projects, I will probably use Tailwind v4 and constantly provide the upgrade guide as context to an LLM. In existing projects, I will continue to use Tailwind v3 until I am certain that it works alongside the tools used by my framework (React Router / Remix).

[NiloCK]

This reservation has taken firm hold on me and has made me a slower adopter of shiny new things.

I feel alright about it from a local perspective (I'm a lot more productive now than I was before), but I do wonder what it does to the overall dynamic and incentive to write shiny new things or generally update the ecosystem.

The LLMs will get more powerful, but to what extent will their work be dominated by existing tools (with lots of existent human-generated exemplar)?

[hipadev23]

LLMs have already plateaued in knowledge imo.

There’s far less reason for humans to contribute code examples, answer questions, work on open-source projects, or even produce content knowing it’ll immediately be slurped up and resold.

Web dev will be stuck with React and Tailwind circa 2021 for a very long time.

[verdverm]

We shouldn't really have to retrain models for them to be able to work with new versions of libraries or frameworks. That seems like a flaw in the LLM (only?) setup. One should probably be using RAG at a minimum to pull in the correct documentation and references. Something like Kapa, but not limited to a single project https://www.kapa.ai/