Material-components-web: Idea on using Web components standard
I am not trying to disturb or anything , just picking your brains on why could not Material Design Team anticipate Web Components v1 ? From seeing the standard felt like it would be on the same lines with concepts involved here about independent components . Polymer 2.0 is going on those lines . But just wanted to know what will be the difference between MDC and Polymer 2.0 with regards to an end user or a developer . Why use MDC ? I mean basically Web Component's standards is a thing now . Shadow Dom v1 and Web Components v1 are approved standards on most browser vendors and expecting more Paper components and Material Components from many users in the coming future . So I am just guessing MDC might get left out sooner than it could make an impact. Please forgive me for pinging you all for such an off topic discussion, but just curiosity.
appunnicer13
>All comments
Hi @appunnicer13, thanks for the question!
The short answer is that web components aren't yet supported in all the browsers we target.
As for the longer answer, take a seat! :)
We love the web components standards, and we do think they're the way forward. However, for many of the browsers we're targeting, native support isn't quite there yet, or won't be coming. Polyfills are required for now, which are in various states of development and come with their own caveats and restrictions. In addition, the best practices around web components are still in development in a number of areas (theming comes to mind), so in a lot of ways we'd be treading uncharted territory as a large UI library which we hope to get to a production state.
We wanted to build something that worked for today's web, and we wanted to meet developers where they are; we wanted our components to work with their technology stacks, rather than have them adopt ours.
So we did something different with MDC-Web: we built components that don't rely on any polyfills, frameworks, or runtime library dependencies, with an architecture that allows not only direct usage, but also deep integration into web frameworks. This also means that it will be possible (and even somewhat easy!) to build Web Components (whether vanilla custom elements, vanilla custom elements + shadow DOM, or Polymer 2.0 components) on top of our code, and we hope to see spin-off projects that wrap MDC-Web in Web Components, just like we've already started seeing projects that wrap MDC-Web in popular web frameworks (Vue, for example).
In time, as Web Components mature, best practices get developed, interaction with popular web frameworks improves, older browsers become less relevant, and modern browsers get native support in stable releases, we will look towards rewriting our components on top of the web component standards. For now, we think the component / adapter / foundation architecture is the best approach.
sgomes
on 28 Dec 2016
Related issues
jimyhdolores
路
3Comments
7iomka
路
3Comments
16rajumane
路
3Comments
kimurakenshi
路
3Comments
yapryntsev
路
3Comments
Most helpful comment
Hi @appunnicer13, thanks for the question!
The short answer is that web components aren't yet supported in all the browsers we target.
As for the longer answer, take a seat! :)
We love the web components standards, and we do think they're the way forward. However, for many of the browsers we're targeting, native support isn't quite there yet, or won't be coming. Polyfills are required for now, which are in various states of development and come with their own caveats and restrictions. In addition, the best practices around web components are still in development in a number of areas (theming comes to mind), so in a lot of ways we'd be treading uncharted territory as a large UI library which we hope to get to a production state.
We wanted to build something that worked for today's web, and we wanted to meet developers where they are; we wanted our components to work with their technology stacks, rather than have them adopt ours.
So we did something different with MDC-Web: we built components that don't rely on any polyfills, frameworks, or runtime library dependencies, with an architecture that allows not only direct usage, but also deep integration into web frameworks. This also means that it will be possible (and even somewhat easy!) to build Web Components (whether vanilla custom elements, vanilla custom elements + shadow DOM, or Polymer 2.0 components) on top of our code, and we hope to see spin-off projects that wrap MDC-Web in Web Components, just like we've already started seeing projects that wrap MDC-Web in popular web frameworks (Vue, for example).
In time, as Web Components mature, best practices get developed, interaction with popular web frameworks improves, older browsers become less relevant, and modern browsers get native support in stable releases, we will look towards rewriting our components on top of the web component standards. For now, we think the component / adapter / foundation architecture is the best approach.