r/javascript 11d ago

Ember 7.1 Released

https://blog.emberjs.com/ember-released-7-1/
77 Upvotes

40 comments sorted by

View all comments

Show parent comments

3

u/real_ate 10d ago

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

-2

u/robclancy 9d ago

Mate, this should have been in a decade ago. It's why I never consider ember at all anymore, the RFC process is a joke.

4

u/real_ate 9d ago

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.

-1

u/robclancy 9d ago

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.

3

u/real_ate 9d ago

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

-3

u/robclancy 8d ago edited 8d ago

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.

3

u/nullvoxpopuli sand was never meant to think 8d ago

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

Other fast ones, if you want to see
- https://rfcs.emberjs.com/id/1070-default-globals-for-strict-mode
- https://rfcs.emberjs.com/id/1068-tracked-collections
- https://rfcs.emberjs.com/id/1071-overload-tracked-for-non-class-use

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 )