3 ms·

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

by 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

by orf 10y ago

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