I’m about to start my next Ember project and I was looking for a little guidance on which version to start with.
I first started playing with 1.13 and quickly got a test app up to look at different tools for creating tables (it’s not sexy but tables make the money so they’re very important to this app). I found the ember-collection addon and integrated it into the test app and was really psyched to see that I could handle 10,000 rows.
My next thought was to go with 2.2 and keep up-to-date with new releases (this time will be different ;0). But, I’ve run into a problem using the ember-collection addon. It’s now complaining that it can’t find a helper defined in the addon:
Uncaught Error: Assertion Failed: A helper named 'fixed-grid-layout' could not be found
If I remove that function and just use {{#ember-collection items=model as |item index|}} then it can’t find the ember-collection component:
Uncaught Error: Assertion Failed: A helper named 'ember-collection' could not be found
It looks like there’s some issue with loading addons in 2.2 (maybe it’s just because it’s a local repo???) but I don’t know if the issue is that addon developers aren’t supporting 2.2 yet or there’s a but or something else. So, I thought I’d ask for advice here.
Thanks!
P.S. There aren’t any features in the 2.0 series that I’m dying to have yet (when routable components drop it will be another story) but a more stable version would definitely be appreciated by me and my team.
I just installed ember-collection from git-hub ember install https://github.com.... instead of using npm link and the errors have gone away and I’ve got my example collection (10,000 rows!!).
When the next major version hits, features marked as obsolete are dropped.
So, given it would be unwise to create a new project and features that are already obsolete, a good rule of thumb would be to always start with the latest version.
The only pitfall, as you found out, is if you need/want a third-party add-on that has not been updated. Although I would argue in that case that you’re better off not using unmaintained addons.
Right, that’s the theory but, in practice, things have been a bit unstable lately. For instance, the 1.13(.3?) release broke all views that inherit from EmberContainerView. Not a big deal unless they were a core part of your product – we build tables using them in our last app so we’re stuck
There was also a performance hit with the introduction of the glimmer engine (specifically for initial render of large lists which is the use case we really care about).
Finally, there are many addons that don’t support glimmer yet (ember-tables, ember-list, etc…). I think™ that ember-collection is the right way to go because it looks like it’s been built from the ground up with the glimmer engine so there’s no porting necessary with it. But, it hasn’t even been published yet so I don’t know if we want to bet the company on it.
Anyway, you’re exactly right in laying out what the philosophy of the core team is. So, in theory, we should build on 2.2 and never look back. But, the core team doesn’t have huge apps like ours or Intercom, etc… that have all of these pesky edge cases. So, I was hoping to hear a few anecdotes about actually using later versions. My main concern is that addon developers won’t port their code to ember 2 right away and so targeting that series will leave us reinventing the wheel.
Thanks again for the reply. I really appreciate your perspective.
So I’ll attempt to chime in here. Starting with some background. We’ve been using Ember at Batterii since version 0.9.7, late 2012. In that time we experienced one very major application overhaul as our product focus was making a pivot (around Q2 2014). Our current application size is about 60K lines of app code (templates + javascript). I consider that to be about “moderate size”, but I do consider our complexity to be significant. It’s hard quickly explain the nature of our app, especially if you’ve never heard of “design thinking”, but here are a few gifs that demonstrate high level complexity.
So hopefully I’ve at least convinced you that our app is above the “trivial” mark. We have A LOT of complexity that leads to many of these pesky use cases. And there are always going to be things that break from release to release. Even if it’s not the “API” breaking. Ember is like an organism that’s continuing to evolve and improve over time. To improve is to change and with that will come unintended consequences, one of which is what you’re seeing with some of the more complex addons at the moment.
My take on 1.13 vs is 2.2 is 2.2. Here’s why, the 2.x branch is the future. I’m not saying that 1.13 won’t have a nice long life. But all of your new features, perf improvements, and most big fixes with be in 2.x. Starting with 1.13 is starting from behind at this point. If you find an addon(s) that don’t work with 2.x you should look for open issues in their repo. If there isn’t one, open one. We’re on 2.x and all of our addons are working fine.
First: awesome app! I don’t understand “design thinking” but that’s just neat.
It’s great to hear that addon maintainers are keeping up with the 2.x changes. That is really my biggest fear so it’s nice to know that people are able to keep up.
I think this is really the heart of the matter. It might be a little bit slower going in the beginning but it seems like it’s the right move to set us up to take advantage of glimmer2, angle-bracket components, and routable components.
Thanks so much for taking the time to reply. I really appreciate it.
Always happy to answer any questions. In our product we have content areas we call “walls”. That feature is what we call the “movable wall mode”. When we had the shift in product focus that I mentioned it was one of the first features we tackled. The idea behind the design is a “canvas” or “whiteboarding area” that has a grid system to help people easily form tight layouts.
The foundation of the system consists of the grid layout engine w/ various sizing and orientations, the collusion detection, lassoing, multiple selection, mouse wheel panning and the floating toolbar. That part of the system took me about 2 months to build working a good amount of overtime. The technical layer above that, where the different content types are rendered has undergone several revisions over the past year. It’s hard to say exactly how much time was spent on them.
Here are two stills of a more extravagant movable wall that shows different content type renderings. Cloudup
