Lit & Friends Community Call #2

[justinfagnani]

Hi again Lit friends,

After the great turnout of our first Lit & Friends Community Call, we're very excited to announce our second Lit & Friends Community Call next Wednesday August 31 at two times: 9:30am PDT and 9:30pm PDT, on Google Meet!

Please join members of the Lit team to talk about all things Lit and web components.

Agenda

• The new Lit RFC process
• Community suggestions

We recently launched the Lit RFC process, and since we don't have any open RFCs yet we can't pull from that for this meeting's agenda. We can talk about the process itself, and then take community suggestions either in this discussion or live.

Please add agenda ideas below. Topics don't need to be limited to Lit, though they should be relevant. They may include web component standards, tooling such as Open WC, and more. We will prioritize existing open issues, pull requests, and discussions in the Lit repo, and address other topics time-permitting.

Info

Lit Community Call

We are scheduling two call times to try to reach the broadest global audience. Attend whichever call is best for you. We will intentionally try to many of the same topics in each time slot so you don't miss anything by attending at your convenient time.

• Americas / EMEA friendly time: Wednesday, August 31 · 9:30am – 10:30am PDT
• Asia-Pacific friendly time: Wednesday, August 31 · 9:30pm – 10:30pm PDT

Lit Community Call # 2 - Americas/EMEA

Wednesday, August 31 · 9:30 – 10:30am
Google Meet joining info
Video call link: https://meet.google.com/zpy-mdth-tzd
Or dial: ‪(US) +1 253-289-6804‬ PIN: ‪375 724 489 33‬#
More phone numbers: https://tel.meet/zpy-mdth-tzd?pin=2362376673442

Lit Community Call # 2 - APAC

Wednesday, August 31 · 9:30 – 10:30pm
Google Meet joining info
Video call link: https://meet.google.com/hee-doob-zue
Or dial: ‪(US) +1 253-289-6784‬ PIN: ‪612 304 035 20‬#
More phone numbers: https://tel.meet/hee-doob-zue?pin=7821705951092

Code of Conduct

This call is covered by our Code of Conduct

[syu93]

Very nice to see this coming again.
I'd like to suggest as topic : What are the best practices or recommendation for the usage of a CSS framework with Web Components ?

[augustjk]

Thanks everyone for joining us! Here are the notes from the Americas/EMEA call.

Agenda topics

• Labs development status, lifecycle (e.g. labs → deprecated, labs → graduate to core)
• CSS Frameworks with Web Components
• Advocating for Shadow DOM support 3P libraries (e.g. hotjar, testing-library)
• Update on SSR framework integrations
• Guidance on app concerns—did not get to due to time

Notes

Labs development status

• [Justin] We have pending task to update lit.dev labs page to document the lifecycle and status / confidence level for each package.
• [Justin] In general, Labs means "not sure", needs feedback / refinement. But overall, so far we feel good about almost all Labs packages.
• [Justin] Closer to graduation: React. Most speculative: Router.
• [Kevin] One of the goals for updating Labs page is to have a place beyond npm stats to gauge interest/feedback like github discussions thread.
• [Kevin] New Labs package can be proposed with RFC.
• [Justin] What signal would be helpful to graduate Labs package?
• [Christian24] Hearing that Lit team is excited about Context package is a good signal to community that it might be more likely to graduate. So "marketing" is a good signal back to the community on what to rely on.
• [Justin] Lit approach tends to be more decoupled/composable packages, which might differ from "framework in a box" approaches
• [Christian24] Not looking for a full package, but some things it does feel better coming from Lit team
• [Michael Warren] Does there need to be a Lit Labs?
• [Justin] It's very useful for the Lit team to get code "we know how to write" out to users and lower the bar for getting value to users sooner while evaluating the cost of committing to it as a full product.
• [Michael Warren] Could use the RFC process for e.g. "Promote xyz from Labs to GA"
• [Justin] Starting with SSR, will start putting Labs documentation onto lit.dev, that's a signal of maturity

CSS Frameworks

• [Herve Tutuaku] How can we put out information to the community on using CSS frameworks (e.g. Tailwind)?
• [Christian24] Probably don't want an entire e.g. bootstrap stylesheet for a single component. Tailwind is going in a direction of more modular styles. Does this work for Lit?
• [Herve Tutuaku] Would need some tooling (e.g. parser integration) support for making this work with Lit.
• [Michael Warren] Have experience combining Tailwind CSS at build time with Web Component. But maybe open-styleable SR direction would be a more natural fit.
• [Samuel Allen] In LESS, "extend reference" allowed "importing" chunks of classes/selectors into individual sheets.
• [Justin] If you're in the Lit world, there are solutions to these problems (e.g. using css exports JS module system); the bigger questions are around adapting other systems that try to solve similar problems into Lit. SASS mixins don't work great because they essential copy (rather than use-by-reference).
• [Justin] Aside: We're working on launching an "articles" feature on lit.dev, which would be a good place to bring more voices to describe these types of integrations / approaches, including e.g. "guest posts"
• [Elliott] With CSS import assertions coming to the browser + deep integration with adopted stylesheets. If the non-WC ecosystem like React starts also taking advantage of this, it might start moving the ball towards platform-based style modularity.
• [Justin] Aside: @import syntax in CSS modules needs resolution.
• [Justin] Also: we should open a discussion thread if there's not one already to continue the discussion and collect the articles shared on the call so far!
• [Michael Warren] Most users probably use build systems to turn .css files into css...; since that is not prominent on the site, it might come across as a negative for the library.
• [Justin] Yes, but in tension with making the onboarding/examples simpler.
• [Herve Tutuaku] In comparison with Vuejs, the documentation is clear about first-class but not required features that users can opt-in to.
• [Elliott] Great use of articles to put more opinion.

