As a non-programmer (UX), I used to watch Polymer with so much interest, since it had HTML tag-like syntax. I copy paste component codes & construct an UI. There was simplicity in <googlemaps lat="89.2" long="123.2" draggable="false"></googlemaps>
Now with lit-html, it went from unique HTML/WebComponent for non-coders, to another one of the JS frameworks out there.
If <google-maps> was rewritten in LitElement, you'd still be able to write:
<google-maps lat="89.2" long="123.2" draggable="false"></google-maps>Unfortunately this breaks down as soon as you start to break up the page into sections (you end up with a component that needs a "layout" to provide surrounding <html><body>(...) etc).
Ironically, now with html5 being rather loose and fast, you might actually get a decent preview of such a widget again... But it's still not right for "web applications" as opposed to "hypertext applications".
Full applications need full gui widgets - and html isn't a good fit.
I think one difference between lit-html and React/other JS frameworks is that lit-html knows which portions of its template are static, and can avoid reconciling static portions. This is the same optimization as what Svelte can do, but without the need to change your toolchain.
Disclaimer: I work at Google, but on a completely unrelated team.
But having separate style-sheets, I don't know. I have done Vue with SASS etc, but the abstraction I felt was a bit too vague. At least our team got a little lazy and wrote massive style sheets with nested classes, and similarly we then ended up fitting too much HTML to the template.
With JSX/TSX I can keep myself from doing those mistakes, and just make small simple components, that do not go overboard with logic. Although I have to say performance-wise React is still very much pain in the ass to debug, and I can't say how many working days I have wasted on some dumb rendering bug, where the components would rerender constantly.
And it's way, way too hard to find those problems and I think this is the weak point of React. No one likes figuring out how to performance optimize a simple list. It should work straight out-of-the-box! I hope that Polymer team will try to make their framework a little better than React on this part.
A colleague of mine went with Polymer for a prototype (against my advice), and switched to Angular within 2 weeks because the performance of Polymer was so bad. I think the web-component approach is inherently inefficient for large apps, because you can't batch DOM reads and write like the other frameworks do.
Were you using CSS modules with your SASS? I've found a few base styles in global SASS along with scoped styles in CSS (SASS) modules works pretty well for keeping things simple.
But Polymer isn't our current generation library anymore. LitElement, which is based on the lit-html template library, is. LitElement measures clearly faster than Angular and React on shootouts.
There's nothing inherently inefficient about web components, and we do batching of DOM updates much like frameworks. LitElement is even able to yield between different component renders naturally, like React concurrent mode, to not jank the page.
EDIT: I was looking at the wrong. I see, it seems like a nifty way to combine styles. But hmm, I guess this one of those things that what works for you, is good enough.
Somehow keeping the styles in the same file, inside the styled components, just makes everything easier to me. Granted the string interpolation is bit annoying at times for accessing the theme variables but ehh.
This has resulted in our newer lit-html and LitElement libraries, where the DOM rendering is done in JavaScript, but it's still possible to do single-file style:
There are a number of reasons why this is better, IMO. Not requiring any builds and utilizing the JS module graph are big ones.The most important though is that the essential job of templates is to interpolate data into DOM. It's much easier this by building DOM in JS, than by trying to access and transform data in HTML.
Templates need some kind of expression language. If the template is in HTML then you need to invent expression delimiters, the expression syntax and semantics, and a way to get data into HTML: HTML doesn't natively have a way to refer to JavaScript objects. This is all custom, needs code to implement, and you need to train developers on it.
On the other hand if you write templates in JS you can take advantage of full JavaScript expressions, imports, and natural lexical scoping... and the data is typically already in JavaScript.