GitHub's Web Component Collection
github.com
github.com
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.
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.
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.
One example of where this goes wrong is if, say, you wanted to implement the indieweb protocols for p2p social networking. With webmentions it's a bit like pingback, but instead of just HTTP POST, the pinger has to have a link on his webpage linking to the pingee's URL. That means the pingee webmention implementation has to be able to parse a page and get the html. With webcomponents doing DOM stuff instead of having HTML text that webmentions implemention (and everything else) has to become really complex instead of a simple curl and parsing text.
(1) recent whatwg html standards say this is all fine and dandy because whatwg is run by corporations for corporate needs. But it isn't fine and the needs of applications are not the needs of documents.
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.
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
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.
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.
There's different ways to do things. Some people have a hard time with that.
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.
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.
I'm really scratching my head to understand your concern here. Apparently there is some magical minimum bar of file size that a project needs to pass before it's worth having a repository on github with a readme, license, etc? Even though the git repo and a few text files only take a few bytes to store?
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.
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
> 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?
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.
From the repo's README:
> We have 16 open source custom elements:
It's feasible that GitHub also have some components that are temporarily or permanently private. Having one repo per component may help to remove the need for that distinction among GitHub developers, who don't have to first check whether to import a component from a public or internal repo.
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
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.
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...
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.
[0] https://thenewstack.io/how-web-components-are-used-at-github...
To maintainers, this example link https://github.github.io/time-elements/examples/ is missing from https://github.com/github/time-elements page
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/examp...
Can someone enlight me?
I would rather use `let`.
In a way it makes good semantic sense if the value shouldn't change within that scope.
As others have mentioned, in JS this is kind of questionable since arrays and objects don't behave as many would expect a constant to behave.
You're free to use either one, really - it largely comes down to preference.
for (const form of document.forms) {
const formInput = form.querySelector('input')
const button = form.querySelector('button')
const state = form.querySelector('.state')
...
}
If you want to persist a const across iterations, you'd define it in a scope above it. You could also modify a let variable defined a parent scope. Personally I avoid doing that, but it's possible. Anything defined in an iteration though, I'd consider disposable unless it's a reference to and outer scope variable.
Someone correct me if I'm wrong!
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.
The rule behind `const` still applies within a loop, which is merely another block like any other. If you don't expect a variable to change in a given iteration of a block, whether it's a loop or via a function call, `const` is technically safer in that it will result in an error. It's all about providing the developer better clues to fix issues. Without `const`, it may be harder to diagnose why a value isn't what it should be. But if you're comfortable using `let`, then by all means.
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.
You have it backward; there's almost never a need to use let in JavaScript, as most variables should never be reassigned.
I've seen bugs pop up many times in client-side development where, for whatever reason, a variable is reassigned in a way that's difficult to predict. By defaulting to const unless reassignment is necessary, you're essentially putting documentation into the actual code and you can prevent logic errors by forcing runtime errors during development.
Why not? Reassigning globals can lead to bugs, sure. But when does reassigning a local lead to bugs?
> By defaulting to const unless reassignment is necessary, you're essentially putting documentation into the actual code
No, by defaulting to const, you're removing documentation. "Does this variable need to be kept safe from reassignment? Is it ever used again after this point in the code? Or is the developer just blindly using const for no reason?" Gotta read the code to figure it out because now const is just meaningless noise.
`const` isn't exactly that useful, especially considering that the tooling most of us use now helps us catch these sort of mistakes before runtime, but there's basically no objective reason to not use it. If you have a value that you don't want to change, `const` is only a few extra bytes from `let` and will provide better feedback when your tests fail because a value was subsequently set when it shouldn't have been. Maybe that never happens to you, but just because it's a rare problem doesn't mean it's useless to take a precaution. Most of us will never get into a car accident, but that doesn't mean that airbags are useless.
But on this subject, at this point, my rule of thumb is to always use ‘const’ first, until I find myself in a situation where I’m forced to change it to ‘let’.
If I’ve gotten into a situation where it seems like I need to use a ‘var’, then I seriously take a minute to rethink the implementation :)
int f(int k) { return k+1; }
and
int f(const int k) { return k-1; }
are considered different.
My foray into webcomponents was at mixpanel and I helped build the component library at 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.
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.
Personally, I'd hate to work on these components. Need to make a sweeping change? Time to create 16 pull requests.
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.
I didn’t know websites could hide the address bar.
Personal access tokens.