
Why is Ember fading away? - vmware508
https://medium.com/@jorgelainfiesta/why-is-ember-fading-away-13da2aa65a06
======
senoroink
As someone who has moved from using Ember daily for 2+ years to now using
React/Redux, I miss Ember on a daily basis. React suffers from lack of
standardization like no other. I hate starting a new project or working on an
existing project and having to think about where to put things. Ember grew
from developers who existed in the Rails space and understood that convention
over configuration is the way to go. React devs likely came from Express land
where everything is composed of tiny modules that you'll spend days carefully
putting them all together.

The React world is the wild west. Libraries come and go so quickly that you're
better off building it yourself if you see your app as long living. Ember, on
the other hand, does a great job of keeping everything in check. Because the
community is so small, things just work because there's less things to
maintain.

Admittedly, when I first got into Ember, it was pre 1.0 days. Even prior to
v2.0, Ember struggled to keep things working as intended. Now that the
framework has matured, most pain points have gone away. The way they do their
versioning is the smartest in the industry. React has been around for years
and still the community seems fragmented.

What it boils down to is:

Is your app fairly small and intended to only last about a year? Use React

Is your app core to your business used by many and intended to last for the
foreseeable future? Use Ember

~~~
coldtea
> _As someone who has moved from using Ember daily for 2+ years to now using
> React /Redux, I miss Ember on a daily basis. React suffers from lack of
> standardization like no other. I hate starting a new project or working on
> an existing project and having to think about where to put things._

And it shouldn't even have to sacrifice it's "open/modular" nature to fix
that.

The core team (Dan, etc) could just adopt/suggest a few specific companions
(router, redux, etc) that they consider "official" part of React, and still
allow open interfaces for people to be able to replace them with whatever they
want.

~~~
senoroink
Sure they could but they haven't, yet.

And there doesn't seem to be anything on the radar to do so. While I've played
with enough boilerplate projects in the React/Redux world, there's nothing
considered to be officially supported and even the most popular ones have
stagnant development.

------
atonse
I still strongly favor Ember for exactly the reasons React and other
frameworks simply haven't caught up: the out of the box experience.

I can start building an actual app within 3 minutes of typing "ember new" –
with React, I'd spend the first couple of days just fiddling around with build
scripts.

Sure, there are now react boilerplates that do this, but there are too many
out there to properly evaluate what to use. Why not just make it a part of the
framework?

I think one of the reasons React has been successful is that most developers
inherently enjoy the actual act of tinkering as much as they do actually
building something. They are ok with spending the first 72 hours of their
project picking and setting up their build tools.

On the other hand, I can't stand that stuff.

That's what's so weird to me about all this. Ember is to front end JS exactly
what Rails was. Yet rails was successful and Ember wasn't. I think it's the
difference between front-end culture and back-end culture.

~~~
davedx
> I can start building an actual app within 3 minutes of typing "ember new" –
> with React, I'd spend the first couple of days just fiddling around with
> build scripts.

> Sure, there are now react boilerplates that do this, but there are too many
> out there to properly evaluate what to use. Why not just make it a part of
> the framework?

create-react-app [1] is the official out-of-the-box CLI for React apps. It's
maintained by the React team and has been around for a while now too. I may
occasionally disagree with what gets included (e.g. service workers) but
overall it's been a massive bootstrapping productivity booster for me.

[1] [https://github.com/facebook/create-react-
app](https://github.com/facebook/create-react-app)

~~~
atonse
As recently as 6 months ago I had react developers point me to a couple
different boilerplates. So my info on this is a bit skewed. Good to check into
this.

------
abledon
I'm just going to say it: Their mascot was an annoying hamster.

This was their downfall.

Angular, sexy geometric design. React, sexy nuclear design. Vue, Sexy V
geometric design. Ember, a big goofy rodent looking at you lol. "But abledon,
what about GOlang? they have a rodent too?" Yes but golang resides in backend
land where designers and frontend visual brains are lacking, only performance
matters, doesnt matter if your framework's logo is a steaming pile of poo, if
its fast and easy to write concurrent code in, it will win the backend holy
wars.

~~~
StevePerkins
I think it's more about corporate sponsorship and branding.

Angular is seen as "The Google Solution" (disregarding that Google doesn't
actually use it as much as people think). React is seen as "The Facebook
Solution". Ember is more decentralized, and lacking a strong primary
champion/sponsor. Something that developers SAY we like in open source
projects, but which frankly doesn't really match our actions so much.

I chuckled a bit at the parent comment, but I won't say that logos don't
matter to front-end developers (half of the HN discussion threads about a link
seem to be about its font and CSS choices rather than its substantive
content). But that's only a slice of what I think is the overall reason. Ember
just doesn't have strong corporate brand muscle behind it.

~~~
nojvek
Sure that has some value, but Angular and React brought in new ideas for their
time.

I think the react 'view as a function of state' makes a ton of things easier
to reason about, and will probably last for a while.

------
heckanoobs
I think there is a lot of tribalism in the js community and liking one
framework (often the one you use for work) is synonymous with hating the
others. Take this survey done where the people who have "heard of Ember and
would NOT use it" is completely outsized with the rest of the data.
([https://stateofjs.com/2017/front-
end/results/](https://stateofjs.com/2017/front-end/results/))

I've been developing professionally for 15 years and even in that short a time
I've had to frequently start fresh in new frameworks or languages as the old
ones lost their edge. The concept that someone would all-caps "NOT" use
something is hilariously junior to me because the sands _will_ shift and you
_will_ one day face the cliff of: my existing skills have no job demand, do I
learn new skills or change profession? Harboring tribalism toward frameworks
will not help you make the right decision in times like these.

~~~
coldtea
> _I think there is a lot of tribalism in the js community and liking one
> framework (often the one you use for work) is synonymous with hating the
> others._

As in nature in general, it helps, from an evolutionary standpoint.

Having too many, and letting them all be, instead of people rooting for their
favorite and having one or two emerge as the leaders, leads to dispersion of
resources, confusion for newcomers, and multiple weaker implementations of the
same thing...

Even if the emergent leader is not the best, the mere fact of it having
eclipsed the others, means tons of work, libs, documentation, books, support
etc will be concentrated towards it.

And it's better to have one leading framework that's 3/5 good with huge
community and support, than a 5/5 good framework with lackluster community and
support.

~~~
heckanoobs
There's no reason you can't have a 5/5 framework with huge community and
support.

Tribalism leads to choosing between two hobbled solutions because it closes
the door on teamwork across tribes. Ember has its flaws but their upgrade
strategy is world class. Every maintainer of an open source project should at
least be familiar; but how can that happen when ppl happily report they "have
heard of Ember and would NOT use it"?

~~~
coldtea
> _There 's no reason you can't have a 5/5 framework with huge community and
> support._

There's no law of physics preventing it. I'll give you that.

But between fragmentation of effort, few full-time collaborators, no funding
for less interesting work, and other such things, there are many reasons we
can't (and don't) have any 5/5 frameworks with huge community and support.

------
3pt14159
I'll take a counter view here.

Ember shines best when building very UI rich, complex front end apps. Not apps
that need to work on shitty connections or devices. Apps you would use from
your office in NY or Toronto.

But the sad fact is that there just aren't that many frontend apps out there,
relatively speaking. Ember is hard to learn because you need to learn a lot to
get things done, and most people building something simple are lazy. By the
time their project is a huge mess they're already locked in. Take HN for
instance, the tech powering it is dead simple. It doesn't need to be giant
frontend app.

Ember is a really solid framework that I love that is never going away, but it
isn't for everyone and that is ok. Ember devs make a higher salary because
they generally need to know more and the apps are more maintainable and
generally run by pro dev shops, but it's not for everyone.

One thing I think that could really help Ember is a version of Rails or some
other backend that required less mucking around to get everything working.
It's such a chore to fully follow JSON API v1.1. But relation links and cursor
based pagination are great with tools like Ember Data, so it's worth the
effort.

~~~
berkes
> Not apps that need to work on shitty connections or devices.

Curious, why would you say that? I've only ever dabbled with Ember a little,
never built anything production-ready with it. But I did have to maintain an
Angular (1) app. And that thing was chatty as hell. I was the backend dev, and
developed the REST api that our apps and this Angular bowl-of-spagetti
communicated with.

Where ember has, built in, localstorage caching and even some cool REST-sync
systems, angular has none of that. The closest I could get was angular-
resources, which is a ORM-alike-approach to communicating with a REST backend.
Proper HTTP-caching headers, Etag caching and so on, allowed leveraging the
browsers-caching to avoid some calls, but Ember has a far neater and cleaner
way to talk to such a backend.

This is just an anecdote, but I was pretty convinced that from all the JS-
frameworks, ember had the "get data in- and out of a REST backend" solved the
nicest, fastest and cleanest.

~~~
3pt14159
It's more the type of app that you build with Ember. It ends up just being so
much more complex and that requires multiple requests. You can't locally store
everything, and you often can't do everything on the first request, so if
you're on a connection where packet loss is an issue instead of 3 or 4 round
trips you end up having 16 or 20. With a shitty device the commutative lag
between janky animations (which ember makes easy with libraries like Ember-
Concurrency) it just destroys the experience.

Whereas the other frameworks don't make things as app-y as easily so its more
like a local template language than an app builder. So people don't go as hog
wild.

That plus a larger initial JS file than something slimmed down like React. It
kinda adds up even if in theory it shouldn't.

------
aclimatt
I think it's the natural evolution of frameworks. About 5 years ago, we had
the Cambrian explosion of front-end frameworks -- Angular, React, Ember,
Meteor, Backbone, even jQuery was still hot back then, and certainly dozens
more. Technology had advanced enough that we finally were seeing new
innovative ways of building web apps, and everyone had their own opinion on
how to do it the Right Way.

This was certainly good for technological progress, but if anyone recalls the
arduous process of "which frontend stack should I choose?" back then, it was
an absolute nightmare. I had no idea which framework was production-ready,
which framework would be around in 2 years, and heck, which framework even
worked as advertised (and I remember distinctly wasting two weeks of my life
trying to get a-then-very-beta ember-data to even fetch correctly, and
eventually gave up and apologized to the client that their project wouldn't be
done on time).

Fast forward to 2018, as happens with basically every technological
advancement ever, we are starting to standardize. Most of the evolutionary
branches are dying out in favor of one or two of the strongest candidates (in
this case, React, as far as I can see). This has resulted in huge maturity
gains, performance improvements, library standardization, lower training
costs, generally lower software maintenance costs, and overall stability in
the ecosystem. And as someone who is generally a fan of the "more wood behind
fewer arrows" philosophy, having suffered through the world war that was
JavaScript in 2013, I am really enjoying the calm before the next storm.

Because, as always, the next wave of disruption will rise again. This current
consolidation is at the expense of change -- there will be less paradigm
shifts, there will be less new ways of doing things, and that both provides
for stability and stagnation. But like clockwork, come about 2020, there will
be a new catalyst for change (maybe our next Cambrian explosion will be thanks
to WebAssembly?).

So in short order, don't worry, we'll get to play the "which of these
libraries even works" game in no time.

~~~
darepublic
Angular 1 and Backbone belong to an older generation of frameworks imo and
shouldn't be lumped in with React and Meteor.

~~~
lucisferre
So Precambrian?

I'd argue that Backbone is from an even older generation.

------
gavinjoyce
We've been using Ember at Intercom for over 4 years to build our main app.

We continue to be super productive with Ember, our customers love our product,
our code base has never been healthier and Ember's careful upgrade path and
approach to deprecations means that we don't spend much energy or time
thinking about non-product related technical challenges.

We've grown from 10 to 150 engineers in that time and Ember's strong
conventions has helped us continue our tradition of enabling new engineers
shipping to production on their first day and shipping a feature to production
in their first week.

Ember is not fading away for us, it's enabling us to focus on continuously
shipping better and better features to our customers.

------
hardwaresofton
In my mind, if you need a large framework that a whole team can use day in and
day out, Ember is the go-to choice. It's got a lot of batteries included and
the learning curve is pretty steep, but it has patterns and a way to do things
for just about everything. It's also been rapidly absorbing the best parts of
other frameworks and approaches -- fastboot, glimmer, etc.

\- Angular had the spot, then bumbled the transition from 1->2->5.

\- Durandal died/was transformed into Aurelia, whose hype never materialized.

\- Backbone +/\- Marionette seems to be in super slow decline, but doesn't
update as fast as Ember.

\- I don't know much about Polymer but it just seems like an interesting
project, not something I'd suggest an org to use (I'm probably wrong).

Ember shouldn't be compared to tools like React/Vue because it's almost
_never_ just React/Vue, and Ember itself has lots of plugins that come into
play. "React" =~ React + React-Router + Redux/Reflux/Fluxxor/Flux/whatever,
and roughly the same with Vue -- though you can choose to extend Ember with
plugins, by default everything you need is baked in, with ONE set of well-
written if not long documentation. I can certainly say that Ember is more
coherently put together than react/vue + react-router/vue-router + redux/vuex.

One of the biggest problems with ember of course, is the breakneck pace of
change. I think it's slowed down somewhat recently, but keeping up with it can
feel like a full time job sometimes, if you get stuck behind for too long, it
gets harder and harder to update your codebase.

As far as I'm concerned, Ember should keep doing what it's doing, it's
basically the only worthwhile competitor these days in the most-batteries-
included (aka frontend framework rather than frontend library) space. If
anything these days, Angular (5?) is looking like it's pivoted it's way to
essentially emulating Ember, so I'd place it second.

~~~
megaman22
> One of the biggest problems with ember of course, is the breakneck pace of
> change. I think it's slowed down somewhat recently, but keeping up with it
> can feel like a full time job sometimes, if you get stuck behind for too
> long, it gets harder and harder to update your codebase.

If there's somewhere in the front-end world where this is not the case, short
of going back to jQuery spaghetti, I'd love to find it. We're largely settled
in with AngularJS, having caught it after the crest, so that is largely
settled, but everything around it is moving and breaking and deprecating
things left and right. I always feel like we're standing on quicksand, just
waiting for some bower or npm package to get yanked out from under our feet.

Compared to the back-end, where things move at a much, much slower rate of
change, it is a little maddening to see the churn in JS-land. I have NuGet
packages that I use all the time that haven't seen more than minor-minor
version updates in three years - and that's fine, they work, they're stable,
there's no reason to burn it down and flex it all around every three months.
But that's also a benefit of being in the Microsoft ecosystem, where
backwards-compatibility is prized.

~~~
hardwaresofton
I actually made that statement with the pace of the front-end world taken into
account -- ember actually churns additionally :( . Part of Ember's openness to
doing things better often involves deprecating/removing parts of their API
that they're convinced was wrong before -- it's not a bad thing, but it means
that if you get stuck on some version, and the next version has gone a
different way on some concept/part of the framework, you're going to have a
bad time, even if the landscape hasn't moved much yet.

I spend a lot in frontend land and I've grown somewhat accustomed to it's
insanity. I actually even like it at this point -- Let everyone go insane in
all the different directions, watch how they fare, then let the good stuff
rise to the top, and pull out the interesting paradigm shifts if there are
any. Platforms like C# often have a lot more enterprise weight behind them and
"stable" takes on a completely different meaning.

I might even say that churn in .NET is happening too, it's just way way more
localized. For example the .NET core/standard move is happening right now, but
I can only assume that the vast majority of codebases on .NET 4.x don't care
at all, and are letting it work itself out maybe over the next year before
they even consider moving (if they ever move at all). As a person who's
struggled with porting a .NET 4.x package to .NET core/standard, and with some
associated libraries (EF, mostly), it was not a pleasant experience, but by
the time it gets to everyone else, it probably will be.

------
makmanalp
I really feel for Ember - we picked it for a project we started a few years
ago because react was still very new and angular was in the middle of the 2.0
transition. The Ember folks really made sure that transitioning to new Ember
versions is straightforward. I don't even enjoy writing javascript, but I have
really nothing but good things to say about it overall.

What it suffers from is a small community: we depended on a table component
someone wrote which used some weird internal APIs and never got properly
upgraded to ember 2.0 so we got stuck with ember 1.x until now because the
overhead cost of switching to another library was too high to be worth it.
Even then, the maturity of the project has been great and things don't break
all the time. The API has been improving and the ember developers are
proactive about pulling in the best ideas from newer projects. If you read the
Ember RFCs they're always introspective and future-conscious and great. I
really hope the project survives, not that I had much doubt. I think there is
still quite a dedicated crowd.

------
tboyd47
> What are your thoughts? What, if anything, should be done to make Ember
> relevant in the JavaScript horizon again?

As a total outsider to Ember, but an insider in the JS community, having
worked in various web-dev roles for 10 years and served as tech lead on a
full-stack ReactJS app, my recommendation is to double down on production of
junior developers (yes, I said "production" instead of education, and that is
how you should look at it; producing capable workers).

High barrier to entry is the Achilles' Heel of ReactJS. It's in a very similar
position to Ruby on Rails five years ago. If you want to kill React, go for
the low-hanging fruit: the juniors. Take a lesson from Python. It doesn't
matter how old you are; capture Programming 101 and the future is yours.

------
mar225
We us Ember at my company. We started using it around the 1.0 release. We have
been very happy with it. But as a shop that doesn't really have any dedicated
front end developers the most frustrating thing for us is that their
conventions are always changing or worse threatening to change but don't so
your left always wondering if what you are doing is the right thing. People
have been waiting for controllers to be deprecated for years. That being said
I think they do have to make these changes to keep the framework moving
forward and I appreciate the amount of effort they put in to keep things
backward compatible. I think now that they are providing code mods for a lot
of the new conventions people won't be as hesitant to upgrade. Before there
was a lot of friction when upgrading to a new version that had different
conventions and you felt you should go and modify your existing code to follow
the new conventions. I have confidence that with their strong user base they
will stay relevant for many types of applications. If people are hesitant to
try it I'd tell them to keep in mind that even though Ember has conventions
and provides the ember way of doing things it is possible to integrate most of
the exciting things going on in the js world with Ember. Some people even use
react components in their ember apps.

------
realty_geek
I invested a lot of my time over the last few years into Ember and though it
was a difficult decision I eventually had to accept that I would be better off
moving to Vue.js. I have written a bit about my decision here:
[https://hackernoon.com/why-i-am-migrating-
propertywebbuilder...](https://hackernoon.com/why-i-am-migrating-
propertywebbuilder-from-ember-js-to-vue-js-ca40925fa633)

Its a shame but the reality is that ember will not stand the test of time.

~~~
anoncoward778
"...will not stand the test of time" Based upon what math do you qualify that
statement? What equations do you apply to support this?

~~~
shard972
Since when did such a statement rely on hard emperical evidence?

~~~
dbbk
You can certainly state it as an opinion, but calling it "the reality" does
typically mean backing the assertion up with some substance.

------
tbassetto
I was confused by the title but this is about EmberJS, the web front-web
framework.

From what I have seen from my peers, EmberJS is indeed often ignored :/ The
developers I know that are using it at work seem very satisfied AND very
productive with it though. And the same core team also released GlimmerJS
which is very interesting: [https://glimmerjs.com](https://glimmerjs.com).

------
tabeth
The premise seems to be that popularity is what's important. I'd say the
useful metric is whether or not you can be productive with the tool at hand.
Popularity is sometimes something that can make a framework more productive
(as tutorials, documentation and libraries are released), however popularity
is hardly a prerequisite.

~~~
barrkel
Popularity is important if you want to hire developers - developers are
generally less interested in moving their career in a different direction than
the industry trends.

Popularity for frameworks is also important if the framework needs adapters to
enable third-party libraries to work with the framework. Depending on how
opinionated the framework is, the friction in embedding libraries may hamper
productivity indirectly.

If you're a one man band, then it's definitely less important. If the
framework is a really good fit for the job, likewise. Otherwise, there's
safety in numbers.

~~~
anoncoward778
"Popularity is important if you want to hire developers" 15+ year vet here.
I'd have to disagree. Popularity is important if you want to hire green
developers. Not if you want good ones.

~~~
barrkel
I've been coding for 25 years, getting paid for it for 21 years.

If you want to grow a team, you need to hire a mix of experience levels. With
younger devs, talent is correlated with being opinionated - they have passion
that hasn't been balanced by broad experience. And opinions are fashion-led.
Find me a young dev who has no real opinions, and I'll show you a dev who has
no taste.

------
soneca
I am a junior frontend dev working on my first dev job and both the main web
apps (customer facing web app and internal tools web app) are in Ember.

I like it, I could do real, valuable (if small) contributions within a month.
I am 9 months in it now and I can handle significantly more complex features.

As it was explained to me, this was part of the decision of choosing Ember.

I will try to list the reasons for us:

\- Timing: it was a time when the Angular broken upgrade from 1 to 2 was
happening and React was starting to get traction.

\- Ember was a solid and mature framework, stable enough to use on a startup
with product-market fit entering the growth phase.

\- There were clear signs that the framework was not going to be abandoned by
its developers. Not only the maturity, but its future seemed solid. In
retrospect, this was right. Ember keeps staying as a modern framework (even if
not hyped that way).

\- Its _" conventions over configuration"_ approach was very important as we
hadn't enough experienced software developers in the team. It made it
welcoming to junior developers (like myself) that could not properly
anticipate all the possible outcomes of early configuration and architectural
decisions. React is very tricky in this aspect. I believe a lot of React
applications being created these days by not so experience engineers will
cause a lot of problems in the future.

The downside is mostly human capital. Hard to find Ember developers these
days. But not such a big deal, as our hiring policy focus on more fundamental
frontend skills rather than framework knowledge, so we hired good frontend
developers that first got in touch with Ember here. And it is fairly easy to
pick up Ember for junior and senior developers both.

That said, talking to some senior developers here, it appears that, were they
doing that decision today, they would probably go with React. Being easier to
attract new hires is a big deal of that decision, as we are growing a lot our
development team and if we could offer React options we would certainly
attract an order of magnitude more candidates.

Also, React is more mature and we have more developers that are experienced
enough to make the right calls on its architecture and configuration.

But, my personal opinion, is that Ember would still be the right choice for
our situation today. Something solid, with a large enough range of problems
already solved, welcoming to new developers, easy enough to be productive from
start.

------
antoniuschan99
Right now there are three main frameworks. Angular, React, and, Vue.

Ember has always been the little guy even in the days when Backbone dominated.
But it seems to have been replaced by Vue in this regard.

~~~
myth_drannon
That's me understanding as well. NG and React are the top players and VueJS
and EmberJS are niche. On stackoverflow jobs looks like around the end of 2017
Vue jobs > Ember jobs.
[http://reallyhyped.com/?keywords=vue.js%2Cember.js](http://reallyhyped.com/?keywords=vue.js%2Cember.js)

~~~
antoniuschan99
Taking it a step further it seems to be broken down:

Enteprise - Angular

Startups and Larger Agencies - React

Smaller Agencies - Vue

Angular is dominant because large Enterprises are slow to adopt and Angular is
really great because it works so well and everything is packaged out of the
box.

React is still new compared to Angular which is why Startups are adopting it.
Kind of like how Rails was popular with the Startups a few years ago.

Vue is universally loved by Developers but is not backed by the big companies
in the States (it's bigger in China apparently?). It's considered Indie in
North America so it's relegated to low budget projects.

------
orf
My very first job after University was creating a large app in Ember. I had no
modern Javascript experience but I was productive enough with it to build a
pretty complex SPA with a lot of bells and whistles. So Ember has a fond place
in my heart.

I think Ember is fading because it's just pretty different from other
frameworks and there is a pretty big learning curve. But once you get up the
curb you become super-productive and it's really nice.

It's a shame.

------
snewcomer24
For any indie developers, Ember can be extremely productive. In the past year,
I have pushed out 3 moderately complex Ember apps in addition to having a full
time job. I've reused some code for each application, have been able to depend
on backwards compatibility for addons and always have received lots of help
from other community members here: embercommunity.slack.com

This is mainly due to my ability to focus on shipping features rather than
build processes. Also, depending on Ember Data, ember-cli-mirage, and the
JSONAPI spec have allowed me quickly spec out how my schema will look,
allowing me to move from the frontend to backend quite seamlessly. I've used
React as well to develop widgets and such, but nothing has matched my ability
to build, test, and ship features more than Ember.

We are all in this together and should focus on lifting all of us up.
Positivity begets positivity.

------
icholy
I moved away from it because the object model is too prescriptive.

~~~
jherdman
Would you be able to elaborate on that a bit?

~~~
ynniv
I avoided it because the team had previously sacrificed the stability of
SproutCore to make it “web designer friendly”, and Ember was more of the same.

------
vasilakisfil
Having worked with React and Ember, in Ember I am super productive. I can
setup a whole app in a couple of days. I think the market is so big in front-
end that even a relatively small market share is actually quite big in
absolute numbers.

Having said that, one of the reasons that Ember's core development seems so
slow is because everything is announced beforehand, even discussed before
hand. So if a feature A is proposed, it first needs to be submitted through
RFC, go through a long period of discussion in Github then implemented and
only then released. So it appears that it takes a long time to deliver
features but it isn't really like that.

------
wink
I'm not surprised, I've had mostly negative experiences with Ember. We wrote a
pretty small web app and several of my colleagues had immense problems getting
into it and making changes. (People who had JS experience and had used other
stuff in the past.) We ended up rewriting it completely in a week (as I said,
it was small) into AngularJS and no one ever complained again.

------
whalesalad
It came and went, plain and simple. It made assumptions and design choices
which at the time seemed sound but by today’s standards look silly. Mustache
templates for instance. Separating logic from presentation should be a choice
not a hard/fast rule with a severely limited templating engine.

~~~
StevePerkins
> _... a retarded (not using this term in the inflammatory sense)..._

Umm, I'm not sure that a "disclaimer" actually nullifies that.

------
matthewmacleod
I don't think it's any fault of Ember, but more that there are now other
competing options in the front-end Javascript space, and these will naturally
suit some other use-cases more.

------
chrisjshull
I see a lot of people who like ember-cli, but after the first few minutes I
just found it frustrating. Granted, this was a little over a year ago, but at
that time if you simply wanted a npm module in your code you had to do all the
extra work to wrap it in an ember plugin. IMO, this severely slowed down the
ecosystem.

~~~
oneplusone
As far as I know it has never been required to wrap an NPM module in an add-
on. I have used Ember since pre 1.0 and you could have just ember-browserify
for the last 3-4 years to pull in an npm module.

------
jacknews
Nominative determinism?

------
dustingetz
Ember felt very Rails-y to me. The ember community felt entrenched in rails,
and rails is reaching end-of-life. It is old-school thought. Ember made
existing ideas better, a 2x gain maybe. I want new ideas, the 100x leap.

~~~
atonse
And have you found that yet?

~~~
dustingetz
I have! Karl and I made this:
[http://www.hyperfiddle.net/](http://www.hyperfiddle.net/) Not possible to
build on ember. React.js in May 2013 was final missing piece that made
Hyperfiddle possible and our first commit was in Dec 2013.

