Ember v3.7 Released
emberjs.com
emberjs.com
Personally, I feel Ember is best suited for the enterprise world. It's a slower moving framework focused on backwards compatibility that remains relatively similar over the years. I feel slightly insulated from the rapid changes in the front end world which allows me and my team the ability to focus on the business. Of course, I push my team to understand what's going on outside of Ember. I've definitely taken things away from React and Redux.
But having to maintain dozens of apps (and growing), I couldn't imagine the technical debt we'd have if we chose a different framework. Our repos would be scattered with the latest and hottest fad and changing standards.
- It is a fully considered (if not well-considered) framework which is great for large teams
- It keeps up with other libraries and best practices by adapting
Unfortunately, the best thing about Ember is also the worst thing -- changes can happen so fast that it becomes necessarily hard to update if you stop keeping up with it.
Ember's only competitor in my mind is Angular in the current landscape -- assuming people do not want to bolt together a vue+vuex+vue-router setup.
https://en.wikipedia.org/wiki/Hype_cycle
Ember is firmly in the "Plateau of Productivity". It's stable, supported, but no longer the "new thing" so you don't hear much about it.
Ember's 1.0 release was 2013 which is the same year React was announced. Yes Ember has earlier history as Sproutcore going back to 2011, but Facebook was using React internally since 2011 as well. I'd also argue that Ember 2.0 was pretty different from 1.0.
Angular is older, going back to 2009, but as 2.0 is a total rewrite as well as departure from where they started out I'm willing to let that one go. (It is also a complete tire fire so let's just ignore it altogether).
VueJS is arguably the "new kid". But really only just barely. The first release was Feb 2014. I'd hardly consider Vue immature at this point though.
I really don't see how one can argue it has a tangible maturity advantage here. I also think that most of the newer generation of SPA frameworks have learned lessons both from the previous generations and their peers (with the exception of Angular perhaps).
My flat mate did a few projects stuck on Ember 1.4 that needed to be updated to 2.0 last year. Somehow Ember devs loved to use private APIs, so most of the apps broke on an update and much had to be re-written.
I'd love to see a source for this, because I do not believe it for a second.
- Main TV Channel (Close to million user per day): https://www.tvnz.co.nz/ - Largest bank app (Half of the population using it): https://www.anz.co.nz/personal/ - Other bank: https://www.co-operativebank.co.nz/ - Christchurch's public transport website: http://www.metroinfo.co.nz/Pages/default.aspx - Ministry of Social Development web app (half million active user): https://my.msd.govt.nz/login - Election System app is not public.
There's value in using tools you're already proficient in. And that's the thing that rubs me about framework debates: it's like we're all debating what screw head is best (Robertson, btw).
It's... fine. If you know Ember, you can build a reasonable app pretty quickly. If you have a team that knows Ember and likes it, there's not going to be giant gains to switching to something newer. Certainly not enough to justify a rewrite. The integration between the framework and Ember Data is nice if you have an API that natively works by the JSON API standard that Ember Data expects. It's big selling point is it's more of a one stop shop than something like React and Vue where you have to bring your own data layer and router etc.
However... if it was up to me, I wouldn't use it again:
If your API doesn't emit JSON API, expect to write a lot of serializer/adapter code.
The Ember object model breaks browser debugging (and no, the Ember Inspector doesn't make up for it, you can't dig down into objects there, the best you can do is send it to $E, then manually issue $E.get() calls). You end up looking in foo._internalModel._data to get a decent look at what the data actually is.
The build tools are slow. Broccoli still cannot output sourcemaps which map back to real source.
The framework has strong opinions about app layout, based on Rails. It groups by concept. So you have folders for models, controllers, components etc. While you can nest within it (so you can have controllers/my-feature/{a,b}.js and components/my-feature/{c,d}.js), it still ends up with your code for a feature all over the place. I'd much rather have my-feature/{controllers/{a,b},components/{c,d}}.js and have all code for a feature in one place. Pods were supposed to fix this, but have been abandoned.
The public API is too prone to spitting out objects that only have private APIs. e.g. look at adapter.createRecord (https://emberjs.com/api/ember-data/3.7/classes/DS.Adapter/me...) . You get based the data in a DS.Snapshot. What public supported actions are available with a Snapshot? (None: https://emberjs.com/api/ember-data/3.7/classes/DS.Snapshot). RecordArray in the past was similar, as were the factory and transition APIs.
Because of the above point, many popular addons are tied to APIs that are considered internal and prone to breakage. This means while the Ember team advertise "Just follow the deprecations, you can update with ease", you really can't. Your addons will break and will need to be updated in parallel and if they've updated their APIs at the same time, you're kind of SOL.
Which addons are problematic? I don’t doubt they exist but seems like any large/complex framework will suffer that problem. EmberData is a separate project from emberjs core.
How does vue+vuex+vue router or equiv react setup avoid same issues?
It's not a fair comparison to talk about a simple mobile-only app, and complain that Ember is too large for bloating the bundle with things you will not use.
The problem isn't that Ember has a lot of things you don't use; it's that the things that are there are much larger than their React counterparts. In terms of actual functionality, Ember doesn't provide anything that React+React Router doesn't. The difference in bundle size arises from the different ways Ember accomplishes the same end goal. This differences make it more suited to desktop apps loaded over high speed internet connections. My point is that as someone who's building PWAs designed to load as quickly as possible, it's unfortunate that Ember isn't even a possible contender due to the minimum bundle size.
- Observable objects and enumerables - Models with a relationship framework - Controllers - A dependency injection framework - A templating system
In addition the router also provides:
- Parsing of query strings in the router (React-Router does not do that) - Explicit loading states - Asynchronous routing
Whereas React-Router + React provides:
- A router - A view layer
I also don't understand your complaint about PWAs and bundle size. Aren't PWAs supposed to fully cache all the Javascript after the first load so bundle size should be less important? And the competition to a PWA is a downloadable mobile app that's often many dozens of megabytes.
Ember is a complete frontend/SPA framework. 2 key advantages Ember.js has over other SPA solutions are server-side rendering and advanced acceptance/end-to-end testing.
- You can do server side rendering with other frameworks however it is significantly easier and better to do it with Ember.js due to the way ember routing model and ember-data works. You can do acceptance testing with other tech stacks however they cannot be as fast as the usual ember acceptance testing stack + ember mirage. Mirage mocks your backend and introduces an in-memory ORM thus your tests wont ever need to hit your backend or the database, I wrote a better mirage alternative as mirage do have issues outside the context of this topic. Backend mocking comes with 3 major advantages and 1 major disadvantage:
Advantage 1: Your tests will be extermely fast(a speed cypress cannot compete with). Ember test suite knows exactly when your app starts, it can listen to the next visit, next Ember loop in the Run loop for async functions and execute immediately without timers. These are well defined and documented in the framework.
Advantage 2: Most web backends are not built on JavaScript, however current trend is to write acceptance tests in JS/node.js due to the all available ecosystem support in a certain SPA framework/library. Since your backend logic is most probably written in another language you cannot access the backend data in your frontend tests. Ember mirage replaces your backend thus you can access your backend data on acceptance tests for higher test quality. If your backend is written in node.js you can require your models and query them inside the tests thus not much there wont advantage here. For the majority of backends you will have to write your own hacky tool to query your backend if you want higher quality testing. Or you have to write your acceptance tests in your backend language which will be no doubt slower than ember tests + headless browsers that have JS API support.
Advantage 3: You can develop very complex frontend demo applications on the development mode with Ember mirage without a backend. There is a productivity advantage when your frontend developers are not backend developers/not familiar with your backend stack. You can source your backend API responses as Ember mirage fixtures thus eliminate the need for data preparation/model generations with factories for each frontend tests. Also you can easily create demo deployments for client meetings.
Disadvantage: - Sometimes you need to write your backend logic in Ember mirage routes. Ember mirage is still an alpha software and all these add up to the learning curve.
Ember.js has lots of potential and a mature ecosystem.