DEV Community: Ignace Maes

Adding custom fonts to your Ember app with Fontsource

Ignace Maes — Thu, 02 Apr 2026 11:49:39 +0000

If you're running a modern Ember app with Embroider and Vite, adding custom fonts is easy. Fontsource is a good way to do it: fonts are packaged as npm dependencies, so you get versioned, self-hosted fonts with zero config on the bundler side.

Here's how it works in practice.

Install the font packages

Pick the fonts you need from fontsource.org and install them:

pnpm add @fontsource/geist @fontsource/geist-mono

Import the CSS

In your app/app.css (or wherever your main stylesheet lives), import the weights you actually use:

@import "@fontsource/geist/400.css";
@import "@fontsource/geist/500.css";
@import "@fontsource/geist/600.css";
@import "@fontsource/geist/700.css";
@import "@fontsource/geist-mono/400.css";
@import "@fontsource/geist-mono/500.css";

Each of these CSS files contains the @font-face declarations for that specific weight. The font files (woff2) ship as part of the npm package and Vite resolves them automatically.

Only import the weights you use. Every weight you add is another font file your users have to download.

Use the fonts in CSS

Reference the font family names in your styles:

body {
  font-family: "Geist", sans-serif;
}

code, pre {
  font-family: "Geist Mono", monospace;
}

If you're using Tailwind v4, you can set them as theme variables instead:

@theme {
  --font-sans: "Geist", sans-serif;
  --font-mono: "Geist Mono", monospace;
}

Tailwind will then use these as the default font-sans and font-mono utilities.

Preloading fonts to avoid FOUT

The setup above works, but you'll probably see a flash of unstyled text (FOUT) on first load. The browser discovers the font files only after parsing the CSS, which is late.

You can fix this by preloading the woff2 files. In an Embroider app with Vite, you can use the ?url import suffix to get the resolved URL for a font file, then inject <link rel="preload"> tags early.

Create a file like app/lib/preload-fonts.ts:

import geist400 from "@fontsource/geist/files/geist-latin-400-normal.woff2?url";
import geist500 from "@fontsource/geist/files/geist-latin-500-normal.woff2?url";
import geist600 from "@fontsource/geist/files/geist-latin-600-normal.woff2?url";

for (const href of [geist400, geist500, geist600]) {
  const link = document.createElement("link");
  link.rel = "preload";
  link.as = "font";
  link.type = "font/woff2";
  link.href = href;
  link.crossOrigin = "anonymous";
  document.head.appendChild(link);
}

Then import it from your app/app.ts entrypoint:

import './lib/preload-fonts';

The ?url suffix is a Vite feature. It makes the import return the final, hashed URL of the asset. In production, this will be something like /assets/geist-latin-400-normal-abc123.woff2. This means your preload links always point to the correct file, even after builds with content hashing.

You only need to preload fonts that are used above the fold. If you have a monospace font that only shows up in specific views, skip preloading it.

Variable fonts

If the font supports it, Fontsource also ships variable font versions. Instead of importing individual weights, you import a single file that covers all weights:

@import "@fontsource-variable/geist";
@import "@fontsource-variable/geist-mono";

The package name changes from @fontsource/ to @fontsource-variable/:

pnpm add @fontsource-variable/geist @fontsource-variable/geist-mono

One file per font, all weights included. The browser only downloads a single woff2 file and interpolates between weights. This is usually smaller than loading 4+ static weight files.

Why Fontsource over Google Fonts?

Fonts are self-hosted. No third-party requests.
You control exactly which weights and subsets are included.
Fonts are versioned alongside your app. No CDN surprises.
Works with any bundler that can resolve node_modules CSS imports (Vite, Webpack, etc).

That's it

Three steps: install the package, import the CSS weights, and reference the font family. Preloading is optional but helps with perceived performance. The whole thing works because Embroider + Vite resolves npm CSS imports and static assets the same way any Vite app would.

I ported shadcn/ui to modern Ember.js

Ignace Maes — Sun, 25 Jan 2026 11:18:40 +0000

About a week ago, I made shadcn-ember public. It is an unofficial, community-led port of shadcn/ui for Ember.js.

If you are not familiar with shadcn/ui, the short version is: you copy component code into your project instead of installing it as a dependency. You own the source. You can change anything. No more fighting with library APIs or overriding styles with !important.

