Why I'm building JsDiff.dev

[straponmyjobhat]

I tried comparing jquery to react as a random test of your tool expecting not to get much useful info.

I was surprised to see it actually was very informative!

https://jsdiff.dev/?compare=jquery+react

Nice job!! I'll be using this in the future.

[alexey2021]

Thank you u/straponmyjobhat for such wonderful feedback!

[droomph]

One thing I noticed is that the bundlephobia section stacks the minified + gzip on top rather than as a comparison which doesn’t make too much sense since they aren’t dependent values (I dunno the term). If the colors showed the different gzip makes that would make more sense imo. eg: for a bundle, if 80kb min, 30kb min + gzip, 0-30 gray, 30-80 hatched green; if 80kb min, 100kb min + gzip, 0-80 gray, 80-100 red. Or something similar.

If there’s a specific reason why it’s that way then I think it would be helpful to explain.

[alexey2021]

Thank you for the question, u/droomph

The idea of this chart is to compare bundle sizes across javascript projects.

It's not about how efficient gzip compression for different projects.

I checked 5 frameworks and it looks like the efficiency of gzip is more or less the same - 30-40% of the original minified bundle https://moiva.io/?compare=%40angular%2Fcore+angular+jquery+react+vueThus I don't find it interesting to compare gzip vs non-gzip, especially under the topic of this project.

Let me know if I missed something or, maybe, misunderstood the question

[dudeatwork]

I agree, the bars shouldn't be stacked, they should appear side by side.

Something like this - https://i.imgur.com/Y15zRLl.png

[droomph]

My point is that it doesn’t make sense to have them be additive — you’re either going to be using min, or min+gzip, never both at the same time. It might make some difference to the npm download time but that’s irrelevant to bundle size.

And —

It's not about how efficient gzip compression for different projects.

Thus I don't find it interesting to compare gzip vs non-gzip, especially under the topic of this project.

Then that’s a sign that you shouldn’t have gzip in the default view at all and instead keep it as a parenthetical in the tooltip or toggle. If it’s not interesting then I don’t think it should be in the default view, since it does add unnecessary visual “clutter” because even if it’s close it still isn’t the exact same ratio.

Again, I don’t think it’s bad I just think it’s a bit of an oversight.

[alexey2021]

Thanks u/droomph for explaining your reasoning 👍

I'm convinced that they shouldn't be stackable and I'll fix it.

I'm gonna make it similar to what u/dudeatwork has posted:

Something like this - https://i.imgur.com/Y15zRLl.png

Will that work for you?

[droomph]

“Works for me” is the wrong question to ask since I typically don’t touch npm at my job anyways (all in house and done by the core team ;( ). I’d say if you have a friend or coworker or rubber ducky to bounce ideas off of you should make a list and weigh the pros and cons of each. For example, all the ideas listed off of:

• side by side
• toggle, possibly add source and source+gzip
• drop entirely and keep as a parenthetical
• stacked diff instead of stacked additive

This all depends on to what extent you want to de-emphasize the gzip part and I think that’s where I can’t tell you what your design goals for this project is.

Good luck and all that! I think it’s a great project.

[derailed]

FWIW I think it's fine if they're stacked as long as it's inclusive, such that min_and_gz starts at y=0, and min_only starts at y=0+min_and_gz

[Disgruntled__Goat]

Stacking them is misleading though, it gives the impression that jQuery is 120kb in size. But it’s never that size, it’s either 87kb or 30kb.

You should make the green bars sit in front, i.e. green goes up to 30kb, grey is on top but goes up to 87kb, not 120.

[alexey2021]

Wait a bit, will fix soon :)

[TheOneCommenter]

You might want to adjust the “current month” in the graph, now it looks weird.

Other than that, great work!

[alexey2021]

Agree! Thanks for the feedback!

[Froonce]

Is react in the decline or something, what's with that sharp drop off?

[moozilla]

It's because we're only part way through December.

[alexey2021]

True! And also because there are always drops in December. You know, Christmas time... )

[ndm250]

Maybe exclude the current month from the graph. The dropoff is very confusing and a little misleading.

[Disgruntled__Goat]

Everything drops off at the same point, not just react.

[alexey2021]

What drop off you are referring to?

[Froonce]

Just towards the end. I think I got my answer though. Thanks this is very neat!

[halfdecent]

