8 ms·

GitHub's Web Component Collection

76 points by mgrayson 6y ago

11235813213455 6y ago
quick demo of some I find interesting https://codesandbox.io/s/gh-web-components-zqff3?file=/src/index.js https://codesandbox.io/s/gh-web-components-zqff3?file=/src/i...
capableweb 6y ago
Why in holy hell is every component in it's own repository and NPM module?! We have gone too far, and no one is stopping us to say "no, what are you doing?". Every module now have independent files for everything except the source code. So things like README, package.json, configuration and everything else, is duplicated 16 different repositories. How are you suppose to maintain that crap? I'm sorry, but if GitHub is supposedly a leader in software companies and this is how modern development looks, then I want to get off this wild ride. I'll stick to my simple tools instead. No wonder that we're seeing bunch of beginners to web development writing about "JS fatigue" if this is what they are looking up to and seeing as how you "de facto" do JS today. I hope some of them manage to see past it at least
- d4mi3n 6y ago
  While I agree NPM bloat is a problem, this doesn't seem like too unreasonable an approach to publishing a la cart libs like these. I haven't looked closely at the repo itself, but code generation through build/release scripts is commonly used to manage the issues you describe. EDIT: Unless I read the source code wrongly, it seems like they actually used the umbrella repo to collect docs and links to all the other components which is the opposite of what I thought was going on here.
  - capableweb 6y ago
    > this doesn't seem like too unreasonable an approach to publishing a la cart libs like these Yes! Yes it is unreasonable. Each component is less than 10KB is source code, the majority of the repository is scaffolding and configuration, which is duplicated for each repository/component. Instead of just having one repository with all the components. I'd understand the approach if you were dealing with MB big components. But these are not that... > code generation through build/release scripts is commonly used to manage the issues you describe Yeah, of course you can always fight bloat/complexity by adding more bloat/complexity, but normally we (developers) only do that when we're lacking time. If we do have time, we try to get rid of it instead, something the GitHub developers definitely should have time for by now.
    - emteycz 6y ago
      I think it's done to decouple versions. Imagine component A updating its major, causing the whole suite to update its major. But that higher major might also have newer versions of components B and C, but you don't want to upgrade your usage of these. There are cohesive component kits versioned as whole package, but I never liked that to be frank. I think this is good evolution, just messy because it's new. I'm sure better tooling will eventually emerge.
      - capableweb 6y ago
        You know what you could also do? Don't break backwards compatibility. I know it sounds strange (if you're coming from modern JS development) but many ecosystems actually pull that off, like the entirety of Windows, or 99% of the ecosystem in Clojure/Script. Then if you have over the years collected a bunch of incompatible changes that you would like to do, you create a new library with a new name, and do all the changes there. Now you have the first library absolutely never breaking compatibility, and the second one for your "I absolutely must change the API interface here" changes. There are some good ideas around versioning here as well (by Rich Hickey): https://www.youtube.com/watch?v=oyLBGkS5ICk https://www.youtube.com/watch?v=oyLBGkS5ICk > just messy because it's new. I'm sure better tooling will eventually emerge. I don't understand this. Either a new solution is better and we try to use that, or the solution is worse and we should avoid it. If it's worse, why should we build better tooling when we can just use a good solution from the get-go?
        emteycz 6y ago
        > I don't understand this. Either a new solution is better and we try to use that From my perspective coming from my experience both as a component kit developer and an application developer using that kit, having one component per versioned package is good. That we live in a world where larger packages are prevalent and thus tooling forces a developer to duplicate configuration everywhere is an unfortunate coincidence that doesn't take away the benefits of separating the project into one versioned package per component. Also consider that it might not even be because of the development tooling, but rather VCS or CI/CD related.
  - no_wizard 6y ago
    I think this should have really been a monorepo myself. Would allow them to do some code sharing in that respect as appropriate. Though, monorepos aren't everyone's 'taste' and I can understand why standalone repositories make some sense in the mental model where you want everything de-coupled and easy to distinguish
    - thirsteh 6y ago
      I suppose it makes sense if you're issuing semantically versioned releases of each module and you want the GitHub releases to match, but the trend of turning everything into its own module until there's nothing left can be very frustrating. This seems very common in JavaScript and Rust. Rust at least compensates for it in its generated docs. PureScript OTOH... Sometimes modules are literally just one type or one function, and the docs don't consolidate them. Whyyyyyyyy.
