Is rivets still being maintained?

[richardbatty]

Given that there are 110 open issues and 27 open pull requests, is rivets still being maintained by anyone?

[benadamstyles]

👍 I hope to God it is, I live for this library!

[MishaMykhalyuk]

+1 for this issue

[benliebert]

Yip, I concur - best library I've found.

On Sun, Jun 21, 2015 at 6:51 AM, Ben Styles notifications@github.com
wrote:

[image: 👍] I hope to God it is, I live for this library!

—
Reply to this email directly or view it on GitHub
#500 (comment).

ben liebert
blackball software ltd, www.blackballsoftware.com

[jpotterm]

I hope Rivets will still be maintained, but for anyone that needs an immediate alternative, you could look at Vue. It's a very similar project that seems to be more active at the moment. It looks like it has taken a lot of concepts from Rivets. I switched because #486 was a blocker for me.

[benadamstyles]

@jpotterm Just purely curious, why was #486 a blocker for you?

[jpotterm]

@Leeds-eBooks because I needed to bind parent data inside a for loop. I needed an active state on one of the items in the loop which depended on comparing it with a property of the global context that referenced the active item. Because of that bug the active state wouldn't update when I updated the global reference to the active item. The only solution I could think of would have been to write my own each directive which is well beyond my skill with Rivets.

[Duder-onomy]

@mikeric Can you weigh in on this? We all love this library and some of us would be willing to take on some work. The last we heard from you was March 24.

My opinions:
I think someone should go through and close most of the issues and PR's this repo has. It is my feeling from looking through them, that the vast majority of them are not valid and should be closed. Doing a little cleanup should reveal any more work that needs to be done.

It would be non trivial, but I think it would be very helpful for the future of this library to transition this back into pure JS, and I would be willing to take some of this work on. This would make the library more accessible for javascript engineers to work on and help push forward.

[gaydenko]

@jpotterm , it's funny situation. You are suggesting vue.js, and yes, it is excellent framework. I have mid-size project in hand with active vue.js using. But after 0.10.x there was full framework rewrite wiht big API changes. At the moment I have decided to look at own code upgrading path and discovered a fact making me sad. vue.js is almost bloated now, about 220 Kb (and was about 120 Kb). So I'm looking for something more focused on just databinding/templating, where rivets.js is the King. You see, it is an opposite direction with regard to your suggestion :) And, of course, inevitably I have found this issue.

So, I'm the next saying to @mikeric : "we need you!"

[jpotterm]

@gaydenko It's true that Vue isn't at v1.0 yet so the API may change and Rivets goal is definitely to be incredibly small and light and it does a good job. But there's not as big of a size difference as you make out. For the minified (not gzipped) versions Vue is 67 KB and Rivets is 25 KB. Vue is only 220 KB for the nonminified version which is mostly comments. Granted that's still more than twice the size. It's funny we went opposite directions :)

[woozyking]

👍

[benadamstyles]

