Skip to content
This repository has been archived by the owner on Nov 16, 2021. It is now read-only.

Discussion: Lost - why? #27

Open
svdoever opened this issue Jun 13, 2020 · 1 comment
Open

Discussion: Lost - why? #27

svdoever opened this issue Jun 13, 2020 · 1 comment

Comments

@svdoever
Copy link

svdoever commented Jun 13, 2020

When I first heard about Bento AMP I thought cool, this makes it possible to use the AMP web components within any place where we use HTML. So use it within larger web components, or within JQuery, React or any other framework.

But now I see that the team is actually implementing the AMP components with Preact, and wrap that implementation within a web-component (to be consumed by React/Preact/Vue/WC?) My question is: why?

Why is Preact used for the implementation of the web components, instead of, for example, StencilJS or Lit-Element+Lit-Html? Especially because the latter comes from Google as well.

I was impressed by [DevFest Nantes 2019] Building a Complex Application with Web Components and LitElement, and am currently looking into working with web components instead of React what I currently always do, so the created components can be used in any context - whether it is an old JQuery site, a CMS like Sitecore, or in any of the frameworks... what is the rationale behind using Preact? Is React easier? is VDOM faster?

Another thing: Preact still needs to use the "slot" mechanism, and not the "react-native" children mechanism, otherwise the children can't be other web-components, JQuery or whatever another framework...

I have read https://github.com/ampproject/wg-bento/blob/master/react/explainer.md but it is still not clear for me. Will the be (possible to be) used externally, or will only the web component be used externally?

Please enlighten me!

@dvoytenko
Copy link
Contributor

@svdoever I think this document explains our decision making well. But also this explainer should be good.

Our first goal was to make our components mutable by design. Preact fit this picture well and it also has a very small footprint. If you look at the explainer, you might notice that nothing there really ties us to the Preact itself. We could, just as well, have used LitElement. But we still settled on the Preact as a recommended path because we felt that it had a more complete set of development tools and APIs, and it's easier for us to optimize it under the hood across all AMP elements that rely on it, vs having to adopt to several such frameworks.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

2 participants