Proposal to use Lit / web components for building Drupal’s administrative UIs

The demo using PolymerJS. This is different to "Web Components" AFAIK.

To get a more W3 compliance "Web Components" working today, it requires:
https://github.com/webcomponents/webcomponentsjs/

So if this topic is about PolymerJS. According to the chart below and the voice in d.org: VueJS is a better choice for production-ready and gain the benefits the Web Components doesn't have.
https://custom-elements-everywhere.com/

native "Web Components" still need another framework on the top (or say embed inside?) if the performance can't hit vdom-like framework or coding habits. It's things like jQuery on the top of JavaScript.

And I think Drupal never say no to Web Components. To VueJS or React improves the productivity to code (DX). Most frameworks will catch up the trend at final I believe. To imagine that FB widget using Web Components one day. But all React sites can't use it? Doesn't it a joke?

Also, there are some interesting packages available:
https://www.npmjs.com/package/react-polymer

-------

I don't know if I misunderstood some comments in another thread. I think, Drupal adding a framework because of:

Add React / Vue -> Better Productivity (solve common problems) -> More Real Demo to test / More features can be implemented -> Improve UX

not:

Improve UX -> Add React / Vue

either build on polymer or directly on webcomponents.

The topic has to focus on either polymer or W3 web components (and webcomponents-lite.js or webcomponents.js for polyfills). We should not bundle polymer's pros/cons to W3 web components.

fix typo, remove extra M

Excited this is gaining steam!

A couple of points of organization / questions:

1. has someone shared a mockup of what that new target UI for dblog is supposed to be, or are we supposed to re-imagine it?
2. We should put in the issue description the key goals of the new UI?
3. We should revise the largely inaccurate claim that Polymer adds 120kb to page load. The size of the polyfills that are included in webcomponents.js vary in respect to a browser's current support of the standards. The size has shrunk drastically over the last few years. Taken to it's extreme support isn't 120kb, but 10kb https://www.captaincodeman.com/2017/03/31/polymer-2-10kb-web-framework

Polymer 3 will have another big impact through it's adoption of NPM + Yarn for package distribution and ES6 modules for registration.

4. Attiks: may i be permitted to add a component library to the repository? Or would you prefer to have that be in a different repo.
5. We should identify and consider bundling the tags we produced under the "Drupal" namespace for distribution on webcomponents.org . I've seen recently that Joomla and other tranditional CMS are beginning to do the same.

just voicing support for this thread and @attiks for kick starting this! Let me know if there's any lessons gleamed from Webcomponents module. D8 is still unstable but methodology isn't too dissimilar.

These are the options that I run in elmsln to the Polymer global to improve render time on polyfill browsers. Also I've seen numerous people say that CMSs probably should be running Shady dom instead of Shadow because CSS bleed through is an advantage in this case. It also gets it closer to the same thing across platforms where as Shadow default (in polymer 2) makes it a bit more annoying to test across platforms since shady / shadow will render slightly different on some properties.

<script>
      /* this script must run before Polymer is imported */
      window.Polymer = {
        dom: 'shady',
        lazyRegister: true
      };
    </script>

As a reference, this is how we're including the polyfill as recommended in the docs.

<script type='text/javascript'>
window.onload = function() {
  if ('registerElement' in document
    && 'import' in document.createElement('link')
    && 'content' in document.createElement('template')) {
    // platform is good!
  }
  else {
    // polyfill the platform!
    var e = document.createElement('script');
    e.src = '" . base_path() . $libraries['webcomponents'] . "/webcomponentsjs/webcomponents-lite.min.js';
    document.head.appendChild(e);
  }
};
</script>

also for reference: this is what Google uses on youtube:

window.Polymer = {
"useNativeCSSProperties":true,
"lazyRegister":"max",
"suppressBindingNotifications":true,
"disableUpgradeEnabled":true,
"suppressTemplateNotifications":true
};

These settings are in the polymer globals and have varying performance improvements on polyfill and non-polyfill platforms as far as time to first paint and element upgrade. The disableUpgradeEnabled is particularly interesting though these may be P1 only settings since P2 is much closer to the pure platform.

https://stackoverflow.com/questions/41071766/how-do-i-enable-shady-dom-i...

Reading through the Vue issue and found this issue where someone attempted to provide an api for dblog:
https://www.drupal.org/node/2828882

@cosmicdreams, I think that is the same base that @attiks has used for his, see https://github.com/Chi-teck/dblog-ui

