Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Resume of Dygraphs development #975

Closed
tomaszs opened this issue Oct 22, 2019 · 9 comments
Closed

Resume of Dygraphs development #975

tomaszs opened this issue Oct 22, 2019 · 9 comments

Comments

@tomaszs
Copy link

tomaszs commented Oct 22, 2019

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?

@leeoniya
Copy link

leeoniya commented Oct 22, 2019

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] #948

@danvk
Copy link
Owner

danvk commented Oct 22, 2019

@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

@leeoniya
Copy link

leeoniya commented Oct 22, 2019

@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.

@danvk
Copy link
Owner

danvk commented Oct 22, 2019

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.

@leeoniya
Copy link

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.

@lmizinski
Copy link
Collaborator

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?

@danvk
Copy link
Owner

danvk commented Feb 18, 2020

@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.

@GitHunter0
Copy link

I hope you can resume this very useful package, thank you for the effort

@mirabilos
Copy link
Collaborator

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).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants