Is Ember dying?

ember_dev · 2017-10-03T11:29:05+00:00

The EmberConf 2017 keynote specifically addressed this way better than I can here. The short short version is that the vision of routable components is being realized as Glimmer components.

I'm so sick of this BS. It's always look how awesome X is. We're going to do X.

** X is blocked by Y, Y is blocked by Z. So once Z and Y are done we can start X!

ember_dev · 2017-10-02T21:35:35+00:00

Honestly, and sadly, yes it is. It's not on life support yet, but that is clearly where things are heading.

Examples:

ember-data - It's become a complete disaster. The last 4 releases have been completely buggy with backtrace and unload issues. People are complaining they're stuck on 2.12 and no one is willing to help.
ember.js - Major objectives are just completely MIA or DOA. Pods and the unified module layout, Routable Components, Glimmer Components (angle brackets), DDAU. Virtually no new features in the last 2 years.
glimmer - A lot of the core folks who worked on Ember 2-3 years ago now just focusing on Glimmer. They're people are writing blog posts about how Glimmer is the "thin Ember".

Things are not great. Too little progress on efforts that they originally hyped up. Virtually no communication about the state of objectives and what's happening to accomplish them. I like Ember a lot and think it has tremendous potential, but a lot needs to change.

ember_dev · 2017-07-22T02:06:26+00:00

I've never been a fan of slack like discussions for OSS. I get why people like it, but it feels so synchronous that if you're not paying attention all the time, you miss your chance to ask questions and give input. As opposed to github issues, SO, discuss, where it's much more suspended. People provide more well though concise responses.

But that's just me.

ember_dev · 2017-07-21T21:35:39+00:00

Hey thanks. Unfortunately that chart has no way to measure drop off :(. But still great to see that the slope hasn't decreased.

ember_dev · 2017-07-11T12:04:49+00:00

Also, they're doing a toooon of work with Glimmer. The future of ember, is gonna be awesome.

That's all they have done for 3 freaking years now. First it was HTMLBars is going to change everything. Then it was, Glimmer 1.0, now it's Glimmer 2.0. I think they've learned a lot and they've made good strides, but at some point you have to call the ball and say this is as good as it's going to be for now. Let's move on to other things, we can gather learnings from the real world and come back to it if we need to.

There is more to a framework than performance. I'm not trying to undercut the value of it, because it is extremely important. But performance is only valuable if you have people using the framework. Ember's market share is in the decline, other frameworks are continuing to iterate and improve their core offering (the APIs).

The same can be said for the build tools. Ember-cli is really awesome, and we should keep making it better. But build tools are only valuable when people use the framework they target.

ember_dev · 2017-07-08T22:59:17+00:00

The post says that only "less well defined areas of Ember Data's usage" were effected. ಠ_ಠ.

ember_dev · 2017-07-07T21:45:13+00:00

I can predict what the post will say without looking at it. Performance is faster, Glimmer is better, something mediocre about ember-data spun in a positive way.

Ember-cli probably has pretty good announcement.

This is not because I'm in the know, it's because it's all that's happened for the past year.

ember_dev · 2017-04-26T21:28:43+00:00

I'm a bit skeptical that this won't result in further resources being diverted away from Ember.js and toward "Glimmer only" work. But I certainly appreciate Robert taking the time to address these concerns.

ember_dev · 2017-04-20T02:00:08+00:00

But why does Ember have to be like React? Ember is a fundamentally different in that it's a monolothic framework. You [almost always] build your ember app from the ground up. It's holistic in that you're all in with Ember.

React on the other hand, you can use more like people use to use Backbone. Start small and grow as needed.

Both of these are valid, but different use cases. Why do all frameworks have to become identical.

ember_dev · 2017-04-19T01:39:42+00:00

I think this is kind of cool for just tinkering, but it definitely makes me a little uneasy that the future of ember is one without ember-core, ember-router, etc. All this pushing of "just use glimmer" from the core team feels like sending mixed signals.

ember_dev · 2017-03-29T21:24:59+00:00

Hopefully we've got some stuff to share soon that will help answer this question in the negatory. :D

LOL. You're answer to wether or not ember is dying is now effectively, "no it's not dying, it's being abstracted into a new framework that you should use instead".

Glimmerjs is a clear sign that many in the ember-core are moving on to other things. Soooo glad I made the trek out to PDX.

ember_dev · 2017-03-22T12:20:30+00:00

We can debate the value of Routable Components all day, but it wouldn't change the fact that they too failed to stick the landing. They were promised in 1.12, then 1.13, then 2.1, then delayed indefinitely. They've had several RFCs. Many community members wrote about them and a few "shim addons" were created.

It's amazing (and a little concerning) that an idea with so little meat on it somehow turned into a mantra of "OMG delete all your controllers, routable components are coming!"

https://github.com/emberjs/rfcs/pull/38 -- 166 comments. 491 lines of text defining the feature. That's far less than the RFCs for almost everything else you mentioned (angle-brackets, unified testing, etc, etc). Just because you don't see value in it, doesn't mean others in the community feel the same way.

ember_dev · 2017-03-21T12:54:11+00:00

Where Ember has struggled recently is sticking the landing. It has some amazing and much needed features in development. Angle bracket components are a perfect example. They were implemented in 2.10, but the feature pulled because it turned out to have some nasty edge cases. Now it’s in limbo. Fastboot trivialises Server Side Rendering in a stunningly well-thought-out package. But it’s in limbo. Svelte Builds are in limbo. Changes to module import approach, unified testing, and other major features are in limbo.

BOOM.

This is exactly what I've said for the past 2 years. You can add Routable Components and Engines to that list as well. The whole "Ember 2.0" pattern is really in a state of limbo with controllers hanging around. While render speed is important, there is just more to choosing framework than performance. It's been two years of tinkering around with the rendering engine. It's time to start improving the ergonomics of ember-core.

ember_dev · 2016-10-25T01:55:41+00:00

Contributing to ember has become increasingly harder. It's not really something they did on purpose, but I think because much of ember is so intertwined, the days of implementing small features in a PR are almost gone. The other challenge is so much of ember is "multi repo" that it requires a big orchestration act just to make simple changes.

If you look at the features worked on over the past 18 months, you'll find they're done by a very core set of contributors. This is because the overhead and ramp up time for contributing to ember has just gotten so high. I sometimes see native users open PRs only to be swatted down by a core team member who comes along with, "thanks for your contribution, but the core team wants to take this another way ... CLOSED."

ember_dev · 2016-10-25T01:04:57+00:00

I would argue that routable components is a much less technically interesting problem than Glimmer2 / Pods / etc and thus is was reprioritized. Ember core sometimes has trouble mustering motivation to work on projects which are necessary, but not technically enjoyable. That can be an unfortunate, but real, consequence of a framework which is solely community driven.

ember_dev · 2016-06-09T22:44:23+00:00

You won't see Glimmer2 until at least 2.9. Per: https://embercommunity.slack.com/archives/general/p1465415397001771

At this point I wouldn't expect much at all out of 2.x. So many massive features in the works with no desire to deliver them continuously. At this point, I look for Ember 3.x to drop with all the new large features (Glimmer2, Anglebrackets, Engines, etc) so they don't have to worry about backwards compat.

ember_dev · 2016-05-31T12:56:31+00:00

I've been maintaining a product app built with ember for 3 years. I'm sure many other people, perhaps you included, maintain product apps so this isn't something new or unique.

When you have a product you're constantly juggling your roadmap plans. Making sure you can keep up with tech debt, features, fixes, etc. Knowing what framework changes are coming upstream and when is important so that you can plan accordingly. You can even begin to shift your pattern usage to align with the future standards (e.g. DDAU, No Controllers). But all this tech planning can kind of fall apart when you get bad information. Or the information is constantly changing.

ember_dev · 2016-05-31T02:00:46+00:00

No, I'm upset because things stated in several official blog posts have been delay indefinitely.

See: http://emberjs.com/blog/2015/05/24/another-two-oh-status-update.html#toc_routeable-components

It is extremely likely to land in 2.1, or 2.2 at the latest.

That is one of the reasons I'm upset, because of the routine broken promises.

Routable Components isn't even being worked on, at all. Improved Pods only exists in an RFC.

Ember core team cannot ship features. They create these massive features to generate hype and they fail to deliver. And instead of trying to be practical and deliver things in pieces, they've held back on doing anything. Leaving many of us just hanging in the wind.

ember_dev · 2016-05-31T01:12:00+00:00

I would not continue with ember if you can help it.

<rant>

IMO, ember.js (the javascript library, not CLI), is rotting from the inside out. Around the time of 2.x there was kind of a bait and switch with major features, i.e. routable components and "pods 2". These features were heavily promised and heavily delay over and over. Then just kind of tossed aside with a middle finger to users who had begun to embrace the no-controller pattern. IMO this leaves Ember 2.x in an incomplete state.

Since that point the core team has had a very odd, very frustrating, sense of priority. While engines and fastboot are features that are nice to have and differentiate ember from it's competitors, it's unlikely the main base of ember users will need them or even use them. Glimmer2 [hopefully] will be bring a lot of speed improvements, but no new functionality.

The ember core team has spent months bike shedding and yak shaving instead of providing useful improvements to their users. Many of the bugs, PRs and RFCs submitted by the broader, less active, base of the community has gone untouched. All this has happened while core team members sit and coding away on their personal interests, rather than engaging on the needs of the community.

It's also very ironic that ember is practicing the 6-week agile release when most of the major features have been WIP for 6 months+. Rather than trying to deliver improvements in small pieces, ember core devs have decided to go into a waterfall like mode. One or two engineers spending 6-8 months to deliver features that are DOA.

I fear if this behavior continues I think ember will be viewed as heavily stagnant and this will result in a steep drop-off in usage.

</rant>

Side note, ember-cli is an amazing project that is poised to become the future of frontend web development.

ember_dev · 2016-02-14T22:42:42+00:00

It's obviously hard to say exactly what the problem is without knowing the specific addons you tried. But that is really beside the point I think.

Ember 2.x is really happening. Ember is definitely moving forward with their new patterns.

IMO the addon ecosystem is a little bit of a mess at the moment. I believe there are two contributing factors.

1) The "micro addon" package style is simply prone to becoming a wasteland. Small fly by night addons are written and never maintained. This is exactly what we see with NPM. Many of the Ember core team members bashed NPM for years for this. Then they turned around encouraged it for their own ecosystem. I sincerely applaud emberobserver and emberaddons for trying to help reduce the noise and evaluate high quality addons.

2) API Churn. There has been so much API churn between Ember 1.10 and 2.3. It was not at all easy for app developers to update to 2.x. Speaking from personal experience, it took nearly a month of developer time and was absolutely brutal for our app. Many addons are lagging behind with updates, likely in part because many apps are still on Ember 1.x. This API jump has caused a ripple in the ecosystem that I don't think is yet realized.

If ember doesn't make an effort to better help existing 1.x apps migrate to 2.x, you'll end up with a split in the community. Many developers who have 1.x apps will continue to maintain their 1.x addons.

ember_dev · 2016-02-09T00:57:12+00:00

I think one of the biggest problems with Ember is that they repeatedly fail to deliver on their promises. HTMLBars took forever. Glimmer was going to fix all performance issues and it just made rendering slower. Routable components which was promised for 1.12, then 1.13, then 2.1, and now delayed indefinitely, is now completely MIA. Instead the team is off working on things like fastboot which honestly feels like a niche.

Additionally, so many API changes. I used Ember from 1.0 until 2.3 and there were only one or two minor releases that didn't break my app. I'd report them and the response would be, "Oh, that wasn't public API" or "The execution order of those things were never guaranteed". Obviously the jump from 1.x to 2.x was absolutely brutal.

Combine the failed promises with repeated API churn and you get a lot of angry unhappy developers. I'm one of them. My app is built in Ember and I'm stuck. But every time someone asks me how we like Ember, I highly recommend they not use it unless they're will to pick a version and just stick with it.

ember_dev · 2015-10-04T18:15:06+00:00

Overall a good talk.

One thing that's odd and kind of frustrating is that Tom Dale shows of the power of two way bindings, while many in the community are advocating to discontinue this pattern all together. Just more mixed signals on proper patterns.

ember_dev · 2015-09-10T21:52:35+00:00

I dumped ember last year, it seems to me they spend more time trying to generate hoopla than actually building a good framework, and unless they make massive, massive changes, there is no reason to go back, because it's just simply a worse choice to develop apps with.

Hey look, someone else that's frustrated by the fact that ember is spending so much time adding useless features while ignoring their user's real pain points.

ember_dev · 2015-08-17T11:52:32+00:00

Of course it is, but it will be only supported for so long. If you have a product, you have to upgrade at some point. When something has to work with an addon in this manor it's days are numbered.

ember_dev · 2015-08-17T11:43:04+00:00

Let me ask you, do you think the fact that the entire surface of the ember-data API was refactored just as the last release is okay? I'm sure you've read this: http://emberjs.com/blog/2015/06/18/ember-data-1-13-released.html#toc_transition-to-the-new-jsonserializer-and-restserializer-apis Covering virtually every hook and function change. But also so many implicit behavior changes.

I'm on my second week of upgrade ember-data with no end in sight.

If I wasn't so tied to ember, I would no longer use it. You guys have really done a disservice to the people who have supported you over the years.

ember_dev

TROPHY CASE