Do you guys (especially @Duder-onomy as I know you've followed Rivets for a while now) think it's worth emailing @mikeric ? There are 30 pull requests waiting now, and there are clearly a lot of people who use and rely on this fantastic library.

If so I'm happy to do it. What do you think the angle should be? Is it too early to suggest translating Rivets to JavaScript (preferably ES6)? I'd happily take on the duty of working on Rivets but I can't do that in CoffeeScript.

[mikeric]

I've started a branch a couple of months ago to rewrite the whole codebase using ES6 (compiled with babel using webpack). It's mostly done, but I feel like there needs to be more concrete tests in place first to ensure things are working the same as before, so still a bit of work to do on that end. I will commit my progress and push the branch up if someone would like to continue down that path (or start fresh if need be).

If anyone is interested in contributing and wants to help get this project back in motion, I'd be more than happy to give push / commit access (@Duder-onomy? @Leeds-eBooks?).

[benadamstyles]

@mikeric This is fantastic news. I'd love to get involved.

[Duder-onomy]

@mikeric I would also love to help out. Though, to be honest, I think your code/kung fu is significantly better than mine. But I will give it a shot. If anything, I would love to help write tests and documentation.

The one thing I will say, Do you think it will be possible to get the each binder to keep items in order? That is the one thing I would love to dump some hours into if a full rewrite is going down. If the middle item is removed from the bound collection, the middle item is removed from the dom.

[benadamstyles]

What should be the first step? @Duder-onomy you suggested above that someone go through the pull requests and close / merge them. I think this is a really goo idea. We could share this work, unless @mikeric is able to do it? And I don't know what the etiquette / standard practice is in these situations, I guess if it's clearly not a valid request, just close it, and if we're not sure, put it to discussion?

[Duder-onomy]

@Leeds-eBooks

My two cents:

Issues : Start with oldest first

• If it is obviously a moot point just close.
• If it is still a possible real issue, we reach out the issue initiator and give them 1 week to respond or else we close it.
• Moving forward, we ask issue creators to close issues if they feel like their question was answered. So that we can keep the issues real and few.

Pull Requests : Start with oldest first

• If PR is a feature request - Inform the initiator that Rivets is being rewritten with es6 and if they feel passionately about their feature, offer to inform them when the rewrite is nearing completion so that they might re-make their PR. Take note of the feature. Then close the PR.
• If the PR is a bug fix - Ensure that the bug is present in the latest build. We write a test for the failing case to be used in the re-write's test suite. Take note of their fix and ensure it makes it into the re-write. Close the PR, but ensure they get credit.

During the closing of issues, we should make a note of issues that have come up more than once. These should be good candidates for documentation, examples and possibly features.

What say you?

[benadamstyles]

Sounds spot on to me. @mikeric ?

[mikeric]

@Duder-onomy, @Leeds-eBooks Yea, that sounds like the right direction. I've added you guys as collaborators, and I've added my branch with the initial effort to convert from CoffeeScript to ES6 here (#511).

After we get all the old issues and pull requests sorted out, get the codebase moved over to ES6 and have better tests in place, I'm hoping we can look at refactoring a lot of the classes into higher-order functions and make the codebase more functional and stateless.

Sorry for the long delays on here, been quite busy with other things lately.

[benadamstyles]

@mikeric Thanks man, taking a look now. And I am so behind the idea of going down the more functional route.

[benadamstyles]

@mikeric Just pushed a commit to es6 branch, hope that's ok!

[mikeric]

@Leeds-eBooks Definitely, thanks and feel free to continue on it or suggest anything else that needs to be done. Maybe let's comment on that pull request if we are working on something so that we don't duplicate efforts. I won't have time to work on it for a little while though..

[Duder-onomy]

@mikeric I am seriously honored. Thanks

I will devote this weekend to getting my ducks in order.

Some things I will champion in the short term:

• making the documentation incredibly bad ass.
• making the test suite incredibly thorough.
• reducing the open issues, only "real" bugs and not questions.
• getting the each binder to keep the DOM in the order of the bound enum. (when one gets taken from the middle of the enum, then one gets taken from the middle of the DOM)

[shannonmoeller]

How is this coming?

[benadamstyles]

@shannonmoeller my fellow maintainers seem to have gone a little quiet, I think they are busy with other things at the moment. Do you have any time to help out? What would be really cool is if you could try the es6 branch out in one of your own projects.

[shannonmoeller]

@Leeds-eBooks I might have time to help out as I'm looking at using this in the theming layer of toga.js. My first priority is going to be a performance test of Rivets vs JS template strings and live dom patching.

[benadamstyles]

Nice, toga.js looks really cool. I think you'll find perf to be good. Well any
feedback you can give on how the es6 branch works out for you will be really
helpful!

On Wed, Sep 9, 2015 at 14:26, mikeric/rivets
reply@reply.github.com
wrote:
@Leeds-eBooks [https://github.com/Leeds-eBooks] I might have time to help out as I'm looking at using this in the theming layer
of toga.js [http://togajs.com] . My first priority is going to be a performance test of Rivets vs JS template
strings and live dom patching [https://github.com/fiduswriter/diffDOM] .

—
Reply to this email directly or view it on GitHub
[https://github.com//issues/500#issuecomment-138908421] .[https://github.com/notifications/beacon/AELX7_E9kYC5f82nxV7rXOswvw5n3Ufkks5owCsWgaJpZM4FHFfz.gif]

[stalniy]

@Leeds-eBooks, @mikeric looks like the project is dead.

First think in to do list should be unit tests then all clean up stuff may happen

In order to understand if we are on the right direction we also need code coverage tool

[benadamstyles]

@stalniy It's certainly not dead. It does seem like I am the only one of the recently added contributors who is at all active on this repo and I don't have the time to take this on single-handedly. I'll try and go through as many PRs this week as I can.

Personally I don't think code coverage is a priority. Unit tests are there already – if you want to add to them, please do go ahead and submit a PR.

[stalniy]

@Leeds-eBooks ok but as far as I see the last update of master was like 10 months ago. Es6 branch has not finished yet and there is small amount of tests

I can help to improve the project but I also need a quick response as currently this library is used in production on the project I'm working on

[blikblum]

@Leeds-eBooks Given the overwork you are submitted, is not the case to add commit rights to more contributors? I'm willing to do such job if you feel appropriate.

Recently, i digged deep into inner works of rivets and i'm confident that i can help. Rivets perfectly fits my needs of a library that increases productivity and also integrates well with others so i'm pretty interested that it evolves.

As for the short term project direction "per si", it was clear that all new work should be done in es6 branch. But i think is a bit premature to do a release with it and the mem leaks fixes (see #546) justify a new release based on master (coffeescript). Additions like #545 and #487 are a no-brainer and small enough that can be included in a short term release.

cc @mikeric

[benadamstyles]

@blikblum I agree completely with everything you've said, but I'd really like @mikeric or at least one of the other contributors, @Duder-onomy for example, to agree to this as well before I add any contributors or make any new coffeescript releases (particularly as I have little experience with coffeescript). Hope you understand that, I have not been a contrib for long and I don't feel I have the authority to make big decisions yet. In fact, I'm not sure I even have the access level to add more contributors.

[Duder-onomy]

@blikblum You have been very active these last 2 weeks! Awesome! Rivets is really great isn't it!
As far as the repo being active, that could not be more false. It is more alive than it has ever been. Personally, as time goes on and I work on apps using other similar libs, I constantly find myself saying, "Man, if I could only get some Rivets up in 'er" Many people are using it in production. I understand that you would like to add more features to suit your use case. This is great. I have no fear of you being a contributor as you seem to know what you are doing and you are being a good person by updating the readme and writing tests.

@stalniy I understand it is frustrating then when a library is not moving as fast as you want it to. I will review your PR's tonight and get back to you ASAP.

@stalniy @blikblum Your work is incredibly appreciated! I will get ahold of @Leeds-eBooks and see how we should handle this. I don't think either of us have the permissions to give anyone contributor access.
Though, at the very least. We will make sure you are getting the fixes and updates you need. If you stick around a while and continue to help, I will personally reach our to Mike and ask him to get you contributor access. (this goes for anyone else reading this)

[blikblum]

To be clear, one of the reasons that i stick with rivets is its small, focused scope when compared with other solutions like RiotJS, Vue and Ractive. So basically i don't need / want to implement new features. In fact, personally, i would remove some of them ;)

The only place that i think may need some more work is component, which lacks some features to deliver what promises

My main focus right now is related to performance and memory usage (see my previous posts and my PRs). I also think that how scope is handled between nested tags / components needs to be made clear and consistent.

[Duder-onomy]

@blikblum Totally agree about rivets being small and focused.

Thanks for all your work. I will be reaching out to @Leeds-eBooks shortly and see what we can do about getting some of your work into the repo.

[jccazeaux]

I'm happy to see Rivets is still alive. I'm a big fan of it. I integrated it in a custom MVVM framework i made for my company (looks like Angular, but very very less complex). I think Rivets has a great potential.

@blikblum i totally agree with you and hope Rivets will stay small and efficient. You're speaking about memory usage. I suggest you take a look at sightglass concerning the issue #430. The solution is pretty simple and i think it should be merged.

I have some other suggestions, i'll write the issues as soon as possible.

[benadamstyles]

@jccazeaux Yeah I'm also really happy that it's stirring from slumber, and that's largely thanks to you, @blikblum and @stalniy. I'm sorry I haven't been more hands-on but I never expected to be the main conduit for new code into this library! I will endeavour to keep responding to and merging any PRs that feel to me like they are undoubtedly the right thing for rivets. For any things which feel to me like new philosophical directions I will need to get more consensus.

Unfortunately I don't think anyone except @mikeric has push access to sightglass.

[blikblum]

@jccazeaux I also spot the same issue as you in sightglass. Together with other fix would fix the memory leaks. Let's wait a little more for @mikeric to merge the PR.
As to memory usage there's a lot of room to improve. I'll post about it later.

[Duder-onomy]

I am going to close this. Rivets is being maintained. If we still cannot get ahold of @mikeric for another month or so, and his absence continues to stop progress, we should open the floor up for a fork.

[boussou]

So... what is the status now?
maintained? forked?

[gitowiec]

Hi, what's up? Everything seems happened a year ago...
I hit #427 so I just checked other issues, and maintenance status just came up. @mikeric could you post on Twitter for a maintainer if you are out of time?
Best regards

[jccazeaux]

I hope it's maintained. @Leeds-eBooks are you still there?

[benadamstyles]

I am here, but so busy and also I'm using Rivets less than I used to, which makes it hard for me to dedicate time to it. I would love for more people to be involved in maintaining this repo. I don't know how many people have push access, but it feels like for a while it has only been me merging PRs, and that's not sustainable.

[blikblum]

maintained? forked?

I forked it here https://github.com/blikblum/rivets/tree/svelte

It fixes some bugs (see notes) and improve memory usage and performance.

It has a few breaking changes though.

I will at least fix the bugs with rv-each desync after array changes

As for performance you can compare this with this

Time allowing i will change the binding compilation to build time allowing remove the current performance bottleneck

[Namek]

I do not maintain the project directly but I looked into it from time to time as you would see from issues. Now I don't use it anymore since I left my job.

However, I managed to write two articles about rivets:

https://www.namekdev.net/2017/05/my-small-secret-web-weapon-to-bind-things-rivets-js/
https://www.namekdev.net/2017/05/binding-with-rivets-js-details-and-tricks/

[jccazeaux]

I don't know either how many havec push access. @mikeric can you tell us?
If I had access I could do some updates.

[boussou]

@blikblum Hi, your fork uses direct JS right? I did the same, adding comments on the compiled coffee.
I think your version is perfect for me: especially your work to resync after array change.

The whole is 1500 SLOC for an equivalent of vue.js : amazing anti-bloat piece of code.

[jccazeaux]

@blikblum Maybe you could send PR here for your non-breaking changes?

[blikblum]

There are some issues

• the branch is written in es6
• the relevant changes are breaking
• the non breaking are just cosmetic

[TilP]

I am a fan. I am an avid AngularJS user, familar with the newer Angular too. Rivets is a fantastic library, I plan to use it to simplify projects. I think the Industry is overcomplicating things a bit. Thanks