-
Notifications
You must be signed in to change notification settings - Fork 923
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
QuickJS Project Health Check-in #188
Comments
I've been trying to get an update on this project's status for nearly 2 years now. Neither the QuickJS mailing list nor @bellard himself have been responsive. You could try e-mailing him directly, provided he's still alive. |
I've noticed that there haven't been any commits in over a year, and there are a few Pull Requests that are still lingering in the open state.
You may note that the GitHub page specifically says to submit patches via this mailing list, not GitHub. So there would more contributions if they were received.
How is everything going? Are there any plans to continue the project? Do you need any help and / or are you hoping to transition ownership at some point in the future?
In my opinion the project needs ownership to be transferred, or a fork. Fabrice hasn’t been around for some time, and even concerns about security and correctness have gone unanswered. At my last job I advocated for QuickJS usage over a coworker’s concerns about the project’s maintenance. I’m left eating my hat (metaphorically) on that one.
If Shopify or someone else with the resources are willing to pick it up, I suspect a lot of interest would follow.
Cheers,
-Felipe
|
There is this fork, which has been a bit more lively and is in active maintenance by the OpenWebF team. This fork has also seen some performance improvements, though, I haven't yet tried them out. |
It's more complicated than that: Fabrice uses SVN, and development happens behind closed-doors. Hell, I was actually the one who nagged Fabrice into making a GitHub mirror. So any future changes made upstream will not only appear in a tagged release, but will also need to be "ported" from SVN to any forks of his Git mirror.
Honestly, I don't blame you for advocating. This project has so much potential, and with such widespread community interest, it's insanely frustrating that Fabrice is apparently unwilling to transfer maintenance of the project (which is something he did with FFmpeg, and we all know how that project turned out… 😉) |
Hey there! I share the sentimet here, as an early QuickJS user on my txiki.js runtime. I had the chance to have a face to face chat with @chqrlie at FOSDEM earlier in the year and he was open to the idea. Unfortunately things got complicated for me so I couldn't follow-up much :-/ Things are better now and I'd be happy to participate in a community effort and reignite it.
Is it necessary though? The community could gather elsewhere. I got https://github.com/quickjs-contrib but @chqrlie was working on getting https://github.com/quickjs as the new project home. |
Without an official passing of the torch (or even just definitive confirmation that QuickJS has been discontinued), there's no guarantee that Fabrice won't resume development on the project after years of ostensible abandon. This can have ugly consequences for a community-led continuation of QuickJS, assuming it's managed to establish itself as a de facto successor. Worst case scenario, QuickJS v2027-02-28 (or whatever) is released out-of-the-blue, turning the past 4 years of community efforts from an unofficial continuation into a feature-incompatible fork of the same name. Best case scenario, this never happens, and QuickJS lives on in multiple, divergent paths of development (à la, BSD). These corollaries aren't supposed to be deal-breakers, but if there's a cleaner, saner way to avoid future frustration and chaos by having Fabrice agree to pass on stewardship of QuickJS to an actively-interested community… well, it'll surely contribute to a healthier future for QuickJS. |
I confess I'm more concerned with Fabrice's well-being instead of QuickJS. The last time he did something was on March 6, 2022 (link) with just one day of activity in the whole year of 2022. Also, 2021 was no different. |
He is not active on GH generally speaking. |
I assume he's okay, judging by his recent activity in an unrelated project.
IIRC, the best way to get in touch with @bellard is by e-mail. |
I tried to reach out as well to no avail... so here we go, QuickJS-ng :-) https://github.com/quickjs-ng/quickjs A friendly fork aiming to bring it forward in terms of features and platform compatibility. Update:
|
Congrats @saghul ! Just saw the announcement in the ECMAScript Newsletter, too, so hopefully that makes the project gain some momentum from a consumption perspective. I look forward to giving it a go, myself! |
Oh what newsletter is that? |
This one: https://ecmascript.news/ In particular, the one from yesterday: https://ecmascript.news/archive/es-next-news-2023-11-28.html |
Oh, thanks! |
bellard has started contributing to the repo again, so atleast for now quickjs isnt dead! happy to see work being done in GH than just the mailing list |
Hi there!
I've been keeping an eye on this project for a few months now, and have recently started exploring its use. I've noticed that there haven't been any commits in over a year, and there are a few Pull Requests that are still lingering in the open state.
How is everything going? Are there any plans to continue the project? Do you need any help and / or are you hoping to transition ownership at some point in the future?
There has been some excitement at Shopify regarding their javy WebAssembly framework and its usage of QuickJS that may likely put more eyeballs on QuickJS.
Hope to hear from you, and thanks for building a killer project!
The text was updated successfully, but these errors were encountered: