12 ms·

Ember.js 3.1 and 3.2 Beta Released

80 points by izelnakri 9y ago

s_kilk 9y ago
(as someone who doesn't use ember) This release looks cool, and I like the general vibe of careful development and clear messaging. Is anyone here using Ember on big projects? How's it working out? I tried ember, maybe 6 or 7 years ago, and was turned off by some weird magical behaviour, but I'm curious about how ember is doing these days, and particularly the glimmer engine.
- vasilakisfil 9y ago
  We use Ember, and it works pretty good actually. I love the addons system which allows you to speed up, but also extend an addon at anytime if it doesn't exactly fit your case. But the great thing with Ember is that anyone of us can jump in a project never worked before and still be productive. I had written a blog post about it, maybe worth checking it out: https://blog.kollegorna.se/3-years-of-ember-6-months-of-react-34ce909a5ce1 https://blog.kollegorna.se/3-years-of-ember-6-months-of-reac...
- jeffkeen 9y ago
  Ember is an incredible framework that's been carefully thought out by a team of super sharp people with loads of experience, and I'm constantly amazed by how quickly I can get real projects built using it. I've used it for many projects since ember-cli came out a few years ago. I feel about Ember for client-side projects how I felt about Rails for server-side projects—it made it fun for me again. But Ember gets a bad wrap from the internet because (admittedly) their marketing materials with the gooofy chipmunks make it look like a toy while React's make it look like you're learning quantum physics. And then there's the timeless "convention over configuration" divide where Ember people are generally on the left side, and React people just love the thought of fiddling around and hand rolling their own custom ungoogleable bespoke artisan framework before actually getting to the meat of the work. I highly recommend using Ember for any size project if you like getting shit done. This is a good talk kinda about this: https://www.youtube.com/watch?v=rWH3UNIKFeg https://www.youtube.com/watch?v=rWH3UNIKFeg
  - s_kilk 9y ago
    Yeah all of this sounds good, thanks!
  - Ralfp 9y ago
    > But Ember gets a bad wrap from the internet because (admittedly) their marketing materials with the gooofy chipmunks make it look like a toy Ember.js is best technology that I've ever dropped, but let me assure you, the Tomster had nothing to do with my decision. Ember got into the spotlight when Atwood and Co. have launched the Discourse. Back then it looked super impressive - first open source forum software and arguably one of first open source apps following "JS fronted and API backend" architecture. And it was all done with Ember.js, js FW marketing itself as the modern way to build JS apps! A lot of people wanted to try it out (myself included), some moving from Angular, other from Backbone, and others coming from backend development. If Ember ever had the cool factor, it was that time. Ember.js was the next big thing, a framework for creating ambitious web applications, and all the people came to it to build their ambitious applications, looking up to Discourse as example of such application. And then those people have hit the roadblock. Ember.js's pitch was building applications, but it's documentation has never moved past explaining individual parts of technology, and into the field of how those should be put together in final application. Angular had millions of easily googleable tutorials like "this is best practice for setting page title when user enters the route" or "this is how you can configure framework to authenticate with your backend technology". I also clearly remember the "calling set on destroyed object" error that happened when you tried to update the state of object that was already destroyed that was impossible to debug, because the error was literally "Error: calling set on destroyed object" and it put world to stop. For comparision, in React.js that was "Warning: calling setState with X, Y and Z on unmounted component ComponentName". That one error was absolute productivity killer when debugging Ember.js apps from day one, and it was years before somebody from Ember.js core actually went to Ember's source code and changed "assert !obj._is_destroyed 'calling set on destroyed object'" to "assert !obj._is_destroyed 'calling set on destroyed object'". There was always bigger fish to fry for Ember.js core team, who were so bussy making blogpost after blogpost of new great features or API changes happening, while being oblivious to comments below those same blogposts asking "can I now do partial updates on models because they are super costful to update?" or "is calling set on destroyed object fixed yet?". And then guys from their ambassador product, Discourse, started writing blog posts following the pattern of "Here's how we've replaced Ember.js's feature with our one because framework's didnt work", and those involved things like `Ember-Data` or Ember views.
- toufka 9y ago
  The most recent large effort in the 3.0 series was to break apart all of the 'magic features' into coherent conceptual units. So if you know what you want you can now use only the magic dust that you think you need. But those units are also still part of the ember such that it's still possible to type '>ember new' and have a fully loaded ready-to-go framework in 10 seconds. And fastboot. And glimmer. It's really nice environment to work in when building a full featured web-app.
- gavinjoyce 9y ago
  We've been using Ember at Intercom for over 4 years to build our main app. We continue to be super productive with Ember, our customers love our product, our code base has never been healthier and Ember's careful upgrade path and approach to deprecations means that we don't spend much energy or time thinking about non-product related technical challenges. The 6 week release cycle is great. We've grown from 10 to 150 engineers in that time and Ember's strong conventions has helped us continue our tradition of enabling new engineers shipping to production on their first day and shipping a feature to production in their first week.
  - s_kilk 9y ago
    That's good to hear. If you don't mind elaborating, which version of ember did you start with? Follow on: can you comment on how ember has improved since then? I'm particularly interested in improvements to performance and error reporting, which I'm lead to believe were pretty bad in early versions.
    - djwasserman 9y ago
      I don’t work there, but was an early customer and have built apps from 1.x days. The things that have improved: 1. Performance, performance, performance. It’s not fair, but anything that existed before react really was slow, because all JS dom updating was basically .innerHtml. Once we (as a JS community left that), everything has gotten faster (especially ember). Seehttps://madhatted.com/2016/11/30/5-things-to-know-about-ember-2-10-and-glimmer-2 https://madhatted.com/2016/11/30/5-things-to-know-about-embe... 2. Composability of components: being able to compose components together dynamically based and have a well defined boundary for colmunicating with the outside world is great. There is still some papercuts with the actual component API, but those are getting smoothed out. 3. Build-tooling/ecosystem. The amount and quality of tools keeps going up to accomplish tree shaking, AST parsing, etc. I just updated an ember app from 2.3 -> 3.0 and it took less than 2 hours to upgrade, test, deploy.
    - gavinjoyce 9y ago
      We started on ~v1.4. Ember has improved in every dimension since then. ember-cli, the ember inspector, contextual components, data down actions up, much better docs, an open RFC process, the ember addon ecosystem, the experimental glimmerjs, a smooth approach to deprecations and major version released. A lot of small steps and the odd big leap really adds up. Performance is great now. The rendering engine has been rebuilt (without major changes to the templating syntax) and the new glimmer-vm architecture yielded huge performance and payload size wins and continues to deliver incremental performance gains every 6 weeks. I've never considered error reporting an issue in the past, but I may just not remember the pain. It's not an issue for us now though. If you (or anyone else reading) would ever like to chat in person, feel free to reach out: https://twitter.com/gavinjoyce/status/928719024644612096 https://twitter.com/gavinjoyce/status/928719024644612096
- mnutt 9y ago
  I've used ember to build a half dozen production apps, ranging from a wysiwyg vector editor to a dropbox clone to an electron-based process manager. It's the frontend framework I reach for any time I expect to need to develop an app longer than a month or two, and ember has scaled well with each project. The ember community conventions have never really gotten in the way of whatever I'm trying to accomplish, and the consistency across projects is refreshing.
nerdymanchild 9y ago
My team is actually in the process of de-Reacting our code base. These frameworks are full of hacks underneath the covers, and their abstractions are mostly ill-specified.
- vasilakisfil 9y ago
  de-Reacting ? Are you going for plain js ? What's your use case?
- boubiyeah 9y ago
  Explain that bold claim? Apart from the very annoying Event compatibility layer with its event pooling and central handling that breaks the usual DOM event bubbling, I never saw something bad enough that would make someone consider de-Reacting. As much as I dislike magic, JS libs working with the DOM will always have code that isn't as clean as your application code.
JepZ 9y ago
Similar to @s_kilk I tried ember years ago and while I liked some of their concepts, the hard learning curve and the oversized results made me search alternatives. Anybody knows what size (js bundle file size) a basic PWA in ember.js has nowadays? I am asking for file size here, as transmitting and parsing that data is usually what defers an instant user interaction.
- sandstrom 9y ago
  If fast bootup is critical, look at Ember Fastboot. https://www.ember-fastboot.com/ https://www.ember-fastboot.com/ It will deliver a minimum HTML-payload to quickly render a page, then subsequently load the data required to boot the full app after the page has loaded. The net effect is that page transitions/loading will be more or less instant.
- anoncoward778 9y ago
  Keep in mind. Ember is built for LARGE applications. No such thing as a "basic PWA" in ember.js. Think of it more like...we've built this huge app for tons of users in library XYZ and our development team of over 20 persons is feeling pain points in transitioning to the updated more secure version of XYZ.
  - msum 9y ago
    I really enjoyed the EmberConf talk about movie studios using it for movie promo sites because they needed to be able to get them up quickly. I think if you took that concept and maybe a blog post about doing an Ember PWA (https://madhatted.com/2017/6/16/building-a-progressive-web-app-with-ember https://madhatted.com/2017/6/16/building-a-progressive-web-a... for example) then maybe the large part doesn't matter so much...
stocktech 9y ago
I lead an internal development team. We're constant building new apps and enhancing old ones. Ember has been a big win for us. Upgrading old apps is a breeze. Every app has a consistent structure and the conventions make it easy for developers to move between projects. We don't need to worry about the individual pieces - routing, data, etc - we trust the core devs so that we only worry about business logic. We're experimenting with Ember Engines right now and I'm not sure how we'd replicate it if we were using React or Angular. All in all, I think it has made us incredibly productive. Outside of the code, the Ember team's communication skills are top notch. I feel like every time I tell my team that "XYZ is coming down the pipe", there's a clear plan of attack and any impact is minimal. In the last 3 years, I've never had to tell my boss that development will be paused to focus on a refactor/upgrade/maintenance. The biggest downside is in hiring, unfortunately. I don't look for Ember experience, but I have had to adjust my expectations when it comes to the learning curve.
- vmware505 9y ago
  Actually, learning Ember.js is quite easy nowadays. There are great free options, where you can go far in a few days: http://yoember.com http://yoember.com | https://guides.emberjs.com/v3.0.0/tutorial/ember-cli/ https://guides.emberjs.com/v3.0.0/tutorial/ember-cli/
  - stocktech 9y ago
    Agreed, but experience has shown some kind of mental block in developers coming from other frameworks. ymmv
  - msum 9y ago
    Also https://medium.com/ember-ish https://medium.com/ember-ish is incredibly useful.
- Edwardzyc 9y ago
  Are you guys hiring? (although I haven't used ember since..before 1.0)
- jonesetc 9y ago
msum 9y ago
The thing that has most impressed me about Ember is the way the teams on a project at giant corp will not do things correctly (honestly, some days it feels like they are doing weird crap on purpose to try to get it to fail) and Ember still works. For a tiny glimpse of context- we have globally distributed teams who all work on different (isolated) parts of the project using ember-engines. All of these parts can either be stood up as a standalone app or become part of one host app. And every single one of these is consuming a single UI Addon that has components, minimal services, and themes. Think about all of the moving pieces there, all of the parts where teams can disagree or do weird stuff, and yet somehow when it all comes together, we have so many things that could colossally fail, yet nothing does. We have a few bugs that are hard to reproduce but that's because we do weird stuff, not because Ember does. It's really epic when I sit back and think through all of it. If you haven't tried Ember in ages, or ever- this is definitely the time to try...and I mean really try. Some of it will be a paradigm shift, but a worthy one.

80 points by izelnakri 9y ago

(as someone who doesn't use ember) This release looks cool, and I like the general vibe of careful development and clear messaging. Is anyone here using Ember on big projects? How's it working out? I tried ember, maybe 6 or 7 years ago, and was turned off by some weird magical behaviour, but I'm curious about how ember is doing these days, and particularly the glimmer engine.

vasilakisfil 9y ago
We use Ember, and it works pretty good actually. I love the addons system which allows you to speed up, but also extend an addon at anytime if it doesn't exactly fit your case. But the great thing with Ember is that anyone of us can jump in a project never worked before and still be productive. I had written a blog post about it, maybe worth checking it out: https://blog.kollegorna.se/3-years-of-ember-6-months-of-react-34ce909a5ce1 https://blog.kollegorna.se/3-years-of-ember-6-months-of-reac...
jeffkeen 9y ago
Ember is an incredible framework that's been carefully thought out by a team of super sharp people with loads of experience, and I'm constantly amazed by how quickly I can get real projects built using it. I've used it for many projects since ember-cli came out a few years ago. I feel about Ember for client-side projects how I felt about Rails for server-side projects—it made it fun for me again. But Ember gets a bad wrap from the internet because (admittedly) their marketing materials with the gooofy chipmunks make it look like a toy while React's make it look like you're learning quantum physics. And then there's the timeless "convention over configuration" divide where Ember people are generally on the left side, and React people just love the thought of fiddling around and hand rolling their own custom ungoogleable bespoke artisan framework before actually getting to the meat of the work. I highly recommend using Ember for any size project if you like getting shit done. This is a good talk kinda about this: https://www.youtube.com/watch?v=rWH3UNIKFeg https://www.youtube.com/watch?v=rWH3UNIKFeg
- s_kilk 9y ago
  Yeah all of this sounds good, thanks!
- Ralfp 9y ago
  > But Ember gets a bad wrap from the internet because (admittedly) their marketing materials with the gooofy chipmunks make it look like a toy Ember.js is best technology that I've ever dropped, but let me assure you, the Tomster had nothing to do with my decision. Ember got into the spotlight when Atwood and Co. have launched the Discourse. Back then it looked super impressive - first open source forum software and arguably one of first open source apps following "JS fronted and API backend" architecture. And it was all done with Ember.js, js FW marketing itself as the modern way to build JS apps! A lot of people wanted to try it out (myself included), some moving from Angular, other from Backbone, and others coming from backend development. If Ember ever had the cool factor, it was that time. Ember.js was the next big thing, a framework for creating ambitious web applications, and all the people came to it to build their ambitious applications, looking up to Discourse as example of such application. And then those people have hit the roadblock. Ember.js's pitch was building applications, but it's documentation has never moved past explaining individual parts of technology, and into the field of how those should be put together in final application. Angular had millions of easily googleable tutorials like "this is best practice for setting page title when user enters the route" or "this is how you can configure framework to authenticate with your backend technology". I also clearly remember the "calling set on destroyed object" error that happened when you tried to update the state of object that was already destroyed that was impossible to debug, because the error was literally "Error: calling set on destroyed object" and it put world to stop. For comparision, in React.js that was "Warning: calling setState with X, Y and Z on unmounted component ComponentName". That one error was absolute productivity killer when debugging Ember.js apps from day one, and it was years before somebody from Ember.js core actually went to Ember's source code and changed "assert !obj._is_destroyed 'calling set on destroyed object'" to "assert !obj._is_destroyed 'calling set on destroyed object'". There was always bigger fish to fry for Ember.js core team, who were so bussy making blogpost after blogpost of new great features or API changes happening, while being oblivious to comments below those same blogposts asking "can I now do partial updates on models because they are super costful to update?" or "is calling set on destroyed object fixed yet?". And then guys from their ambassador product, Discourse, started writing blog posts following the pattern of "Here's how we've replaced Ember.js's feature with our one because framework's didnt work", and those involved things like `Ember-Data` or Ember views.
toufka 9y ago
The most recent large effort in the 3.0 series was to break apart all of the 'magic features' into coherent conceptual units. So if you know what you want you can now use only the magic dust that you think you need. But those units are also still part of the ember such that it's still possible to type '>ember new' and have a fully loaded ready-to-go framework in 10 seconds. And fastboot. And glimmer. It's really nice environment to work in when building a full featured web-app.
gavinjoyce 9y ago
We've been using Ember at Intercom for over 4 years to build our main app. We continue to be super productive with Ember, our customers love our product, our code base has never been healthier and Ember's careful upgrade path and approach to deprecations means that we don't spend much energy or time thinking about non-product related technical challenges. The 6 week release cycle is great. We've grown from 10 to 150 engineers in that time and Ember's strong conventions has helped us continue our tradition of enabling new engineers shipping to production on their first day and shipping a feature to production in their first week.
- s_kilk 9y ago
  That's good to hear. If you don't mind elaborating, which version of ember did you start with? Follow on: can you comment on how ember has improved since then? I'm particularly interested in improvements to performance and error reporting, which I'm lead to believe were pretty bad in early versions.
  - djwasserman 9y ago
    I don’t work there, but was an early customer and have built apps from 1.x days. The things that have improved: 1. Performance, performance, performance. It’s not fair, but anything that existed before react really was slow, because all JS dom updating was basically .innerHtml. Once we (as a JS community left that), everything has gotten faster (especially ember). Seehttps://madhatted.com/2016/11/30/5-things-to-know-about-ember-2-10-and-glimmer-2 https://madhatted.com/2016/11/30/5-things-to-know-about-embe... 2. Composability of components: being able to compose components together dynamically based and have a well defined boundary for colmunicating with the outside world is great. There is still some papercuts with the actual component API, but those are getting smoothed out. 3. Build-tooling/ecosystem. The amount and quality of tools keeps going up to accomplish tree shaking, AST parsing, etc. I just updated an ember app from 2.3 -> 3.0 and it took less than 2 hours to upgrade, test, deploy.
  - gavinjoyce 9y ago
    We started on ~v1.4. Ember has improved in every dimension since then. ember-cli, the ember inspector, contextual components, data down actions up, much better docs, an open RFC process, the ember addon ecosystem, the experimental glimmerjs, a smooth approach to deprecations and major version released. A lot of small steps and the odd big leap really adds up. Performance is great now. The rendering engine has been rebuilt (without major changes to the templating syntax) and the new glimmer-vm architecture yielded huge performance and payload size wins and continues to deliver incremental performance gains every 6 weeks. I've never considered error reporting an issue in the past, but I may just not remember the pain. It's not an issue for us now though. If you (or anyone else reading) would ever like to chat in person, feel free to reach out: https://twitter.com/gavinjoyce/status/928719024644612096 https://twitter.com/gavinjoyce/status/928719024644612096
mnutt 9y ago
I've used ember to build a half dozen production apps, ranging from a wysiwyg vector editor to a dropbox clone to an electron-based process manager. It's the frontend framework I reach for any time I expect to need to develop an app longer than a month or two, and ember has scaled well with each project. The ember community conventions have never really gotten in the way of whatever I'm trying to accomplish, and the consistency across projects is refreshing.

nerdymanchild 9y ago

My team is actually in the process of de-Reacting our code base. These frameworks are full of hacks underneath the covers, and their abstractions are mostly ill-specified.

vasilakisfil 9y ago
de-Reacting ? Are you going for plain js ? What's your use case?
boubiyeah 9y ago
Explain that bold claim? Apart from the very annoying Event compatibility layer with its event pooling and central handling that breaks the usual DOM event bubbling, I never saw something bad enough that would make someone consider de-Reacting. As much as I dislike magic, JS libs working with the DOM will always have code that isn't as clean as your application code.

JepZ 9y ago

Similar to @s_kilk I tried ember years ago and while I liked some of their concepts, the hard learning curve and the oversized results made me search alternatives. Anybody knows what size (js bundle file size) a basic PWA in ember.js has nowadays? I am asking for file size here, as transmitting and parsing that data is usually what defers an instant user interaction.

sandstrom 9y ago
If fast bootup is critical, look at Ember Fastboot. https://www.ember-fastboot.com/ https://www.ember-fastboot.com/ It will deliver a minimum HTML-payload to quickly render a page, then subsequently load the data required to boot the full app after the page has loaded. The net effect is that page transitions/loading will be more or less instant.
anoncoward778 9y ago
Keep in mind. Ember is built for LARGE applications. No such thing as a "basic PWA" in ember.js. Think of it more like...we've built this huge app for tons of users in library XYZ and our development team of over 20 persons is feeling pain points in transitioning to the updated more secure version of XYZ.
- msum 9y ago
  I really enjoyed the EmberConf talk about movie studios using it for movie promo sites because they needed to be able to get them up quickly. I think if you took that concept and maybe a blog post about doing an Ember PWA (https://madhatted.com/2017/6/16/building-a-progressive-web-app-with-ember https://madhatted.com/2017/6/16/building-a-progressive-web-a... for example) then maybe the large part doesn't matter so much...

stocktech 9y ago

I lead an internal development team. We're constant building new apps and enhancing old ones. Ember has been a big win for us. Upgrading old apps is a breeze. Every app has a consistent structure and the conventions make it easy for developers to move between projects. We don't need to worry about the individual pieces - routing, data, etc - we trust the core devs so that we only worry about business logic. We're experimenting with Ember Engines right now and I'm not sure how we'd replicate it if we were using React or Angular. All in all, I think it has made us incredibly productive. Outside of the code, the Ember team's communication skills are top notch. I feel like every time I tell my team that "XYZ is coming down the pipe", there's a clear plan of attack and any impact is minimal. In the last 3 years, I've never had to tell my boss that development will be paused to focus on a refactor/upgrade/maintenance. The biggest downside is in hiring, unfortunately. I don't look for Ember experience, but I have had to adjust my expectations when it comes to the learning curve.

vmware505 9y ago
Actually, learning Ember.js is quite easy nowadays. There are great free options, where you can go far in a few days: http://yoember.com http://yoember.com | https://guides.emberjs.com/v3.0.0/tutorial/ember-cli/ https://guides.emberjs.com/v3.0.0/tutorial/ember-cli/
- stocktech 9y ago
  Agreed, but experience has shown some kind of mental block in developers coming from other frameworks. ymmv
- msum 9y ago
  Also https://medium.com/ember-ish https://medium.com/ember-ish is incredibly useful.
Edwardzyc 9y ago
Are you guys hiring? (although I haven't used ember since..before 1.0)
jonesetc 9y ago

msum 9y ago

The thing that has most impressed me about Ember is the way the teams on a project at giant corp will not do things correctly (honestly, some days it feels like they are doing weird crap on purpose to try to get it to fail) and Ember still works. For a tiny glimpse of context- we have globally distributed teams who all work on different (isolated) parts of the project using ember-engines. All of these parts can either be stood up as a standalone app or become part of one host app. And every single one of these is consuming a single UI Addon that has components, minimal services, and themes. Think about all of the moving pieces there, all of the parts where teams can disagree or do weird stuff, and yet somehow when it all comes together, we have so many things that could colossally fail, yet nothing does. We have a few bugs that are hard to reproduce but that's because we do weird stuff, not because Ember does. It's really epic when I sit back and think through all of it. If you haven't tried Ember in ages, or ever- this is definitely the time to try...and I mean really try. Some of it will be a paradigm shift, but a worthy one.