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
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".
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?
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?
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
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.
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.
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.
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. :-)
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.
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.
Tests are a way to judge what it does. It does the judging for you, ensuring features work as advertised, and provide usage examples that are guaranteed to work.
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.
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.
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? ;)
Possibly because it doubles the amount of work to make small changes, because you also have to learn the testing setup and write tests for your change?
> 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.
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.
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.
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 :)
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]
And this seems to imply that any increase in time was offset by reduced maintenance costs due to improved quality.
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?
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
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.
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.
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.
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?
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.
