Ember v3.7 Released(emberjs.com)
emberjs.com
Ember v3.7 Released
https://emberjs.com/blog/2019/01/07/ember-3-7.html
41 comments
Ember is by far the best application framework out there (react is a view library). It's refreshing to see features come out of the box instead of having to roll your own react + mobx + react router. Build tools are easy to use and very transparent.
Is ember still used? I always only hear that ppl nowadays use react, vue or angular. What does ember differently/better?
I've used Ember in a large non-tech organization. Ember's particular way of doing things, being opinionated, allowed us to focus on building the logic out instead of worry about secondary decisions: file structure, routing, data stores, build pipelines, etc.
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.
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.
Personally, I still have ember apps from 2015 that are now on v3.6 and have had pretty much painless updates. I have used react professionally, but used Ember when starting a new app this past fall. I just trust them to keep things stable over time and I don't have the ability or desire to spend a lot of time bikeshedding my setup. It's not glamorous, but I do get a lot done and can keep things working for years.
The upgrades in the 2.x range were pretty demoralizing for myself and my team. Have they gotten any better?
The tooling around upgrading has definitely gotten a lot better, though if you’re carrying around a relatively older codebase there’s a potentially thorny deprecation coming up in the future
It is usually automatic, with running one command: https://yoember.com/emberjs/how-to-keep-your-ember-js-projec...
In theory yes, but for larger apps, especially those that use addons, definitely not.
The 2.x were the reason I
many people I know dropped it.
I would say that for most frameworks/libraries. Keeping up with the Joneses is hard and Ember has taken particular care in both pioneering new ideas and bringing in new ideas from other domains and libraries. I'm just grateful that all the apps I have worked on since 1.13 have not been painless to upgrade, but have been totally worth it. Over the long term, stability, ergonomics and performance have been improving steadily and there has been a nice community around to help. That is about all I can ask for. Continuous improvement + nice people == recipe for software success over the long term.
Ember is still used (and should be) though it's not on the hype train these days for a few reasons:
- 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.
- 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.
Probably much more than you would think.
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.
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.
I'm not sure how linking to an article about the hype cycle can be considered evidence of Ember's maturity relative to its peers.
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).
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).
I didn't read that as evidence, simply a link to define the term "Plateau of Productivity".
The only stuff I heard was that there are many outdated Ember projects that owners need to be updated.
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.
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.
It is one of the most commonly used framework in serious industry projects. For example in New Zealand so many important websites and services built with Ember. General Election system, nation wide Social Service tool, major banks web apps, main television website, second largest city public transport website, etc.
I thought the Kiwis went all in on Silverstripe??
> It is one of the most commonly used framework in serious industry projects
I'd love to see a source for this, because I do not believe it for a second.
I'd love to see a source for this, because I do not believe it for a second.
If you have Ember Inspector in your Chrome, you can see it.
- 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.
- 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.
Those are examples of sites that use Ember, but far from proof that it's one of the most used frameworks.
Linkedin is largely built on Ember. There's ample gnashing of teeth internally about that but that's what it is now.
You mean they would use something else instead? Most of the project who use Ember, they love it, and they would not use other tool. For example Intercom in Dublin is a huge supporter of Ember.js and they are big fun of the framework.
Many don't like Ember and the majority of front end engineers think not working in React is a problem as far as it relates to resume building.
I think many ember users use it because it's what they know. And for most projects, any of these choices, including ember, will do the job just fine.
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).
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).
[deleted]
On a team that uses it.
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.
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.
What version are you on? Aside from existing “pod” structure, the newer module unification feature follows a structure more in line with what you describe.
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?
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?
Travis-CI uses Ember.
I haven't got a chance using ember. But the rancher guys https://rancher.com seem to use ember a lot for their web app. And it looks solid. There's no doubt that ember is capable when it comes to handling complex application.
In my opinion Ember’s huge value added is Ember Data. I couldn’t find anything compared to it in any other library/framework.
Ember was the first web framework I tried to learn. Maybe my mind is too dense. Couldn't really figure out shit. I guess for a simpleton like me my mind works best with micro frameworks react or vue. I work as frontend engineer now.
This free tutorial helped me to understand the concept behind the framework. Actually, I can adapt this knowledge to other work also. https://yoember.com
I'm still really disappointed that Ember gave up on trying to compete with libraries like React on bundle size. I loved my experience with Ember, and I really like what they've done recently, but the fact that out of the box it's several times larger than an equivalent set of React libraries makes it hard to justify. It's super awesome if you're building complex, ambitious desktop web apps, but for simple, mobile-focused progressive web apps it just doesn't seem worth the extra bytes.
React and Ember.js is not an apple to apple comparison. React is a UI library, Ember.js is a framework. Glimmer would be a better comparison.
Right, which is exactly why I said "an equivalent set of React libraries" as opposed to just React.
Ember as you guessed, is not for simple apps. So an equivalent set of React libraries would have to do everything that Ember does---even when you are building an app that does not require all those parts.
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.
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.
> 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.
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.
I thought Ember provided:
- 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.
- 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.
Isn’t GlimmerJS their React equivalent?
Really excited to see what v4.0 brings!! Lots of hard work in the making.
I wrote this before, I'm writing this here again:
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.
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.