The value proposition of material-web was really convincing (accessible, high quality web-based component built on top of lit) and the dev team did an incredible job. It was killed even before they got a chance to release a full component set.
Highly recommend David Basis "Mathematica: A Secret World of Intuition and Curiosity" or "Mathematique, une aventure au coeur de nous-meme" in french.
For me, it has been a refreshing and profound way to reflect (and possibly better understand) on my own way to "think" (for instance when I build software architecture), and explore what might be happening in my head while doing so.
> since Material Web seemed to quickly end up in maintenance mode
This is really unfortunate to say the least - the engineering team has done a fantastic job there, but apparently no backing from Google despite the nice promise at the the launch of Material Web.
Will check this out with a lot of interest when HN hugging will be over - we are building https://accessiblesurveys.com a survey tool for everyone. It tries to go beyond web accessibility standards (by including Sign language, Easyread versions or read aloud into forms).
> developer burden imposed by needing to denormalize information.
> Then the other pain point is the "joins" use case;
We usually do that client side, with the aid of a web-component holding a ref to the (realtime db, not firestore) database path, and rendering its value. The payload is small as you only fetch data you use.
That works pretty well, even with long lists or grids; quotas/price on the realtime db are pretty generous.
Thanks a lot for your advice! Live demo used to be working on webcomponents.org - one service powering them has stopped working...
I launched this approx 2 years ago - using it in prod, but not had proper time to devote on better doc/demo/presentation. Looking forward to it during current migration to lit-element.
Shameful plug here - and yes dc.js is great!
An alternative web-component based approach to dc.js is available here: https://github.com/PolymerEl/multi-verse.
It is still based on Polymer 2.0, migration to lit-element in the way.
Core idea behind this approach is to expose API properties as web-component attributes so that you can compose your charts and visualization at markup level (and share/react to properties between components).
I do not see any reason why this could not work with your API. If interested, some concrete/simpler examples available from https://github.com/PolymerEl/multi-chart (also being ported / simplified; ETA next week)