The solution is an open, flexible, scriptable and drawable canvas where design and code co-exist in exact harmony. Design changes directly modify front-end code, and front-end code directly modifies design equivalently. I see the endgame as a model where designers and FEE's are co-owners and co-authors of the front-end with zero handoff.
replyDreamweaver?
replyFlash! Those were the days lol.
replyWhat if the approach isn't reusable, but instead is rebuildable? We are stuck in the mindset of creating components that we can grab and plug in to new designs. When we have a component that we like, why not ask the tool to create a markdown definition of it. Later on, when we're doing a new design where we would like to reuse that component, we tell the tool to read the markdown and use that whenever they need to use that component. I think the future will be much more flexible and interesting.
replyI don’t know what level of complexity you’ve seen in your software buildouts, but at anything “enterprise” scale, building your own components from scratch is a recipe for absolute disaster. There are so many nuances, especially with accessibility, and edge case bugs, that I would really strongly recommend against it. And by extension, I’d be against this approach.
replyMaybe you could make it work if everyone agrees on a base set of headless components to use, but we seem to be moving in the opposite direction with things like ShadCN.
> I don’t really see Claude Design fixing the fundamental Storybook hell of designing reusable and pretty components and layouts
replyFWIW Claude Code is decent at scaffolding those out if you have a good set of examples for it to work from.
But the argument is that is unneeded as we move forward as making changes and extracting things and such becomes basically "free". I'm not so convinced, but I do see the argument.