Advocating for Shadow DOM support in 3P libraries

• [Benny Powers] How can we organize to advocate for Shadow DOM support in 3P libraries
• [Christian24] If we had a collective effort, we could divide & conquer.
• [Kevin] custom-elements-everywhere was a good community effort to push that forward. Maybe shadow-dom-everywhere?
• [Justin] Similar issue for ES Modules. Considered a repo of test cases where we collaborate on filing issues/repos and working towards getting them resolved.
• [Justin] Could vend helpers for common solutions that we could point 3P libraries at to help them support shadow DOM (like deep query selector)
• [Kevin] Like the idea of a website & repo for issues / repro cases

Update on SSR framework integrations

• [Al] SSR is generally a high priority for the team. Next big milestone is integration with Next.js.
• [Al] Other recent related advancement is ability to load Lit modules in node.js without errors, to at least unblock non-deep WC rendering in 3P frameworks.
• [Justin] To the audience: What other SSR integrations are important?
• [Michael Warren] +1 for Next.js as high-priority
• [Herve] Vuejs/Nuxt seems it should be a next priority.
• [Kevin] Plug for the test helpers, which is a plugin into @web/test-runner to validate that components are SSR compatible. lit.dev docs section on SSR are also in-flight.
• [Justin] Re: next.js configuration, we have some options for adding support.
• [Michael Warren] It would be helpful if the SSR docs give guidance on where to move e.g. DOM access to be compatible.
• [Al] Could consider having the dom-shim provide some dev-mode warnings to provide guidance
• [Justin] Will likely also have an isSSR flag that will be useful [labs/ssr] A way for client code to check if running in server (isSsr) #3158

Discord

• [Al] Lit team is considering moving the Lit & Friends Slack community from Slack to Discord
• [Herve] Might even increase traction, due to Discord popularity
• [Al] Slack feels like a higher barrier to join & commit to a new "account" vs. just adding a Discord channel

Closing

• [Justin] Re: Scheduling, will try a 9:30PM PDT call to be open for APAC region, everyone also welcome.
• [Elliott] Just launched lit.dev "edit this page" feature!
• [Justin] How about the cadence for Community Calls?
• [Michael, Benny, Herve] +1 Quarterly
• [Justin] Let's be sure to continue these discussions in … https://github.com/lit/lit/discussions

Resources from chat:

• Articles on using Tailwind CSS with Lit
  • https://dev.to/43081j/using-tailwind-at-build-time-with-web-components-1bhm
  • https://dev.to/michaelwarren1106/lit-web-components-tailwindcss-styles-at-build-time-44ab
• Tailwind CSS to semantic CSS converter: https://www.vanillabreeze.dev/
• LESS reference
  • https://lesscss.org/features/#import-atrules-feature-reference
  • https://medium.com/@dehuszar/semantic-remapping-with-css-pre-processors-906ba1a9910c
• Lit SSR Testing utility: https://www.npmjs.com/package/@lit-labs/testing
• Lit SSR Eleventy Plugin: https://www.npmjs.com/package/@lit-labs/eleventy-plugin-lit

[p-ob]

Advocating for Shadow DOM support 3P libraries

Oh huge +1 on this. There are quite a few tools my organization uses that have issues with shadow DOM, and not all have been issues we've been able to work around.

custom-elements-everywhere was a good community effort to push that forward. Maybe shadow-dom-everywhere?

Love this idea!

[43081j]

FYI this is an updated blog post of the one you linked from me:
https://dev.to/43081j/using-tailwind-postcss-and-stylelint-with-lit-element-projects-2hb9

as there's now postcss-lit which allows postcss/stylelint/tailwind to understand templates in JS etc.

[Christian24]

Is anyone taking action on making shadow-dom-everywhere a reality? Maybe we should start compiling a list in an issue here?

[kevinpschaaf]

Below are notes from Lit Community Call # 2 - APAC.

Notes

Lit docs/tutorial

• [Steven Traversi] Experience ramping up new dev on Lit has been overall really good. Feedback on docs/onboarding: there is a lot of advanced topics that he had to direct the new dev to skip over. Built https://lit.how/ to try and document a "minimal what you need to know" flow through key concepts.
• [Jared White] An intro to Lit might also benefit from a cheat-sheet on the platform concepts.
• [Kevin] Noting similarity to tutorials, but the "exploded" format of being able to scroll through all the "steps" makes it more of a "cheat sheet"
• [Steven] Modeled after https://learncssgrid.com/
• [Jared] Also similar: https://cssreference.io/flexbox/
• [Justin] Having a variety of "tones" for articles/documentation from the community is nice.

Advocacy

• [Jared] Often heard misunderstanding: "Lit looks cool, but you have to use Lit to use their components"
• [Justin/Al] Maybe "works everywhere" needs to be more prominent on the landing page?
• [Steven] Average developer doesn't know what the word "web component" means. But are surprised (and excited!) to learn you can extend HTML.

CSS frameworks

• (Tailwind - lots of light discussion)
• [Justin] Would be cool to build a SASS-to-JS compiler, that could turn mixins into functions that can dynamically generate e.g. lit CSSResults