DEV Community: Lloyd Smith

On Things

Lloyd Smith — Thu, 23 Apr 2026 23:05:54 +0000

It is cheaper to make a thing next year than it is to make it today.
It is cheaper to maintain a thing next year than it is to maintain it today.

Therefore ...

A third-party thing needs to provide much more value for me to use it over just making my own version that thing myself.
I will not feel bad about making things.

Other Things:

The supply chain attacks of yore taught us that perhaps a trivial thing like "leftPad" should be inlined.
The definition of "trivial thing" has evolved to include much greater scope than in the past.

Do NOT Hallucinate

Lloyd Smith — Thu, 07 Aug 2025 21:05:01 +0000

Shared with me: Using Vega Lite with Ember.js

Lloyd Smith — Thu, 07 Aug 2025 17:36:50 +0000

a little -- bisonica is a vega-lite implementation, and I demo'd it in ember here: -- @nullvoxpopuli

example of using vega-lite with Ember.js via Bionica library

Shared with Me: State Charts with EmberJs

Lloyd Smith — Thu, 07 Aug 2025 17:33:12 +0000

Thanks to @nullvoxpopuli ! He shared an example of using state charts with emberjs with me!

Also shared:
A video of how "XState keeps getting better" -- Cortrah

A book recommendation on statecharts:

A good book on statecharts is the early book by Ian Horrocks "Constructing the User Interface with Statecharts" but it sounds to me like you are more interested in the event handling aspects which would be a related topic but a different emphasis. For this you'll want to search on Actor libraries (and XState has actors so that might be a good starting point) I'm not sure offhand what js libraries might be most useful for actor stuff in Ember, but for a good high level description which applies pretty well to any language (though the examples are in scala/java) is Vaughn Vernons "Reactive Messaging Patterns with the Actor Model"

Ember.js in 60 Seconds

Lloyd Smith — Tue, 29 Oct 2024 21:10:12 +0000

Before generative AI filled our world with bloated texts, humans relied on grammatically indifferent, terse notes to help others—and themselves—navigate the vast sea of software development. Here’s what I deemed essential about Ember, drawn from a note unearthed years ago:

ember-data is an ORM-ish persistence layer that Ember uses by default. It uses models, adapters, serializers, and a store as it's fundamental concepts. When an API is not a good fit for ember-data, it's possible to use an ad-hoc REST endpoint or RPC-style endpoint.

The store returns resources wrapped in "promise objects". These proxies allow the resources to be lazy loaded and trigger fetches when accessing a relationship that isn't loaded. Doing this in a loop is what causes N+1 queries.

Ember templates use data binding to automatically re-render portions of the DOM when the backing model changes.

Ember apps are "single page applications". The web server returns a static HTML page for all incoming requests and once the JavaScript is loaded the request is routed through Ember components which make API calls to one of our myriad microservices.

Components are the UI abstraction ember provides, which combine a template and a JavaScript file. Ember also provides for a dependency injection container, services (singletons managed by the container), routes, and so on.

The Top 7 Reasons You Should NOT Use Ember.js on Your Next Project

Lloyd Smith — Fri, 25 Oct 2024 22:37:55 +0000

If you're starting a new project and trying to decide on which frontend framework to use, then this article is for you. Here are my top 7 reasons to NOT choose Ember.js for your next web application project.

1. You Aren't an Ambitious Web Developer

Ember markets itself as "A framework for ambitious web developers," and let's face it, not everyone is ambitious—or a web developer. Ambitious developers work on ambitious projects, and ambitious projects need infrastructure that Ember just includes out of the box.

Back in 1998, I created my first website, "The Track Shack." It was a site about our high school track team, of which I was a member. I didn’t know how to code back then. I wrote articles using Microsoft Word 97 and used the "Save as Web Page" feature to export them to HTML, which I then uploaded to my Geocities website. One day, my coach asked if I had created a website—apparently, other coaches across the state were using it to get track and field news from our area. I’d even included meet results from The Commercial Appeal (which back then wasn’t online) and added dramatized accounts of our team's events from local meets.

If a simple site like that meets your needs, go right ahead and use Word's "Save as Web Page" feature.

2. You Want to Assemble Your Own Framework

Ember is an opinionated, batteries-included frontend framework. If you'd rather spend your time selecting each library, right down to the patch version, and crafting your own bespoke setup, you’ll be sorely disappointed with Ember.

In Ember, you start a new project by running:

npm install -g ember-cli
ember new my-project

And voilà—a new project is ready to be run with:

npm start

Note that unit tests will already be configured, which brings us to reason number three.

3. You Don't Plan on Writing Any Unit Tests

Ember automatically sets up unit, integration, and acceptance tests and generates stubs in the correct locations any time you use its built-in code generators. For example, if you create a new component with ember generate component big-button, Ember generates the component files and test stubs for it, which you’re supposed to fill out with assertions to test your component.

If you don’t want tests, you’ll end up with stubs that might raise eyebrows in code review, potentially requiring you to actually write tests—or spend extra time deleting the stubs before you submit the pull request. Sure, you can skip test generation with a command line flag, but that’s hard to remember and not recommended.

4. You Hate Native JavaScript

Ember makes heavy use of native JavaScript features, and using libraries like jQuery to manage the DOM is generally frowned upon. For example, here’s how a class-based component might look:

import Component from '@glimmer/component';

export default class DeleteJavaScriptButton extends Component {
   handleClick = () => {
      fetch(`/api/v1/languages/JavaScript`, {
          method: 'DELETE',
      }).then(() => console.log('deleted JavaScript'));
   }
   <template>
      <button {{on 'click' this.handleClick}}>Delete JavaScript</button>
   </template>
}

If you’re not a fan of native JavaScript, Ember’s definitely not for you.

5. You Hate Separating Templates from JavaScript

In the old days, we built HTML pages with good old JavaScript strings, like this:

var myHtml = '<script>\n' +
  document.getElementById('#myInput').value +
  '\n</script>';
document.getElementById('#myContent').innerHTML = myHtml;

Template languages eliminate this need, automatically escape dangerous values, and enforce a separation of concerns between logic and presentation (HTML)—which is concerning for some developers.

Another potentially annoying thing about Ember’s template engine is that it automatically updates the HTML in your app when the data changes, which is known as "data binding." If you prefer manually managing the DOM, concatenating strings, or using a different template engine, Ember is not for you.

6. You Hate Updating Dependencies Ever

A core value of the Ember community is "stability without stagnation." The framework is regularly updated in backward-compatible increments, following semantic versioning. Any deprecated functionality triggers a warning in development, telling you when it will be removed and how to update it.

These deprecation messages can create more work if your manager insists on a warning-free build. Updating Ember is generally straightforward, especially if done regularly, but if you’ve ignored updates for years, you’ll have some catching up to do.

7. The Ember Community Uses Discord

If you need help with an Ember project, the community's Discord server, is one of the best places to find it. But if Discord is against your company’s policy (or just not your style), this might be a dealbreaker.

In the Discord server, you will find Ember newbies and framework developers alike, and you can get help, share ideas, and even chat about the future of the project. But beware: these conversations can get interesting—and distracting, which may be why some companies ban Discord.

So, if you prefer AI to real people, Google searches over expert advice, or really hate Discord, save yourself the trouble and skip Ember.js.

Conclusion

And there you have it—my top 7 reasons not to use Ember.js on your next project. If you choose to ignore this advice and dive into Ember anyway, you might just find me lurking in the Discord server. If you have a question and I know the answer, I might try to help—but someone more knowledgeable probably will get to it before I can. So maybe we can just chat about more reasons not to choose Ember for your next project!