
Ember.js 2.7 and 2.8 beta released - andruby
http://emberjs.com/blog/2016/07/25/ember-2-7-and-2-8-beta-released.html
======
erikrothoff
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
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__
> 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
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.

------
Longwelwind
Over-reliance on strings is a pattern that I've seen a lot in the Javascript
environment. For example:

    
    
      var arr = [{ value: 'a' }, { value: 'a' }, { value: 'b' }, { value: 'b' }];
      arr.uniqBy('value');  // [{ value: 'a' }, { value: 'b' }]
    

Wouldn't be better to do something like this ?

    
    
      var arr = [{ value: 'a' }, { value: 'a' }, { value: 'b' }, { value: 'b' }];
      arr.uniqBy(element => element.value);  // [{ value: 'a' }, { value: 'b' }]
    

You have to write a little bit more (I could have used "e" instead of
"element", though) but if you do a typo in the name of the property, it can be
caught by a linter/compiler, and you don't get the feeling you're relying on
Vodoo magic.

Are there any advantages to use a string instead of a "static" way of
accessing the property ?

~~~
orf
EmberJS uses strings as property paths. You can use 'foo.bar.firstObject.baz'
as a unique key the same as any other function that takes a property paths
(like a computed property). In Ember you write a _lot_ of these so any small
overhead like a lambda is a bit of a waste.

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.

~~~
Longwelwind
Thanks, I didn't know that Ember did more than just fetching the value.

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.

~~~
orf
I agree and one of the downsides is exactly this. I've felt this pain before
:(

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.

------
jjawssd
How does Ember fit into today's web ecosystem especially as it relates to
React?

~~~
erikrothoff
Ember is moving to a similar view model as React (though still having
templates separated from logic) but isolated components with immutable state
being passed down. React has a really vibrant ecosystems with lots of
batteries to choose from, whereas Ember comes with batteries included. For
example routing, test runners, controller/view logic concerns.

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.

------
nagarjun
I am really excited to see Engines getting some more recognition in this
release. We are building [https://tripcloud.io/](https://tripcloud.io/)
entirely with Ember and the application is starting to get bigger and bigger.

We have been waiting to see it stabilize a little so we can adopt it. Can we
safely use it in production now?

~~~
dgeb
Developers from several large public-facing sites have already told me that
they're using engines in production. In fact, Kacey Coughlin is giving a talk
tonight at the SF Ember meetup about LinkedIn's experience using engines [1].
Granted, the talk is titled "On the Bleeding Edge with Ember Engines", which
fairly points out that there are some rough edges left to smooth over.

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.

[1] - [http://www.meetup.com/Ember-
SF/events/231368426/](http://www.meetup.com/Ember-SF/events/231368426/)

------
co_dh
I used Ember once, took over an Ember project from a very good Ember
programmer. I found I have to duplicate the models from database, to ORM in
backend, and Ember. Everytime I have to modify/add a database column, I have
to modify 3 places. So I end up get ride of Ember and use Flask-Admin only.
Even better, I get ride of the ORM in Flask too, using reflection. Then my
code is 3 times less, and I feel happy.

~~~
ben336
if your project was capable of running as just a series of backend driven
pages, Ember probably wasn't the right choice to start with. That isn't really
what it is for.

------
esistgut
Does Ember offer something similar to React Native for React or NativeScript
for Angular 2?

~~~
mrinterweb
I don't believe so. My opinion is that well optimized hybrid apps can often
compete with the quality of native apps. It is not easy crafting a good hybrid
app, and few good ones exist. Many of the low quality hybrid apps have given
hybrid apps a bad reputation. Ember + cordova can be a good toolset for
creating good hybrid apps.

~~~
dbbk
Which one is it? "Hybrid apps can often compete", or "few good ones exist"?

~~~
mrinterweb
LOL. I can see how that could be confusing. In theory a hybrid app could
compete, if it was written well; yet, there are plenty of bad hybrid apps that
give hybrid apps a bad name. I think it is a matter of effort that developers
are willing to put into making a hybrid app. With a hybrid app, having good UI
design is more of a challenge because they can not always leverage OS UI
components, and when they try to mimic OS UI components, they never look quite
right. With custom UI design, many users may never know if they are using a
hybrid app or native. Obviously, hybrid apps are not an option for all types
of apps, but I'd argue that hybrid is a viable option for many if not most
types of apps. So long as the performance of the hybrid app is not noticeably
slow to the end user, hybrid apps can be great apps.

------
geekodour
This will be awesome

------
jjawssd
Why does Ember matter?

~~~
awesomepeter
Why wouldn't it matter? It's an actively developed framework which many people
really like. I'm actually baffled that it doesn't get mentioned more often.

~~~
okket
A fair amount of posts on HN deal with the negative sides of things, so it
could be a good sign that Ember does not get mentioned more often while
growing >)