I wanted that for Ember. So I (and Claude) built it.

What is this, exactly?

It is a collection of 47 components: buttons, dialogs, dropdowns, tooltips, toasts, sliders, tabs, sidebars, and more. All built for modern Ember (Glimmer components, .gts files, tracked properties).

The components are styled with Tailwind CSS v4 and use CSS variables for theming. You can customize colors, border radius, and dark mode out of the box.

There is also a CLI that handles the "copy and paste" part for you.

How it works

1. Set up your project

Run the init command. It installs dependencies, sets up the Tailwind config, and adds the cn utility for class merging.

npx shadcn-ember@latest init

You will get a few questions: which style, which base color, whether to use CSS variables. Pick what you like.

2. Add a component

npx shadcn-ember@latest add button

This puts a button.gts file in app/components/ui/. It looks like this:

import { hash } from '@ember/helper';
import Component from '@glimmer/component';
import { cn } from '@/lib/utils';

// ... types and variants

class Button extends Component<ButtonSignature> {
  get classes() {
    return buttonVariants(
      this.args.variant ?? 'default',
      this.args.size ?? 'default',
      this.args.class
    );
  }

  <template>
    <button class={{this.classes}} ...attributes>
      {{yield}}
    </button>
  </template>
}

export { Button, buttonVariants };

It is just a Glimmer component. Nothing special. You can read it, understand it, and change it.

3. Use it

import { Button } from '@/components/ui/button';

<template>
  <Button @variant="outline">Click me</Button>
</template>

That is it.

Other CLI commands

There are a few more commands if you need them:

npx shadcn-ember@latest add dialog toast tabs adds multiple components at once
npx shadcn-ember@latest view button shows you the component code before you add it
npx shadcn-ember@latest build generates registry JSON if you want to host your own component registry

Installation options

The docs cover setup for:

Vite (recommended for new projects)
Astro
Manual (if you want to set things up yourself)

All install guides are at shadcn-ember.com/docs/installation.

Why I made this

Ember has always valued stability and conventions. But when it comes to UI, we have been a bit behind. I wanted to bring the same "open code" approach that has worked so well in other ecosystems.

The original shadcn/ui project has a clear philosophy: you should be able to read, understand, and modify your UI code. That resonated with me, and I think it fits well with how Ember developers like to work.

This is an ongoing project. There are more components to add, edge cases to handle, and docs to write. Contributions are welcome.

How to use the new Ember theme for QUnit

Ignace Maes — Tue, 11 Jun 2024 17:17:42 +0000

The integrated web UI test runner in Ember is a convenient way to run your tests. If you've been using the default QUnit theme, it might not surprise you that it was designed over ten years ago.

As of the latest release of ember-qunit, support for theming has been added. The qunit-theme-ember, a modern theme based on the Ember styleguide, has been included as a built-in option. Here's how to enable it in your app:

First, create an Ember app if you haven't already.

npx ember-cli new example-app --embroider --pnpm

If you already have an app, make sure ember-qunit version 8.1.0 or above is used as dependency.

pnpm install -D ember-qunit@^8.1.0

Next, install @embroider/macros to be able to pass configuration options to ember-qunit.

pnpm install -D @embroider/macros

Now configuration options can be set in the ember-cli-build.js file. Add the following to the file:

module.exports = function (defaults) {
  const app = new EmberApp(defaults, {
    // Add options here
+    '@embroider/macros': {
+      setConfig: {
+        'ember-qunit': {
+          theme: 'ember',
+        },
+      },
+    },
  });

  // ...
};

And that's it 🎉

Simply restart your dev server and go to http://localhost:4200/tests to see it in action.

The easy way to access the last JavaScript array element

Ignace Maes — Fri, 29 Mar 2024 18:32:15 +0000

In JavaScript, accessing the last element of an array is not as straightforward as in other languages. In Python, for example, you can use negative indexing to access the last element of an array. In JavaScript, however, using negative indexing with brackets [] doesn't work. Instead, you have to use brackets with the length of the array minus one.

const frameworks = ['Nuxt', 'Remix', 'SvelteKit', 'Ember'];

// ❌ Doesn't work
frameworks[-1];
// undefined


// ✅ Works
frameworks[frameworks.length - 1];
// 'Ember'

To make array indexing more flexible, JavaScript introduced the at method. The at method allows you to get the element at a given index in an array, with support for negative indexing.

const frameworks = ['Nuxt', 'Remix', 'SvelteKit', 'Ember'];

// 🔥 Supports negative indexing
frameworks.at(-1);
// 'Ember'

However, the at method is only an accessor method. This means that you can't use it to mutate the array. If you want to mutate the array, you have to use the bracket notation.

const frameworks = ['Nuxt', 'Remix', 'SvelteKit', 'Ember'];

// ❌ Doesn't work
frameworks.at(-1) = 'React';
// Uncaught ReferenceError: Invalid left-hand side in assignment

// ✅ Works
frameworks[frameworks.length - 1] = 'React';
// ['Nuxt', 'Remix', 'SvelteKit', 'React']

A similar method for mutations that does support negative indexing has been introduced as well. The with method allows you to change the value of an element at a given index in an array. However, it returns a new array with the change, as it doesn't mutate the original array.

const frameworks = ['Nuxt', 'Remix', 'SvelteKit', 'Ember'];

// ✅ Returns a copy with the change
frameworks.with(-1, 'React');
// ['Nuxt', 'Remix', 'SvelteKit', 'React']

Browser support

The at function has baseline browser support on since 2022. Node has support in all current LTS versions.

If you're targetting older browsers, a pollyfill is available in core-js.

Chrome	Edge	Firefox	Safari	Node.js
✅ 92	✅ 92	✅ 90	✅ 15.4	✅ 16.6.0

The with function is newer, having only baseline browser support since July 2023. Node includes support since version 20.

Luckily, there is also a polyfill available in core-js.

Chrome	Edge	Firefox	Safari	Node.js
✅ 110	✅ 110	✅ 115	✅ 16	✅ 20.0.0

Conclusion

This article introduced the at method to access elements in an array. It supports negative indexing, which comes in handy when selecting the last elements. The with method is a new syntax that allows you to change the value of an element at a given index. However, it returns a new array with the change, as it doesn't mutate the original array. Both methods are supported in modern browsers, but you might need a polyfill for older browsers.

Interested in content like this? Follow along on ~Twitter~ X.

Automate NPM releases on GitHub using changesets 🦋

Ignace Maes — Wed, 18 Oct 2023 16:11:17 +0000

You've built an awesome JavaScript library and can't wait to share it with the world. But how do you package and release your library, manage versioning, and maintain a tidy, structured changelog?

Doing these tasks by hand can quickly become a hassle. If you're open to receiving contributions from others, it can be an even bigger headache. In this post we'll cover how to use changesets to automate all of these steps.

Setting up changesets

Changesets is a tool to manage versioning and changelogs in an automated way. It works by keeping a markdown file per change, conveniently called a "changeset". This file is used to track the type of change together with a description.

To install changesets, run the following command in your project root:

npm install --save-dev @changesets/cli && npx changeset init

Running this command will generate a .changeset folder. This folder contains a README.md with some general info and a config.json file to customize the tool. All "changesets" will also be stored in this folder.

Versioning

Now that changesets is set up you can start making improvements to your project. Once you're ready to open a PR and merge your changes, it is time to add a "changeset".

Changesets follow semantic versioning conventions. In a nutshell, this indicates that the version number follows the fixed format of major.minor.patch. A patch is a backwards-compatible bugfix, a minor is a feature that is backwards compatible, and a major is for any change that isn't backwards compatible.

To create a "changeset", simply run:

npx changeset

It will first ask to choose the type of version change (patch, minor, or major) followed by a description of the change that's made. This description is what will end up in the changelog when a release is done. After running this command a new markdown file will be created in the .changeset folder. Congratulations, you've made your first "changeset"!

To remind contributors (and yourself!) to add this changeset to PRs, install the Changeset bot from the GitHub Marketplace.

Release action on GitHub

You've now merged a couple of great new features and it's time for a release of your package! While changesets offers commands to do this process manually, let's go all out and automate this using GitHub actions. This will save time, and perhaps more importantly, reduce potential manual errors.

Create a file .github/workflows/release.yml with the following content:

name: Release

on:
  push:
    branches:
      - main

concurrency: ${{ github.workflow }}-${{ github.ref }}

jobs:
  release:
    name: Release
    runs-on: ubuntu-latest
    steps:
      - name: Checkout Repo
        uses: actions/checkout@v3

      - name: Setup Node.js 20.x
        uses: actions/setup-node@v3
        with:
          node-version: 20.x

      - name: Install Dependencies
        run: npm install

      - name: Create Release Pull Request or Publish to npm
        id: changesets
        uses: changesets/action@v1
        with:
          publish: npx changeset publish
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
          NPM_TOKEN: ${{ secrets.NPM_TOKEN }}

The action needs access to your NPM token in order to be able to do releases. Add this secret in your repository's settings located at Settings > Secrets and variables > Actions using the name NPM_TOKEN. If you do not yet have an NPM token, create one on npmjs.com. Make sure the token supports automation as it will be used to run in CI.

The newly added GitHub action will run every time a commit is made on the main branch. If the commit has a "changeset" it will open the release PR. (or update, if there is already one open) This PR gives an overview of all changes which are currently on the main branch but not yet in the latest release. The PR will include three changes:

The removal of all "changeset" markdown files
The package version is bumped accordingly
A changelog entry is added for every "changeset"

The next package version is determined by looking at all "changeset" entries. When two "changesets" are included which are of the type minor, the minor release will only be bumped once. Likewise, when a mix of version types are included, the most significant version is bumped. For example: if both a bugfix and minor are included, only the minor version will be bumped. The days of manually calculating the correct package version are gone!

Finally, when you're ready to go, the release PR can be merged and the GitHub Action will automatically do a publish of the package to NPM.

Bonus: upgrade your changelog game with GitHub links

By default the changelog just combines all changeset descriptions. With custom formatters, it can be extended to do more.

The @changesets/changelog-github package formats the changelog to include links to the merged PRs as well as a reference to the GitHub user who submitted this change. This is great to give proper credit to contributors as well as easily finding back changes that have been made. It can be installed with the following command:

npm install --save-dev @changesets/changelog-github

Next, register it as the changelog formatter in your .changeset/config.json.

 {
   "$schema": "https://unpkg.com/@changesets/config@2.3.1/schema.json",
-  "changelog": "@changesets/cli/changelog",
+  "changelog": ["@changesets/changelog-github", {
+    "repo": "your-org/your-repo"
+  }],
   "commit": false,
   "fixed": [],
   "linked": [],
   "access": "restricted",
   "baseBranch": "main",
   "updateInternalDependencies": "patch",
   "ignore": []
 }

Upon merging the release PR, the changelog will now include links to PRs as well as the authors.

Conclusion

Changesets is a great tool to automate versioning and changelogs for JavaScript packages. By streamlining the release process, it not only saves time but also reduces the potential for errors.

Do you automate your releases already? And which tool do you prefer?

Questions? Leave a comment or reach out on ~~Twitter~~X @Ignace_Maes!

The road from Ember classic to Glimmer components

Ignace Maes — Thu, 02 Feb 2023 14:20:47 +0000

In late 2019, the Ember.js Octane edition was released which included a new way of writing components: Glimmer components. Components now extend the component class from the Glimmer package instead of Ember. Besides this minor difference in importing there’s a large difference in functionality. This article will go over the differences, reasons why you would want to upgrade, and an upgrade strategy to tackle this in large codebases.

Classic vs. Glimmer

Glimmer components can be seen as a slimmed down version of classic components. Most lifecycle hooks were removed. Arguments are scoped and built upon auto tracking reactivity from Glimmer. There’s no more HTML wrapping element. They use native class syntax. And a lot of classic leftovers were cleaned up.

The following example implements a component which copies the text passed as argument to the clipboard when clicking a button. When using classic Ember components, it could be implemented as follows:

// copy-to-clipboard.js
import Component from '@ember/component';
import { set } from '@ember/object';

export default Component.extend({
  isCopied: false,
  actions: {
    async copyToClipboard() {
      await navigator.clipboard.writeText(this.text);
      set(this, 'isCopied', true);
    }
  }
});

<!-- copy-to-clipboard.hbs -->
<button {{action 'copyToClipboard'}}>
  {{if isCopied 'Copied!' 'Click to copy text'}}
</button>

The same component using Glimmer would look like this:

// copy-to-clipboard.js
import Component from '@glimmer/component';
import { tracked } from '@glimmer/tracking';
import { action } from '@ember/object';

export default class CopyToClipboard extends Component {
  @tracked isCopied = false;

  @action
  async copyToClipboard() {
    await navigator.clipboard.writeText(this.args.text);
    this.isCopied = true;
  }
}

