I haven’t been super active in these forums but actually came by yesterday to gripe about some of these exact things This thread caught my eye and I have spent the rest of the time reading it. Some of these things I have probably griped about in detail to some of you personally before – hi @lukemelia and @mixonic I am obviously thankful for Ember and all the work that everyone has done, and feel passionately about the fact that it could be made even better, so please don’t take offense to anything here.
By way of explanation, and to mirror what some others have said in this thread, there is a group of users whose issues are being ignored because of the current makeup of the core team. I took a peek and as far as I can tell @machty is the only core team member that appears to be working on a small product team, most everyone else is a full time ember consultant, with a couple working in large orgs. My experience mirrors almost exactly what @domchristie said here and@2468ben said here. You are missing the perspective of a key constituency who is using your software, and betting their businesses and careers on this community’s success. I don’t think this means you put real representation of us ‘amateurs’ into core necessarily, but perhaps some other mechanism can be found to alleviate this blind spot.
Like many in this community, I came from the Rails world. I have been using Ruby and Rails since pre Rails 1.0, so have gone through a lot of transition there. I have used just about every other Ruby ‘framework’ as well (merb,sinatra,grape,webmachine,etc). None of the pain around big bang releases, or the introduction of concepts like Bundler and rvm in Rails compares in any way with the magnitude of pain currently experienced by Ember programmers trying to use this framework for professional work. Yes, bundler and rvm were rough in the beginning and if you were upgrading from rails 2->3, 3->3.2, or 3.2 -> 4 it was a significant effort, but it was doable, and totally possible to put surrounding issues in the rearview mirror once complete. We have 2 relatively normal (from my perspective) Ember applications, 1 is in production, with the other one going to production shortly. We also have several ruby/Rails applications in our list of responsibilities, and I manage the team. This means that I don’t spend every single waking moment reading about Ember and scouring the internet for changes and quirks that have happened. Right now I probably work on our Ember applications 4-5 days a month in aggregate, and I am spending > 50% of my time dealing with platform quirks (ember-cli, npm, bower, builds, etc) instead of writing application code. Literally, every time I pull our app from the repo after leaving it alone for a few days or a week, there is a build issue somewhere in the stack. When this happens my instinct is to think: “Hey, maybe I am just out of date and I should upgrade the entire world?” (ie, ember, ember-cli, our various dependencies). This never works, because the same problems exist in every other layer of the stack, and you just get all of them at once. The resolution is alway sitting in some obscure corner of the internet, the 5th hidden comment on an SO question, or deep in a github thread that I find 5 hours later.
For example: On the glob issue referenced beforehand, which we also hit, you need to read a voluminous amount of info before you can decode the fact that the comment by SeanK here is the actual resolution to your problem. I probably looked at this specific SO thread 5 times before it clicked.
I will say, for me almost none of this pain comes from changes in Ember itself (I think), but from the current state of the ecosystem. However, like many have stated here I have no idea that that is the case because I actually can’t tell, because it’s so bad and so overwhelming that blaming the release cycle actually seems reasonable to me (sometimes).
Where we stand:
@wycats your summary of the situation is excellent, and calming in your usual way, but it leaves out a big piece, which is what is the core team going to do about it right now and where should everybody on this thread put their energy? There are decisions that we can make right now, and don’t need to wait on or be pushed under the rug again. Specifically I think there are a couple of dangerous “memes” which get repeated by some when issues like this are brought up as a way to deflect. I even came up with cute names for them
- The Well Actually: “Well actually, Ember itself is totally stable and follows SemVer, your issue is with X project”
- The It’s not me It’s You: “The fast release cycle minimizes work for all of us, maybe there is something wrong with you/your team/the way you work.”
- The You Don’t Have to Use It: “You could just freeze your app on INSERT VERSION HERE, and you’d be fine.”
In order to move forward (and be successful), I think now would be a good time for everyone on core to realize this is what it sounds like they are saying to certain criticisms, and hopefully spend some more time thinking through some of these issues. A plan and a commitment to resolve the concerns would go a lot further than honing these arguments to sound better.
I think everyone probably knows that the title of this thread and the release cycle in and of itself is not THE ISSUE, however I do think core team members and others who are not hitting the “Scour the Internet” sandtrap are failing to realize one thing about it. The release cycle currently compounds all of the other ‘real issues’ discussed here. We are not in a stable system, where this is the only change, and the current release cycle contributes to a cognitive dissonance that makes application programming in Ember much more painful than it should be.
This does not mean that we need to change the release cycle right now, for me it just means more effort needs to be put on the real issues raised here (and less effort potentially on new features). I do think layering a LTS plan on top of the current structure and committing to LTS of 2.0 are great ideas I would likely support. I think they would go a long way towards making people feel more comfortable adopting Ember long term.
In the spirit of constructiveness, and brainstorming ways to actually fix this stuff, here is my off-the-wall proposal:
Defacto components of the ecosystem need to be included in the release cycle. When non-power-users say “Ember” this is what they mean anyway (whether core likes it or not at the moment).
- Ember becomes a meta-project
- Ember CLI and Ember Data (I will gripe about this in a different thread), along with a new Ember Core (current Ember) become dependencies of Ember (the meta-framework). This mirrors the project structure of Rails (which includes ActiveRecord, ActionController, etc)
- This paves the way for breaking up other parts of Ember into standalone libraries as they mature.
- If effort on feature work needs pause in Ember Core when necessary to get fixes in for these other required parts of Ember, it can.
Ember needs to own responsibility for the ecosystem:
- NPM and Bower have a horrific user experience when coming from the stability of Bundler. If Ember CLI and the ecosystem are going to depend on them then we need to wrap and hide their warts (ember server, ember build and ember install should do the right thing). Issues that these projects should own, should be fixed locally, and pushed upstream if possible.
- In order to actually fulfill the SemVer promises, more real apps need to be tested in a repeatable way. Start a (potentially secure/private) registry of ‘donor’ applications with test suites. The scripted upgrade (currently ember init) must apply, and must pass the application’s test suite, or its a bug. This will drive ember init to actually be usable as well.
I will reiterate that what those working actively on Ember have built is amazing and the main reason I ever even took a look at it in the first place was because of all the amazing people I knew working on it. I think if we can get this part of the story right, it will be by far the best front end platform to work on. Thanks for listening.
Edit: list formatting