Closed krausest closed 1 year ago
Hmm well we had planned to move to marionette
and remove the backbone
dependency. A lot of that got derailed during some departures during covid. I believe I added the alpha here. Then interestingly backbone was revived a bit.
backbone.marionette
is complete AFAIK outside of any security alert and would be superseded by marionette
if/when there's progress made. The library is perhaps surprisingly still in use so I don't consider it dead, but it certainly isn't overly active. I doubt people are looking up benchmarks on it. However if marionette development gets going again I'd certainly continue to test it against this library. Whichever.
hullo
yes, for both tests
sure thing, I am not planning on further development of callbag-jsx
with any substantial changes, and it also has a minuscule user base so I can just refer to my own fork for whomever wants to run the benchmark for themselves.
1more is on pause, but I'm planning to continue development. I'd keep it for representation, as one of examples of VDOM diffing + template literals.
Sounds good, I've stopped the development of Isotope
, since I've discovered Solid.js. :)
FYI my lib are still maintained and working … there’s a difference between zero activity and done. No bugs means done and, unless deprecated on either the repo or the npm registry, there’s no reason to drop these libraries. hyperHTML is in maintaining mode so maybe that’s ok, the rest simply works …. It’s like removing vanilla js test because no changes happened in years … I don’t get this metric.
@WebReflection It's perfectly fine to keep your frameworks if they are still maintained. Most dead frameworks so far died without announcement. The metric might not be perfect, but it's a good indication to start asking whether it's actually dead. What about hyperHTML? Should we keep it?
@krausest you can remove hyperHTML as it's "legacy" compared to others and not interesting in results ... I will try to bring in udomdiff which is domdiff successor but until that please keep domdiff around, thanks! Others might be also replaced by udomsay but these are hooks alternatives (heresy, neverland, lighterhtml) so thanks for keeping these around for the time being.
@krausest Reaml is not maintained anymore, you can remove both reaml-react and reaml-preact.
Knockout is certainly still in use across the web, although I doubt any new projects are selecting it as the framework of choice. There is a v4 rewrite underway, but that will be a significant breaking change from v3.
I'm planning to publish a pretty large skruv update soon, and I have a local branch to update the js-framework-benchmark tests for it, so if we can keep it that'd be nice.
I don't know you @rahulcs but I'm pinging @tornqvist and @yoshuawuyts for the @choojs case. I'm not monitoring it nowadays.
I no longer see doohtml on the current results. What is the reason?
https://krausest.github.io/js-framework-benchmark/current.html
On Fri, Dec 30, 2022 at 12:30 PM Stefan Krause @.***> wrote:
Closed #1146 https://github.com/krausest/js-framework-benchmark/issues/1146 as completed via 0d87866 https://github.com/krausest/js-framework-benchmark/commit/0d87866c7c945b37f492c64c914353746e86be02 .
— Reply to this email directly, view it on GitHub https://github.com/krausest/js-framework-benchmark/issues/1146#event-8131645938, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABUCUQIOVSZOCOBXYMSZKATWP5A5VANCNFSM6AAAAAASMSH6CQ . You are receiving this because you were mentioned.Message ID: @.*** com>
The last pull request was on Nov 7, 2022, why is that considered no activity? https://github.com/krausest/js-framework-benchmark/pull/1129
On Fri, Dec 30, 2022 at 4:30 PM Henrik Javen @.***> wrote:
I no longer see doohtml on the current results. What is the reason?
https://krausest.github.io/js-framework-benchmark/current.html
On Fri, Dec 30, 2022 at 12:30 PM Stefan Krause @.***> wrote:
Closed #1146 https://github.com/krausest/js-framework-benchmark/issues/1146 as completed via 0d87866 https://github.com/krausest/js-framework-benchmark/commit/0d87866c7c945b37f492c64c914353746e86be02 .
— Reply to this email directly, view it on GitHub https://github.com/krausest/js-framework-benchmark/issues/1146#event-8131645938, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABUCUQIOVSZOCOBXYMSZKATWP5A5VANCNFSM6AAAAAASMSH6CQ . You are receiving this because you were mentioned.Message ID: @.*** .com>
@hman61 My metric to check for activity didn't work for doohtml, since it's not installed via npm. I'm sorry and I'll restore doohtml soon. Do you consider publishing doohtml on NPM?
Yes, I’m definitely going to eventually publish it to npm, but I’m not doing it until I decouple the data store, so that it can work with any popular data store.
On Fri, Dec 30, 2022 at 6:13 PM Stefan Krause @.***> wrote:
Reopened #1146 https://github.com/krausest/js-framework-benchmark/issues/1146.
— Reply to this email directly, view it on GitHub https://github.com/krausest/js-framework-benchmark/issues/1146#event-8132137285, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABUCUQM4LDRDEZ7YFJN4H2TWP6JDXANCNFSM6AAAAAASMSH6CQ . You are receiving this because you were mentioned.Message ID: @.*** com>
Can you send me the reason why the latest DooHTML was not merge?
On Sat, Dec 31, 2022 at 2:43 AM Stefan Krause @.***> wrote:
Closed #1146 https://github.com/krausest/js-framework-benchmark/issues/1146 as completed via f236681 https://github.com/krausest/js-framework-benchmark/commit/f23668176e39e1168bc5a16b9d73b0d94ef329df .
— Reply to this email directly, view it on GitHub https://github.com/krausest/js-framework-benchmark/issues/1146#event-8132560827, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABUCUQO4D4N2ISDBY6FT6CDWQAE5BANCNFSM6AAAAAASMSH6CQ . You are receiving this because you were mentioned.Message ID: @.*** com>
https://open.spotify.com/track/4NLNaPIqMMrYBUrC7101gg?si=329d44113c3a4826
Keyed Frameworks that seem inactive > 1 year:
callbag-jsx and callbag-jsx-list @loreanvictorhyperHTMLisotope @areknaworeaml @utkarshkukretiPlease let me know if we should make an exception and not retire an implementation.
Some of the bigger frameworks seem to be inactive for more that a year:
Should we consider them dead?
BTW I'm not asking about the non-keyed implementations. They will be removed if no updates within the last year happened. Those are: