DEV Community: Lloyd Smith

vibe coding vs pair programming?

Lloyd Smith — Tue, 14 Jul 2026 16:58:08 +0000

❯ i disagree with:

Design
Storage: new CimdDocumentCache table (not columns on McpClient)
A new model in oauth/models.py, one row per presented client_id URL:

why can't we just add the expires, ttl, etc, values on the CMID doc itself? we're just replacing it if it's expired / can't be used (in one place).

you can push back on this -- i'm trying to minimize complexity.

You're right, and I'll concede most of it — my three reasons for the separate table mostly dissolve under scrutiny. Let me be explicit about what holds and what doesn't:

broken windows

Lloyd Smith — Mon, 13 Jul 2026 03:06:40 +0000

I deleted this comment before sending. It would have been a reply to a comment:

Anyone else's agents tend to write a lot of overly-defensive lines like this.foo?.bar?.baz || []? Are you doing anything to mitigate it? I would imagine it's a bigger problem for JS teams than TS

In the olden days of Java we had PMD and FindBugs and Eclipse and they would warn you about unnecessary null checks.

Yet codebases routinely had thousands of warnings.

The only way to get people to stop was:

fixing all those warnings, which required a heroic, thankless effort, or starting a new project
and then configuring strict build checks that failed the build
watch them so they don't disable it or just suppress warnings on every line

This was maybe 20 years ago.

People are still people-ing, I guess, via AI bots. The AI, I wonder, must have been trained on this sloppy human code.

P.S., Potential null pointer dereferences were almost as common.

kubernetes development tools

Lloyd Smith — Sat, 11 Jul 2026 00:51:39 +0000

I was reading pseudo-random New Relic documentation on distributed tracing and somehow saw mention of a tool called skaffold.

Long story short, it replaces a bunch of bespoke commands in my Makefile to make dev.

It watches the files copied into images and if you change any of them, it automatically rebuilds the appropriate container, etc.

It also sets up the port forwarding -- something I occasionally forgot to do with the old system.

Run skaffold without tearing down the database when you exit (keeps your persistent volume claims and maybe other stuff):

skaffold dev --cleanup=false

Trigger Manual is nice when you don't want it to rebuild with every edit (possibly breaking the test environment, which others could be using). You click in the terminal running skaffold and hit "Enter" and it will rebuild with this mode.

skaffold dev --cleanup=false --trigger=manual

As I was developing an MCP server and testing it with actual clients, I wanted to run the dev environment as close to production as possible and using minikube made this a cinch! I didn't have skaffold in those days and I'd be Ctrl+C and arrow-up or reverse-search (Ctrl+R) to get my serve command. And then forget the port forwarding or some other aspect. Also, it would build everything instead of just the changed components. It was fast enough as the Dockerfiles were using multi-stage build with cached layers, but skaffold is even better!

I used Ember.js to make an MCP server

Lloyd Smith — Wed, 08 Jul 2026 13:01:35 +0000

https://mcp.decile.com is an MCP Server I built that uses Ember.js!

Okay, perhaps I overstated that a bit. The MCP server was built using a whole bunch of stuff for the backend, frontend, and infrastructure from Kubernetes to Starlette to Django REST Framework to nginx to ... you name it. Ember.js only powers the MCP Apps that are embedded by the MCP Server (about 5 of them so far). Unsurprisingly, ember was well suited to this problem (although not perfect).

What went well?

The "gjs" file format is very pleasant for human authoring and AI did a great job of working with it. I suspect that this is because it uses strict imports for everything so the AI (or human) don't have to rely on implicit context in order to reason about what a component does.
The new build system based on Vite was lightning fast and flexible! I was able to make the customizations I needed to execute in an MCP App context pretty easily.
Using a monorepo with shared components importable by any of the MCP Apps and tree-shaken away if not used was very convenient! Sharing the boilerplate lint config files, vite configs, etc., as importable ".mjs" files to avoid copying those across each separate mcp-app (and full ember app).
Using an Ember.js service to abstract away the mcp-apps SDK into a more reactive, "ember native" API was really easy and makes testing trivial.

'use strict';

module.exports = function (environment) {
  const modulePrefix = 'view-audience';
  const ENV = {
    modulePrefix,
    environment,
    rootURL: '/',
    locationType: 'hash',
    EmberENV: {
      EXTEND_PROTOTYPES: false,
      FEATURES: {},
    },
    APP: {
      MCP_SERVER_BASE_URL: '__MCP_SERVER_BASE_URL__',
    },
    'mcp-app': {
      appInfo: {
        name: modulePrefix,
        title: 'View Audience',
        version: '1.0.0',
      },
      capabilities: { availableDisplayModes: ['inline', 'fullscreen'] },
    },
  };

  ...

  return ENV;
};

What didn't go so well?

Originally, I planned on using the new renderComponent( helper that allows rendering an individual component instead of a full app with router, service injections, etc., but I quickly started to miss the things the app provided.
The bundle size is larger than desired, but much of that is actually the MCP Apps SDK, which bundles every locale of zod.

There's a lot more to speak to but I'm out of time (it's 9 AM now)!

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!