Create demos that demonstrate usage inside different frameworks

Is your feature request related to a problem? Please describe.
The date of first release from this repo is May 09, 2018, Its almost 2 years now. I know all contributors might have worked with some limitations. but still it's a long time.
Here is my few suggestions to help developers to make their life easier.

Describe the solution you'd like
We can do following things to make developers life easier.
1st
Kindly release all completed components to 1.0 (production Ready) and then work for remaining so developer can start experimenting with it, right now what happens repo shows its not production ready so no one is trying to use it.
And it will also help them to get familiar with such new and powerful technology.
2nd
Add some examples in repo or in docs like how to use it with other frameworks like angular, react & vue. Which will help new developers to get started.
3rd
Add components from this repo so more developers can have an idea that what can be done with lit powered components.
4th
All this things will help them to build their own in house design system on top of this lit powered technology with this components so it will be very useful for small teams and for new developers also to get started.

So without delaying now all contributors of this repo are requested to release all completed components to V1.0. And now as per current situations with corona days and remote work it will also help developers to achieve more and faster

Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.

Additional context
Add any other context or screenshots about the feature request here.

@asyncliz @e111077 @dfreedm @aomarks
Any consideration for this guys?

[e111077]

Hello, the reason we have not tagged this as 1.0 is because it is very much not ready for production. There are large scale refactors and changes coming very soon so it would not make sense to tag as 1.0 then make those changes.

Your second point can probably stand as a feature request on its own.

Third point includes components that are not related to Material Design, and this repository is to showcase our Material Design components not LitElement.

@e111077 ok, thanks for response.

[cintaccs]

There are large scale refactors and changes coming very soon

@e111077 Thanks for all the work you are doing on the components! Can you, by any chance elaborate a bit on the refactoring and changes coming soon? I believe a lot of developers are already depending on the Material Components and it would be nice to know whether we should expect fundamental changes?

[e111077]

There will be fundamental changes. Likely to custom element naming, package names, and repo location. Likely place we will live in is in the MDC repo at

https://github.com/material-components/material-components-web

Also large API changes to support deeper theming and future SSR integration (think start up state on every component be describable via declarative props). OS consumer-side SSR will be way later down the road; we are only starting with internal Google SSR and working our way to external from there.

There will be fundamental changes. Likely to custom element naming, package names, and repo location. Likely place we will live in is in the MDC repo at

https://github.com/material-components/material-components-web

Also large API changes to support deeper theming and future SSR integration (think start up state on every component be describable via declarative props). OS consumer-side SSR will be way later down the road; we are only starting with internal Google SSR and working our way to external from there.

@e111077 I think you guys should update Readme with roadmap so other developers can have some idea that what is going on and what's has been planned.
OR make new roadmap file and link it to readme, its ok if everything is with no ETA.
This will really help new developers to take decisions easily and also will help to keep patience from developer side. If roadmap is detailed and well explained then developers can start playing with such new, powerful and cutting edge technology like lit-html & lit-element also.

And can't you release first all components without SSR and production ready so developers can start their projects with that? Rest of the features you can develop later, not possible?

Because developer community is waiting from last few years for this.

[cintaccs]

There will be fundamental changes. Likely to custom element naming, package names, and repo location. Likely place we will live in is in the MDC repo at

https://github.com/material-components/material-components-web

Also large API changes to support deeper theming and future SSR integration (think start up state on every component be describable via declarative props). OS consumer-side SSR will be way later down the road; we are only starting with internal Google SSR and working our way to external from there.

Thanks a lot for more details! I appreciate the effort!!! As SSR seems to be a bigger thing on lit development too - do you have somewhere a desciption / youtube video / something that explains why SSR should be such a big thing for Web component implementations? I am not sure it is super clear why the server side pre-rendering is a benefit ...? and with the current functionality attrbutes of Array and Object types can already be delivered on the components - so I don't see why SSR eventually wouldn't be just delivering the components together with such attributes and properties set?

[e111077]

One main reason is that we went to build webcomponents that fit into anything anywhere which means any framework. Quite a lot of frameworks implement SSR which means that despite their code being in the client, sometimes it lives in the server (see NEXT js for a real interesting mix of client and server). So if WCs want to live everywhere with 0 compromise, they must also find a way to live in the server.

The problem is that each SSR implementation is unique to its framework. Unlike client-side where they all rely on the same thing, the browser. This makes it a difficult problem and is reason why our progress has been slow. Therefore we are going with an internal google framework first which we think is likely the "hardest-case" scenario.