- qbasic_forever 6y ago
  The NPM world is putting a lot of weight behind monorepos and have tooling like lerna and yarn workspaces (also now in NPM 7) to make working with multiple packages in one or many repos easy. They're learning the lessons that folks like Google did with monorepos being much easier to manage and change sets of related projects (i.e. atomic commits that update everything at once). As far as why break every component up into different packages, that's a nice easy optimization for end-users. If you only want to use one of these components you just link to it in your page and you're done. No need to setup a complex bundler with tree-shaking etc. to remove all the other components you aren't using. Remember with JS & HTML every import is paying a cost in time and space for your endusers so it's critical to prune unused or unnecessary code. IMHO you need to spend a few months getting into frontend development. These kind of repos and organizations will make a lot more sense when you see and deal with the problems firsthand. You look pretty silly calling it 'crap' and no one who reads this is going to take you seriously...
- ravenstine 6y ago
  Are we really going to have a debate over individual repos versus monorepos in 2021? Having a bunch of individual repos and NPM modules is quite the norm, has always been, and will continue to be. Why are you applying a different standard for web components? It's like web components never get a break from anyone. If it's called a "web component", there must be something wrong with it.
  - rektide 6y ago
    This is an indignity! An outrage! An affront! /s There's different ways to do things. Some people have a hard time with that.
- serverholic 6y ago
  Yeah this is nuts.
- 40four 6y ago
  I don’t really get the argument. You are assuming this is supposed to be a library. Apparently that’s not what they intended here. Why assume everyone would want to bring in the whole collection as a single library. What if I only want the autocomplete & the file attachment elements. I think it is rather nice to ‘npm install’ them standalone. I think this use case would be way more common actually, than to find yourself in a situation where you actually need every element in the collection. I think your anger towards ‘complex’ JS tooling is skewing your initial reaction. Web components don’t even fall into that ‘complex tooling’ category. It’s literally dependency free, vanilla JavaScript. Heck, copy and paste them from the repo into your project if you don’t want to use a package manager. I’m glad this exists, as I’m excited for the vanilla web components ecosystem to mature. I’m also glad I can use these components ‘a la carte’, and not bring in 14 other components I don’t need. Edit: looking at the source closer, it’s actually Typescript :) not JS, but that doesn’t really change my point.
- throwaway4good 6y ago
  It is the micro library idea. The idea that one library should do one thing and one thing only. A library pr. book if you will. We hit the peak of the micro library bubble with the left-pad library in 2016. This may be some kind of dead cat bounce.
aphextron 6y ago
This is how you do web components. Tightly scoped, no framework dependencies, no stylesheets, made with aria accessibility in mind. Good stuff.
- deleted 6y ago
  [deleted]
- 40four 6y ago
  Yes these look excellent, will have to try them out soon! You’re right, you can tell accessibility and compatibility were considered here. I haven’t looked at them all yet, but I noticed the autocomplete element uses XmlHttpRequest versus Fetch.
  - no_wizard 6y ago
    you get better portability that way. They still serve corporate markets where IE 11 access is a requirement.
    - 40four 6y ago
      Yeah for sure. I appreciate that they chose that route for compatibility. I know I don’t in my hobby projects :)
- inbx0 6y ago
  Some of them have stylesheets, for example https://github.com/github/image-crop-element/blob/main/src/index.css https://github.com/github/image-crop-element/blob/main/src/i...
- rektide 6y ago
  Personally, I'd really like to see the unmolested, with-dependencies versions[1]. This version is VERY easy to ship and adopt. But in my mind, these components hide how the sausage is made! Many were built with a library (Catalyst[2]), but the tools were obfuscated out in these end products. There's a huge amount to be said for these web components. We need more models like this. But I also think there's an opportunity lost here, to teach, to inform, to help others learn how to build components, using the tech Github actually used to develop them. [1] https://news.ycombinator.com/item?id=26439167 https://news.ycombinator.com/item?id=26439167 [2] https://github.com/github/catalyst https://github.com/github/catalyst
tmcw 6y ago
On my last project - which was mostly a Rails app with Stimulus, but Web Components for the parts where they fit, we exclusively used GitHub's components. They're all really solid and well-engineered, and you have the guarantee that they're actually used on GitHub, in production.
disgrunt 6y ago
`GitHub historically has been top notch from an accessibility standpoint. Full marks there. But the recent trend to start hiding things in the GitHub UI is driving me up the wall. They're hiding the files in a repo by default, they're burying the SSH cloning info under a "Download" button (huh?), good luck finding the branch listing link. GitHub is not a UI that needs to be "simpler", it needs to be functional given its audience. Edit: Clarifying which cloning info I'm referring to.
- quink 6y ago
  > they're burying the repo cloning info I didn’t know websites could hide the address bar.
  - rustyminnow 6y ago
    If you have 2fa turned on (which is really a good idea and enforced in a lot of orgs) you can't clone private repos or push changes with the https protocol - you need the ssh/git url
    - quink 6y ago
      Yes you can. Personal access tokens.
  - edoceo 6y ago
    I think they meant the clone links in the UI which used to show the https and ssh based repo links with copy button.
warpech 6y ago
Github is one of the strong believers in W3C Web Components. Another one is Salesforce: https://lwc.dev/ https://lwc.dev/
- superkuh 6y ago
  Funny how you call it W3C Web Components when W3C has been marginalized and pushed out of the flow of things by the corporate whatwg. Web Components is not a web standard so much as it is a google standard that other mega-corps have picked up because it's good for mega-corps. It is not good for human persons or the existing web of documents. It's only good for the megacorps' intended not-web of applications. So this is how the web dies...with thunderous applause.
  - warpech 6y ago
    I don't know why you are down voted, because it's an interesting point. I often use the term W3c Web Components to differentiate from JavaScript components that use other APIs. I know that Web Components are a recurring topic in W3C meeting agendas. I am not aware about parallel fast track discussions in WHATWG, but that makes sense. I think there are already two Webs (simple and complex) and Web Components are actually a good way to create progressively enhanced websites that work well in both.
  - 40four 6y ago
    Can you elaborate on how web components are ‘not a web standard so much as it is a Google standard’? Every major browser supports web components at this point. Purportedly it’s a ‘Google’ standard & Mozilla & Microsoft are only supporting it because it serves them as mega corps? Why do you consider it ‘not good for humans or the existing web’? Anyone and everyone who wants to can write web components, and they will work in all major browsers. No dependencies, No libraries, no 3rd party APIs. Just vanilla HTML, JS & CSS. To me that seems like a great advance for regular humans. We can develop ‘complex’ JS components with existing web tech. No build step, no learning 3rd party libraries.
    - superkuh 6y ago
tima101 6y ago
Wow, I like it. I wish I saw this library sooner. I may replace Material-UI library in my current project. To maintainers, this example link https://github.github.io/time-elements/examples/ https://github.github.io/time-elements/examples/ is missing from https://github.com/github/time-elements https://github.com/github/time-elements page
- koddsson 6y ago
  Thanks! I just set it as the repo URL.
tzury 6y ago
This is a simple ES6 question. Why would folks use const inside a loop? I mean, isn't const means a constant that is not going to be changed? When inside a loop, it is changed every iteration, ain't it? https://github.com/github/auto-check-element/blob/main/examples/index.html#L38 https://github.com/github/auto-check-element/blob/main/examp... Can someone enlight me? I would rather use `let`.
- dsego 6y ago
  It doesn't change every iteration, it is declared anew for every iteration.
- capableweb 6y ago
  const isn't actually a constant as you probably know it. It's just that the reference is constant, not that the value is constant. Besides the point, but I guess good to clarify. And yeah, you can use let/const, doesn't really matter except for performance optimizations, which depends on browsers and what patches they deployed that day anyways. Effectively, the difference is +-0. `let` you usually use to signal that the variable will change in the future, within the scope. `const` usually signals the opposite. As the variable defined as a `const` here does not change within that scope (each loop is it's own scope), I think it's appropriate to use a `const` here.
- vulcan01 6y ago
  The value is constant for each iteration: they don't want formInput to change on line 43, for example.
- earthboundkid 6y ago
  Basically all uses of const in JavaScript are pointless. I have asked many times for someone to show me an example of a bug that shipped that would have been prevented by const as it exists in JS. I'm still waiting. The only time I can think of where const is useful is in Vue 3, it lets you ensure that you remember to change myref.value instead of trying to reassign myref by mistake. But it's just sort of a coincidental side effect of the fact that Vue reactivity has to work by mutating properties and not rebinding names. Plus Evan You is experimenting with a syntax transform to make it not necessary to use .value anyway.
btbuildem 6y ago
Aside from npm bloat and the dependencies that come with that, this is pretty neat. Nice clean components, framework agnostic, no opinion on style. A good example!
rajangdavis 6y ago
For everyone complaining about NPM bloat, the dependencies for these packages are for spec tests or include other Github components from the above repo...
rektide 6y ago
I was hoping to see a couple use Catalyst[1] but checked a couple & appears not so. [1] https://github.com/github/catalyst https://github.com/github/catalyst
- Keithamus 6y ago
  We use Catalyst for internal components on GitHub.com, but we actually convert them to plain Web Components when we open source them, so that many projects (even those without catalyst) can benefit.
  - rektide 6y ago
    I'd like to gently encourage that perhaps the Catalyst forms be published too. I feel like we're getting the not-as-understandable, downcompiled, kiddie-script version of the real thing via this process, and that while open source, we're not getting an experience with how the sausage gets made. Also it'd be lovely for those who are going in on Catalyst to have some well written robust components to either imitate or extend. And if multiple components are leveraging the shared Catalyst library, the marginal size of using a new component ought be significantly less. Even without, thanks! Leaving Catalyst version available does seem like an excellent learning opportunity for all, & have some great technical upsides, but it's great that these components are available.
serverholic 6y ago
First microservices and now microlibraries. Personally, I'd hate to work on these components. Need to make a sweeping change? Time to create 16 pull requests.
DanielKehoe 6y ago
Richard MacManus did a recent interview in The New Stack with the team leads at GitHub and Salesforce about "How Web Components Are Used at GitHub and Salesforce" [0]. Small, narrowly-scoped repos (as opposed to big library monorepos) make sense for web components otherwise you add bloat for build tools with tree shaking to get rid of components that you don't need. I've been writing in The Stackless Newsletter [1] about using web components with ES6 modules and module CDNs (JSPM and Skypack) for development without frameworks or build tools. It's sweet. [0] https://thenewstack.io/how-web-components-are-used-at-github-and-salesforce/ https://thenewstack.io/how-web-components-are-used-at-github... [1] https://stackless.community/ https://stackless.community/
nojvek 6y ago
I wish they had screenshots for each component. My foray into webcomponents was at mixpanel and I helped build the component library at https://design.mixpanel.com https://design.mixpanel.com Before I was skeptic on webcomponents but using it on production for many years, it’s a great layer of abstraction and works well with native dom and html. All major browsers now support it without polyfills. A lightweight virtual dom library like snabbdom + webcomponents is a good match. Component driven development is the way to go and web components is a tool that every web dev should keep in their belt.
- Keithamus 6y ago
  That’s some good feedback! We’ll look into adding screenshots. As most of the components have no CSS (the ones that do are mostly layout, no theming) - they don’t look great, they are mostly useful for their behaviours.
fulafel 6y ago
Do these work in Safari without polyfill? The "Browsers" section is ambiguous.

76 points by mgrayson 6y ago

quick demo of some I find interesting https://codesandbox.io/s/gh-web-components-zqff3?file=/src/index.js https://codesandbox.io/s/gh-web-components-zqff3?file=/src/i...

capableweb 6y ago

Why in holy hell is every component in it's own repository and NPM module?! We have gone too far, and no one is stopping us to say "no, what are you doing?". Every module now have independent files for everything except the source code. So things like README, package.json, configuration and everything else, is duplicated 16 different repositories. How are you suppose to maintain that crap? I'm sorry, but if GitHub is supposedly a leader in software companies and this is how modern development looks, then I want to get off this wild ride. I'll stick to my simple tools instead. No wonder that we're seeing bunch of beginners to web development writing about "JS fatigue" if this is what they are looking up to and seeing as how you "de facto" do JS today. I hope some of them manage to see past it at least

d4mi3n 6y ago
While I agree NPM bloat is a problem, this doesn't seem like too unreasonable an approach to publishing a la cart libs like these. I haven't looked closely at the repo itself, but code generation through build/release scripts is commonly used to manage the issues you describe. EDIT: Unless I read the source code wrongly, it seems like they actually used the umbrella repo to collect docs and links to all the other components which is the opposite of what I thought was going on here.
- capableweb 6y ago
  > this doesn't seem like too unreasonable an approach to publishing a la cart libs like these Yes! Yes it is unreasonable. Each component is less than 10KB is source code, the majority of the repository is scaffolding and configuration, which is duplicated for each repository/component. Instead of just having one repository with all the components. I'd understand the approach if you were dealing with MB big components. But these are not that... > code generation through build/release scripts is commonly used to manage the issues you describe Yeah, of course you can always fight bloat/complexity by adding more bloat/complexity, but normally we (developers) only do that when we're lacking time. If we do have time, we try to get rid of it instead, something the GitHub developers definitely should have time for by now.
  - emteycz 6y ago
    I think it's done to decouple versions. Imagine component A updating its major, causing the whole suite to update its major. But that higher major might also have newer versions of components B and C, but you don't want to upgrade your usage of these. There are cohesive component kits versioned as whole package, but I never liked that to be frank. I think this is good evolution, just messy because it's new. I'm sure better tooling will eventually emerge.
    - capableweb 6y ago
      You know what you could also do? Don't break backwards compatibility. I know it sounds strange (if you're coming from modern JS development) but many ecosystems actually pull that off, like the entirety of Windows, or 99% of the ecosystem in Clojure/Script. Then if you have over the years collected a bunch of incompatible changes that you would like to do, you create a new library with a new name, and do all the changes there. Now you have the first library absolutely never breaking compatibility, and the second one for your "I absolutely must change the API interface here" changes. There are some good ideas around versioning here as well (by Rich Hickey): https://www.youtube.com/watch?v=oyLBGkS5ICk https://www.youtube.com/watch?v=oyLBGkS5ICk > just messy because it's new. I'm sure better tooling will eventually emerge. I don't understand this. Either a new solution is better and we try to use that, or the solution is worse and we should avoid it. If it's worse, why should we build better tooling when we can just use a good solution from the get-go?
      - emteycz 6y ago
        > I don't understand this. Either a new solution is better and we try to use that From my perspective coming from my experience both as a component kit developer and an application developer using that kit, having one component per versioned package is good. That we live in a world where larger packages are prevalent and thus tooling forces a developer to duplicate configuration everywhere is an unfortunate coincidence that doesn't take away the benefits of separating the project into one versioned package per component. Also consider that it might not even be because of the development tooling, but rather VCS or CI/CD related.
- no_wizard 6y ago
  I think this should have really been a monorepo myself. Would allow them to do some code sharing in that respect as appropriate. Though, monorepos aren't everyone's 'taste' and I can understand why standalone repositories make some sense in the mental model where you want everything de-coupled and easy to distinguish
  - thirsteh 6y ago
    I suppose it makes sense if you're issuing semantically versioned releases of each module and you want the GitHub releases to match, but the trend of turning everything into its own module until there's nothing left can be very frustrating. This seems very common in JavaScript and Rust. Rust at least compensates for it in its generated docs. PureScript OTOH... Sometimes modules are literally just one type or one function, and the docs don't consolidate them. Whyyyyyyyy.
qbasic_forever 6y ago
The NPM world is putting a lot of weight behind monorepos and have tooling like lerna and yarn workspaces (also now in NPM 7) to make working with multiple packages in one or many repos easy. They're learning the lessons that folks like Google did with monorepos being much easier to manage and change sets of related projects (i.e. atomic commits that update everything at once). As far as why break every component up into different packages, that's a nice easy optimization for end-users. If you only want to use one of these components you just link to it in your page and you're done. No need to setup a complex bundler with tree-shaking etc. to remove all the other components you aren't using. Remember with JS & HTML every import is paying a cost in time and space for your endusers so it's critical to prune unused or unnecessary code. IMHO you need to spend a few months getting into frontend development. These kind of repos and organizations will make a lot more sense when you see and deal with the problems firsthand. You look pretty silly calling it 'crap' and no one who reads this is going to take you seriously...
ravenstine 6y ago
Are we really going to have a debate over individual repos versus monorepos in 2021? Having a bunch of individual repos and NPM modules is quite the norm, has always been, and will continue to be. Why are you applying a different standard for web components? It's like web components never get a break from anyone. If it's called a "web component", there must be something wrong with it.
- rektide 6y ago
  This is an indignity! An outrage! An affront! /s There's different ways to do things. Some people have a hard time with that.
serverholic 6y ago
Yeah this is nuts.
40four 6y ago
I don’t really get the argument. You are assuming this is supposed to be a library. Apparently that’s not what they intended here. Why assume everyone would want to bring in the whole collection as a single library. What if I only want the autocomplete & the file attachment elements. I think it is rather nice to ‘npm install’ them standalone. I think this use case would be way more common actually, than to find yourself in a situation where you actually need every element in the collection. I think your anger towards ‘complex’ JS tooling is skewing your initial reaction. Web components don’t even fall into that ‘complex tooling’ category. It’s literally dependency free, vanilla JavaScript. Heck, copy and paste them from the repo into your project if you don’t want to use a package manager. I’m glad this exists, as I’m excited for the vanilla web components ecosystem to mature. I’m also glad I can use these components ‘a la carte’, and not bring in 14 other components I don’t need. Edit: looking at the source closer, it’s actually Typescript :) not JS, but that doesn’t really change my point.
throwaway4good 6y ago
It is the micro library idea. The idea that one library should do one thing and one thing only. A library pr. book if you will. We hit the peak of the micro library bubble with the left-pad library in 2016. This may be some kind of dead cat bounce.

aphextron 6y ago

This is how you do web components. Tightly scoped, no framework dependencies, no stylesheets, made with aria accessibility in mind. Good stuff.

deleted 6y ago
[deleted]
40four 6y ago
Yes these look excellent, will have to try them out soon! You’re right, you can tell accessibility and compatibility were considered here. I haven’t looked at them all yet, but I noticed the autocomplete element uses XmlHttpRequest versus Fetch.
- no_wizard 6y ago
  you get better portability that way. They still serve corporate markets where IE 11 access is a requirement.
  - 40four 6y ago
    Yeah for sure. I appreciate that they chose that route for compatibility. I know I don’t in my hobby projects :)
inbx0 6y ago
Some of them have stylesheets, for example https://github.com/github/image-crop-element/blob/main/src/index.css https://github.com/github/image-crop-element/blob/main/src/i...
rektide 6y ago
Personally, I'd really like to see the unmolested, with-dependencies versions[1]. This version is VERY easy to ship and adopt. But in my mind, these components hide how the sausage is made! Many were built with a library (Catalyst[2]), but the tools were obfuscated out in these end products. There's a huge amount to be said for these web components. We need more models like this. But I also think there's an opportunity lost here, to teach, to inform, to help others learn how to build components, using the tech Github actually used to develop them. [1] https://news.ycombinator.com/item?id=26439167 https://news.ycombinator.com/item?id=26439167 [2] https://github.com/github/catalyst https://github.com/github/catalyst

tmcw 6y ago

On my last project - which was mostly a Rails app with Stimulus, but Web Components for the parts where they fit, we exclusively used GitHub's components. They're all really solid and well-engineered, and you have the guarantee that they're actually used on GitHub, in production.

disgrunt 6y ago

`GitHub historically has been top notch from an accessibility standpoint. Full marks there. But the recent trend to start hiding things in the GitHub UI is driving me up the wall. They're hiding the files in a repo by default, they're burying the SSH cloning info under a "Download" button (huh?), good luck finding the branch listing link. GitHub is not a UI that needs to be "simpler", it needs to be functional given its audience. Edit: Clarifying which cloning info I'm referring to.

quink 6y ago
> they're burying the repo cloning info I didn’t know websites could hide the address bar.
- rustyminnow 6y ago
  If you have 2fa turned on (which is really a good idea and enforced in a lot of orgs) you can't clone private repos or push changes with the https protocol - you need the ssh/git url
  - quink 6y ago
    Yes you can. Personal access tokens.
- edoceo 6y ago
  I think they meant the clone links in the UI which used to show the https and ssh based repo links with copy button.

warpech 6y ago

Github is one of the strong believers in W3C Web Components. Another one is Salesforce: https://lwc.dev/ https://lwc.dev/

superkuh 6y ago
Funny how you call it W3C Web Components when W3C has been marginalized and pushed out of the flow of things by the corporate whatwg. Web Components is not a web standard so much as it is a google standard that other mega-corps have picked up because it's good for mega-corps. It is not good for human persons or the existing web of documents. It's only good for the megacorps' intended not-web of applications. So this is how the web dies...with thunderous applause.
- warpech 6y ago
  I don't know why you are down voted, because it's an interesting point. I often use the term W3c Web Components to differentiate from JavaScript components that use other APIs. I know that Web Components are a recurring topic in W3C meeting agendas. I am not aware about parallel fast track discussions in WHATWG, but that makes sense. I think there are already two Webs (simple and complex) and Web Components are actually a good way to create progressively enhanced websites that work well in both.
- 40four 6y ago
  Can you elaborate on how web components are ‘not a web standard so much as it is a Google standard’? Every major browser supports web components at this point. Purportedly it’s a ‘Google’ standard & Mozilla & Microsoft are only supporting it because it serves them as mega corps? Why do you consider it ‘not good for humans or the existing web’? Anyone and everyone who wants to can write web components, and they will work in all major browsers. No dependencies, No libraries, no 3rd party APIs. Just vanilla HTML, JS & CSS. To me that seems like a great advance for regular humans. We can develop ‘complex’ JS components with existing web tech. No build step, no learning 3rd party libraries.
  - superkuh 6y ago

tima101 6y ago

Wow, I like it. I wish I saw this library sooner. I may replace Material-UI library in my current project. To maintainers, this example link https://github.github.io/time-elements/examples/ https://github.github.io/time-elements/examples/ is missing from https://github.com/github/time-elements https://github.com/github/time-elements page

koddsson 6y ago
Thanks! I just set it as the repo URL.

tzury 6y ago

This is a simple ES6 question. Why would folks use const inside a loop? I mean, isn't const means a constant that is not going to be changed? When inside a loop, it is changed every iteration, ain't it? https://github.com/github/auto-check-element/blob/main/examples/index.html#L38 https://github.com/github/auto-check-element/blob/main/examp... Can someone enlight me? I would rather use `let`.

dsego 6y ago
It doesn't change every iteration, it is declared anew for every iteration.
capableweb 6y ago
const isn't actually a constant as you probably know it. It's just that the reference is constant, not that the value is constant. Besides the point, but I guess good to clarify. And yeah, you can use let/const, doesn't really matter except for performance optimizations, which depends on browsers and what patches they deployed that day anyways. Effectively, the difference is +-0. `let` you usually use to signal that the variable will change in the future, within the scope. `const` usually signals the opposite. As the variable defined as a `const` here does not change within that scope (each loop is it's own scope), I think it's appropriate to use a `const` here.
vulcan01 6y ago
The value is constant for each iteration: they don't want formInput to change on line 43, for example.
earthboundkid 6y ago
Basically all uses of const in JavaScript are pointless. I have asked many times for someone to show me an example of a bug that shipped that would have been prevented by const as it exists in JS. I'm still waiting. The only time I can think of where const is useful is in Vue 3, it lets you ensure that you remember to change myref.value instead of trying to reassign myref by mistake. But it's just sort of a coincidental side effect of the fact that Vue reactivity has to work by mutating properties and not rebinding names. Plus Evan You is experimenting with a syntax transform to make it not necessary to use .value anyway.

btbuildem 6y ago

Aside from npm bloat and the dependencies that come with that, this is pretty neat. Nice clean components, framework agnostic, no opinion on style. A good example!