@attiks
To be honest I think this should be its own issue. All the issues are already full of incomprehensible arguments. I'm happy to comment on there ...

For the Vue / React and this issue. We are likely to be creating a visual display of log data that is being delivered by data service.

Perhaps it would be good ask the community what they use the database logging page for and what kind of experiences they need from it. To that end I have posted here: https://plus.google.com/+ChrisWeber/posts/YxQw9jwiVzU

and here: https://www.reddit.com/r/drupal/comments/75hv6j/user_research_what_do_yo...

Thanks for making this issue you'll....Glad there's a counter movement to this React business...

I don't know how much I can help with development but I'll sure test or help with documentation or things like that....

For my own understanding, if the detraction against React is due to "cause Facebook" and the MIT license, and Polymer is built by Google under another license, what makes Google "better" over Facebook in this case? Or are we just strictly talking web components?

Just want to understand why one solution is considered bad and Polymer would not be?

So from my perspective, its all about using open standards that are universal and not controlled by any one corporate entity.

So as I understand it, Webcomponents is that thing, and Polymer and other JS libraries use Webcomponents.

Don't we as a community have values that we use "international recognized standards" over corporate controlled "standards"....

To me, basing things on React would be equivalent to when Microsoft made "JScript" for IE, instead of working with ECMA Javascript...something like that...

If an infrastructure is built to use webcomponents in general, and makes it easy to use libraries such as Polymer to build the interfaces, then we'd be headed in the right direction.

Please correct me if I'm wrong about webcomponents, is it a google thing too?

My understanding is (this may not be correct, still learning myself :)):

• Web Components is a W3C thing, or aiming to be: https://www.webcomponents.org/specs
• However, because support is rather spotty in the various browsers, you can't use them natively today: https://caniuse.com/#search=components
• Therefore, you need a "polyfill" library, which mocks up the behaviours of web components using JavaScript in browsers that don't support it.
• Polymer is one such polyfill library, which seems to be fairly popular (the most popular?), and is written and maintained by Google, and BSD licensed: https://en.wikipedia.org/wiki/Polymer_(library)
• However, https://github.com/webcomponents/webcomponentsjs/ is an alternative polyfill library, more inline with W3C, and is not backed by a company like Google.

@webchick thank you for responding

So maybe the W3C spec isn't 100% ready yet, but its open source, Facebook has infinite money to throw at React.

But Webcomponents, and polyfill library will get there, and I assume it gets closer everyday.

If a major project like Drupal were to embrace it, we could be the leaders of freedom in this little aspect of the open source world, and draw attention, developers, etc... to webcomponents, to accelerate the process.

Hi all: a couple of clarifications.

23.3 and 23.4: the polyfill needed is webcomponents.js. Polymer is a extra syntactical sugar that makes the practice of writing web components faster and easier. It's gone through several iterations since 2013 and it's not done yet. It's also a distraction form the key issue. Web Components is an official standard that browsers are working to support natively. They work today, for sites in production, that aren't run by Google and they provide the best way for frameworks to share components without requiring the developer to work to make sure the components continue to work from Framework X to Framework Y.

23.5: webcomponents.js is not an alternative, but rather a dependency of polymer and every other thing that want an easy to include polyfill for getting webcomponents to work across all browsers.

24: If one wanted to be perfectly accurate the current state of the standards involved in the concept of Web Components are:

Custom Elements: Editor's Draft : https://w3c.github.io/webcomponents/spec/custom/
Shadow Dom: Editor's Draft : https://w3c.github.io/webcomponents/spec/shadow/
Templates: Apart of the HTML5 Standard : https://www.w3.org/TR/html5/scripting-1.html#the-template-element
ES6 Modules: apart of the ES2015 standard : https://www.ecma-international.org/ecma-262/6.0/#sec-module-namespace-ex...

Html Imports was initially proposed as a solution for packaging and distributing custom elements but they've figured out how to use ES6 instead, which a lot of JS devs support.

#21: The attraction to web components is that as a web standard it seems like a great way for all frameworks (.Net, Perl, Ruby, PHP, JS) to define sharable, reusable components that work no matter where they're used in. For many of us, the detraction to React is their incomplete support for the standards. In some cases React seems to have made the same choices that .Net ActiveControls and Cold Fusion have made, to leverage incompatibility to lock in developers. I feel the previous might be too harsh of a way to put it.

