track component size

[yields]

Wouldn't be awesome if when we did component search something it will show the size of the component in bytes, the minified size.

I believe this will cause component authors to write smaller more specific components, and of course it will benefit consumers...

[timoxley]

Interesting idea, though how would this take into account size and overlap of the dependencies? If your component is only 200 bytes of code but has 100 dependencies, that could mean many hundreds of kilobytes of additional code… but this wouldn't mean any additional code for dependencies if I'm already using those 100 deps in my codebase.

Also note as soon as you display any metric, people naturally feel it's important to 'get the most points' and turn it into a game. This could lead developers to writing more obfuscated code than they normally would in an effort to have the best compressing components (how valuable is that?), at the cost of readability/maintainability. A metric for useful, simple and maintainable is far more valable. Conveniently, the number of github stars for a project is a reasonable approximation of this metric, and is already visible.

[yields]

has 100 dependencies

Sometimes it won't be accurate i agree, but it's still nice to know how big a component is before you use it.

get the most points

I don't think devs will do that, because it has nothing to do with how you write your code, we simply minify gzip and check to see how large the component is.

[timoxley]

because it has nothing to do with how you write your code

I was imagining people going demoscene style, where they write code optimised for the compression algorithm, but perhaps that's far-fetched…

Hm, if the size of dependencies isn't counted, it could actually encourage people to seek out and use dependencies rather than fattening their codebases with duplicated functionality, which is a positive… more code reuse and more separation of concerns.

[yields]

Yeah the idea isn't perfect.

demoscene style

I have never seen that before haha..

There is a lot of unreadable code on github that's for sure, devs who write unreadable code will keep writing that way, regardless of what we are doing...

use dependencies

I agree, but not adding the size of the whole component with it's dependencies will be kinda useless because it's not real.

I think we can solve this with adding standalone size which includes dependencies and size which is the code.

I don't know haha, let's wait to hear some more ideas on what is the best way to go...

[weepy]

only other thing to point out. I mostly dont care about size of dependencies wrt download speed etc. BUT I do find it very useful for a quick heuristic about how complex a project is. I avoid larger project not because I worry about my users having to wait 10ms longer in their first request, but more because BIG ~= BLOATED

On Tue, Nov 6, 2012 at 10:36 AM, Amir Abu Shareb notifications@github.comwrote:

Yeah the idea isn't perfect.

demoscene style

I have never seen that before haha..

There is a lot of unreadable code on github that's for sure, devs who write unreadable code will keep writing that way, regardless of what we are doing...

use dependencies

I agree, but not adding the size of the whole component with it's dependencies will be kinda useless because it's not real.

I think we can solve this with adding standalone size which includes dependencies and size which is the code.

I don't know haha, let's wait to hear some more ideas on what is the best way to go...

— Reply to this email directly or view it on GitHubhttps://github.com/component/component/issues/135#issuecomment-10105860.

[timoxley]

Good point. Something similar to the component.io idea can be found over at http://microjs.com/

They list the watchers (stars?) forks, sizes in kb, and tweets(!). Looking at that, I agree, the size definitely influences how complex a lib appears to be.

[tj]

library focus is definitely more important than size, but it would still be interesting to track, even if just later for graphs ets

[ForbesLindesay]

I do think it would be nice to clearly mark things that have the 'big' dependencies, such as jQuery. I don't think the size of the components is going to be a big issue any time soon, but using say jQuery or Prototype just seems to fly in the face of the whole point of component.

[tj]

yeah those will go away with time, we just have to extract everything that jquery does into components

[ForbesLindesay]

hmm, some newbies will still write components that rely on jQuery for a forEach loop or to get an element by its ID. That's fine as long as they're clearly identifiable.

[tj]

closing for now. filesize isn't really the main concern, gzip squashes pretty much anything but complexity is certainly a concern but not every component can really be judged by size, definitely a nice-to-have so we can re-open once we've hit a 1.0 and got everything rolling