<!-- copy-to-clipboard.hbs -->
<button {{on 'click' this.copyToClipboard}}>
  {{if this.isCopied 'Copied!' 'Click to copy text'}}
</button>

The Glimmer component can make use of decorators as it uses native class syntax. There is a clear separation between arguments passed to the component (here text) and the local state (isCopied). Regular assignment expressions can be used to update state that should trigger template rerenders thanks to Glimmer auto tracking. And there's a lot more improvements which aren't illustrated in this small example.

Why migrate to Glimmer components?

Every code migration requires engineering time which can not be used to build new products to sell to customers. So for a business to invest into refactors and migrations there has to be another benefit. Classic components in Ember are still supported in the latest major version, so why upgrade? The following benefits for us made it worth the trade-off.

One way of doing things

Glimmer components for new code became the standard practice since the release of Ember Octane. This caused our codebases to contain two component types. This adds extra mental overhead when working in codebases which contain both. You have to be aware of which type of component you’re working with and make changes accordingly. For people new to Ember this can be extra confusing.

Closer to native JavaScript experience

Glimmer components contain very little Ember specific code practices compared to classic components. This makes it easier for people to get started in Ember coming from a different background. Every JavaScript developer should be able to get started in our codebase and get up to speed relatively quickly.

Rendering performance

The previous points are nice from a developers perspective. There’s, however, also a benefit for customers. Glimmer components render substantially faster than classic components.

TypeScript support

TypeScript has proven it’s here to stay in the wider JavaScript ecosystem. It has risen in interest and kept its place as the most popular JavaScript flavour.

In 2022 Ember acknowledged official TypeScript support with a dedicated core team. Glimmer components unlock the full potential of TypeScript support in Ember. Template type checking with Glint is also under active development. Exciting!

Future-proof a codebase

Ember.js development doesn’t stagnate. Progress is already being made for new improvements to the current component model. The RFC for first-class component templates has been accepted and merged in 2022 and will provide new benefits to Ember users. By first adopting Glimmer components, we’re prepared for what’s coming next.

Migration strategy

While you could jump straight in and start migrating every component one by one, we decided to go for a different strategy. For smaller codebases migrating components one by one can be a feasible approach, but this can be cumbersome for large codebases (think 100K+ lines of code). This effort is way too large for a single person and has too many side effects. This is why we broke up our migration effort into nine milestones.

1. Native JavaScript class syntax for components

Historically Ember used object syntax to define components. As class syntax matured in JavaScript in general, it also became the standard for Glimmer components. Classic components in Ember provide support for both object and class syntax. This makes switching to class syntax a great first step towards Glimmer components.

Ember provides a codemod to convert object syntax to class syntax. This has saved us a tremendous amount of time. By doing this our development experience also greatly improved.

2. No implicit this

Arguments in Glimmer components are bundled in the args object. This avoids clashes with custom defined properties in the component’s own scope and creates a clear distinction between properties defined locally and passed arguments.

Glimmer component templates reflect this by using the @ prefix when using arguments and the this. prefixes when accessing properties of the backing class. This way of working is also supported in classic components, even though arguments are in the same scope as local properties. This means the migration is non blocking, and luckily there’s a codemod available for this as well. The codemod however can’t make a distinction between arguments and local properties, and is something that will be cleaned up in a later phase.

3. Getting the simple components out of the way

By reviewing all components and checking which used none or limited of the classic component features, we were able to identify a set of components which were easily migrated to Glimmer. Examples are components which did not have any JavaScript logic, as Glimmer introduced the concept of template-only components which work without an explicit backing class. This was low hanging fruit and by getting them out of the way directly we avoided unnecessary overhead of the other phases.

4. Remove outer HTML semantics

Classic components have a wrapping HTML element which doesn’t exist in Glimmer components. A first step to prepare for this removal was to get rid of all properties that have an impact on this wrapping element. In most cases this usage was the classNames attribute which added CSS classes to the wrapping element.

Converting was done by adding these properties directly in the template of the component.

5. Making components tagless

Wrapping elements of classic components can be removed by setting the tagName to an empty string, hence the name “tagless” components. The @tagName decorator from the ember-decorators package can be used to do this. This makes it easy to spot and clean up in a later phase.

Making the component tagless in this phase still introduces breaking changes which we fixed together with adding the decorator.