It's clear that members of the React team are receptive to accepting patches that improve React's compatibiilty with custom elements and web components. The previously linked https://custom-elements-everywhere.com/ not only shows the current level of support, but also a list of existing frameworks that do support Web Components and the test suite that is currently being used to assess compatibility.

#24: I would argue that Web Components are important for the web. It's an idea, that if it were to take hold, would refocus development on producing testable, reliable components that very clearly state what their own internal apis are and make it easy to treat web development more like web engineering.

@webchick, I recently geeked out about this topic at Drupal Camp STL, here: https://2017.drupalstl.org/sessions/surviving-componetized-future

@kevinquillen - I think some are conflating that aspect (FB = Evil; Google some how != evil) as far as license based on past FUD. My issue w/ React would be associated w/ them having the worst interop' scores against custom elements / Web components. Perhaps that will evolve and not be an issue down the road (would be awesome if that was) but they've been pretty outspoken previously about thinking webcomponents aren't the way forward (interesting perspective for a group that's built their kingdom on something that replicates the majority of what they do but eh)

@webchick very close in your assessment. Minor tweak on the polymer = polyfill part

The webcomponentsjs is the polyfill that's generally agreed upon across libraries.

Polymer isn't a polyfill but more so helps make it a bit easier to create stock components. For example, to make a component have properties you'd have to create a getterValue and setterValue function per each property named 'value'. This is a bit tedious so if you define a property on the polymer object it creates those for you based on the type you define (object, string, bool, etc). It also does some nice-ities associated w/ listeners, mutation observing, interfacing w/ shadow-dom and applying CSS styles to shadow roots.

In my experience with it the only thing I've found that it's doing "non-standard" is the data binding / two-way data binding and that's simply because there's still no agreed upon platform level syntax for [[property]] and {{property}} so this is an issue it shared w/ all other platforms (though I'm not sure React supports two-way binding but I could be wrong).

It is possible to create vanilla webcomponents (stock JS implementing the spec) and then have the webcomponentsjs polyfill make it show up in platforms but I'm not as big a fan of the developer UX.

For comparison purposes:
A stock / vanilla v0 spec'ed webcomponent -- https://github.com/LRNWebComponents/page-scroll-position/blob/master/pag...
A Polymer 1.x syntax web component - https://github.com/LRNWebComponents/elmsln-loading/blob/master/elmsln-lo...
A Polymer 2.x syntax web component - https://github.com/attiks/dblog-ui/blob/8.x-1.x/polymer/src/dblog-app/db...

Version differences for clarification:
Polymer 2.x effectively just takes off training wheels from 1.x (note how the 2.x element looks a bit more like the vanilla one). Polymer 3.x is in heavy development (probably 6 months to a year out) and has already said it will look drastically different as well; however it'll be compatible w/ these other elements still. They are keeping each version compatible w/ the others.

Hope this clarifies where it stands in the universe (and there are other "polymer"-esk web component factory things too). In February of this year we completely re-tooled from Angular to Polymer 1.x / hybrid mode so I'll try to translate as people have any questions about what the implications would be.

And I think this is what @btopro was talking about when he suggested that the React team spend an hour to work through one of the Google's code tutorials: https://codelabs.developers.google.com/?cat=Web (search for Polymer or Web components). So much understanding could be gained by expanding ones understanding of the practice of making Web Components by trying.

There has been a number of articles that people typically bring up when talking about web components. I feel that people use those in place of understanding and it has detracted from communicating about the real facts.

@btopro: The proposed ui seems like it should use a vaadin-grid. AMIRIGHT?

It already supports external data, sorting, and expandable rows.
https://cdn.vaadin.com/vaadin-grid/3.0.1/demo/row-details.html

Cool, thanks for the corrections. Always appreciate learning new things! :)

How does this team respond to the assertion made by the pro-React folks that this initiative is basically exactly the same as the proposed Theme Component Library initiative, and thus orthogonal to the goal of adding a JS library into core to provide more dynamic UX and attract outside JS developers?

I have one general question about web components, which might be me being really naive: There was a lot of research going into fixing the state problem in apps, aka. the facebook notification number not showing the correct amount of notifications unread, while you actually have read them already.

At least in the react world flow and redux appeared, which used the idea of an unidirectional data flow: State is handled in one places and rendering itself is stateless, but can trigger new state changes, more on http://redux.js.org/docs/introduction/Motivation.html

In the world of web components though each web components is inherently stateful: The point is to have web components be embeddable everywhere, and as such they carry their own state. While this works fine in small scale, do web components at some point run into the same state management issues?

