Show HN: Frappe Charts – GitHub inspired JavaScript charting with zero dependencies(frappe.github.io)
frappe.github.io
Show HN: Frappe Charts – GitHub inspired JavaScript charting with zero dependencies
https://frappe.github.io/charts/
91 comments
Impressive! What are the supported browsers? What are your plans going forward?
Supported across all major browsers :)
We've covered much ground on the most used charts (while the heatmap just happened to be something we needed) and have the basic components down. That'll facilitate putting in, say, more axis charts in future. We're sure of not running out of ideas, there are just so many chart types out there :D
> Supported across all major browsers
Please be more specific: Frappe Charts doesn't work in MSIE 11 which is the latest IE for Windows 7 which is used by a lot of enterprises.
Please be more specific: Frappe Charts doesn't work in MSIE 11 which is the latest IE for Windows 7 which is used by a lot of enterprises.
It works on iOS, and I think there are a lot more iPhones out there than win7 desktops. ;)
Be that as it may, that doesn’t address the apparent fact that it doesn’t work in all major browsers — certainly IE11 would be considered one by most.
Moreover, whatever % of global browser share IE11 has, within the market of people who want charts, it's much higher. The simple chart is also the #1 feature priority of every business-IT product manager that has ever existed, narrowly beating "make it work in Internet Explorer".
Google Charts is a solid lib if you need the go-wide support
Do you have a separate repo with unit tests? If not, how do you test the charts?
We look forward to adding those (just created an issue). They are quite decoupled as of now, so shouldn't be much trouble.
I have really bad experience using controls that didn't have a large test suite. They don't have to be "unit" , I just care about the ratio of the number of state transitions it tests to possible state transitions. If that library was written in typescript (or some other strongly typed language), I'd been slightly less worried about the lack of tests, and possibly slightly more convinced to try it out in its early stage.
I agree, unit tests wouldn't be very useful here, i was thing that visual regression tests with constant data, that capture graph image and compare with older version for regressions would have been really nice here.
As a side note: I find these kind of tests flaky, because the antialiasing doesn't seem stable at constant resolution on the same machine & browsers when you repeat tests. When you do a fuzzy compare (ie. allow for X pixels difference), then you are always chasing the golden middle. A test I would like to see for a control is trigger multiple state transitions (for example change 5 properties of a chart), do assertions on the generated DOM.
Unless maybe some HNer knows how to do such SVG/picture testing non flaky?
Unless maybe some HNer knows how to do such SVG/picture testing non flaky?
If you also support react native using their canvas, it might be a pretty sweet addition. Plotting libraries are somewhat missing in react-native.
Also checkout the Gantt lib we published earlier https://frappe.github.io/gantt
Does this support arbitrary time spans? Like from minute 1 to minute 58 without any other date/full date?
It's so good! I am thoroughly impressed with its performance and the dynamic data binding. I discovered in comments that there's a frappe-gantt chart as well, would be nice if such "extra" plugins were listed on homepage (since the gantt example is even more impressive!).
All the best for the project. Are you looking for community contributions?
All the best for the project. Are you looking for community contributions?
Yes, community contributions are always welcome.
Right now, we have specifically covered the cases we needed for our product.
So, it'd be cool if we can make these as generic as possible.
The biggest thing I find missing from most charts is their ability to interactively and dynamically chart over a large data set.
I once found a chart ( can't find it again ) that was super ugly but had a nice scheme for dynamically loading and caching data at different zoom levels that made the chart very snappy
I once found a chart ( can't find it again ) that was super ugly but had a nice scheme for dynamically loading and caching data at different zoom levels that made the chart very snappy
You rarely can visualize anything meaningful of large dataset on screen. You can draw 100k data points on screen easily. But human brain rarely can make sense of those data points. What you need to do is to analyze and create filters to present meaningful insights from the dataset.
Nice work. The code itself is clear and concise also.
Thank you! We tried many approaches, but the simplicity of object oriented UI components is classic. Its much more refreshing to read old fashioned object oriented code vs hybrid libraries that seem to be trending these days.
Is the annual heatmap supposed to be empty?
Also, for the clickable charts, clicking on the popover should count as well. If the bar is really short it can be quite hard to click on, such as the 2007 entry in the first chart.
Also, for the clickable charts, clicking on the popover should count as well. If the bar is really short it can be quite hard to click on, such as the 2007 entry in the first chart.
We gave it too less data than it deserved I believe.
Thanks for reporting the click problem. Would you mind creating an issue at GitHub, so that we can keep track?
Thanks for reporting the click problem. Would you mind creating an issue at GitHub, so that we can keep track?
This looks great. Can I ask why you didn't use chart.js?
I would also appreciate an answer to this question. It's not about "why'd you reinvent the wheel", but rather that I suspect you must have found chart.js while searching for options and decided something was missing or could be improved. I am interested to know how they compare, to have an idea how seriously I should look into this new option.
The argument would be no different from all the products out there who design their own UI (MUX, GitHub). Our framework Frappé (and product ERPNext) has a great emphasis on minimal style, and we really wished the charts to be free of visual clutter (not have too many measure markings for instance). Something that even the customizing API should take care off. Chartjs is awesome and very comprehensive, it just didn't go too well with our look and feel :)
chart.js isn't perfect, but it's pretty easy to customise and remove/change any element you don't like. I find it hard to believe it was easier for you to create an entirely new charting library than to set the option to remove ticks.
I'm not complaining because it's always good to have options and I really like the look of your library. I just find it a very curious use of resources.
Of course, it's your business and you can do whatever you like with it regardless of whether you have a good reason. :-)
I'm not complaining because it's always good to have options and I really like the look of your library. I just find it a very curious use of resources.
Of course, it's your business and you can do whatever you like with it regardless of whether you have a good reason. :-)
Because Javascript.
Looks nice, 0 dependency, simple design but there is one issue...
I see that you don't have a single unit test or integration or functional etc.
Even if your in house developers know what they are doing (which is a myth, stuff will break) it's going to be difficult accept contributions from community without any tests that make (almost) sure existing features are working with the changes.
I see that you don't have a single unit test or integration or functional etc.
Even if your in house developers know what they are doing (which is a myth, stuff will break) it's going to be difficult accept contributions from community without any tests that make (almost) sure existing features are working with the changes.
How would you even test a UI library? For example, if some weird input makes the bar charts too spread apart, how do you convert that to a unit test? If you tried to unit test this, you'd either be fully reproducing the actual source code for spacing logic or you'd be hard-coding in thresholds that might all break if the maintainer decides on a UI change such as "increase the spacing for bar charts having many grouped bars".
It seems for UI projects, testing can only cover about 1-10% of the issues that eventually end up on the GitHub issue tracker, so 25% of your time on this project would go toward writing tests, which would save you 1-10% of your time. Doesn't make sense.
You can test more than you'd realize: The generated math, the number of axes and number of visible points, etc. I'm not saying its def. a valuable use of time here, but I've been surprised how investing a little bit in helper methods (like, `getSelectedOption` or `isVisible`, etc) can generate quite useful and expressive unit tests.
Judge work by what it does, not by what it doesn't have.
Like users, programmers don't care whether programs have tests as long as it does what it needs to do.
Like users, programmers don't care whether programs have tests as long as it does what it needs to do.
Speak for yourself... that's quite the generalization. I'm a programmer, and I care when something doesn't have tests, especially if it's my own code.
While this is true for you and me, this isn't true for a huge number of developers.
So I should wait until stuff starts breaking, then start complaining.
Yeah.
I am glad that this approach works for you but I am not brave enough to use a new library without a single test.
I guess this project isn't for you then.
Well I would use it, but I wouldn't contribute, because I write all my code in a test driven programming way. AFAIK Chuck Norris writes the code first, never the test.
[deleted]
If nothing breaks why would you complain?
It's not a question of wether something might break, it's a question of when will it break and how long a new introduced bug might be undetcted, that could have easily detected by some tests? Bugs always happen in projects, if someone says otherwise, he either proved his program to be correct (e.g. in COQ) or is wrong (and sometimes both :).
In that case, I wouldn't. But I believe that it will happen eventually, this is not a 10lines project, has many lines of code and since it's new, I expect a lot to be changed. Then those changes are going to break features.
If you are worried about them breaking it as they develop it, but like the current implementation then just use the current implementation.
If you feel like having tests are a blocking feature for you then just watch this issue: https://github.com/frappe/charts/issues/7
If you feel like having tests are a blocking feature for you then just watch this issue: https://github.com/frappe/charts/issues/7
I see where your coming from, but I disagree. This isn't a new OS, its a tiny charts library/utility. I'm more inclined to contribute because there are no tests. Either way, someone could PR tests if they wished. Perhaps your comment should have been such a PR? ;)
> Perhaps your comment should have been such a PR? ;)
I really hate seeing this used in discussion. Just because it's open source does not mean it's immune from criticism. Yes, technically some random HN'er could spend tens of hours writing unit tests and submit a PR, but really this is a task for the library author/maintainer.
Having tests is a measure of quality, and should be cared about if you want people using your library.
I really hate seeing this used in discussion. Just because it's open source does not mean it's immune from criticism. Yes, technically some random HN'er could spend tens of hours writing unit tests and submit a PR, but really this is a task for the library author/maintainer.
Having tests is a measure of quality, and should be cared about if you want people using your library.
The library author has already invested probably hundreds of hours creating the library; if someone who benefits from it only has to spend tens of hours writing the unit tests, they've saved an order of magnitude of time.
We need to stop thinking of OSS as something we're entitled to, that if a stranger doesn't put in enough free labour we're allowed to complain about it. I try to view my dependencies as favours other people have done for me. You wouldn't nitpick about a lack of tests after someone wrote a whole charting library for you; you'd thank them and add your own tests.
We need to stop thinking of OSS as something we're entitled to, that if a stranger doesn't put in enough free labour we're allowed to complain about it. I try to view my dependencies as favours other people have done for me. You wouldn't nitpick about a lack of tests after someone wrote a whole charting library for you; you'd thank them and add your own tests.
And we need to stop thinking of criticism as complaining. I'm very grateful for the OSS dependencies that I use in my projects and often contribute back to them, but I wouldn't touch a project without tests with a ten foot pole. I don't mean that in a bad way, for others it might fit their requirements fine. I'm guessing the author of this project would like people to actually use it, so I don't know why we should avoid giving this sort of feedback just because it's free labour.
Yeah, it's fair to provide criticism... my issue was more with the idea that the library author is responsible for doing what the consumers request, that the burden is 100% on the author. In my ideal world, this project would now be a community effort, and anything the community wants can be implemented by the community.
I was hoping the winking face would have led readers to understand that my suggestion was made in jest.
My point was: Many are dogmatic about tests these days, and I find it refreshing there are no tests.
Tests can be added later for something like this library, if/when the need arises - or when someone decides to spend "tens of hours" writing them.
Tests can be a measure of quality, but they aren't the only measure - and do not apply in all cases
My point was: Many are dogmatic about tests these days, and I find it refreshing there are no tests.
Tests can be added later for something like this library, if/when the need arises - or when someone decides to spend "tens of hours" writing them.
Tests can be a measure of quality, but they aren't the only measure - and do not apply in all cases
maybe you could start contributing to the project by helping writing some tests? i see that this is a library for a product that develop, so this might be a project they just extracted from that. as such it most likely was already has the "works on my box" seal of approval :)
Some of us believe that tests increase work by 25% while only reducing defects by 60%.
https://www.microsoft.com/en-us/research/wp-content/uploads/...
https://www.microsoft.com/en-us/research/wp-content/uploads/...
Interesting - that 25% seems to come from managers estimating the impact, not from developers.
Increase in time taken to code the feature because 15–20% 25–35% 15% 25–20%
of TDD (%) [Management estimates]
Another interesting observation from the outcome measures in Table 3 is the increase in
time to develop the features attributed to the usage of the TDD practice, as subjectively
estimated by management. The increase in development time ranges from 15% to 35%.
From an efficacy perspective this increase in development time is offset by the by the
reduced maintenance costs due to the improvement in quality (Erdogmus and Williams
2003), an observation that was backed up the product teams at Microsoft and IBM.I don't see how that isn't a good trade as defects only compound on larger projects. In fact without tests, which basically function as a spec, how can you be sure that your refactor still works as the previous version?
Microsoft uses WordPress?
TIL
TIL
D3 doesn’t have dependencies. Why use this?
D3 is not a charting library but a data visualization library with which one can produce standard charts. The code required to create a simple line chart in D3 spans dozens of lines, not including the data. Using a charting library it is usually one or two (plus options).
Lots of libs advertise 0 dependencies. I'm not fussed if a library depends on D3 though. D3 is 80k gzipped, this is 15k gzipped, ChartJS is about 20k gzipped. If you need one chart, sure, go for it.
But each of those libraries would be <5kb of D3-dependent code. With the added benefit that:
1. The code is much simpler and easier to understand and contribute to
2. Knowing D3 means you can modify the visuals, fork the library, and customize it without spending ages wading through unnecessary and unfamiliar re-implementations of D3 primitives. So many requirements I've seen involve tweaking visuals just far enough that a pre-baked library ceases to cut it.
3. Chart authors can rely on those primitives for a less buggy experience, given that they are tested and used elsewhere
4. D3 already supports IE9+, which this library doesn't
5. You have the power of D3 to build your own dataviz
But each of those libraries would be <5kb of D3-dependent code. With the added benefit that:
1. The code is much simpler and easier to understand and contribute to
2. Knowing D3 means you can modify the visuals, fork the library, and customize it without spending ages wading through unnecessary and unfamiliar re-implementations of D3 primitives. So many requirements I've seen involve tweaking visuals just far enough that a pre-baked library ceases to cut it.
3. Chart authors can rely on those primitives for a less buggy experience, given that they are tested and used elsewhere
4. D3 already supports IE9+, which this library doesn't
5. You have the power of D3 to build your own dataviz
Yea, I’ve found similar use case where any custom work is much better off done using raw d3.
Well timed. I'm in the middle of trying to figure out how to replace some C3 charts. Looks very nice!
Really nice work on this. Does it support pie charts currently? If not, any plans to do so in the future?
Check our take on why they weren't a priority for us, and we went with percentage charts (the 'Why percentage?' link on the website): http://www.storytellingwithdata.com/blog/2011/07/death-to-pi...
I noticed, when viewing the demos on my phone, that there were some issues relating to responsiveness. Specifically, the axes labels were overlapping. Is responsiveness a priority with this library?
Other than that, great work. I look forward to testing this out.
Other than that, great work. I look forward to testing this out.
> Is responsiveness a priority with this library?
It sure is. Just pushed a fix, thanks for reporting :) Do report any issues you find over at https://github.com/frappe/charts/issues
It sure is. Just pushed a fix, thanks for reporting :) Do report any issues you find over at https://github.com/frappe/charts/issues
This look really nice. Great job.
Question: For codebases that are all about package managers Yarn, what's best practice for integrating something like this? Just push it into a 'vendor' folder?
It depends on how the library is implemented, so you're expected to look at the source.
If you're using something like Webpack and the library just places everything on the global scope, you can configure exports-loader [0]. That way you can reference the module as if it were written with CJS or ESM, without having to change the source.
If it's not published on npm, you can reference the git repo along with the specific release tag you want to use. My suggestion would be to fork the repo and point to your fork in package.json, so things continue to work if the original repo ever gets taken down.
[0] https://webpack.js.org/loaders/exports-loader/
If you're using something like Webpack and the library just places everything on the global scope, you can configure exports-loader [0]. That way you can reference the module as if it were written with CJS or ESM, without having to change the source.
If it's not published on npm, you can reference the git repo along with the specific release tag you want to use. My suggestion would be to fork the repo and point to your fork in package.json, so things continue to work if the original repo ever gets taken down.
[0] https://webpack.js.org/loaders/exports-loader/
You would have to dive into how the library was implemented and see if it is compatible as a node module. There is an issue right here in the repo you can follow: https://github.com/frappe/charts/issues/6
Yeah this is really impressive. Right now I can't think of a use case for it but if I need charts like this in the future I will most likely use this be library.
Any support for realtime/updating graphs on the fly?
This charts looks awesome. Will surely use in my next project. Can I know how I can add two data points.
I mean how to show two graph lines in single chart?
The second example seems to do just that, if you switch to "line chart".
Really cool that this is built completely from scratch. I expected a dependency on something like d3 at least.
Thanks! That just about answers the burning question: why another charting library?
It all boiled down to us needing some simple charts for our report data; nothing fancy, just something that went with our classic design. All we needed was some mappers to translate numbers to relatively sized shapes (or positions). The graphs over at GitHub looked awesome to start the styles from; from there on we focussed on making them generic.
The annual heatmap is particularly cool, and not something I've seen in many (any?) other libraries.
We used cal-heatmap (https://github.com/wa0x6e/cal-heatmap) earlier. It's pretty neat.
Looks awesome, thanks for sharing!
[deleted]
This is great. Thank you!
Looks Neat.
Great work folks.
Well done!
No stacked bar charts, unfortunate. Looks really nice.
it's called - "Contribution".
https://i.imgur.com/gKQ7EMP.jpg
https://i.imgur.com/gKQ7EMP.jpg
