Ember.js 2.7 and 2.8 beta released
emberjs.com
emberjs.com
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.
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!
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.
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.
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.
Any examples you can give? Anywhere I can read more about this?
To me it looks like mobx provides all that is provided by ember models, but also adds unobtrusive syntax and automatic observable dependency tracking.
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.
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'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 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.
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.
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.
var arr = [{ value: 'a' }, { value: 'a' }, { value: 'b' }, { value: 'b' }];
arr.uniqBy('value'); // [{ value: 'a' }, { value: 'b' }]
var arr = [{ value: 'a' }, { value: 'a' }, { value: 'b' }, { value: 'b' }];
arr.uniqBy(element => element.value); // [{ value: 'a' }, { value: 'b' }]
Are there any advantages to use a string instead of a "static" way of accessing the property ?
Also I don't think ember would work with functions instead of strings, the whole point of the strings is that the unique function is only called when one of the items in the property paths changes, and you can't get that from functions. You can only evaluate them.
About time wasted, I feel like in the long run, you gain more time by writing statically analyzable code. If you make a typo in the string, you would have to build/transpile+launch the code in order to see the error. Additionaly, if you ever refactor the name of the property, the linter will directly tell you that "value" in the lambda must be changed.
But there is no way around it - property keys are strings because they can be many layers deep (`foo.bar.test.abc`), and if any of those are undefined then the result is undefined. Also any of those properties (`foo`, `bar`, `test` or `abc`) could be themselves computed properties that depend on others. You also get features like `@each`, used for arrays like `foo.@each.bar`.
Perhaps a good middleground would be to do something like C#'s LINQ stuff, where the lambdas are analysed and the values extracted.
Example:
Ember.computed.map('myArray', function() {
return foo.bar;
})
Ember.computed.mapBy('myArray', 'bar')
There isn't really great linter/compiler support for ember anyways, mainly because of how you're forced to use getters and setters. In ember, your example would look like
var arr = [{ value: 'a' }, { value: 'a' }, { value: 'b' }, { value: 'b' }];
arr.uniqBy(element => element.get('value')); // [{ value: 'a' }, { value: 'b' }]
> Are there any advantages to use a string instead of a "static" way of accessing the property ?
It's just shorthand for (what I imagine is) the most common use-case. Keep in mind that `uniqBy` is a property macro, which provide simplified apis for very specific use-cases. You always have the ability to write more complex, custom computed properties.
It's pretty common in ember to look up a property by string to set or get using the methods `get` and `set` on an ember object (ember has it's own object model[1]), and these property keys/strings can also express nested properties by spacing dots between nested property names. Like `user.get('organisation.name')` to get an user's organisation and the name of the organisation, this handles the situation when organisation is null, by returning null. So it's similar to `user.organisation?.name` in swift.
So for consistency sake and predictability sake ember also uses a string for this method. If we look at the implementation[2] you can see it use's a method called `guidFor`, it basically handles the whole null checking stuff, which in a lambda version would look something like
var arr = [{ value: 'a' }, { value: 'a' }, { value: 'b' }, { value: 'b' }];
arr.uniqBy(element => (element != null) ? element.value : null);
[1]: https://guides.emberjs.com/v2.1.0/object-model/
[2]: https://github.com/emberjs/ember.js/blob/45c92fb2c8931b4ca41...
[3]: https://github.com/emberjs/ember.js/blob/45c92fb2c8931b4ca41...
Ember also has an optional data package called ember-data, with the goal of being the defacto way of dealing with server side state. It's fairly opinionated, but swappable with other alternatives.
We have been waiting to see it stabilize a little so we can adopt it. Can we safely use it in production now?
Still, I think it's a pretty good time to start exploring engines. I'd say that the feature should be quite stable by the time 2.8 stable ships. Plus, we should have a preliminary lazy-loading story finished by then, which has the potential to really impact your app's perceived performance.
That said,
if (Something is on the frontpage) { it matters for some users of the HN community. }
I don't want to self promote but I am sure you can find my other posts, I am creating a web app once every 2 or 3 weeks with ember and firebase - the beauty of conventions over configurations and of opinionated frameworks.
There 50 ways to setup a react or angular project. There is ONE way to do it in ember. You can move into a new code base and know exactly where everything is. (ps: you could change the conventions if you wanted, but why would you do that!!!)