Utopia founder here. Totally with you on this, inline styles are at best a starting point. We already support changing the style target to `css` (styledC / emotion) and the various pseudo states. We also have primitive support for CSS classes.
We started with inline styles because typically that's the starting point when designing / prototyping. A lot of the features on our near-term roadmap are about then abstracting those: "take this element with styles and make it a component", "refactor this manually styled thing with the best matching layout component" etc.
Our design philosophy here is to help you do what you'd do in code (heck, you can even do it in code!), but not make broad assumptions about what that is or should be. Inline styles, helper components, utility css classes, styledComponents all have their place, and it's your job as a designer / engineer to decide on where to use what. What we can do is make those changes as fast as possible, while always showing you the resulting code. No black box, no "smart" decisions.
We started with inline styles because typically that's the starting point when designing / prototyping. A lot of the features on our near-term roadmap are about then abstracting those: "take this element with styles and make it a component", "refactor this manually styled thing with the best matching layout component" etc.
Our design philosophy here is to help you do what you'd do in code (heck, you can even do it in code!), but not make broad assumptions about what that is or should be. Inline styles, helper components, utility css classes, styledComponents all have their place, and it's your job as a designer / engineer to decide on where to use what. What we can do is make those changes as fast as possible, while always showing you the resulting code. No black box, no "smart" decisions.