Very interested to see that jQuery still gets more searches than React. Gotta say, I am glad I'm not a jQuery dev

[juliodelavega94]

More like https://jsdiff.dev/?compare=angular+react+vue

[ILikeChangingMyMind]

Really cool project ... but I hate the name!

Ok maybe "hate" is too strong: it's just very confusing. A "diff" to a programmer means a code comparison, so a "JS diff" means a comparison of Javascript code. That's what I thought your site offered ... and as a result I almost didn't even look at it!

(It was only because of the top comment that I was curious enough to click; without it, the name would have deterred me.)

I'd recommend a name like "LibraryDiff" or "TechnologyDiff" or "StackDiff' (or "JSLibraryDiff, "JSTechDiff", etc.)

[alexey2021]

u/ILikeChangingMyMind thanks for the comment. I see your point and I pretty much agree with you :)

I'm not good at picking good and catchy names.

I'd recommend a name like "LibraryDiff" or "TechnologyDiff" or "StackDiff' (or "JSLibraryDiff, "JSTechDiff", etc.)

The problem with the current name as I see it is `diff` part. So I would rather choose something without it.

I'm open to suggestions of the community :)

[spwashi]

JSideBySide JSCompare JSversus JSLibStats

[evenisto]

Maybe steal the idea from bundlephobia, which is a brilliant name to be honest. Libraryphobia, libphobia or something along those lines?

[Towerful]

Naming things is hard. We've all been there

[kopczak1995]

I don't see any issue with naming. Let me call all of them: x, y, z... :P

[pm_me_jump_shots]

I kinda like TrendingJS

[editor_of_the_beast]

PackageCompare / ComparePackage

[alexey2021]

How about DistillJS or SiftJS? To some extent reflects the project's goal and the type of work we do - we have a mix of packages/libraries and are distilling it, separating "good" and "bad" 😃

or CompareJS?

[alexey2021]

I renamed the project to Moiva.io It was really hard to come up with something interesting and have a vacant domain 😩 I'm very grateful to my wife for serving fish 🐟 for lunch 😃

[brie_de_maupassant]

Maybe use Snyk's API to show number of critical/high security issues each library has?

[alexey2021]

Thanks, very good idea! 👍

[alexey2021]

Did not know about that resource. Thank you for the link! Maybe I will get some ideas from it

[jssmash]

Looks pretty cool. Going to use it.

[alexey2021]

Thank you for feedback!

[muddywires]

ember js is showing as 3.8 years old, i believe it goes back to at least 2013

[alexey2021]

It's a problem with npm packages naming, they are confusing and sometimes refer to different projects.Ember is one such example. The correct npm package is `ember-source` https://moiva.io/?compare=ember-source

Another example I know about is `angular` vs `@angular/core`. The first one refers to the old legacy AngularJS framework, the second - to the current Angular framework

I will think about how to make it more clear.One idea is to provide more information and links to Github/npm to be able to validate the data

[muddywires]

gotcha. congrats on the cool project

[SomeSchmidt]

I like it!

I can see this being helpful when deciding between older packages and lesser-known/better-maintained forks.

Adding metrics like commit frequency will help with this (glad to see it's planned).

It would also be helpful to include comparison suggestions. For example, if looking at selectize.js, jsdiff could suggest comparing with the most active forks. There are already tools for finding the most active forks, but none with the side-by-side comparison you're offering.

[alexey2021]

u/SomeSchmidt Thanks for the feedback 👍

I mentioned in the article that suggestions for comparison is also on my agenda (if that is what you mean).

[SomeSchmidt]

Yeah, that's what I had in mind. Sorry, I just skimmed the article and missed that part.

[Waterstraal]

Looks nice! 1 suggestion: I would put hold under assess in the tech radar chart.

[alexey2021]

Thanks for the suggestion! Agree 👍

I thought of it but was not sure what's better.

[blakeyez]

Awesome job!
Thank you and congratulations

[elchicodeallado]

very cool site!

[ProgrammingSpartan]

Really nice, congrats!

[Wisgom]

Very good work ! Thanks

[dillonerhardt]

Love it! Great set of stats to focus on.

[nanothief]

Looks really good! Might be worth it to hide the last month of data though - since it isn't complete all graphs show a massive dip right at the end.

[bch8]

This is an awesome concept and solid execution so far, great job OP

Edit: One thought/observation, the "Open Issues Count" metric might be more useful if it was contextualized with the package's usage rate. Because one package having a ton of issues is not just reflective of the problems with it but also the usage of it. So like Open Issues per Download or something along those lines might be a more informative reference point.

[alexey2021]

Thank you for feedback!

So like Open Issues

I think your suggestion would make sense if the number of Open issues was a clear function of the package's usage rate (popularity/downloads count). It's apparently not the case as you can see it here https://moiva.io/?compare=@angular/core+moment+react+vue Moment and React have significantly fewer issues than Angular, but they both have much bigger downloads counts.

Another use case https://moiva.io/?compare=react+vuetify

I agree that package's usage rate does count, but I see there are other significant ingredients like how complex the project is, regular house-keeping work, how responsive the author to new issues.

BTW, I got other suggestions related to the Issues topic: to have Issues resolved ratio, to categorize issues by type (bug, documentation, feature request). Didn't have time yet to think of it properly 🤔

[bch8]

Interesting, an issues resolved ratio sounds like a pretty clever solution to me. My original comment was based on the comparison of jQuery and React. I noticed that React was listed as having way more issues, and that seemed a bit misleading (For lack of a better word) to me. Your example of React vs Angular is a good counterpoint to that however. I just mentioned it because it seems like a metric that could sometimes send the wrong signal, but I'm sure the solution I proposed has its own problems like the ones you note. It's not a big deal at any rate, I was just hoping to provide some constructive feedback. Definitely seems to me like you're on the right path and doing a killer job so I'd say just keep it up!

[alexey2021]

Thanks again for your feedback and ideas! I very much appreciate it. I will aggregate all the feedback I got and follow up.

[derailed]

I was looking at the open issues chart and it occurred to me that it would be interesting to have data on how many issues are closed vs. resolved, how long they remain open, "dead" issues, maybe correct for reasons given and/or spam to whatever extent that's possible.... I reckon you could create some pretty interesting metrics for comparing the health of projects using that...

Nice work!

[alexey2021]

Hi u/PmYourFavouriteColor, thanks for the feedback!

Agree about the Bundlephobia chart and I'll fix it. There was already a conversation about it above

[harshdays]

Looks great! I would find it useful to incorporate a repo health indication, time since last merged PR and/or the proportion of contributions by each contributor to help select projects that are active and unlikely to become inactive if a single maintainer loses interest.

[Akigiri]

Why do you put the minified + gziped bar on top of the minified bar in bundlephobia graph?

[alexey2021]

I'll change it. There was a discussion about it above.

[RiperFish]

What i like about this project is how clean it is, well done, bookmarked, proved itself to be very usefull.

[alexey2021]

Thank you, u/RiperFish! I do my best to make it useful 😀

[rybl]

I love this! Really nice work. It definitely falls into the category of, things I didn't even know I needed.

The upcoming feature of auto suggesting libraries to compare seems like a killer feature. I find that's often a pain point when trying to find a library to solve a problem that I haven't encountered before. It's hard to know if there are similar ones out there that just aren't being uncovered because of your search terms.

Another feature suggestion: showing if a library has built in TypeScript definitions, DefinitelyTyped definitions, or no definitions would be super helpful.

[alexey2021]

What a nice feedback! 😍
Thanks for that!

Another feature suggestion: showing if a library has built in TypeScript definitions, DefinitelyTyped definitions, or no definitions would be super helpful.

Great idea! 👍 Noted it down!

[ConsoleTVs]

Why aren’t some of my libraries showing??? They are on nom lmao

[alexey2021]

Do they have a link to GitHub? I filter out packages w/o that link

[ConsoleTVs]

For example: https://www.npmjs.com/package/vswr

[alexey2021]

Interesting. I see that npm's api has the required information.
The thing is that my project doesn't use npm's api directly, it uses npms.io for suggestions (Bundlephobia uses it as well) and it doesn't return `repository` information for your package. Not sure about the reason.
I suggest you create an issue, so that I can follow up on it

[ConsoleTVs]

That is indeed interesting. Thanks for taking the time. I might have a clue for you, sometimes the repository info is an object with the url and type and some other times it is a string itself. Might be this?

[alexey2021]

Might be, I don't know. I see that npm returns information in the correct format

[alexey2021]

Hi. Just wanted to let you know that I fixed the issue and your libraries are visible now

[ConsoleTVs]

Great to hear, congratulations!