npmgraph.an VS js-framework-benchmark

It's referring to all transitive dependencies - not just direct dependencies. More like this: https://npm.anvaka.com/#/view/2d/vue

All the points listed above are multiplied, to some extent, by the number of dependencies in the entire dependency tree of the project. A great tool to check the complete dependency tree: https://npm.anvaka.com

A colleague of mine just told everyone that vue.js is simply bloat, other frameworks are better and he doesn't want to work with vue.js. As "source" he sent this following link: https://npm.anvaka.com/#/view/2d/vue and told us to compare it to @angular/core and react. I love vue and obviously know that it isn't bloat, but I don't know how to argue my point.

I saw this yest and it’s kind of cool to visualize all the dependencies of a package. Hope it helps https://npm.anvaka.com/

You can compare performance in a more rigorous way by consulting Stefan Krause's js-framework-benchmark project. Here are results based on the latest snapshot:

Sorry, this is a bit out of my area of expertise (especially in non-React frameworks), but until someone more knowledgeable comes along, maybe I can at least offer some links for getting started?

A writeup: https://blog.logrocket.com/rendering-large-datasets-vue-js/

As for implementation, this is probably a situation where I'd reach for Someone Else's Library™ instead, at least to learn from. Maybe something like https://www.ag-grid.com/example/ (try the 100k row example) with maybe a serverside data model: https://www.ag-grid.com/vue-data-grid/server-side-model-upda...

That's a ready-made open-core implementation (paid additional features), but you can see an example of how to make an performant implementation. Often, big tables like that can use some sort of virtualization (https://www.ag-grid.com/vue-data-grid/dom-virtualisation/), or here's another lib that does something similar: https://tanstack.com/virtual/latest

There is also a JS framework benchmark at https://github.com/krausest/js-framework-benchmark and a vue-pinia implementation at https://github.com/krausest/js-framework-benchmark/tree/mast...

Lastly, I would say it might be worth considering how the whole dataset works, holistically, as in whether the client really needs to handle all that data at once or if it can be streamed in chunks to & from the server, maybe with a bit of buffer in every direction. It's the same windowing concept, just moved to the network.

And of the data on the client, how much of it is bottlenecked by rendering vs other in-memory operations (sorting, filtering, pagination, etc.) -- can you speed that part up with any better algorithms or data structures?

But it sounds like your main bottleneck right now is rendering large datasets into the DOM, so hopefully some of those above will help.

At some scale, it might also be worth considering moving out of the DOM altogether and into a canvas, like https://canvas-datagrid.js.org/ or https://github.com/xwinstone/canvastable?tab=readme-ov-file. The DOM isn't really made for something like that, and it's pretty amazing what the libs can do, but the canvas can be much much faster. You do lose all the built-in DOM functionality though so you end up having to recreate a lot of functionality (like search, selection, drag & drop, etc.)

------

Good luck! I hope someone comes along with more experience and wisdom to share.

# Clone the repository git clone https://github.com/krausest/js-framework-benchmark.git cd js-framework-benchmark # Install dependencies and start the server npm ci && npm run install-local npm start # Run the benchmark npm run bench # Generate the results table npm run results

By comparing performance on benchmark, we can see that Svelte outperforms front-end frameworks such as React, Vue, and Angular overall, except for being slightly behind Solid.

JavaScript benchmarks are instruments for measuring the speed and effectiveness with which a JavaScript engine—such as the ones found in web browsers—can complete particular tasks. Benchmarks are used by developers and browser vendors to evaluate various engines, find places in the code where improvements are needed, and make sure JavaScript standards are being followed.

Strange then that frameworks advertise how fast they are at rendering, mutating, and creating objects in the DOM, and one of the main JS benchmarks everyone likes to measure their performance by is literally a benchmark about DOM manipulation: https://github.com/krausest/js-framework-benchmark

Oh wait. It's not strange. Because state manipulation is a largely solved problem, and even the least performant state manipulation is blazingly fast. However, presenting components in the browser's DOM is tens of magnitudes of orders less performant than anything you can throw at state manipulation.

And every single framework is busy solving one single problem: how do we touch the DOM as little as possible?