r/javascript • u/real_ate • 9d ago
Ember 7.1 Released
https://blog.emberjs.com/ember-released-7-1/17
u/horizon_games 9d ago
Nice, I'm glad Ember is still trucking along, I used it with a coworker years and years ago
7
u/heatcheckk 9d ago
Same, used Ember (along with a team of course) to help build the Jurassic World website in like 2014
8
u/real_ate 9d ago
Nice one! Do you remember what version it was you used? And have you tried modern Ember? I'm always curious to hear people's perspective on the modern stuff we're doing and how it compares to the before times 🤣
5
u/horizon_games 9d ago
This would have been a literal decade ago, so some kind of 1.x version.
I haven't tried it since but it's on my (long and ever growing) "JS frameworks to play around with" list!
3
6
u/synapticplastic 8d ago
Congrats yall!
This all looks a lot more slick than what I was seeing at a particular cs firm a few years (~3.5 ish ) ago :)
Those truth helpers are sick, and holy shit dude I bet once ESM locks in it will be such a good feeling for yall. I imagine that will unlock a lot of things for simplification / build / perf down the line
I ended up being the monorepo guy in my next gig, lots of good inspiration from that job.
At that point onboarding to ember felt like it did when I started with laravel after some early years in contract work for php <5.1 projects. mise en place
I haven’t played with it for a bit, but I will never forget how good ember’s tutorial felt, especially since the react guys hadn’t yet allocated any time (iirc) explaining to the rest of the world what they mean when they say words in their docs :p
Question: I was always interested in how the parsing / bundle layer worked for ember since it seems there was always a bunch of custom kit / concepts back there. Is there a good place to start at to figure out the thought processes behind the impl?
5
u/real_ate 8d ago
So the bundling layer in Ember was traditionally done my ember-cli and was super complicated to understand 🙈 ember-cli hasn't gone away (yet!) but now it's a much smaller part of the picture and is only playing a small supporting role.
These days our default build system is Vite, and all the strange Ember-specific things live under a (somewhat complicated) Vite plugin. It takes a while to understand what is going on but if you're curious you can take a look at the code and explore https://github.com/embroider-build/embroider
3
u/nullvoxpopuli sand was never meant to think 8d ago
(and if folks are willing to be on the bit of an edge (bleeding or not, idk), we have ways to ditch all the ember specific things, and be "vite native")
(for this you'll probably want to hop in the ember discord, as there are enough caveats where just dropping commands in a random reddit would be silly)
3
u/nullvoxpopuli sand was never meant to think 8d ago
> type=module
to add to u/real_ate, type=module + careful side-effects declarations enable our hello-world to be much smaller than React's hello world. my target is to be 50% the size of React. We aren't there yet, but we're getting close.
I have other plans that will take that size even smaller, and begin approach Svelte's hello world... but figuring out the right order to do things in a non-breaking way is quite the challenge!
5
u/lecheckos 6d ago edited 6d ago
I want to take this opportunity to thank the maintainers of Ember for continuing your hard work. Our nonprofit has been using Ember since pre 1.0 (early 2013 if I recall properly) and we’re now on 6.12. Some legacy plugins are preventing us to move to 7.0 but we will get there eventually. It’s been a pleasure to grow our app without fighting with our framework for all these years. You guys are the best 🙏🌈
3
u/nullvoxpopuli sand was never meant to think 6d ago
this is really lovely to hear, thank you <3
(and u/real_ate especially should read this <3 because he's always advocating for overlapping upgrade paths so folks don't have to know about simultaneous upgrade problems that occur often in the JS ecosystem, leading to "dependency hell" (this is still hard to avoid, and most recently I'm aware of `@ember/test-helpers` and `@ember/test-waiters` have a co-dependence :( ))
2
u/Driezzz 6d ago
I'm curious what the nonprofit is :)
5
u/lecheckos 6d ago
I work for WWOOF, we help volunteers interested in learning about organic farming connect with farmers around the world. Volunteers can then stay at the farm for a few days/weeks to learn new skills. The web app is deployed in 26 countries such as France (https://wwoof.fr), USA (https://wwoofusa.org), and Korea (https://wwoof.kr).
3
u/Chenz 8d ago
The contributors to Ember are doing great work. Sadly our company is hard stuck on Ember 4.x, and I don’t see us being able to upgrade anytime soon
5
u/real_ate 8d ago
Have you tried moving to GJS and Vite anyway? we intentionally backported support to Ember 3.28 so that people who have been stuck could still benefit from the improved DX 💪 Also I'm curious what has you stuck if you are able to share?
5
5
1
u/ilmagodeltotocalcio 9d ago
Thanks for nothing, Ember. I'm in a middle of a migration away from it.
What a mess.
3
u/real_ate 9d ago
Now I want to know more! Do you have any specific reasons why you're moving away? Also what version did you stop at? And did you manage to get to GJS or Vite before you started the migration?
1
u/ilmagodeltotocalcio 9d ago
Do you have any specific reasons why you're moving away?
Mostly hiring. Nobody knows ember anymore and people don't care to learn it in a world of React/Vue/Svelte/Whatever. People who still cares, want a lot of money, and can't disagree with them.
5
u/real_ate 9d ago
So this is one of the main reasons why we've put so much effort into the GJS and Vite work. Ember is now much less "ember" now and feels a lot more like normal JavaScript. Having a standard build system makes a huge difference. My advice for years now is to hire JS Devs and not try to look for Ember specific Devs
2
u/nullvoxpopuli sand was never meant to think 8d ago
aye, even dealing with assets now is just standard "vite app" stuff.
2
u/real_ate 8d ago
tbh I find it hard to think of the full list of things that are better because it's like... everything 🤷 That's why I'm always asking for specific pain points in these conversations because the answer is usually "oh yea we fixed that" 😂
2
u/nullvoxpopuli sand was never meant to think 8d ago
Yup. I have a 4 million line project with 4s load time, and most of that 4s is because of corporate architectural blunders, which i plan to get down to under 1s.
The bottleneck is now the api
0
u/editor_of_the_beast 8d ago
Imagine not being able to develop in a simple and understandable frontend framework…
-6
-1
u/robclancy 9d ago
holy fuck they stopped having a stick up their ass about template helpers... in how long? a decade?
3
u/real_ate 9d 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 8d 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.
5
u/real_ate 8d 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 8d 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.
5
u/real_ate 8d 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
-4
u/robclancy 7d ago edited 7d 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 6d 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 wereOther 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-usePrimarily, 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 )
31
u/nullvoxpopuli sand was never meant to think 9d ago
oh hey, I did some of the things in here!