
Ember v3.7 Released - izelnakri
https://emberjs.com/blog/2019/01/07/ember-3-7.html
======
jorblumesea
Ember is by far the best application framework out there (react is a view
library). It's refreshing to see features come out of the box instead of
having to roll your own react + mobx + react router. Build tools are easy to
use and very transparent.

------
amonsch
Is ember still used? I always only hear that ppl nowadays use react, vue or
angular. What does ember differently/better?

~~~
jameskilton
Probably much more than you would think.

[https://en.wikipedia.org/wiki/Hype_cycle](https://en.wikipedia.org/wiki/Hype_cycle)

Ember is firmly in the "Plateau of Productivity". It's stable, supported, but
no longer the "new thing" so you don't hear much about it.

~~~
lucisferre
I'm not sure how linking to an article about the hype cycle can be considered
evidence of Ember's maturity relative to its peers.

Ember's 1.0 release was 2013 which is the same year React was announced. Yes
Ember has earlier history as Sproutcore going back to 2011, but Facebook was
using React internally since 2011 as well. I'd also argue that Ember 2.0 was
pretty different from 1.0.

Angular is older, going back to 2009, but as 2.0 is a total rewrite as well as
departure from where they started out I'm willing to let that one go. (It is
also a complete tire fire so let's just ignore it altogether).

VueJS is arguably the "new kid". But really only just barely. The first
release was Feb 2014. I'd hardly consider Vue immature at this point though.

I really don't see how one can argue it has a tangible maturity advantage
here. I also think that most of the newer generation of SPA frameworks have
learned lessons both from the previous generations and their peers (with the
exception of Angular perhaps).

~~~
gwright
I didn't read that as evidence, simply a link to define the term "Plateau of
Productivity".

------
tonysickpony
I haven't got a chance using ember. But the rancher guys
[https://rancher.com](https://rancher.com) seem to use ember a lot for their
web app. And it looks solid. There's no doubt that ember is capable when it
comes to handling complex application.

------
pb060
In my opinion Ember’s huge value added is Ember Data. I couldn’t find anything
compared to it in any other library/framework.

------
dzonga
Ember was the first web framework I tried to learn. Maybe my mind is too
dense. Couldn't really figure out shit. I guess for a simpleton like me my
mind works best with micro frameworks react or vue. I work as frontend
engineer now.

~~~
vmware505
This free tutorial helped me to understand the concept behind the framework.
Actually, I can adapt this knowledge to other work also.
[https://yoember.com](https://yoember.com)

------
dstaley
I'm still really disappointed that Ember gave up on trying to compete with
libraries like React on bundle size. I loved my experience with Ember, and I
really like what they've done recently, but the fact that out of the box it's
several times larger than an equivalent set of React libraries makes it hard
to justify. It's super awesome if you're building complex, ambitious desktop
web apps, but for simple, mobile-focused progressive web apps it just doesn't
seem worth the extra bytes.

~~~
lyime
React and Ember.js is not an apple to apple comparison. React is a UI library,
Ember.js is a framework. Glimmer would be a better comparison.

~~~
dstaley
Right, which is exactly why I said "an equivalent set of React libraries" as
opposed to just React.

~~~
true_religion
Ember as you guessed, is not for simple apps. So an equivalent set of React
libraries would have to do everything that Ember does---even when you are
building an app that does not require all those parts.

It's not a fair comparison to talk about a simple mobile-only app, and
complain that Ember is too large for bloating the bundle with things you will
not use.

~~~
dstaley
> bloating the bundle with things you will not use

The problem isn't that Ember has a lot of things you don't use; it's that the
things that are there are much larger than their React counterparts. In terms
of actual functionality, Ember doesn't provide anything that React+React
Router doesn't. The difference in bundle size arises from the different ways
Ember accomplishes the same end goal. This differences make it more suited to
desktop apps loaded over high speed internet connections. My point is that as
someone who's building PWAs designed to load as quickly as possible, it's
unfortunate that Ember isn't even a possible contender due to the minimum
bundle size.

~~~
true_religion
I thought Ember provided:

\- Observable objects and enumerables \- Models with a relationship framework
\- Controllers \- A dependency injection framework \- A templating system

In addition the router also provides:

\- Parsing of query strings in the router (React-Router does not do that) \-
Explicit loading states \- Asynchronous routing

Whereas React-Router + React provides:

\- A router \- A view layer

I also don't understand your complaint about PWAs and bundle size. Aren't PWAs
supposed to fully cache _all_ the Javascript after the first load so bundle
size should be less important? And the competition to a PWA is a downloadable
mobile app that's often many dozens of megabytes.

------
snewcomer24
Really excited to see what v4.0 brings!! Lots of hard work in the making.

------
izelnakri
I wrote this before, I'm writing this here again:

Ember is a complete frontend/SPA framework. 2 key advantages Ember.js has over
other SPA solutions are server-side rendering and advanced acceptance/end-to-
end testing.

\- You can do server side rendering with other frameworks however it is
significantly easier and better to do it with Ember.js due to the way ember
routing model and ember-data works. You can do acceptance testing with other
tech stacks however they cannot be as fast as the usual ember acceptance
testing stack + ember mirage. Mirage mocks your backend and introduces an in-
memory ORM thus your tests wont ever need to hit your backend or the database,
I wrote a better mirage alternative as mirage do have issues outside the
context of this topic. Backend mocking comes with 3 major advantages and 1
major disadvantage:

Advantage 1: Your tests will be extermely fast(a speed cypress cannot compete
with). Ember test suite knows exactly when your app starts, it can listen to
the next visit, next Ember loop in the Run loop for async functions and
execute immediately without timers. These are well defined and documented in
the framework.

Advantage 2: Most web backends are not built on JavaScript, however current
trend is to write acceptance tests in JS/node.js due to the all available
ecosystem support in a certain SPA framework/library. Since your backend logic
is most probably written in another language you cannot access the backend
data in your frontend tests. Ember mirage replaces your backend thus you can
access your backend data on acceptance tests for higher test quality. If your
backend is written in node.js you can require your models and query them
inside the tests thus not much there wont advantage here. For the majority of
backends you will have to write your own hacky tool to query your backend if
you want higher quality testing. Or you have to write your acceptance tests in
your backend language which will be no doubt slower than ember tests +
headless browsers that have JS API support.

Advantage 3: You can develop very complex frontend demo applications on the
development mode with Ember mirage without a backend. There is a productivity
advantage when your frontend developers are not backend developers/not
familiar with your backend stack. You can source your backend API responses as
Ember mirage fixtures thus eliminate the need for data preparation/model
generations with factories for each frontend tests. Also you can easily create
demo deployments for client meetings.

Disadvantage: - Sometimes you need to write your backend logic in Ember mirage
routes. Ember mirage is still an alpha software and all these add up to the
learning curve.

Ember.js has lots of potential and a mature ecosystem.

