dygraphs
dygraphs copied to clipboard
danvk
Resume of Dygraphs development
Hello,
I have been using Dygraphs for some time now, and find it very useful. I think a lots of you can confirm this. Unfortunately the project is discontinued for almost 2 years now. And from what i have read, author who created this amazing component (thanks danvk!) does not seem to be able to continue the development.
Since that, i am wondering what we could do to proceed with the development. We have some pull requests that could be merged and deployed to a new version. Also maybe, other people would be willing to provide more contributions based on their modifications?
i think it's very challenging to dive into an unfamiliar codebase when the author cannot dedicate time to a transition, as seems to be the case. my ready-to-go PR [1] has been in limbo for quite some time.
since then, i have written a dygraphs replacement for myself (called uPlot) for the features which i needed. there are no plans to recreate all of dygraph's features, but it may be useful for many looking to use something small & fast.
https://github.com/leeoniya/uPlot
[1] https://github.com/danvk/dygraphs/pull/948
@tomaszs thanks for the message. I've added you as a collaborator, feel free to merge any PRs you like. I still find dygraphs to be a very useful, flexible library whenever I want to visualize time series. I'd love it if someone else could pick up development.
@leeoniya sorry for letting your PR go stale! uPlot looks very cool. dygraphs added enough features and data formats early on that it's not able to make as pure a play for performance/code size as uPlot does.
I've been writing a book on TypeScript this year (pre-order now!) and, as research on migrating JavaScript projects to TypeScript, I ported dygraphs. You can see that work here. This would obsolete most of the open PRs, but might be an interesting direction for the project to go. It certainly exposed some odd aspects of the design of this library, e.g. the 48 member variables of the Dygraph class:
https://github.com/danvk/dygraphs/compare/typescript#diff-e48394c1ce13d76c0788885bafd4575cR89-R136
Context: #727
@danvk i hear ya, maintaining open source projects is a thankless job.
dygraphs added enough features and data formats early on that it's not able to make as pure a play for performance/code size as uPlot does.
dygraphs is a great lib, though admittedly written in a different time (browser perf-wise) and a different landscape (js ecosystem-wise). As the saying goes, "There are only two hard things in Computer Science: cache invalidation and naming things."...and resisting scope creep.
as research on migrating JavaScript projects to TypeScript, I ported dygraphs. You can see that work here. This would obsolete most of the open PRs, but might be an interesting direction for the project to go.
i think it would be useful to possible maintainers that you clarify whether you plan on continuing dygraphs as a TS project or if it was just something to work through for your book. personally, i would not be terribly motivated to contribute to the current master that will become "the old version" in 6mo.
as for TS itself, i have mixed feelings. i certainly see the benefit (especially when used with an IDE/VSCode), but for me personally, the inline type annotations greatly clutter the code and make it less readable despite its self-documenting nature. i tend to be on the side of providing a .d.ts for a public API but for my own single-maintainer projects, i stick to pure JS.
Not going to get dragged into the TS vs. JS debate here :)
To be clear, my intention is not to make a new version of dygraphs that is in TS. I just wanted to point at the work that had been done towards that end if anyone else wants to continue it.
Not going to get dragged into the TS vs. JS debate here :)
not trying to convert anyone or debate. i only brought it up because the qty of JS devs >> TS devs, which is probably relevant if you don't intend to maintain the lib yourself. i'm in the camp that would not likely sign up to maintain a TS codebase but i'm certain there are plenty of others (besides yourself) who have exactly the opposite view.
To be clear, my intention is not to make a new version of dygraphs that is in TS. I just wanted to point at the work that had been done towards that end if anyone else wants to continue it.
ok, cool.
Hi @danvk. Thank you for time and effort you put into this library. It is great tool and makes a lot of things much easier.
Recently I found a bug that cannot be bypassed, so the only way to deal with it is fixing the source code. I could make a fork, but I'd rather help develop Dygraphs. Would you mind adding me as collaborator as well?
@lmizinski thanks for your interest. I've commented on your PR and added you as a contributor. Feel free to merge after adding a test.
That particular behavior is a vestige of the original use case of dygraphs: an internal dashboard for my team in 2006 that happened to use that format for dates.
I hope you can resume this very useful package, thank you for the effort
I think having #727 is probably enough, no need to keep two issues open right now. I’m trying to get a hang of what’s still relevant, at least for things reported for 2.x (older ones need triage or don’t apply any more anyway).
