8 ms·

I remember seeing the blog post about Ember 2.0 being released around this time 1 year ago. Previously I was edging towards React and the built tools du jour. I

I remember seeing the blog post about Ember 2.0 being released around this time 1 year ago. Previously I was edging towards React and the built tools du jour. I started a new job which needed a rewritten frontend, so I went with Ember and am super happy. The CLI tools are fantastic, and coming from Rails the integrated test suite, generators and opinionated framework is such a breeze. I am super excited about what the future holds, and having a community working together on one project and goal is amazing. Even though they don't have a huge commercial backing, a lot of medium-large companies are using Ember and improving the ecosystem. The core team are really smart people, and I am amazed at the smart stuff they build, yet how they have found a way of working to iterate so fast.

orf 10y ago
I'm in the same boat, it's one of the only tools I feel almost fanatical about sharing and spreading. It's really nice and it's a shame it doesn't get more love on HN. The only downside is it takes a while to get your head around its object model and how to structure your apps in terms of computed properties and observers. Once that clicks though your in a nirvana of productiveness, and having toyed with the react ecosystem I've got to say that Embers learning curve is a lot nicer. There is Glimmer 2 comming out soonish, fast boot taking off and the Ember engines RFC implemented in the next version. Things are looking good!
- k__ 10y ago
  > it's a shame it doesn't get more love on HN Probably because it feels a bit like "the old way" for many. A big framework that covers all and brings its own tooling. Today, everyone uses its own stack to build. WebPack, Browserify, Rollup, tsc, Gulp, Make etc. When I was using Ember, I used it with Gulp, Emblem, LiveScript etc. Then they pulled this Ember-CLI stuff and some modules told me, that they depend on it. Suddendly I had to learn a new tool and tell it to do my bidding or else I couldn't use Ember add ons (painlessly). I don't think it's a inherently bad idea, especially for a Framework as old as Ember, which reinvents itself constantly.
  - addicted 10y ago
    Ember was around well before Ember-CLI became a thing and it still didn't get much love. Seems to me the obvious answer is the obvious. Lack of marketing muscle that is provided by being part of a Google or a Facebook.
- spion 10y ago
  How does the ember object model compare to MobX? https://mobxjs.github.io/mobx/getting-started.html https://mobxjs.github.io/mobx/getting-started.html To me it looks like mobx provides all that is provided by ember models, but also adds unobtrusive syntax and automatic observable dependency tracking.
- tomdale 10y ago
  One thing that I'm really excited to start working on is aligning the Ember object model towards the new features coming in ES2016+. During the period of JavaScript-the-language stagnation, we had no choice but to add these features as runtime augmentation. Now that the pace of evolution on TC39 and in the browsers is so much more vibrant, we can start pushing a lot of those features into the language itself. That has two important side effects. One, it means huge swaths of code can be deleted from Ember. Two, and perhaps most importantly, it increases the chances people will already be familiar with those features once they try to pick up Ember, reducing the learning curve that much more.
  - orf 10y ago
    > aligning the Ember object model towards the new features coming in ES2016+. Any examples you can give? Anywhere I can read more about this?
    - tomdale 10y ago
      For example, see Robert Jackson's addon for using decorator syntax to describe computed properties: https://github.com/rwjblue/ember-computed-decorators https://github.com/rwjblue/ember-computed-decorators
staticelf 10y ago
I really like Ember as well and uses it daily. However, if I could remake my decision I would not pick Ember today since it's too opinionated for the current project I am working on. Our stack, as it turns out, is not really ember-friendly. For example, we need several endpoints for the same models which was a pain to get to. Also we don't use jsonapi which also is a pain if you use ember and so on. We didn't know these things before picking the framework, but it's really opinionated which can be a good thing as long as you pick the same opinions and solutions as they do. Developing in Ember for me means basically figuring out how to implement stuff that Ember already have out of the box since we cannot use some of that. But when we can, development is a breeze. If anyone is thinking of using Ember for a new project, be really sure that Ember really is going to work with you and not against you.
- vertex-four 10y ago
  Note that Ember is not actually strongly tied to Ember Data - the model() function on a route can return any Ember promise, and you can save data however you want. If the rest of Ember is roughly what you want, implementing a custom method of getting Ember objects from API responses and vice versa is probably easier than trying to wrangle Ember Data into doing what you need.
  - staticelf 10y ago
    We had a discussion if we should skip Ember Data or not but concluced that it seemed easier to write custom serializers and adapters for most models instead. Maybe it was an incorrect assessment but after a pretty steep learning curve I can at least say I know a lot about how ember works :) Also, if you do not use Ember Data, you don't get to use the data part of the nice Ember plugin for web browsers.
    - Touche 10y ago
      I don't follow your criticism then. Sounds like you have a really bizarre back-end setup and Ember provides you a low-level way to integrate it, so how is that "too opinionated"? Did you expect a high-level API that would work with this multiple endpoint setup?