A common pitfall we noticed was that attributes on an Ember component had no place to be set and were dropped. In Glimmer you explicitly need to tell where the passed attributes have to be placed. This can be done by using the ...attributes syntax. Often this caused styling bugs as classes or id’s weren’t set. Our visual tests came in useful to detect these issues. If you’re interested in how we set up visual testing, check out our talk at EmberFest 2022.

A second issue was that lifecycle hooks that depended on this wrapping element no longer got invoked. Those lifecycle events contain the Element reference, e.g. didInsertElement. To migrate these we made use of the render-modifiers package. Ever since Glimmer and Octane, there are new ways to encapsulate this logic like using the constructor and destructor, writing custom modifiers, or using resources. For the sake of limiting the scope we opted to keep this a separate effort.

6. Removing Mixins

Mixins were a way to share common code across different components. In Glimmer they’re no longer supported. We reviewed our mixins and listed a way of restructuring them as in most cases mixins could be replaced with a more specific way of sharing code.

Common cases were template formatting logic which could be made into a helper, shared constants which could be moved to a separate file, and utility functions which could be separated as they didn’t require the Ember context. For usages that didn’t fit nicely in any of the standard ways of sharing code, we opted for creating custom class decorators as described in “Do You Need EmberObject?” by Chris Garrett.

7. Removing deprecated lifecycle events

In phase 5 a subset of deprecated lifecycle hooks were already removed. There are still others left which are not bound to the wrapping element, like didRender, willUpdate and others. Removing these lifecycle events can be done using a similar strategy as used in phase 5. Generally they can also be replaced with native getters.

8. Removing observers

Usage of observers has been discouraged in Ember for a long time. They were often overused when a better alternative was available, could cause performance issues, and were hard to debug. With Glimmer components, the @observes decorator is also no longer supported.

Refactoring of observers can be non-trivial as it requires you to think of your state updates differently. Rather than reacting to changes, Glimmer introduced autotracking which allows marking of inputs which should trigger UI updates. Some usages can be replaced by working with getters and autotracking. In other cases the did-update modifier of the render-modifiers package can be used as a replacement. Writing custom modifiers is also an option here.

9. And finally … extending from Glimmer!

Now that all classic specific features have been removed, it is time to extend the Glimmer component base class instead of the Ember classic one.

By making this change, arguments will move to the args object instead of the component’s local scope. Usages in the backing class have to be adjusted to use this step in between. One edge case to take into account is that by the change of this scope, they no longer override default values in the component. This can be resolved by writing a native getter which returns the argument from the args object and falls back to a default in case the argument is not passed.

Likewise, argument usages in the template also have to be updated to indicate the difference in scope. The @ prefix has to be set for arguments as the codemod didn’t handle this like mentioned in phase 2.

Finally, the tagName decorator added in phase 5 can be removed as Glimmer components are always tagless.

Conclusion

This article provided a strategy to migrate large Ember codebases from classic to Glimmer components. Following this component migration ensures codebases don’t get stuck in the past. Even better, they unlock modern features Ember provides and new ones being worked on at the very moment!

DEV Community: Ignace Maes

Adding custom fonts to your Ember app with Fontsource

Install the font packages

Import the CSS

Use the fonts in CSS

Preloading fonts to avoid FOUT

Variable fonts

Why Fontsource over Google Fonts?

That's it

I ported shadcn/ui to modern Ember.js

What is this, exactly?

How it works

1. Set up your project

2. Add a component

3. Use it

Other CLI commands

Installation options

Why I made this

Links

How to use the new Ember theme for QUnit

The easy way to access the last JavaScript array element

Browser support

Conclusion

Automate NPM releases on GitHub using changesets 🦋

Setting up changesets

Versioning

Release action on GitHub

Bonus: upgrade your changelog game with GitHub links

Conclusion

The road from Ember classic to Glimmer components

Classic vs. Glimmer

Why migrate to Glimmer components?

One way of doing things

Closer to native JavaScript experience

Rendering performance

TypeScript support

Future-proof a codebase

Migration strategy

1. Native JavaScript class syntax for components

2. No implicit this

3. Getting the simple components out of the way

4. Remove outer HTML semantics

5. Making components tagless

6. Removing Mixins

7. Removing deprecated lifecycle events

8. Removing observers

9. And finally … extending from Glimmer!

Conclusion