- The original goal of eww was to be two-dimensional polybar with support for full visuals and CSS, rather than just colored text. This means that my target audience, at least initially, was also more the polybar crowd than the awesomeWM crowd. Eww aims to be usable without really needing to know how to program, and aims to provide declarative UI description language that reduces complexity of state management and logic as much as possible. This is, arguably, a goal I've at least somewhat reached -- primarily given the fact that eww DID grow quite fast, and did enable lots of people to do more interesting UI designs than other projects (such as AwesomeWM) did. "Widgets for everyone" is a tagline I don't wanna leave, and thus requiring users to do full-on scripting is not something I'd wanna do easily.

- if you remove yuck and it's state management architecture from eww, you'll be left with quite little. Thus, there would at that point be little added value over existing GTK wrappers. The thing that makes eww appealing (at least IMO) is that it does simplify lots of the most commonly needed things down to a very simple state and UI structure, and provides a great iteration-cycle with great error messages. This would be very hard to keep when turning it into a regular, more imperative library