Let‘s move away from web components

[TheDadi]

Let‘s discuss with the all the frontend guys/girls if it‘s still a good practice to build webcomponents, since we have now a more clear sight who is using which framework and what the trend shows for axa switzerland. The new disussions with multiple teams shows a trend from moving away from angular to react. Let‘s discuss this since we are facing multiple problems with webcomponents... and they are not as simple to use in an other franework as thought.

[LucaMele]

Well, the framework of choice should always be React these days in AXA. I fully agree, we should not move away from react. Web Components can be integrated in other framework as they are pure html/js. I underline it: they can and not they must.

The Style guide here is only a reference and Web-components are chosen as a framework agnostic technology in order to show HTML/CSS DEMOS. Developers can include Web-Components but can also just use plain HTML for their React classes.

I can't see other options at the moment. I Don't want to make another toolkit that strictly depends on a specific Framework. The goal here is to GUIDE developers in creating awesome fronted stuff. What is not the GOAL is to be another Toolkit that lives only as long as the Framework of choice.

[LucaMele]

This Style-guide uses ONLY Custom Element from the Web Components proposed Standard. Nothing else. And only to make developing holistic components easier. Other Developers CAN import the component into their framework of choice or not and take their own Risk (Same as using experimental css selectors, JS features and etc).

[LucaMele]

And, this has already been discussed in the glide this sommer and communicated at the ARP PI5. The Style Guide will be pure HTML JS CSS (with SCSS as a helper here, but traditional CSS is visible). Web-components is something I added to help the integration. If we want to discuss about that i'm in. But i won't discuss again if its a Toolkit with React components. This has been discussed in the glide and now is too late. If the web-components disturbs, i can remove them and provide pure Living Standard JS.

[LucaMele]

So, do we want just Living Standard JS in our Style-Guide OR Proposed Standard JS.

[AndyOGo]

Interesting discussion. I will try to elaborate from different use cases and view points. So I would like to look at the following separately:

• Web Components themselves
• SPA, Large Scale Website Suitability
• Third Parties, Reference Implementation, Living Guide Lines

Web Components themselves

The original idea of custom HTML <elements> isn't brand new. I'm sure every developer wished he could just write what he thinks suits best. The first draft arrived an 2011 and was presented at fronteers. Nope, even earlier with XHTML in 2000, but...

Pros	Cons
Everyone loves the idea	Still in Draft state
	The only Living Standard <template> tag, doesn't even incorporate a usable template language. Man it's like saying black is white, it's a bug...
	API Specs have changed over time
Polyfills provided	weak Browser support
	According to our test/problems: components lifecycle including initialisation is vague
	forced wrapping root aka container node for every component (React is much smarter in this regard)
Polymer claims SSR support	not verified
	efficient Bundling and reuse of modules way more complex

SPA, Large Scale Website Suitability

In general there are way to many features missing to say that Web Components alone can serve as a SPA, LSW foundation.

Pros	Cons
reuseable tags
just string props
slow DOM
missing template language
no context

Third Parties

This is imho the biggest benefit of web components. In case we want to provide a reference implementation of the defined living style guide, it's super beneficial to build it framework- and library-agnostic. This way any agency, external or internal people don't have to grasp their head around very advanced and complex Frameworks like React, Angular, Vue, you name it (I admit they still need to grasp Web components).

And yeah even if I don't like it, in terms of collaboration, freedom of choice, etc; this is really what we get from using Web Components. Does this make them production ready? IMHO never in the next 20 years.

Update As @LucaMele mentions Youtube is using Web Components. That is actually true, though they use a big monster around it called Polymer, which itself does not 100% support IE11 (I admit again the IE series should be engraved 😉 ). IMHO since Google is the major driver behind Web Components I simply don't accept above fact as making it production ready. Fact is all Web Component specs are either Draft or faulty Living standards.

[LucaMele]

I would add, there is more risk for production, but a lot of big websites are build just with them (YouTube as an example). Therefore, they are productive already, event if they can bring some headaches.

When we develop something, it has to be goal oriented. Everything else is pointless. This is valid for any Software language and every framework.

Engineers, as practitioners of engineering, are people who invent, design, analyse, build and test machines, systems, structures and materials to fulfill objectives and requirements while considering the limitations imposed by practicality, regulation, safety, and cost.

The objective for the styleguide is to reach out as many people as possible. Therefore I believe that being native can best fulfill that criteria. SSR, SPA, etc is not on the Style-guides objective.

[LucaMele]

This is not a discussion on which technology is absolutely better. It is a discussion which technology is better for a certain objective. Im not a FanBoy of Web-Components or React or whatever. They are just tools to fulfill a goal/objective

[LucaMele]

As said, use them at own Risk. I think they can be tested and implemented and if it works why not use them. Are they mature? no. Are they mature enough? i think yes. Not just google is behind them. Also the EDGE team is developing on them. Safari is native with the custom element. FF under a flag. Is only a matter of time till they are standard. But developers will decide in their own projects if they make sense to use or not. I don't know if u guys realise that i'm trying to fix an issue that is in AXA since almost 2 years and non of you were able to provide useful alternatives to our common objective. Our customers have a different layout on every micro app they go and this is the main damage. Whats so bad in trying to find a common ground? So unless there is a useful suggestion, i will close the issue.

[AndyOGo]

Got it. As I said, for third party stuff, I really see the benefit

[AndyOGo]

Those critical features are enough reason to continue discussion

42 #31

[LucaMele]

Those two bugs are personal preference. The specs say:

Because element definition can occur at any time, a non-custom element could be created, and then later become a custom element after an appropriate definition is registered. We call this process "upgrading" the element, from a normal element into a custom element.

Upgrades enable scenarios where it may be preferable for custom element definitions to be registered after relevant elements have been initially created, such as by the parser.

[LucaMele]

Sorry only one is personal preference: #42

[AndyOGo]

I understand. Unfortunately the "specs" are still in draft state, have changed and will change in the future. Obviously specs can be wrong, in case of Web components this is very often the case and that fact is reason why disclosure statements are everywhere.

This section is non-normative.

[LucaMele]

Agree. But we keep within the proposal and not invent new features.

[LucaMele]

I encourage you to report it to the w3c community

[AndyOGo]

IMHO working 7 years and not making a good product indicates lag of competence

[LucaMele]

The custom elements is proposed standard and therefore not normative. But till it changes we adapt to it. And obviously browser implementation follows the proposal so far. So if we want our custom need to be implemented, we need to ring the door bells as google, Mozilla, Microsoft and apple. Plus all the w3c community. Totally out of scope. Please srick to the non normative proposed specs.

[LucaMele]

U are free to tell google, Mozilla, Microsoft, apple and the whole w3c community your personal opinion

[LucaMele]

Both bugs are irrelevant to this and therefore closing again

[AndyOGo]

@LucaMele Please stop closing issues because you don't agree with them personally. We have rudimentary issues regarding Web Components and it's valid to discuss those in an open manner. It's a major paradigm shift and we need to be aware of what that means and all it's consequences including the positive and negative parts.

Even the spec itself admits this gap:

Although today there are many limitations on the capabilities of custom elements—both functionally and semantically—that prevent them from fully explaining the behaviors of HTML's existing elements, we hope to shrink this gap over time.

[LucaMele]

I will open a new issue where we can discuss whatever we need web components or we stick to only already standard features. Spec BUGS, nice to have, native HTML comparisons with other Framework, etc are out of topic here.

[LucaMele]

See issue #45