Emberfire seems to be abandoned
brendanoh opened this issue · 7 comments
There are many disheartened Emberjs developers who feel that Firebase has abandoned the "Official Ember Data adapter for Firebase". I think I can speak for many of us by saying that we love Firebase but are increasingly frustrated.
An issue was opened in Github more than 2 months ago asking if the Emberfire project had been abandoned.
There have been zero responses from anyone from Firebase/Google.
Saying that the "Emberfire repo seems to be abandoned" is not a complaint by an ungrateful developer or me throwing shade, it is the only rational conclusion one can come to by the way this repo has been left to languish for what seems like two years. The fact is the Emberfifre code base most of us are using hasn't been changed substantially since Apr 26, 2017.
James Daniels has a PR opened from 7 months ago that also seems to have been abandoned or at very least deemed so unimportant as to be left unfinished without even an status update in over 3 months.
So I guess I am asking for the EmberFire community:
If EmberFire hasn't been abandoned then can we get an actual update?
Cross posting in the Firebase Google Group
Brendan, after silently spectating the suspenseful lack of an update, I am speaking up to say thanks for your continued efforts to get a status on Emberfire from the Firebase team. I am also a huge fan of Firebase and have not found a faster way to a robust backend. I share your frustration in knowing that James has had a RC in the wings for ages, and that a successful Google product has not allocated the resources to follow up/through. I get the feeling that James' teams are at full capacity, but Google...
James, thanks for your work to date on Emberfire. Could you please schedule a few minutes to provide a clear status? I do understand the merit of usage statistics determining allocation of resources, but the longer Emberfire goes without an update the less merit that metric holds. Here is what I found after a quick visit to npmjs.com:
angular shows 450,909 weekly downloads
angularfire shows 1441 weekly downloads
ember-cli shows 112,385 weekly downloads
emberfire shows 725 weekly downloads
A near obsolete version of emberfire has twice the pickup rate. I think those usage metrics show that Firebase is a good companion to Ember. Firebase provides a serverless backend and Ember provides the "rest of it" for developers who are delivering instant POCs, that can turn into prototypes, and into production.
A status update for the Ember Community is a reasonable re-re-request and a response from Firebase is long overdue.
Thanks all the work you have already done, and hopefully for your attention to these requests.
I would like to echo the previous sentiments wholeheartedly. I did notice that James seemed to have created a new branch (v3-scratch) that has some more recent activity (around a month ago).
Unfortunately, he doesn't seem to engage on this project anymore - either here or on twitter. There is also an open query on the firebase's ember slack channel that wasn't responded to either.
Would just be good to get some sort of official statement one way or another. I'm really struggling to evangelize firebase in my company when we're stuck in this state.
@tastebud I'm going to wait for @jamesdaniels full response here, but you have the wrong metrics.
You need to search for @angular/fire instead of angularfire. You can also include the deprecated package of angularfire2 and you would get ~55k downloads per month instead of 1,441.
I do understand the frustration about a lack of response and that is a big fault on our parts. We needed to be more clear about what's going on. But we do want you do understand that we cannot give a concrete timeline or a future roadmap.
That is not due to a lack of enthusiasm about the library, it's just about time. Contrary to what a lot of people think, working on these OSS libraries are not a full-time position. The work is commonly done in large spurts when time is available. James has been extremely busy and has not had the time to put in the work he wishes he could. However, that doesn't mean Firebase doesn't care about Ember or any other JS framework for that matter. The bulk of our work revolves around the core platform of Firebase. @brendanoh stated that no major work has been done on EmberFire for nearly two years. But in the last two years we've been working on adding foundational platform features like Cloud Functions and Cloud Firestore. We work hard to keep improving the core of Firebase and that makes it difficult to keep each and every library up to date in terms of time and product updates.
Like I said, I'll let James give a full update. But we do care about the JS ecosystem and supporting Ember is a part of that.
At Firebase we really do love Ember. We're trying to turn things around and increase adoption.
In an ideal world Emberfire wouldn't need to exist at all, Firebase would just work out-of-the-box. But that's not the world we live in 😉
Thanks for adding some perspective @davideast.
The original angularfire for Angular.js is actually an apt comparison, but not in the way you're thinking @tastebud. The last update to that library was 2 years ago. It's not abandonware either but stable, suiting the needs of it's users but not necessarily getting active investment. If there is a severe problem it would be addressed or the library deprecated.
@angular/fire (and the older version angularfire2), the Firebase library for Angular, is a different beast entirely. Over a million downloads a year; hosted on the Angular github org; published under the Angular scope on NPM; a prominent table with staff, swag, and talks given at ng-conf every year; and many more behinds the scenes benefits. Now obviously as our paychecks come from the same company we have a closer relationship with much of the Angular team, but a lot of that is due to demand. External communities (such as AngularFirebase) organize on their own and many talks are given on Firebase / AngularFire by people who are not Googlers. If we weren't making a better developer experience for Angular developers someone else would.
Back to Emberfire, beyond the issues mentioned in #542 I've been working with and seeking feedback from organizations whom are using Ember and Firebase but not opting to use Emberfire. I know that's unfair to this small community but I'm just being realistic about what needs to be done for our continued investment in Ember, given (for various reasons) the lesser demand for Firebase. More often then not, it turns out the core devexp issues don't involve Emberfire in it's current incarnation. You won't always see my influence on Github in this regard, as usually it's captured in internal discussions with regard to the Firebase JS SDK, but occasionally a keen eye might.
FWIW AngularFire actually went through a similar exploration and we were unstable for several years. I was hoping to spare this community from an experience like that by developing on the v3 branch but it seems unless I'm cutting RCs on latest people will continue to believe there is no investment and Firebase is not worth adopting. Also, there's also some internal tooling issues with branches that I'd rather not dive into (which is why there isn't an NPM release on another tag).
Next steps
I'm going to start developing version 3 on master and cutting RCs on NPM latest. @davideast and I did this with AngularFire. While it did irk some folk, it better manages expectations. Namely that version 3 is unstable but the one being actively invested in, version 2 is in maintenance mode.
Currently I'm writing a more robust test suite and documentation tooling, which is turning out to be a bigger rabbit hole than I thought (one of the reasons why I've not had a commit on v3 in a while). Once that is done, hopefully very soon, I'll merge and start cutting releases. In the meantime, I will pin both this and the v3 proposal issues.
Please bear with, I know all of this could have been handled much better but I'm really trying to stay motivated while maintaining a semi-rational balance between this and my other responsibilities.
Feel free to continue to discuss but if the conversation goes in a direction that is not conductive to getting version 3 out the door, I will start locking threads for my mental health. To be frank, if I burn out there won't be an Emberfire.
Thanks for starting the conversation @brendanoh.
I say this with utmost kindness and respect — but Google has some deep pockets, why not hire an extra hand to help you? If they offered remote I’d immediately apply myself. And of course I realize you have to weigh out the value proposition as you just did, and it’s great you’re sharing all that with us, but I think it’s largely about marketing and gaining new users. Googs shouldn’t expect this to be a profit center, at least not without more marketing effort behind its existence at all. I think Ember and Firebase really offer something combined that hugely outweighs the sum of parts. It’s the new rails 15 minute blog story, only way way way better.
I love Firebase but it’s only because of your hard work on this addon that it offers me any real value. So, forget everything else, thank you for your contributions here. I learned a lot even if I have to reconsider my infrastructure and write a server eventually.
Thanks @jmonster.
Obviously can't speak to how things work internally; but if it blows up like that it will probably get more resources 😜 Has a couple orders of magnitude and some more low hanging fruit to go before that conversation though. So tell ya friends, do a lightning talk at your local Meetup, etc. 😉
Hoping v3 gets us further along.
@jamesdaniels first thanks for your contributions.
The biggest problem for me was not that there is no active development. But I missed the Firestore so much. The Ember Data Adapter for the Realtime Database worked so good. And something like that for the new Firestore database would be just amazing.