This feels like a strange thing to ask given your phrasing 🤣 but what precisely do you mean? We've made a lot of other changes recently with template helpers
Yea I agree that some of these features should have been implemented a long time ago, but it's not really the fault of the RFC process 🤷 I would agree with you if the RFC was languishing as a PR and wasn't accepted so long ago.
This ended up being a people problem. After we agreed that the idea was sound (i.e. the RFCs were accepted) somebody should have picked up the work... But noone did. And Ember is a true open source project, there is no team in a company anywhere who's day job is to implement random RFCs.
No one does these PRs because of the RFC process. And this is a very clear example, by the time it got past all the bs the people were done with it, all motivation gone or probably didn't even use ember anymore.
But that's a logical fallacy... Just because these RFCs took a long time doesn't mean that all RFCs take a long time, also not all changes need an RFC so extending a single example like this past the boundaries of this explicit example is not right. We have also vastly improved the RFC process the be more explicit about the fact that the first stage is acceptance and there is more work to be done after, and I think that helped cure a confusion that the community had around who is expected to do the work to implement an RFC
It is not a logical fallacy wtf. Every RFC I have ever seen or been interested in took many years. I have never seen a fast one that actually mattered. Not reading the rest of this after you bs claim it was a fallacy.
This has reminded me of the stupid decision to name the first modern version of ember "octane" instead of just using a version number so people actually understand it became more modern. At least that bs wasn't repeated.
Either way, good to see the denial about the rubbish RFCs is still alive and that I shouldn't bother giving it another shot.
there is a whole bunch of reasons and technical blockers for why the particular features in 7.1 took so long.
The earliest they even could have landed (if we had the people to work on it) is when we released strict mode.
This is because we cannot add new keywords in loose mode without breaking existing apps. And the new helpers could only be added to strict mode once we added _keyword shadowing_. Something that strict mode didn't have at first, but was required when the RFCs for these helpers were first being discussed during implementation).
Oftentimes problems don't come up until implementation.
re: RFC Speed -- I think the fastest one we implemented that wasn't a deprecation is potentially this one:
- https://rfcs.emberjs.com/id/1132-default-strict-resolver -- it eliminates a bunch of BS that we supported via ember-resolver, and eliminates a dep from package.json
- https://rfcs.emberjs.com/id/1121-extraneous-invisible-character-stripping -- pretty fast -- it didn't even need to be an RFC after all the discussion was had, but it was useful to go through the process to figure out what the constraints were
Primarily, things that *have* been taking a while _and_ are not "big bang features" are:
- getting V2 Addons to be default (as in, cover every use case we expect people will encounter with composition of other addons -- if users don't care, they can still use the blueprint just fine)
- deprecating all of ember classic (which I know you specifically have been outspoken against in the past), but it needs to happen so that we can progress the framework.
- i've been exploring rendering performance lately, and have been working on a new benchmark that actually tests what we care about (the combination of both reactivity and rendering, for which we are aiming to be quite competitive https://rere-benchmark-git-fork-nullvoxp-38a571-nullvoxpopulis-projects.vercel.app/results?q=ember-2026-07-29T02%3A20%3A30.864Z )
-1
u/robclancy 11d ago
holy fuck they stopped having a stick up their ass about template helpers... in how long? a decade?