orf 10y ago

I'm in the same boat, it's one of the only tools I feel almost fanatical about sharing and spreading. It's really nice and it's a shame it doesn't get more love on HN. The only downside is it takes a while to get your head around its object model and how to structure your apps in terms of computed properties and observers. Once that clicks though your in a nirvana of productiveness, and having toyed with the react ecosystem I've got to say that Embers learning curve is a lot nicer. There is Glimmer 2 comming out soonish, fast boot taking off and the Ember engines RFC implemented in the next version. Things are looking good!

k__ 10y ago
> it's a shame it doesn't get more love on HN Probably because it feels a bit like "the old way" for many. A big framework that covers all and brings its own tooling. Today, everyone uses its own stack to build. WebPack, Browserify, Rollup, tsc, Gulp, Make etc. When I was using Ember, I used it with Gulp, Emblem, LiveScript etc. Then they pulled this Ember-CLI stuff and some modules told me, that they depend on it. Suddendly I had to learn a new tool and tell it to do my bidding or else I couldn't use Ember add ons (painlessly). I don't think it's a inherently bad idea, especially for a Framework as old as Ember, which reinvents itself constantly.
- addicted 10y ago
  Ember was around well before Ember-CLI became a thing and it still didn't get much love. Seems to me the obvious answer is the obvious. Lack of marketing muscle that is provided by being part of a Google or a Facebook.
spion 10y ago
How does the ember object model compare to MobX? https://mobxjs.github.io/mobx/getting-started.html https://mobxjs.github.io/mobx/getting-started.html To me it looks like mobx provides all that is provided by ember models, but also adds unobtrusive syntax and automatic observable dependency tracking.
tomdale 10y ago
One thing that I'm really excited to start working on is aligning the Ember object model towards the new features coming in ES2016+. During the period of JavaScript-the-language stagnation, we had no choice but to add these features as runtime augmentation. Now that the pace of evolution on TC39 and in the browsers is so much more vibrant, we can start pushing a lot of those features into the language itself. That has two important side effects. One, it means huge swaths of code can be deleted from Ember. Two, and perhaps most importantly, it increases the chances people will already be familiar with those features once they try to pick up Ember, reducing the learning curve that much more.
- orf 10y ago
  > aligning the Ember object model towards the new features coming in ES2016+. Any examples you can give? Anywhere I can read more about this?
  - tomdale 10y ago
    For example, see Robert Jackson's addon for using decorator syntax to describe computed properties: https://github.com/rwjblue/ember-computed-decorators https://github.com/rwjblue/ember-computed-decorators

staticelf 10y ago

I really like Ember as well and uses it daily. However, if I could remake my decision I would not pick Ember today since it's too opinionated for the current project I am working on. Our stack, as it turns out, is not really ember-friendly. For example, we need several endpoints for the same models which was a pain to get to. Also we don't use jsonapi which also is a pain if you use ember and so on. We didn't know these things before picking the framework, but it's really opinionated which can be a good thing as long as you pick the same opinions and solutions as they do. Developing in Ember for me means basically figuring out how to implement stuff that Ember already have out of the box since we cannot use some of that. But when we can, development is a breeze. If anyone is thinking of using Ember for a new project, be really sure that Ember really is going to work with you and not against you.

vertex-four 10y ago
Note that Ember is not actually strongly tied to Ember Data - the model() function on a route can return any Ember promise, and you can save data however you want. If the rest of Ember is roughly what you want, implementing a custom method of getting Ember objects from API responses and vice versa is probably easier than trying to wrangle Ember Data into doing what you need.
- staticelf 10y ago
  We had a discussion if we should skip Ember Data or not but concluced that it seemed easier to write custom serializers and adapters for most models instead. Maybe it was an incorrect assessment but after a pretty steep learning curve I can at least say I know a lot about how ember works :) Also, if you do not use Ember Data, you don't get to use the data part of the nice Ember plugin for web browsers.
  - Touche 10y ago
    I don't follow your criticism then. Sounds like you have a really bizarre back-end setup and Ember provides you a low-level way to integrate it, so how is that "too opinionated"? Did you expect a high-level API that would work with this multiple endpoint setup?