Custom elements

[adriankremer]

i would like to eliminate the necessity of using data-attributes and use custom elements custom-elements-spec instead. Custom elements need to be polyfilled https://github.com/WebReflection/document-register-element#document-register-element

JS:

@component("SuperButtonExtreme") // customElements.define("super-button-extreme", SuperButtonExtreme);
class SuperButtonExtreme extends GondelBaseComponent {
//...
}

Html:

<super-button-extreme text="super power" />

Type of issue

• Feature request

The issue refers to:

• the gondel core

[dhardtke]

I'd like to point out that browser support for custom elements (V1 of the spec) has improved a lot since this issue's creation: https://caniuse.com/#feat=custom-elementsv1

Libraries such as lit-element are on the rise (used by big players such as Google, Adobe, Microsoft, etc.) and what I especially like about custom components is the encapsulation where the CSS and markup are all part of the component, i.e., the consumer (e.g. a CMS) doesn't have to know the internals (markup) of the component. For "traditional" websites that are no SPA a full-blown framework such as React or Angular might not always be the best fit.

I'd love to see Gondel adhering to the custom elements spec but am sure that's quite an effort and most importantly probably a breaking change. Also, I'm not sure what would make Gondel stand out from projects like lit-element.

[jantimon]

I discussed adding custom-elements to gondel with @adriankremer lately.

custom-element implementations like lit-element have one big issue: slow performance

what do I mean by that? the browser is not able to render a custom-element before the javascript has been downloaded, parsed and executed - so the browser needs more time to display something meaningful to the user

https://www.eon.com/en.html is a very good example where you can see how the entire page is flickering during load time and during page switch because of that issue.

basically it has the same speed as an angular or react app. however unlike react or angular there is no stable ssr implementation for lit-element.

gondel has been built for enterprise cms or ecommerce which are mainly written in java or c# and have no nodejs ssr capabilities at all. so even if lit-element would provide stable ssr we would probably not be able to use it for gondel projects.

but that does not mean we should not look into this topic any further in fact it could still help with better dx (e.g. <accordion> instead of <div data-g-name="accordion">).
to add basic custom element support to gondel we would need to find a good replacement for the following code:

https://github.com/namics/gondel/blob/846e08b8e4b2745428c73908bf6c9773fce9e715/packages/core/src/GondelDomUtils.ts#L133-L156

This code is looking through the entire dom and returns all gondel elements.
Right now it is using a css selector like [data-g-name] and get's a quite fast result.

If you have any idea how we could replace that part for custom-elements please let me know or create a pull request :)

[dhardtke]

https://www.eon.com/en.html is a very good example where you can see how the entire page is flickering during load time and during page switch because of that issue.

Imo, that's because of the sheer amount of JS (jQuery 3.3.1, jQuery 1.11.2, jQuery UI, Bootstrap - you name it) that is loaded and executed from different domains using HTTP/1.1. HTTP 2 can help there, especially with deferred loading of script tags and inlining critical CSS. See https://developers.google.com/speed/pagespeed/insights/?hl=en&url=https%3A%2F%2Fwww.eon.com%2Fen.html&tab=desktop

the browser is not able to render a custom-element before the javascript has been downloaded, parsed and executed - so the browser needs more time to display something meaningful to the user Yes, that is true. But frameworks like React and Angular ship a lot more JS that needs to be parsed. Custom Elements are meant to be small and portable.

I get your point, though. Using SSR is a huge benefit (not just for performance but also for SEO reasons). It is a trade-off between hiding complexity / abstracting away the internals, i.e., the HTML from the consumer (the backend of a CMS) and delaying rendering a little bit. It depends on the component I guess, e.g. a videoplayer that takes lots of space on a page leads to more "flickering" than a simple button.

Regarding findComponents: I don't think there's a much more performant solution to querying Gondel components in the DOM. And I don't feel like there's much to gain by just using custom elements for expressiveness, e.g. <our-button> instead of <div data-g-name='OurButton'>. It's just syntactic sugar at this point.

Custom Elements provide so much more than just encapsulating the markup. They also rely heavily on the Shadow DOM and are really portable and easily shareable.

[jantimon]

It depends on your cumulated javascript code size - every byte will increase the time until the entire javascript is downloaded, parsed and executed. If you say we should not use SSR at all we could use preact which is half the size of lit-element and brings the same advantages.

[dhardtke]

If you say we should not use SSR at all we could use preact which is half the size of lit-element and brings the same advantages.

I didn't say that 😁 (But preact is quite nice).

[janwidmer]

@adriankremer as this ticket is already older than two years, can we close it?

[adriankremer]

@janwidmer yep