I was stumbling about this, when I tried to find out why elm doesn't use web components. Elm has a super nice community, so if web components would be the way to go, they would have certainly discussed it already: https://www.reddit.com/r/elm/comments/5ls1jd/discussion_web_components_i...
At least for me it comes down to: State managment is hard and you need to handle that outside of your components.

@webchick - my worldview changed on "these are design components" when I saw a demo that had this component in it -- https://www.webcomponents.org/element/PolymerElements/iron-ajax

So, you end up effectively building out the whole design / UX patterns in a vaccum and then slap a tag w/ two-way data binding on it; point to a json backend *cough drupal cough*. And now you've got a nicely compartmentalized headless drupal element :)

I would say they are related initiatives; a suite of elements for data connectivity to Drupal (ala this thread) compliments a suite of "dumb" elements that are purely for design purposes.

Example: https://github.com/LRNWebComponents/lrnsys-comment/blob/master/lrnsys-co... provides a comment as a card display.

https://lrnwebcomponents.github.io/lrnsys-comment/components/lrnsys-comm... comments wired up to a data source (faked here but we do use this with Drupal's comment engine on the backend). So both different initiatives but intertwined if pulled off correctly.

@dawehner you are absolutely spot on with that assessment and a plus for React. But, Redux can be used elsewhere when needs get beyond block / widget type of scope to a full on app -- https://www.webcomponents.org/element/tur-nr/polymer-redux

In our Apps I haven't run into this yet but I know I will. For now it's mostly using event firing up out of elements and ensuring that anything you can invoke on an element is done via a property so that state can be maintained via the data binding. We've talked about using Redux as we get into increasingly more complicated things.

+1 to this issue. I'm curious to see what an implementation built entirely with Web Components looks like vs. implementations built with React and Vue.

For many of us, the detraction to React is their incomplete support for the standards.

I think that's a bit orthogonal to this issue. Building an entire UI, whether dblog, layout builder, views ui, whatever, entirely with Web Components rather than a vdom library might have its own merit. But it's also possible to build that UI with React or Vue and then allow plugins / leaf components to be built with web components. That's the current approach in development by WordPress Gutenberg. For those concerned about React specifically, and its incomplete support for Web Components, I opened #2915311: JavaScript VDOM library evaluation: integrating web components as a child of the React issue. Feedback there would be great, and I hope that doesn't distract from this issue's exploration of web components all the way down.

Hi @effulgentsia:

I'm hoping I'll have time to reply to that issue. On the surface it seems like you're asking me to learn React, then demonstrate flaws in how react handles their support of web components. If that's what you're asking for, then I'll try to put the effort in. Before then, I'll reply with links to the various issues that are also referenced from https://custom-elements-everywhere.com/ and see if I can summarize and identify the key issues.

- Added auto update (5 sec interval)
Auto-update is awesome, and this is possibly not the right issue to discuss, but what about a watchdog/logger call issuing a server-sent event instead?

i.e. https://www.w3schools.com/html/html5_serversentevents.asp

@attiks nice! Might want to throw the body of the material into a `` which I think will render those basic tags (need coffee)

Looking forward to the weekend so I can jump in / evaluate and help out. Thanks for all the effort being poured in here.

http://usergroup.tv/videos/web-components-a-simpler-and-faster-react worth a share out to the other related issues. explains it all very well as well as Comcast's switch from React to Web components

Thanks for that link. At the end, the video mentions hyperHTML, which upon first look, looks incredibly awesome to me due to it being based on ES6 template literals. First looks can be deceiving though. What do folks here think of it relative to Polymer? Do we need any Polymer-specific features/sugar to benefit from a declarative/reactive approach to web components, or is hyperHTML simpler and just as good?

Polymer's lit-html looks similarly interesting, but isn't stable yet, which is why I'm asking about hyperHTML instead, but if there's strong arguments to be made to wait for lit-html instead, please share those too. Thanks!

another thing to check out - this dood made the same component in 3 different ways (Vanilla, SkateJS and lit-html) https://github.com/Hotell/reactive-typesafe-webcomponents

Personally from a readability perspective I'm not enjoying anything as much as Polymer thus far (Stencil isn't terrible). Just thinking DX as opposed to raw power; I can see room for both.

I have opened a related issue for discussion: #2916453: Decide on committing to and adopting W3C Web Components standards

Hey gang:

I reviewed the current work and it seems like this could be the Hitlist of actions we should take next. Before reading it, I just want to thank chi-teck, attiks and all the contributors to it. If some of the tasks below do not make sense, or if I'm not seeing the big picture, please let me know:

For what I see in attiks' repo, this is what seems to need to be done:

1. Modify dblog-ui.html.twig so that it uses the custom components : api-blog.html and dblog-app.html
2. Work up a few more examples of elements that can consume the api. Thinking of vaadin-grid and other data grids here
3. Consider removing the remainder of the vue.js artifacts from markup and the module to demonstrate that the page does work without it.
4. Consider renaming the current element that displays dblog results to be dblog-grid-paper.html so that we can create a dblog-grid-vaadin.html and dblog-grid-x.html to show that you can swap the implementation without changing the api.

Should I put these in the issue summary?

I am 100% onboard with name-spacing the components as drupal- . It would be cool if we could publish these elements on webcomponents.org that way too.

Attiks, I'm having trouble fetching from your fork. Did you lock down permissions for your github repo?

@btopro also put together a really interesting demo here:
https://www.webcomponents.org/element/LRNWebComponents/hax-body

This isn't the dblog ui that we're currently putting together here. But it is an example of making web components work with D7 in a really compelling way.

Here are few videos that demonstrate it's use:
https://www.youtube.com/watch?v=ea1Byuahrf8
https://www.youtube.com/watch?v=3sADk6K8CHs

https://www.youtube.com/watch?v=tDiRRvYCmG4&t=4s one page app using vaadin-upload has 3 function calls that are drupal specific so this stuff can be pretty losely coupled to Drupal version at all on the backend as well :)

@attiks: I was able to kick the tires of the solution today.

It's easy to introduce scope creep like breaking each piece into it's own component so we could iterate on each. I'm at the Acquia Engage conference this week, so I'll have time to break up the current work and exclude the vue.js pieces.

I've made my fork of the repo here: https://github.com/cosmicdreams/dblog-ui and will focus on that today.

Speaking of scope creep... I've been thinking of doing the following and need you to talk me out of it:
1. build up alternative dblog-app(s) that demonstrate how the API can remain the same but the components can be swapped out.
2. Build up snazzier UI, specifically focusing on: better drop downs, better datagrid, better actions on rows of data.

What do you think?

@attiks: Is it important that we separate the api call and the datagrid? What are we accomplishing by doing that?

Sorry if this bursts any bubbles, but I opened #2917161: JavaScript library evaluation: polymer license compatibility with GPL2. I'm very open to comments that can point to legal arguments that refute that or to other ideas that would make it a non-issue. But at least as it stands right now, I think it's a critical blocker to moving forward with Polymer in Drupal core.

Yikes, I'm surprised to see that. StencilJS and SkateJS are MIT licensed, and vanilla web components have no license (obviously), so there're still paths forward if this ends up blocking progress on Polymer. 😢

@attiks: While the discussion in #2917161: JavaScript library evaluation: polymer license compatibility with GPL2 progresses (looks like some really good discovery work there, we might actually get Google to weigh in with answers of questions), How do you feel about getting together for a work session?

I don't mean physically, I don't have budget to hop on a plane to come to you so we can work. But if you pick a time that works for you and what timezone you're in I can see what I can do to be online during that time so we can work on this together.

I'm running in to several issues with my attempt to exclude vue.js that I think could be resolved rapidly if we worked together for an hour or so.

I'm serious, even if I need to wake up at 3 in the morning I'll get online to work with you.

So #2917161: JavaScript library evaluation: polymer license compatibility with GPL2 resolved with the answer, yes, Polymer's license is suitable for Drupal.

Great progress with @Attiks today.

Our next steps are:

1. Enable Sorting (Grid driven, fallback to API driven)
2. Make filters look better
3. Remove Operations column
4. Add detail templates to grid so that displays when row expands
5. Make long output details flow better
6. Make the table look better
7. Add back paging

New video of status update coming soon.

As the React team begins experimentation, I still think there is value in following this idea through. If you're interested in seeing how web components can help this effort, follow our development on Attiks github repo.

We're in the process of adding filtering and improving the output of full detail in data rows.

A couple of other thoughts that I think would be fun to pursue:

- Right now we're using off the shelf components to implement things like the data table. What could we get done with vanilla js?
- Perhaps it would be worth while to see what could be done to adapt a data-providing react app. Does that break the web components's expectations / dependencies?
- It would be cool if we could post our component on Web Components.org. We should pursue a proper namespace for Drupal components.

Solid ideas. I'd look stencil before looking Vanilla just because having done one in Vanilla it was too jarring for me coming from Polymer. You'll be doing a lot to get yourself the parts of Polymer you really love (data binding, etc).

Question about web components in general: If you build an entire UI with nested custom elements (without any vdom library like React), then do you get into a situation of custom-element-itis, similar to the divitis situation that themers often complain about? I mean, it's common to want to refactor things as you go: take a big component and break it up into smaller components, rename components, etc. With a vdom approach, all those implementation details can be accomplished without changing any of the markup that's output to the dom. But with custom elements as the primary architecture, each such change gets reflected into the markup, so that your resulting DOM now contains all these elements with no intrinsic semantic meaning. For anyone with experience in doing this for a UI with many nested components, how have you handled this, and/or why is it not an issue? Note that I still think custom elements are great and have their place: I'm just questioning whether they make sense as a complete replacement to vdom libraries, or whether it makes more sense to use them in conjunction with vdom (e.g., to use a very rough analogy with PHP, then custom elements as the equivalent of @api and vdom components as the equivalent of @internal).

Question about Polymer: Polymer 2 uses HTML imports, but that's a dead/dying standard, so Polymer 3 won't. Since this issue is still in its Idea stage, it seems to me that if we continue showcasing with Polymer, then we should start doing so with Polymer 3. Otherwise, what's being demonstrated is already about to be obsolete. And that's relevant, because without HTML imports, Polymer runs into many of the same challenges that React and Vue have: how to express HTML within JavaScript (React uses JSX and Vue defines its own custom template syntax), and we shouldn't sweep that under the rug. How do you all feel about Polymer 3?

I'd look stencil before looking Vanilla

For Stencil, I'm curious about the security implications. For approaches that use a runtime library (like Polymer and Skate), if a security vulnerability is discovered with that library, then Drupal could ship a security release that updates the library. However, if a compiler is discovered to have a security vulnerability that leaks into the compiled code, how would we coordinate contrib projects to all recompile their components at the same time? Anyone know if this has been discussed anywhere else on the internet where JS compilers are used?

custom-element-itis

- It's certainly possible with too much of any good thing. I haven't run into this with the apps / UIs we've built because you make semantically named tags that deliver very specific things and basically just have like by-reference style HTML.

For example. I have a one page app (in drupal but could be anything) with screenshot attached. The high level provides a lot of the wiring via properties for everything inside. source-path for example gets passed down into an iron-ajax tag performing an ajax request. I'm not going to have a lot more tags then that for the scope of "go get me data so I can use it".

On the render side, in the interface in question if I have a "card" that's being presented, I'll want to keep that card as tight as possible both in properties and in markup since it's still unpacking into the UI for the end user. I think of this more as just making the html more maintainable and intentional as to try and avoid the div-ities problem. Another example worth reviewing is youtube.com which if you inspect you'll see they still have a lot of normal div / semantic markup but then anything heavily designed / repurposable they have as a tag.

I've seen a lot of critique of component based apps mostly w/ disbelief that you can't possibly do it all without a higher level vdom. From the perspective of the apps I've built in it so far, I haven't found this to be the case. It's like peeling an onion in reverse; every level you work up simplifies what that level is in charge of. I spend a lot more time planning out the names of things and when i'll get data from element A to B than having hit a ceiling per-say where I'm like "wow I wish I had a higher level app wrapper". My 2nd in command on our project / app development thinks you'll still need something at the highest level but like I said, we haven't run into that just yet. This might be because we are building UIs into Drupal which then if we hit a certain threshold we can always let the page reload to another path / route / mini-app w/ drupal handling that bootstrap but could be conflating a crutch I currently have :).

I'm still using Polymer 1. Polymer 2 is just 1 with less Polyfill / training wheels and given that members of my development team don't have to fight syntax I actually kind of prefer the training wheels at this time. Everything we write is extremely readable and very easy to follow. We implement a mix of P1 and P2 elements and use Polymer 1.x.x still because we have no real incentive (yet) to move forward.

