Echo JS 0.11.0

<~>
andreykh 2077 days ago. link parent 1 point
According to the article, Chartist only has 3 chart types, Chart.js - 8, not to mention those "huge" are not all that monolithic and heavy, say AnyChart offers different modules https://docs.anychart.com/Quick_Start/Modules. Not to mention many of those JS charting libraries like Highcharts, AnyChart, amCharts are not really focused on single use cases like one simple pie chart (noone likes pie charts, btw) but rather on satisfying enterprises with a lot of diverse data visualization tasks, you now. But there are very different libraries on the list, so probably you should take a closer look at the list at least to know where to look when you ever get a sophisticated data visualization task. Just a thought. I am not the author.

Replies

tracker1 2077 days ago. link 1 point
I was probably overly critical, but even the libraries I looked at that did break them up were pretty big... I understand that it may be useful or worth it when you do need more complex, or larger visuals without the time to work through the math/render yourself.  With a JSX supported interface, you can actually do a lot of SVG work with far less additional overhead in the browser, right now that's generally my goto for the few areas of the apps I'm working on requiring more complex/interactive visuals.

I'm not a total minimalist here. I strive to keep my payload (min+gz) as small as reasonable, generally under 300-500k, though I love when I can deliver under 100k.  This often turns into 1-2mb parsed, and a 3-5mb logic tree in memory.  Some of the charting libraries in the article take that much by themselves.  This may not seem like much, but it's often quite a bit of overhead on a modest laptop. 300kb is actually enough room to bring in a *LOT* I'm using several react/redux libraries and a couple dozen Material-UI components as well as quite a few SVG icons (mdi-material-ui) and a lot of custom components for the project (about 20-25% of total payload)

There is absolutely no mention of or consideration of size delivered, parsed or computed in the article. Your referenced AnyChart, the core is over 300kb delivered by itself... the pie chart on top of that isn't bad at around 18kb, though there are other pie chart libraries that are stand alone in the 4-5kb range.  Both min+gz.  I could probably run core + pie through closure compiler to see how small it can be though.  Right now, my main projects are an SPA where the entire payload is at 380k min+gz, and another where it's around 130kb.  AnyChart's core would just about double my larger app.  And is 2.5x the size of the smaller.

In the end, you and anyone else can make their own decisions on how/what to bring into their projects.  That said, all of the charting libraries mentioned (I only looked at a few of them, admittedly) are considerably larger than I would consider for *MOST* applications.  I know a lot of people are fine sending many megabytes of various modules/libraries down to the browser and either don't know or care about the impact/overhead.  I know a lot of others that go to the opposite extreme, working hard to keep delivery under 30-50k max.  I'm a bit more pragmatic, and even then these charting libraries are over the top for me.