Starting a New Ember App: What Addons Should I Install From the Start?

1

I’m starting a brand new ember app for the first time in forever. I’m a huge fan of starting with guardrails in place for things that will be harder to add later, but easy to always follow along from beginning. I have a list of things I want to add right away, almost all of which I’ve used in the past:

I also would love to have some measure of performance testing automated from the beginning. I looked into scripting Ligthhouse to test this, which I can get to work, but it keeps reporting 15 seconds for Time to First Meaningful Paint on a brand new ember app, which doesn’t make any sense. Maybe I have something set up incorrectly.

I have some questions:

  1. Does anyone do automated performance testing for the Ember apps? I’m thinking about payload size and time to first meaningful paint, but what other metrics are there that you like to automatically track regressions for?

  2. What other “from the beginning” things would you add to a new ember app? I don’t think the type of application overly matters. I’d love to hear about whatever this questions means to you.

5 Likes
2
  • ember-cli-page-object is a must have for me or testing feels wrong and twice as difficult.
  • ember-cli-mirage for mocking my api during tests.
  • ember-sinon for a nice integration with sinon.js for mocking/stubbing/spying during tests
  • ember-cli-bundle-analyzer - a great visualization of the dependencies in your app to help you know where you can slim your app’s bundle size (by targeting the largest dependencies or seeing if test resources make it into the prod build on accident)
2 Likes
3
2 Likes
4

These are also super helpful for just about any app:

  • ember-auto-import (makes import of NPM packages easy)
  • ember-awesome-macros (excellent set of composable macros to create computed properties)
  • ember-cli-app-version (helpful for keeping track of versions to prompt users to update)
  • ember-cli-new-version (prompt users to reload app)
  • ember-cli-deploy (collection of add ons to enable deploy process)
  • ember-composable-helpers (move some logic into templates as appropriate)
  • ember-cp-validations (great validation library)
  • ember-in-viewport (efficient way to trigger behavior when an element enters/exits viewport)
  • ember-math-helpers (helpful math in templates)
  • ember-moment (great wrapper around moment for use in templates)
  • ember-page-title (easily update the page title from templates)
  • prember (pre-render fastboot app if you need a static version of the app)
3 Likes
5

In addition to some of the others already mentioned (ember-auto-import, ember-concurrency, ember-cli-deploy):

  • ember-svg-jar is a must-have for my apps. It’s such a nice experience compared to digging through assets folders.
  • ember-test-selectors
  • ember-a11y addons, especially testing
1 Like
6

These two would be recent entrants. And really useful.

Also ember-router-scroll && ember-cli-head depending on the type of application.

As a side note, I would personally be rather sparse in what I install and delay that decision until when actually needed. It’s weird how the winds change as you move along in the project :slight_smile:

2 Likes
7

I would like to second ember-cli-tailwind with the caveat that I would rather have it part of a larger design system instead of bing a part of a single project.

Honorable mentions that have not yet been called out:

ember-cli-deploy-json-config - perfect for deploying application through non standard channels (example: served from an .net application instead of static index.html)

2 Likes
8

Re: time to first paint, are you testing dev or production?

Also, using broccoli-concat-analyzer, where are all your bytes going? Here is my app: Broccoli Concat Analyser

Time to first paint is < 1s, using the appshell technique

1 Like
9

Thanks for all of the great responses!

For my perf testing, I was indeed testing dev and probably the wrong ember app. I fixed those issues. Now, I’m working with a with a new ember app (with some dummy content in the application template). Here’s my performance script: lighthouse-command-line.js · GitHub

In the Chrome Performance Audit normally, TTFP is 0.3 seconds. Using my script above, the report says 2.4 seconds. I really don’t know why that would be.