rajangdavis 6y ago

For everyone complaining about NPM bloat, the dependencies for these packages are for spec tests or include other Github components from the above repo...

rektide 6y ago

I was hoping to see a couple use Catalyst[1] but checked a couple & appears not so. [1] https://github.com/github/catalyst https://github.com/github/catalyst

Keithamus 6y ago
We use Catalyst for internal components on GitHub.com, but we actually convert them to plain Web Components when we open source them, so that many projects (even those without catalyst) can benefit.
- rektide 6y ago
  I'd like to gently encourage that perhaps the Catalyst forms be published too. I feel like we're getting the not-as-understandable, downcompiled, kiddie-script version of the real thing via this process, and that while open source, we're not getting an experience with how the sausage gets made. Also it'd be lovely for those who are going in on Catalyst to have some well written robust components to either imitate or extend. And if multiple components are leveraging the shared Catalyst library, the marginal size of using a new component ought be significantly less. Even without, thanks! Leaving Catalyst version available does seem like an excellent learning opportunity for all, & have some great technical upsides, but it's great that these components are available.

serverholic 6y ago

First microservices and now microlibraries. Personally, I'd hate to work on these components. Need to make a sweeping change? Time to create 16 pull requests.

DanielKehoe 6y ago

Richard MacManus did a recent interview in The New Stack with the team leads at GitHub and Salesforce about "How Web Components Are Used at GitHub and Salesforce" [0]. Small, narrowly-scoped repos (as opposed to big library monorepos) make sense for web components otherwise you add bloat for build tools with tree shaking to get rid of components that you don't need. I've been writing in The Stackless Newsletter [1] about using web components with ES6 modules and module CDNs (JSPM and Skypack) for development without frameworks or build tools. It's sweet. [0] https://thenewstack.io/how-web-components-are-used-at-github-and-salesforce/ https://thenewstack.io/how-web-components-are-used-at-github... [1] https://stackless.community/ https://stackless.community/

nojvek 6y ago

I wish they had screenshots for each component. My foray into webcomponents was at mixpanel and I helped build the component library at https://design.mixpanel.com https://design.mixpanel.com Before I was skeptic on webcomponents but using it on production for many years, it’s a great layer of abstraction and works well with native dom and html. All major browsers now support it without polyfills. A lightweight virtual dom library like snabbdom + webcomponents is a good match. Component driven development is the way to go and web components is a tool that every web dev should keep in their belt.

Keithamus 6y ago
That’s some good feedback! We’ll look into adding screenshots. As most of the components have no CSS (the ones that do are mostly layout, no theming) - they don’t look great, they are mostly useful for their behaviours.

fulafel 6y ago

Do these work in Safari without polyfill? The "Browsers" section is ambiguous.