With Glimmer as a standalone library, I think ember's going in the right direction. There's been some excellent work on Fastboot and Engines in the last year or so and I really like the approach ember's team is taking with this.

React, for me, still offers better composability. You deal in plain JS objects, pass them around, and can build really complex UIs on top of that. I also really like redux. I still use ember heavily though; I think we'll get there as well!

I think Ember is really good at marketing the stuff they work on, but it is usually overhyped.

Fastboot, for example, was announced what, 3 years ago? The readme says it's still not ready to use:

> The bottom line is that you should not (yet) expect to install this add-on in your production app and have FastBoot work.

https://github.com/ember-fastboot/ember-cli-fastboot

I find this is often true of Ember projects (like Glimmer 1), a lot of hype for something that has a lot of rough edges.

At the end of the day, the Ember team takes a lot of time to not just build things the right way, but also make it as painless as possible for teams to upgrade along the blessed path. This has been a learning process to understand how much more time that takes, and has caused some past announcements to feel like they weren't delivered on, when in fact they simply just took more time to get right.

Yep, the 90-90 rule[1]

The other lesson to take is to be more cautious about announcing stuff before its really ready. But they don't seem to have learned that here. Here we have a project with its own logo, a marketing video with a nice electronica beat behind it, and a YouTube Live announcement...

... For something they are telling you to install from their master branch.

[1] https://en.wikipedia.org/wiki/Ninety-ninety_rule

One of the things with a large framework is that moving to a completely new direction is more challenging than it looks. So, at times, ember has made unrealistic promises — and Yehuda alluded to this in the keynote — but one can learn from it and get better.

As for Fastboot, it has its edges but there are people using it in production (DockYard is one, if I'm not wrong). ember-engines also says it's experimental and it does have some missing stuff (from my experience) but what is there works well.

Some of the things perhaps needed a rewrite of the underlying architecture. One great thing about ember (apart from v 1.13) has been just how painless it has been to upgrade. All the major changes they have made have largely been drop-in. Getting to that kind of backward compatibility is also a pretty impressive feat considering how big it is.

So, all in all, I agree that some of the things were overhyped and unrealistic but it seems they have learned from it, and I think that's just fine.

Yes, I had the same feeling.

While the Ember devs talked about stuff like Fastboot and Glimmer, while other frameworks just had all this out of the box.

Their whole approach seems to be rather concept heavy and back in the days (2014/2015) the docs where horribly outdated and you had to check stackoverflow for basic things.

I had to use Ember 2 years on a project and found it clunky, but okay. I switched to React 2 years ago. And after I met a few hardcore Ember devs from back in the days, who said they switched to Angular2 or React I think this was the right decision. It's nice that the existing projects get so good support, but I wouldn't recommend anyone to start something new with Ember :\

Why would you want to build a bespoke React-based framework for every app you make? Why not simply have everything you need out of the box, plus the ability to easily integrate any npm library into your app via first-class build tooling that is miles easier to use than something clunky like Webpack?

Because in my experience the "out-of-the-box" solutions always break down the more you want to customise them.

Now I rather prefer solutions that have customisation in mind from start, so it's always easy to switch things.

I remember when that wave hit the Ruby/Python space, with things like Pyramid/Pylons. These days that seems to have gone the way of the dodo, with the big monoliths still being around and then some minimal HTTP decorators like Sinatra/Flask/Node. Problem is that the middle ground would require a level of modularity that we still haven't reached, despite all the talk of "software ICs" that came around with early OOP.

I predict that's how we're going to end up in a few years again. Some big monoliths (whatever react is morphing into currently, plus Angular and as the world is a cruel mistress, ExtJS), plus a plethora of DOM wrappers and view libraries.

And 72 build systems.

You know that pyramid powers some of the most important infrastructure for python? Like new version of PYPI (https://pypi.org/)? And lots of big organizations use it - like Mozilla or NASA, sites like Reddit still use pylons.

IF you think it went the way of the dodo, I'd suggest doing a bit of better research before predicting the future :D Because IMO you are seriously off here.

I'm talking about the trend of build-your-own frameworks, not the software itself. Heck, there are enough sites out there still using Zope, MASON and Aolserver.

I really don't, and few do, hence the popularity of create-react-app and next.js

So you're still working within a framework, then.

But when the app grows, you can customize it instead of forking ember to get around it's opinions, something I have had to do in production apps.

I've been working full time on Ember stuff for a long time now, and I can not imagine a single reason to ever fork Ember. I've used different programming languages (CoffeeScript, don't make fun), templating languages (Emblem.js, don't ask), built and served it with Rails, without rails (Ember-CLI was a godsend), and hacked at it in a million different ways. All this was supported by API's or tooling within Ember (even when it was a bad idea, which it often was).

I would really like to know what prompted you to fork Ember.

The first time it was for a sub-route that could be brought up in any other route (to show a little search pane in the app). We were told by the community just "not to do that" but it was in our spec and there wasn't a way to load the same countroller for multiple routes. The second time was more short lived, but it was to allow asynchronous modules to be loaded after the main app. There were no community solutions to this at the time. The last time wasn't really forking ember but we underwent a painful process of remaking most of our views in vanilla JavaScript for performance on mobile, which has gotten completely out of hand with all the two way bindings of pre-glimmer ember. It felt like we were fighting the framework the whole time.

If you go off the rails, it is extremely painful. I haven't looked at Ember in a while, because of my experiences, so ymmv. It could all be completely different now.

When and why did you fork Ember to get around it's opinions? I've been developing with Ember for 5 years now, and the only time I ever had to modify the source was with Ember Data pre-1.0.0, when it wasn't solidified at all. The concepts behind the framework are really simple, and literally everything is configurable.

That hasn't been my experience with ember in the past 1.5 years. Granted when I was first introduced to it about 3 years ago, there were many issues and I wasn't keen on using it but since then things have improved a bunch.

Nice to hear, I haven't used Ember for about 2 years now. When they started putting more effort in their CLI, this was the signal for me to jump ship and go for something more light weight.

> still it accomplishes everything Ember did

That isn't really accurate unless you are adding additional libraries to accomplish all of the things Ember does. I'm not arguing with the rest of your post, just saying that statement is incorrect (in that it doesn't tell the entire story).

Glimmer.js may be more your speed!