The concerns associated with Polymer 3 are legitimate and something I share; At this time, looking at the construction of Polymer 3 elements I don't personally like them (again I'm looking at readability of a novice audience so I can maximize contributors). I also view Polymer 3 in the same vein as if people said "let's talk about Drupal 9" - as in it's not even something that crosses my mind (funny... we run D7 still...). The nice thing about a webcomponent based approach though is that things should all play nice together no matter how they are constructed. In this way, Polymer team says that 1 2 and 3 elements will all work together in hybrid mode. I completely agree with you though that it's something worth talking about and not trivial.

Re Stencil: I've never thought about that before (compiling = security vector).. if it's a core one, then recompile and push out as there being a security issue in a piece of code (no matter how it got there). Communicating a version of that to use yea that'd be potentially complicated (if indeed it stemmed back to there). Certainly worth considering; also a reason potentially to stick to vanilla ones in core or more of a methodology for including and auto-loading webcomponents and not pick a method of building them at all. No matter what core would adopt I'm still going to use Polymer for the foreseeable future; the beauty of the spec :)

@effulgentsia it seems that you are focusing on an implementation that uses the custom elements standard but not the shadow dom standard. With custom elements it is possible to have a scenario that you are describing: A series of nested custom elements that have all of their information pushed into the DOM. The Shadow Dom standard was created to avoid the trouble you are concerned about. Shadow DOM encapsulates and hides the implementation of a custom element from the DOM, therefore a panacea for custom-element-itis.

From a custom element creator's perspective, they we still have to care about the proper bundling and delivery of the element but composition can be accomplished by piecing together well known components.

Question about focusing on replacing vdom:
Should that be the goal? Is there nothing to be gained by attempting to combine whatever vdom is doing with the custom elements and shadow dom standards?

At a recent roundtable that gathered JS framework developers was able to get them to talk about Web Components. Listen to Andrew Clark's take on web components and Alex Russel's assertion that there shouldn't be any conflict between VDOM and web components. Here's that starting point of that part of the conversation: https://youtu.be/q5HDhQtpDRU?t=25m6s . It would be worth your while to listen to a few minutes earlier to hear other frameworks take on web components: https://youtu.be/q5HDhQtpDRU?t=16m30s . The whole talk is great.

About templating in Polymer 3:
The guidance for developer focusing on making Polymer 3 components seems to be to use HTML-lit for templating: https://www.youtube.com/watch?v=Io6JjgckHbg (great talk, specifically compares / contrasts with VDOM)

Which seems like it could be replaced with anything else that serves as a templating handler in JS. Anything that satisfies the static template() function that component needs.

Shadow DOM encapsulates and hides the implementation of a custom element from the DOM, therefore a panacea for custom-element-itis.

Independently of this issue, I would LOVE for Drupal to start benefitting from Shadow DOM if the polyfills are good enough for our needs. For anyone interested in that, please provide your expertise in #2195695-44: Admin UIs on the front-end are difficult to theme.

The guidance for developer focusing on making Polymer 3 components seems to be to use HTML-lit for templating

That's exactly my point in #63. This issue's current summary lists "Approachable by novices, React developers, and Angular developers alike." as one of the benefits. And yet there's a lot of people (I'm not one of them) who worry that JSX is already not approachable (e.g., search for comments about JSX in #2913321: Proposal to experiment with React for building Drupal’s administrative UIs), and Polymer 3 / lit-html is about to follow the exact same pattern for embedding HTML templates inside JavaScript, but with even more cumbersome syntax. Personally, I really like where Polymer 3 and lit-html are going, but if we're using this issue to surface concerns, including DX concerns, then keeping the demo in Polymer 2 (with HTML imports) is setting up false expectations on what the DX will end up being with Polymer 3 (lit-html).

We've discussed this internally and there are no current plans to adopt Polymer 3, mostly because of DX (which is worth noting that Google currently runs Polymer 0.6 / 1.0 w/ a handful of 2.0 elements in some of their production applications). So Polymer 3 is way out there on the edge of what I feel is an unacceptable level of risk (personally, for my own projects). We run a mix of Polymer 1, Polymer 2, and stock-javascript / vanilla components. That is the point of the approach, to use whatever to hit the spec and then everyone is happy (how you get there matters less).

Specifically on the Import issue; there's a polyfill that hits that across everything not currently supported. I don't find this to be a big deal given that the same logic could be applied to the entire spec right now in that Edge/IE and Firefox need a polyfill for custom elements and shadow dom.

This is issue just posted (https://github.com/w3c/webcomponents/blob/gh-pages/proposals/Template-In...) is why I am calling a hard stop on Polymer 3 / Lit and waiting on the sidelines a bit for Stencil in my personal projects. TLDR; that link is an issue opened w/ the W3c by Apple about web components and effectively is proposing that HTML / webcomponents work natively in a way very similar to lit-html.

Going back to my previous recommendation for building were Drupal to adopt anything; vanilla components, stencil or Polymer 2. If DX is already an issue w/ Drupal then continuing to not care about that we should use vanilla. If it is a concern but we want raw performance and to adopt something that seems a little ahead of the game but in order to hit the sweet spot, start working toward adoption now knowing it'll mature when we get there: Stencil. If we want something that's production ready today then Polymer 2 based elements that minimize their reliance on polyfills. Polymer 2 is more modular then Polymer 1 w/ a smaller footprint out of the box.

Some real numbers on a Polymer 1.x project:
- Polyfill conditionally loaded on Firefox / IE/Edge / Safari - 39.9 KB
- Build file w/ 100+ elements in it - 240 KB

Currently loading jQuery + Materialize.js is bigger then my polyfill and my build file is a load 1x and then all future loads are faster w/ less markup delivered (providing some context). If anyone wants to see what this looks like in different browsers, here's a Drupal 7 site delivering these things -- https://courses.openulmus.org/xapi/

Yes, lit-html is heading into territory that React is already having issues with, in regard to Drupal development experience. I hope you can see the larger point I'm making when I say that anything that implements the static template function of a Polymer 3 driven web component would satisfy that method and therefore the component. (highlighted for emphasis)

I can appreciate @btopro's real world experience here and @effulgentsia concern of attempting to solve the DX issue at the center of this issue. At this time there appear to be a number of js-enabled templating languages that are vying for developer's attention like HyperHTML: https://viperhtml.js.org/hyper.html

It's notable that the article you linked (in #68) that is intended to demonstrate that lit-html has a more cumbersome DX than JDX doesn't demonstrate a usage of lit-html, but rather it shows a usage of html literals. For code examples of lit-html, see: https://github.com/PolymerLabs/lit-html

Also note, the comparison and contrasting of lit-html vs HTML templates and JSX. My main take-aways from reading through it:
1. lit-html provides full access to JS variables without the need of additional parsing engines (in comparison to HTML Templates)
2. lit-html needs to do less work than JSX because it doesn't build up a Virtual DOM tree.

Postponing to simplify triage of the ideas queue on the component topic.

It would be helpful to highlight the needs addressed by this idea in the issue summary and add it to #3240805: [meta] Organize components-related ideas as well to consolidate all the different related issues.

Changed title to Lit as Polymer is a legacy project. It still works because of following the web platform standard but Lit is way faster, smaller, and the future.

Any progress on this?

Kind of actually. With Drupal 10.1's single directory components we're able to start building components that work within Drupal Core. Now we just need to demonstrate a component or set of components that provide value to the system. We're also able to compare and contrast different approaches to making components.

Here's a component I made with lit for reference: https://www.drupal.org/project/pokemon_card

@cosmicdreams
Thanks for the reply.
I have a question:Do we need to build web components specific to Drupal?
Wouldn't it be better to use existing components e.g. from Lit?

@pinkonomy - yes and no. It would probably be best to take some dumb components (design specific) and use them as the basis to wire into smart components (drupal specific). There are many out there but the two I think are the most well developed as far as providing reusable pieces that are within a specific design system they'd be:
- https://shoelace.style/
- https://github.com/material-components/material-web

Both are built on top of Lit and are very small as a result.

@cosmicdreams is correct that Drupal has a methodology for organizing and loading these assets.

@pinkonomy: I think this question goes back to the classification of components. I like to think of it as:

• display component: just frontend stuff, intakes variables prepared by the server
• layout components: components with slots, built to wrap other components
• data-driven components: components that are built to got fetch data from outside sources

Now, I suspect that either with web components / lit or not. The fact that we can componetize bits of markup and share them (like within a module or a theme) will help Drupal go a long way down the road to making it easier to interact with Drupal's from a template / component level. And whether the final component was written with vanilla / lit / whatever component library, the way we'd interact with it via twig will be the same. As a result, it would likely be a good idea to make each component be self contained.

We'll have to see.

One of the adventures I'd like to do before Drupalcon is to take a component library and see what it would take to convert it to SDC. A few I've looked at for that effort include:

• https://www.patternfly.org/v4/
• https://getbootstrap.com/docs/5.0/components/offcanvas/

Now I'll add shoelace