Hacker News Reader

Comment by erikrothoff | Hacker News Reader

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.

View on HN

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!

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

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.

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

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.

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.

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.

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?

Clearly the criticism is that it was very muh harder than it had to be, due to the opinionated nature of Ember, even though it's possible. Eg, things you expect to work just not working, because some hidden convention is being violated, and requiring a bunch of hacks to make it work (making this example up btw, I haven't done any Ember).

I'm not sure I'd conclude that their backend is bizarre, sometimes things cannot be perfectly resource-oriented in a 1:1 fashion with the backend. I know I've needed to expose two different endpoints and frontend models for the same backend model, for good reasons.

If your data isn't resource-oriented, you are probably better off without ember-data. We started off using ember-data with an aggregated stats API and eventually found that just using regular ajax was much easier. No hacks needed, just define model() as an ajax call and don't pull in ember-data.

If you're using ember without ember-data, you don't have a "store" and ember-inspector's data-store inspector won't do anything. You'll probably end up having to look at network calls.

Ember is opinionated in plenty of ways, but I don't think reliance on ember-data is one of them.

This. I can say that maybe it would have been a better choice to go without Ember Data but since we started there is simply too much work to redo a lot of stuff instead of just continuing in the same path.

We didn't know ember had these conventions when we started working with it since it doesn't really advertise it and the problem first arises when you're trying to do something that feels easy but gets complicated due to Embers convention.

> Clearly the criticism is that it was very much harder than it had to be, due to the opinionated nature of Ember, even though it's possible.

The opinion is just wrong, then. It wasn't harder because Ember is opinionated. It wouldn't have been any easier with React, which has no model layer at all.

Reply on news.ycombinator.com