
Ember.js 3.1 and 3.2 Beta Released - izelnakri
https://emberjs.com/blog/2018/03/26/ember-3-1-released.html
======
stocktech
I lead an internal development team. We're constant building new apps and
enhancing old ones.

Ember has been a big win for us. Upgrading old apps is a breeze. Every app has
a consistent structure and the conventions make it easy for developers to move
between projects. We don't need to worry about the individual pieces -
routing, data, etc - we trust the core devs so that we only worry about
business logic. We're experimenting with Ember Engines right now and I'm not
sure how we'd replicate it if we were using React or Angular. All in all, I
think it has made us incredibly productive.

Outside of the code, the Ember team's communication skills are top notch. I
feel like every time I tell my team that "XYZ is coming down the pipe",
there's a clear plan of attack and any impact is minimal. In the last 3 years,
I've never had to tell my boss that development will be paused to focus on a
refactor/upgrade/maintenance.

The biggest downside is in hiring, unfortunately. I don't look for Ember
experience, but I have had to adjust my expectations when it comes to the
learning curve.

~~~
vmware505
Actually, learning Ember.js is quite easy nowadays. There are great free
options, where you can go far in a few days:
[http://yoember.com](http://yoember.com) |
[https://guides.emberjs.com/v3.0.0/tutorial/ember-
cli/](https://guides.emberjs.com/v3.0.0/tutorial/ember-cli/)

~~~
msum
Also [https://medium.com/ember-ish](https://medium.com/ember-ish) is
incredibly useful.

------
msum
The thing that has most impressed me about Ember is the way the teams on a
project at giant corp will not do things correctly (honestly, some days it
feels like they are doing weird crap on purpose to try to get it to fail) and
Ember still works.

For a tiny glimpse of context- we have globally distributed teams who all work
on different (isolated) parts of the project using ember-engines. All of these
parts can either be stood up as a standalone app or become part of one host
app. And every single one of these is consuming a single UI Addon that has
components, minimal services, and themes.

Think about all of the moving pieces there, all of the parts where teams can
disagree or do weird stuff, and yet somehow when it all comes together, we
have so many things that could colossally fail, yet nothing does. We have a
few bugs that are hard to reproduce but that's because we do weird stuff, not
because Ember does. It's really epic when I sit back and think through all of
it.

If you haven't tried Ember in ages, or ever- this is definitely the time to
try...and I mean really _try_. Some of it will be a paradigm shift, but a
worthy one.

------
s_kilk
(as someone who doesn't use ember) This release looks cool, and I like the
general vibe of careful development and clear messaging.

Is anyone here using Ember on big projects? How's it working out?

I tried ember, maybe 6 or 7 years ago, and was turned off by some weird
magical behaviour, but I'm curious about how ember is doing these days, and
particularly the glimmer engine.

~~~
jeffkeen
Ember is an incredible framework that's been carefully thought out by a team
of super sharp people with loads of experience, and I'm constantly amazed by
how quickly I can get real projects built using it. I've used it for many
projects since ember-cli came out a few years ago. I feel about Ember for
client-side projects how I felt about Rails for server-side projects—it made
it fun for me again.

But Ember gets a bad wrap from the internet because (admittedly) their
marketing materials with the gooofy chipmunks make it look like a toy while
React's make it look like you're learning quantum physics. And then there's
the timeless "convention over configuration" divide where Ember people are
generally on the left side, and React people just love the thought of fiddling
around and hand rolling their own custom ungoogleable bespoke artisan
framework before actually getting to the meat of the work.

I highly recommend using Ember for any size project if you like getting shit
done.

This is a good talk kinda about this:
[https://www.youtube.com/watch?v=rWH3UNIKFeg](https://www.youtube.com/watch?v=rWH3UNIKFeg)

~~~
Ralfp
> But Ember gets a bad wrap from the internet because (admittedly) their
> marketing materials with the gooofy chipmunks make it look like a toy

Ember.js is best technology that I've ever dropped, but let me assure you, the
Tomster had nothing to do with my decision.

Ember got into the spotlight when Atwood and Co. have launched the Discourse.
Back then it looked super impressive - first open source forum software and
arguably one of first open source apps following "JS fronted and API backend"
architecture. And it was all done with Ember.js, js FW marketing itself as the
modern way to build JS apps!

A lot of people wanted to try it out (myself included), some moving from
Angular, other from Backbone, and others coming from backend development. If
Ember ever had the cool factor, it was that time. Ember.js was the next big
thing, a framework for creating ambitious web applications, and all the people
came to it to build their ambitious applications, looking up to Discourse as
example of such application.

And then those people have hit the roadblock. Ember.js's pitch was building
applications, but it's documentation has never moved past explaining
individual parts of technology, and into the field of how those should be put
together in final application. Angular had millions of easily googleable
tutorials like "this is best practice for setting page title when user enters
the route" or "this is how you can configure framework to authenticate with
your backend technology".

I also clearly remember the "calling set on destroyed object" error that
happened when you tried to update the state of object that was already
destroyed that was impossible to debug, because the error was literally
"Error: calling set on destroyed object" and it put world to stop. For
comparision, in React.js that was "Warning: calling setState with X, Y and Z
on unmounted component ComponentName". That one error was absolute
productivity killer when debugging Ember.js apps from day one, and it was
years before somebody from Ember.js core actually went to Ember's source code
and changed "assert !obj._is_destroyed 'calling set on destroyed object'" to
"assert !obj._is_destroyed 'calling set on destroyed object'". There was
always bigger fish to fry for Ember.js core team, who were so bussy making
blogpost after blogpost of new great features or API changes happening, while
being oblivious to comments below those same blogposts asking "can I now do
partial updates on models because they are super costful to update?" or "is
calling set on destroyed object fixed yet?". And then guys from their
ambassador product, Discourse, started writing blog posts following the
pattern of "Here's how we've replaced Ember.js's feature with our one because
framework's didnt work", and those involved things like `Ember-Data` or Ember
views.

~~~
ben_jones
EmberJS was the first front-end framework I learned as a web developer,
shortly after learning Django. This was before Ember 1.0 . It was cool at
first - but once I started developing real projects I ran head first into
unreadable or cryptic internal stack traces and APIs that forced me to adapt
my back-end to fit the needs of the front-end app. A short time later I picked
up angular 1.x and was off to the races because anytime I ran into a problem
with a feature or design decision I could easily find the hack that would keep
my momentum going.

I always felt like EmberJS meant well but chose rigidness where it should have
been flexible, and flexibility where it should have been rigid. It's probably
changed and solved many of these early problems. I want to go back and re-
evaluate, but nowadays so many different technologies, frameworks, languages,
and tools, are pulling at my time that I don't think I will be able to.

FWIW my current stack of choice (and at work) is Golang and Vue (w/Typescript)
- which might identify where some of my biases and predilections are.

~~~
anoncoward778
MAN....ember before v 1.0 ???...I'd suggest taking a revisit. Version 2.0 was
a different universe let alone 3.1

------
JepZ
Similar to @s_kilk I tried ember years ago and while I liked some of their
concepts, the hard learning curve and the oversized results made me search
alternatives.

Anybody knows what size (js bundle file size) a basic PWA in ember.js has
nowadays?

I am asking for file size here, as transmitting and parsing that data is
usually what defers an instant user interaction.

~~~
anoncoward778
Keep in mind. Ember is built for LARGE applications. No such thing as a "basic
PWA" in ember.js. Think of it more like...we've built this huge app for tons
of users in library XYZ and our development team of over 20 persons is feeling
pain points in transitioning to the updated more secure version of XYZ.

~~~
msum
I really enjoyed the EmberConf talk about movie studios using it for movie
promo sites because they needed to be able to get them up quickly. I think if
you took that concept and maybe a blog post about doing an Ember PWA
([https://madhatted.com/2017/6/16/building-a-progressive-
web-a...](https://madhatted.com/2017/6/16/building-a-progressive-web-app-with-
ember) for example) then maybe the large part doesn't matter so much...

------
nerdymanchild
My team is actually in the process of de-Reacting our code base. These
frameworks are full of hacks underneath the covers, and their abstractions are
mostly ill-specified.

~~~
boubiyeah
Explain that bold claim?

Apart from the very annoying Event compatibility layer with its event pooling
and central handling that breaks the usual DOM event bubbling, I never saw
something bad enough that would make someone consider de-Reacting.

As much as I dislike magic, JS libs working with the DOM will always have code
that isn't as clean as your application code.

