RFC: fight for simplicity with regards to Open Web Components project future

RFC: Buildless.md

Goal

1. Help the adoption of Going Buildless by frontend developers, regardless of frameworks or libraries they use.

2. Make the most valuable tools related to Going Buildless easy to discover, use and contribute to.

Overview

@open-wc has become an umbrella project which consists of lots of parts mixed in the same repo and docs site:

• tools:

  • es-dev-server
  • karma-esm
  • @mdjs/core
  • storybook-prebuilt (separate repo)
  • mdjs-viewer (separate repo)

• utilities:

  • building-utils
  • polyfills-loader
  • import-maps-generate
  • import-maps-resolve

• plugins:

  • rollup-plugin-html
  • rollup-plugin-polyfills-loader
  • storybook-addon-web-components-knob
  • storybook-addon-markdown-docs
  • webpack-index-html-plugin

• presets:

  • building-rollup
  • building-webpack

• testing helpers:

  • chai-a11y-axe
  • semantic-dom-diff
  • testing-helpers

• WC helpers:

  • dedupe-mixin
  • lit-helpers

• configs:

  • eslint-config
  • prettier-config
  • testing-karma-bs
  • testing-karma
  • testing

• recommendations:

  • testing-wallaby
  • deploying
  • IDE (VSCode)

• onboarding:

  • create
  • codelabs

• experiments:

  • scoped-elements

Problems

IMHO, the current situation has the following problems, that affect developer experience:

• navigation. I always struggle to find a link to ES dev server docs, due to complex navigation structure. And I'm already an experienced user familiar with the site. What about newbies who just discovered open-wc?

• piling up content. Things like ESLint, Prettier, VSCode or Wallaby are definitely useful for those who never tried them. However, these are also matter of personal preference and probably should be downplayed.

• contributing. The monorepo itself is kinda scary for certain users. It might be easier to maintain, but less clear how to contribute - find an issue, setup the environment locally, submit a PR, deal with CI.

• versioning. Because of Lerna, there are many releases that are version bumps only. That forces me as a user to look through CHANGELOG entries figuring out if there are valid reasons for me to upgrade.

• branding. The joke about WC has been so much repeatedly happening, and honestly now it's too annoying. When you reach out to external developers, their first impression really matters, and now it's a bit weird.

• positioning. Many tools are not specific to web components, and could be used by frameworks users. Unfortunately, there is a somewhat negative feeling about Web Components in certain communitites.

• walled garden. Despite the fact that developing with ES modules is becoming popular (e.g. Snowpack), the tools and libraries by open-wc are mostly used by web components (former Polymer) community.

Proposal

Let me make a suggestion that might tackle some of the problems and help to achieve goals:

• introduce Buildless as a separate brand and GitHub org.

• suggested slogans:

  • "build less, do more"
  • "start with index.html"
  • "you might not need build tools"
  • "forget about JS fatigue"

• move the following packages to separate repos under new org:

  • tools
  • utilities
  • plugins (except storybook-addon-web-components-knob)
  • presets

• create a new website (consider 11ty). These domains are free:

  • https://buildless.dev
  • https://buildless.org

• keep configs, recommendations, codelabs, WC helpers under Open WC

• refer to Buildless as a "sibling" project from https://open-wc.org

• invite other tools authors (Vue.js / Vite, Snowpack) to collaborate

Thoughts?

Quoting and fully agreeing with @thepassle

Imo open-wc should be all about getting started with web components, and making it easy for people to build web components or apps with web components. This includes guides/codelabs/examples, but also build/test/lint etc configurations. We've also discussed giving more advanced/in-depth guidance on building apps.

I truly do not want to see "how to use WC with Vue" or "how to use WC with React". I don't even think tools that are usable by other frameworks should even mention those other frameworks on open-wc. Those specific tools have their own documentation on how to use them with other frameworks. What is missing from most of those tool's sites are how to use them with standard web components. And that is where open-wc fills a gap.

@LarsDenBakker, I gather that https://github.com/modernweb-dev/web is the direction that this is headed? Could we get perhaps a broad overview/philosophy of how the @open-wc projects are going to get split between the two org repos? It's great to see this project maturing.