Hacker News Reader

Comment by orf | Hacker News Reader

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!

View on HN

> 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.

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.

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.

> aligning the Ember object model towards the new features coming in ES2016+.

Any examples you can give? Anywhere I can read more about this?

For example, see Robert Jackson's addon for using decorator syntax to describe computed properties: https://github.com/rwjblue/ember-computed-decorators

How does the ember object model compare to MobX? 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.

Reply on news.ycombinator.com