12 ms·
Show HN: Frappe Charts – GitHub inspired JavaScript charting with zero dependencies
- throwaway2016a 9y agoThis look really nice. Great job.
- polskibus 9y agoImpressive! What are the supported browsers? What are your plans going forward?
- pratu16x7 9y agoSupported 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
- polskibus 9y agoDo you have a separate repo with unit tests? If not, how do you test the charts?
- pratu16x7 9y agoWe look forward to adding those (just created an issue). They are quite decoupled as of now, so shouldn't be much trouble.
- rinchik 9y agohttps://rbcs-us.com/documents/Why-Most-Unit-Testing-is-Waste.pdf https://rbcs-us.com/documents/Why-Most-Unit-Testing-is-Waste...
- polskibus 9y agoI 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.
- rinchik 9y agoI 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.
- polskibus 9y agoAs 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?
- silvestrov 9y ago> 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.
- bradknowles 9y agoIt works on iOS, and I think there are a lot more iPhones out there than win7 desktops. ;)
- thinkpad20 9y agoBe 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.
- cormacrelf 9y agoMoreover, 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".
- bpicolo 9y agoGoogle Charts is a solid lib if you need the go-wide support
- tehlike 9y agoIf you also support react native using their canvas, it might be a pretty sweet addition. Plotting libraries are somewhat missing in react-native.
- rushabh 9y agoAlso checkout the Gantt lib we published earlier https://frappe.github.io/gantt https://frappe.github.io/gantt
- dylz 9y agoDoes this support arbitrary time spans? Like from minute 1 to minute 58 without any other date/full date?
- hackNightly 9y agoWell done!
- deleted 9y ago[deleted]
- _ar7 9y agoReally cool that this is built completely from scratch. I expected a dependency on something like d3 at least.
- pratu16x7 9y agoThanks! 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.
- taupefrancis 9y agoNice work. The code itself is clear and concise also.
- rushabh 9y agoThank 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.
- bobrown101 9y agoYeah 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.
- techaddict009 9y agoThis 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?
- matt4077 9y agoThe second example seems to do just that, if you switch to "line chart".
- sjroot 9y agoI 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.
- pratu16x7 9y ago> 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 https://github.com/frappe/charts/issues
- boffinism 9y agoQuestion: 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?
- paultannenbaum 9y agoYou 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 https://github.com/frappe/charts/issues/6
- pratu16x7 9y agoUpdate: https://www.npmjs.com/package/frappe-charts https://www.npmjs.com/package/frappe-charts
- TheAceOfHearts 9y agoIt 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/ https://webpack.js.org/loaders/exports-loader/
- mmcnl 9y agoNo stacked bar charts, unfortunate. Looks really nice.
- achillesr 9y agoit's called - "Contribution". https://i.imgur.com/gKQ7EMP.jpg https://i.imgur.com/gKQ7EMP.jpg
- harunurhan 9y agoLooks 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.
- codazoda 9y agoSome 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/2009/10/Realizing-Quality-Improvement-Through-Test-Driven-Development-Results-and-Experiences-of-Four-Industrial-Teams-nagappan_tdd.pdf https://www.microsoft.com/en-us/research/wp-content/uploads/...
- RubenSandwich 9y agoI 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?
- iamflimflam1 9y agoInteresting - 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.
- bonyboy 9y ago
- valar_m 9y agoReally nice work on this. Does it support pie charts currently? If not, any plans to do so in the future?
- pratu16x7 9y agoCheck 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-pie-charts http://www.storytellingwithdata.com/blog/2011/07/death-to-pi...
- koolhead17 9y agoLooks Neat. Great work folks.
- dabernathy89 9y agoThe annual heatmap is particularly cool, and not something I've seen in many (any?) other libraries.
- pratu16x7 9y agoWe used cal-heatmap (https://github.com/wa0x6e/cal-heatmap https://github.com/wa0x6e/cal-heatmap) earlier. It's pretty neat.
- dabernathy89 9y agoLooks awesome, thanks for sharing!
- jazoom 9y agoThis looks great. Can I ask why you didn't use chart.js?
- developer2 9y agoI 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.
- opmac 9y agoBecause Javascript.
- pratu16x7 9y agoThe 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 :)
- jazoom 9y agochart.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. :-)
- m1 9y agoAny support for realtime/updating graphs on the fly?
- eridius 9y agoIs 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.
- pratu16x7 9y agoWe 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?
- avenoir 9y agoWell timed. I'm in the middle of trying to figure out how to replace some C3 charts. Looks very nice!
- keithnz 9y agoThe 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
- dnprock 9y agoYou 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.
- pteredactyl 9y agoD3 doesn’t have dependencies. Why use this?
- ryantbrown 9y agoD3 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).
- cormacrelf 9y agoLots 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
- pteredactyl 9y agoYea, I’ve found similar use case where any custom work is much better off done using raw d3.
- kapauldo 9y agoThis is great. Thank you!
- prashnts 9y agoIt'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?
- netchampfaris 9y agoYes, 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.