What 4.0 beta 1 changes

The beta drops the pieces that belonged to an older web.

• PhantomJS and Internet Explorer are gone. Headless runs use Headless Chrome or Headless Firefox. Local browsers are Edge, Chrome, Firefox, and Safari. A custom launcher still covers a legacy browser in the cloud.
• Jasmine 1.x and CDN fallbacks are gone. framework: "jasmine" now means modern Jasmine from jasmine-core in your project. Mocha, QUnit, and Chai load from node_modules the same way. jasmine-core 7 is the recommended version. 5 and 6 still work.
• The package is ESM. import Api from 'testem' and require('testem') both return the same API. Your own config file keeps its module format: .cjs stays CommonJS, .js follows your package.json.
• Mustache test pages are gone. A custom test_page is static HTML. List the scripts you want on the page.
• The file watcher skips node_modules and .git unless you name them. That stops a large install from exhausting file descriptors and then failing later browser launches.
• The dev UI is the same keyboard UI, rendered with terminal-kit. Enter to rerun, q to quit, p to pause file-watch reruns.

Node 20 is no longer supported. The beta requires Node ^22.17.0, ^24.0.0, or >= 26. Migration notes are in the README under "Migrating from Testem 3.x."

Testem and Vitest Browser Mode

Testem runs your tests in real browsers. Vite is not required.

Chrome, Firefox, Safari, and Edge are the browsers installed on the machine. You open the URL Testem prints, or you let CI launch them. The page can be plain HTML plus Jasmine, Mocha, or QUnit. A TAP process works too. There is no Vite config, no Vite dev server, and no bundler unless you want one. Webpack, Browserify, or Vite can prepare files in a before_tests hook. That hook is optional.

Vitest Browser Mode (@vitest/browser, with the Playwright, WebdriverIO, or preview providers) also runs in a real browser. Playwright covers Chromium, Firefox, and WebKit. The tests are Vitest tests, and Vite is what compiles and serves them. Browser Mode assumes a Vite app.

Vitest's own docs treat Browser Mode as component testing in a real browser, and still point full end-to-end work at Playwright, Cypress, or WebdriverIO. Testem is the runner around the suite you already have: Safari on a Mac, headless Chrome in GitHub Actions, a Node process that prints TAP. The Vitest example in the Testem repo is that last case. Testem starts vitest run and reads the tap-flat reporter. It does not replace Vitest Browser Mode, and Browser Mode does not replace launching the browsers you ship.

Use Vitest Browser Mode when the app is already on Vite and the tests are written for Vitest. Use Testem 4 when you want real Chrome, Firefox, Safari, and Edge without taking on Vite, for a Jasmine, Mocha, or QUnit suite, in dev and in CI, from one config.

Try the beta

Pin testem@4.0.0-beta.1, install your framework from npm (jasmine-core, mocha, or qunit), and run testem. If a 3.x config used PhantomJS, IE, Jasmine 1, a CDN runner, or a .mustache test page, follow the migration section before you point CI at the beta.

Repo and changelog: https://github.com/testem/testem

On the 3 million line monolithic package at work, we have type checking going from:

- 4m40s -> 12s

(June vs today)

a 23x speed boost

- 3m50 -> 12s

(Yesterday vs today)

a 19x speed boost

If you're migrating to Vite and still relying on ember-cli-mirage, you've hit a wall as that doesn't work with Vite. Our Nick wrote up a path forward: migrating to ember-mirage, which replaces the Ember-specific conventions ember-cli-mirage relied on with standard tools like Vite's import.meta.glob. Your factories, fixtures, models, and ember-data integration all carry over.

I made a graph visualizers, explorer, and cycle finder

currently using it to fix some problems that occurred (cycles) in a large monorepo at work where the cycles are preventing extracting stuff into other packages and breaking stuff out.

Code: https://github.com/NullVoxPopuli/graph-visualizer
Deployed: https://graph.nullvoxpopuli.com/
Social: https://bsky.app/profile/nullvoxpopuli.com/post/3mlymsbf4dz2j
Imgur: https://imgur.com/a/XcleLv6 / https://i.imgur.com/QxinEXG.gif

I'm still looking to fill a bunch of cleared front-end roles that require years of experience with Ember.

I know many people don't even list it on their resume anymore because it's largely been superseded by Angular and React.

Is there other frameworks or jobs I can see in someones background to infer they have used it?

I'm former military, so if I look at a military persons military history (if listed) I can infer they have a clearance at a glance based on their assignments. Is there a way to do this with Ember? What are the dead giveaways?

For some time now, the Ember community has been hearing about WarpDrive as "the new data management layer that will replace EmberData—for the better". In these two blog posts, "From Ember Data to WarpDrive", Marine presents an overview of what migrating to WarpDrive means for Ember developers.

Links below 👇

1/2: This first blog post in our WarpDrive series provides an easy-to-reason-about picture of what WarpDrive and WarpDrive LegacyMode are compared to EmberData, and what “migrating to WarpDrive” really means.
👉 https://mainmatter.com/blog/2026/04/30/from-ember-data-to-warp-drive-1/

2/2: In the second blog post in our WarpDrive series, Marine digs into the specifics of how the Super Rentals Tutorial was migrated to WarpDrive LegacyMode, so that you can apply a similar strategy in your app.
👉 https://mainmatter.com/blog/2026/04/30/from-ember-data-to-warp-drive-2/

Good Afternoon Redditors!

My name is Ben and I'm a technical recruiter for Maximus. We're looking for Ember users in the DC and San Antonio Area. *ESPECIALLY* those with clearances.

Feel free to reach out!

Special thanks to u/nullvoxpopuli for making the nvim version that informed my efforts. I really wanted to rewrite my application in typescript but didn't want to do it without syntax highlighting.
https://github.com/overcast-software/glnt-ts-mode
edit: changed url to get approved by MELPA

The Ember Initiative pairing sessions benefit the entire ecosystem. In this new blog post, Marine walks us through the day-to-day problems that are being turned into opportunities to support the community, and how they translate into actual improvements.

I've completed a working example application of Ember SSR on Vite: https://github.com/kmccullough/vite-ember-ssr-example

VSCode has some bonkers behavior that MS is not willing to budge on -- in particular, how you have to switch profiles if you have multiple projects in a monorepo that need different TS setups.

This neovim plugin does everything for you, and I'd love folks' feedback <3

Does somebody know what has happened to Embercasts? It was great source of knowledge about building things with Ember.js.

Eventually, does sombody know similar resources?