

What's Coming in Ember.js in 2014 - makepanic
http://emberjs.com/blog/2013/12/17/whats-coming-in-ember-in-2014.html

======
adamnemecek
I have a small suggestion for the Ember.js team. When I was trying to learn
Ember, I was looking at the source code of the Discourse project and I noticed
that they do some things that are AFAIK discouraged (e.g. referencing
App.__container__ directly).

Idk how much effort it would be to keep an eye on the project and submit an
occasional pull request but doing that might be a good idea. Discourse is
probably the first place where people go once they have read the docs and want
to see Ember in action. And seeing these hacks might reflect badly on the
framework even though it's not Ember's fault.

------
Bahamut

        EMBERDART
        
        Just kidding.
    

I laughed.

This progress for Ember is really making me interested - I will probably do my
next big app with Ember. I'm happy to see that they are moving away from
requiring jQuery & swapping Handlebars to HTMLbars, which will help reduce
Ember's JS required footprint, which is massive currently.

Nice integration with ES6 also sounds promising. One thing I fight with
Angular so far is with asynchronous loading of
modules/controllers/directives/services/etc. - while I love Angular, its not
good for lazyloading.

I'm a bit wary since I have found that I don't like convention over
configuration personally, but I am liking some of the high level decisions
made recently to refine Ember.

------
aaronbrethorst

        Despite the imminent End of Life status of
        Windows XP, we will continue supporting
        Internet Explorer 8. We know many Ember.js
        users still need to target enterprise and
        education customers, who will be on IE8
        for some time.
    

It'll be interesting to see if the Angular folks end up having to walk back
their v1.3 removal of IE 8 support. Also, I'm very pleased to see the Ember
folks adopting a more 'realistic' attitude.

Edit: Also, where's Ember Data?

~~~
argonaut
I doubt it. It's not like IE8 is dropped by Angular. If you want to use
Angular with IE8, use v1.2.

~~~
orand
Too simplistic. Yeah that's a fine solution today. But it's not fine a year
from now. This has a big impact on decision-making for any project that
actually matters and will therefore be around for a while.

Dropping IE8 support + the "don't worry, it's free" Dart port make me very
concerned about committing to Angular for anything I might be maintaining 2 to
5 years from now.

~~~
argonaut
Expecting Angular to support IE8 is highly unrealistic. Angular is innovative
and different, IMO. To expect Angular to maintain support for IE8 is to expect
Angular to sacrifice speed of development / innovation. Support of IE8
constrains the feature set that is possible in Angular. There's a reason
Angular seems to be winning more independent/general developer mindshare than
Ember, and this is the reason.

Anecdotally, I've noticed more established/larger tech companies (other than
Google) using Ember, and more startups using Angular (with some exceptions
like Amazon, which uses Angular). I think this is also a reason.

------
ben336
Inventing their own build tools instead of using a Grunt plugin seems like a
severe case of NIH for ember. I'd be curious to hear their rationale beyond
"the currently-available options all have fatal flaws that make them
unpleasant to use as your app gets larger."

~~~
wycats
In general, I've come to believe that it's very easy to look at decisions as
"severe cases of NIH" by looking at available tools and assuming that
_something_ must fit the bill.

Especially in the young ecosystem that is JavaScript, there are often areas
where the existing out-of-the-box solutions just don't satisfy the use cases
of other open source projects.

As Stef said, our first attempt was to build a grunt-based build solution, and
it may still be possible to do so, but it wasn't as simple and drop-in as you
might expect. When the work to build on top of existing solutions becomes
significant, it's not longer an obvious and "severe case of NIH" to consider
more home-rolling. Sometimes those home-rolled solutions even become useful
for the broader ecosystem (for example, git).

I don't think that Ember should build a huge, monolithic build tool system
tightly coupled to Ember. We're already looking at bringing together the best
in breed of existing tools and working with people who are building other
tooling components that satisfy some of our needs. We absolutely plan to use
bower for package management, for instance.

NIH is a really easy accusation to throw out, but real life, especially with
large open source projects and young ecosystems, is hardly that simple.

~~~
ben336
Fair enough. I think the "tightly coupled to ember" part is what left a bad
taste with me. Obviously the ember community is free to use whatever they
want. But if the build tool is only useful for ember (and the "ember" name in
the example cli indicates that will be the case) it seems like it might
struggle longterm to keep up with grunt or other more broadly applicable build
system.

~~~
iamstef
Your concern is noted, and is also a concern of ours. Rest assured the ember-
cli will only be a small veneer providing a curated experience of community
tools.

The reason for the proposed tight coupling within the ember-cli is to ensure
we can provide a stable, performant development experience.

------
weeksie
Honestly, Ember has been incredibly frustrating to get going. Mainly in the
area of testing—it's a nightmare.

The documentation is nicely formatted but missing a lot of context. For such a
large project, it needs more than API docs and the overviews are not
especially useful.

Using it with Rails is a nightmare, you have to fiddle with ember rails and if
you want to use anything but Handlebars it's a huge hassle (tags, what? I
thought we'd collectively moved past that to things like Haml, Jade, Thin,
etc. . .)

I love where it's headed and I like a lot of the ideas, but it's been pretty
aggravating to get up and running.

~~~
samratjp
I started a major rewrite for a Rails App that I'm converting to Rails API +
Ember with Ember Data. Yeah, the learning curve has been huge and Ember Data
pretty much didn't help things. But, I've stuck with it and everytime I
struggle with something (happened first with routing nested resources - still
feels a bit magic sometimes), I take a step back and look at the Ember way of
doing things and I usually become enlightened with the very well thought out
decisions.

For those of you struggling with Ember Data - this is your best friend -
[https://github.com/emberjs/data/blob/master/TRANSITION.md](https://github.com/emberjs/data/blob/master/TRANSITION.md)
probably the best documentation on the matter. If you got Active Model
Serializers, use the right serializer on Ember data side to get going.

IF you're using Ember Rails - be sure to check that it's pulling the latest
Ember Data.

I like that there are more tutorials and demos coming out but seriously, we
need some more non-trivial UI examples. Maybe after my project I'll write up a
blog post if anyone here is interested.

------
hablahaha
Yay EmberConf! Anyone have any idea where it might be?

Sidenote, this was really fun to read for some reason, like eating a bunch of
little mini cookies.

