That’s personal preference and depends heavily on the workflow.
I avoid writing something manually unless it’s necessary, and with Cwicly that’s very rarely the case. That applies to any kind of code.
Things may change for me as soon as the Quick Code Editor supports Relative Styling and the Relative Styling rules allow free input.
Being faster doesn’t automatically mean better for me.
Relative Styling also provides an instance of code organization. This can be an important factor in several scenarios.
I think one should figure out what Cwicly offers and how it could fit into an improved workflow instead of sticking to habits or even trying to carry over workflows from similar tools, which in most cases harms more than it helps.
I actually use the stylesheet in 60% of my new build now. Its so much easier tbh. I use Cwicly mainly to just create the blocks for things I’m building and styling them a little bit and most part as the author mentioned, I use global css say .button to have every details I need for my buttons, and button-primary etc for the types of button it is. The main css for these classes are in the stylesheet. I work faster this way and tbh predictable way to maintain bugs/ visual issues I have with the design and build later.
Now if ONLY Cwicly also supports HTML typing like LiveCanvas do, it would be a killer feature
I think that’s unrelated to Relative Styling, at least if you don’t use any combinators.
Did you know you can use a code editor and the GUI in combination?
It’s also planned that Relative Styling will support Relative Styling, so this might solve your issue then.
Live Canvas supports HTML, because it’s based on HTML.
For Cwicly, this is therefore rather out of the question.