Show HN: Frappe Charts – GitHub inspired JavaScript charting with zero dependencies
frappe.github.io
frappe.github.io
Unless maybe some HNer knows how to do such SVG/picture testing non flaky?
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.
All the best for the project. Are you looking for community contributions?
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
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.
Thanks for reporting the click problem. Would you mind creating an issue at GitHub, so that we can keep track?
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 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.
https://www.microsoft.com/en-us/research/wp-content/uploads/...
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.TIL
Like users, programmers don't care whether programs have tests as long as it does what it needs to do.
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 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.
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.
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
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
Other than that, great work. I look forward to testing this out.
It sure is. Just pushed a fix, thanks for reporting :) Do report any issues you find over at https://github.com/frappe/charts/issues
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.