Hacker News Reader

Comment by capableweb | Hacker News Reader

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

View on HN

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.

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.

This is an indignity! An outrage! An affront! /s

There's different ways to do things. Some people have a hard time with that.

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.

> 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.

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.

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

> 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?

> 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.

> I think it's done to decouple versions.

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.

Having a consistent version number gives you some reassurance that your components are compatible with each other.

Each of these components stands on their own. You can use one without having to link to or consume any of the others. Shouldn't each one have documentation that describes how they work, a license, etc? I don't want to have to go hunt down some separate documentation project, which is almost certainly years out of date, to figure out how to use these components. If someone is consuming or even contributing to one of these components everything they need is in front of them in one repo.

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?

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

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.

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...

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.

Yeah this is nuts.

Reply on news.ycombinator.com