DEV Community: Vincent Romanus

Signals: I Was Wrong. Kinda.

Vincent Romanus — Mon, 08 Jun 2026 12:35:10 +0000

A while ago, I wrote an article called Signals: The Enshittification of Angular.And I still agree with a lot of it.

The first iterations of Signals felt unfinished, awkward and weirdly ideological. Performance issues, endless update loops, another reactive abstraction on top of Angular’s already fragmented architecture and a community suddenly acting like the default was a historical mistake.

At the time, Signals didn’t feel like Angular becoming simpler. They felt like Angular having an identity crisis. But with the recent updates: Signals work now. The endless update loops from the first iterations seem to be gone, the performance issues are no longer a real concern and Angular finally started building the framework consistently around the concept: httpResource, forms as signals and the overall direction finally make Angular feel coherent again.

And that’s the part where I was wrong. Kinda.

Angular created a reactivity war

One of Angular’s biggest ironies is that its original default change detection worked perfectly fine for most applications.

Then the community overwhelmly decided it was unacceptable.

OnPush, Async pipes, Subjects, manual detectChanges() everywhere. Entire components looking like handcrafted RxJS operators just to handle a loading state. Angular developers spent too much time writing boilerplate to replicate behavior Angular already handled automatically. And somehow this became “clean architecture”.

Everyone had a different definition of “proper Angular” and Signals didn’t really introduce a revolutionary new paradigm for me. Just made it look like another Wannabe-React.

Signals made Angular coherent again

This is the part I genuinely underestimated. Signals unified Angular’s mental model in a way Angular desperately needed. State changes update the UI. That’s it.

No async pipe ceremony for synchronous state. No manually triggering change detection because Angular randomly missed another case. No weird “reactive but not reactive enough” social media post every week.

Signals made a kinda straightforward solution the standard again.And honestly, that alone improved Angular more than most technical features ever could.

Because for years, Angular’s biggest problem wasn’t really performance. It was that the ecosystem normalized complexity and called it scalability. Signals quietly killed a massive amount of unnecessary abstraction.

Angular didn’t need this shift. The community did.

This is the one thing I still struggle with. I’m still not fully convinced Angular itself needed such a massive architectural shift in the first place. A lot of the problems Signals solved were arguably created by Angular culture itself. Overusing OnPush, pushing reactive purity over developer experience and normalizing increasingly convoluted boilerplate as “enterprise best practice”.

Angular probably could have solved a large part of this by enforcing simpler standards and better defaults much earlier. Instead, the ecosystem slowly drifted into a place where developers manually optimized everything while recreating behavior the framework already had.

So maybe Angular didn’t need Signals as much as the community did. Signals became the escape hatch from that complexity. Ironically by introducing another reactive primitive.

The weird part is that it worked, so I'm not against Signals anymore.

Signals: The Enshittification of Angular

Vincent Romanus — Fri, 27 Feb 2026 11:43:11 +0000

Let’s start with a term that perfectly captures what’s happening here: Enshittification.

Coined by Cory Doctorow, it describes the slow degradation of a product or platform over time. First, it’s amazing. Then it starts optimizing for growth. Then for platform goals. Then for “strategy”. Eventually, the thing that made it great gets diluted, replaced, or buried under abstractions nobody asked for.

It doesn’t break overnight. It erodes.

And that’s exactly how Angular feels right now.

Angular Is Throwing Away Its Superpower

Angular had a superpower. And no, it wasn’t TypeScript. It wasn’t DI. It wasn’t the CLI.

It was Zone.js + RxJS + Default Change Detection.

That combination was insane.

You could write reactive code with RxJS, pipe your streams, bind them in templates, and Angular would just… update the view. No manual state sync. No explicit subscriptions everywhere. No setState. No signal triggers. No reducers. No “please re-render now.”

Zone.js patched the async boundary and said: “Don’t worry. I got this.”

And it worked. Surprisingly performant, too - if you knew what you were doing.

People love to hate on Zone.js because “magic.” But that “magic” eliminated boilerplate. It allowed reactive rendering without introducing a state management framework every five minutes.

Angular had something no one else had:

React needed setState (and later 50 state libraries). Vue leaned into its own reactivity system. Svelte compiles it away.

Angular? It just rendered your damn data.

RxJS handled data flow. Zone.js handled the async boundary. Change detection did the rest.

You didn’t need Redux. You didn’t need manual triggers. You didn’t need architectural gymnastics.

It was enterprise-grade and boring in the best possible way. And now? We’re slowly being told that this wasn’t good enough.

The Massive Architectural Pivot - But For What?

Signals. Server-side rendering. Hydration. Zone-less Angular. Why?

Angular was never the scrappy “micro-frontend for landing pages” framework. It was the enterprise beast. The SAP dashboard monster. The internal tooling machine. The multi-team, multi-year platform workhorse. It had an identity.

Now it feels like it’s chasing something else.

SSR? Sure. Nice to have. But Angular didn’t dominate because of SEO. It dominated because of structure, stability, and predictability. This architectural shift feels less like evolution and more like insecurity. Instead of doubling down on what made Angular powerful, predictable reactive UI without ceremony, it’s pivoting toward parity with frameworks that already own that space.

React has owned the fine-grained manual reactivity narrative for years. Svelte owns compiled reactivity. Angular trying to out-react React feels like Apple suddenly deciding to build budget Android clones.

The Forced Migration = The Real Shittification Here’s where it gets ugly.

Right now, you can still use Zone.js. You can still use default change detection. You can still write Angular the way it was designed. But read between the lines:

Zone-less is the future. Signals are the new primitive. Manual control is the direction.

Did you check Angular? I got wonky. The moment updates don’t behave the same way with zone + default detection, the moment you start having to manually push updates even though you’re using the “old” model, that’s it. That’s the enshittification moment.

Because now:

You add boilerplate.
You introduce manual triggers.
You lose the simplicity of “it just works.”
You risk performance regressions because humans are now responsible for what the runtime handled flawlessly.

And that’s the irony: Zone.js was criticized for being magic. But the alternative? You become the runtime. Congratulations. You now manage update boundaries yourself. How is that progress?

Angular Is Losing Its Identity

Frameworks win by owning a philosophy.

React : explicit, manual, flexible, chaotic. Svelte : compile-time intelligence. Vue : progressive reactivity. Angular : was structured, opinionated, enterprise-stable, reactive without ceremony.

Signals aren’t bad. SSR isn’t bad. Zone-less isn’t evil. But forcing a shift that invalidates the original design philosophy? That’s where the identity cracks.

When Apple builds phones, people buy them because they are Apple phones. If Apple suddenly released plastic budget clones trying to beat Xiaomi at its own game, what happens? People who want premium stay confused. People who want cheap buy Xiaomi anyway. You lose both sides. That’s what this feels like.

Angular is walking toward a space where React and Svelte already have cultural dominance. And when a framework loses its identity, it doesn’t immediately die.

It slowly becomes… less. Less special. Less distinct. Less obvious.

Final Thought

This isn’t about hating Signals. Just a little.

It’s about watching a framework abandon the exact design choices that made it powerful.

Angular didn’t need to be React. It didn’t need to be Svelte. It didn’t need to win the SSR hype cycle.

It just needed to remain the enterprise reactive beast that didn’t make you manually babysit your view updates.

Enshittification doesn’t happen because something becomes terrible. It happens because it stops being what made it great.

And right now? Angular feels like it’s forgetting who it is.

Hot Take: AI Didn’t Kill Tailwind’s Business. The Business Model Did.

Vincent Romanus — Fri, 09 Jan 2026 16:42:16 +0000

By now, most people in tech have seen it. If not, here’s the full comment, that sparked a wildfire in the community, where he said:

“75% of the people on our engineering team lost their jobs here yesterday because of the brutal impact AI has had on our business. And every second I spend trying to do fun free things for the community like this is a second I'm not spending trying to turn the business around and make sure the people who are still here are getting their paychecks every month.”

Let’s unpack that.

What is Tailwinds Business Model?

In short:

Prebuilt UI components (HTML + Tailwind CSS snippets)
An UI kit for React and/or Headless UI
One-time payment, no recurring revenue

In a space with insane competition:

Flowbite
DaisyUI
Preline
HyperUI
Headless UI
TW Elements
TailGrids
FlyonUI
Meraki UI
Wind UI
Ripple UI
Material Tailwind

Some of these are completely free. So, yeah, you get the idea: if your product is a one-time bundle of copy-pastable HTML, and every mid-level dev can churn out each block in some hours or even minutes... That's not exactly a good long-term strategy in this market.

What a 75% Layoff Really Means

A 75% layoff sounds catastrophic, until you realize it's about three people. No punchline.

The Media Hype Train

Big dev YouTubers like Theo - t3․gg jumped in to declare:

“This is one of the first examples of AI immediately causing engineers to lose jobs.”

Come on, man. For real?

My 2 Cents

Is it still sad? Yes, of course. Tailwind is arguably the most popular UI library in web development right now. But when your entire business sits on a shaky foundation, it doesn’t take AI to pull the rug out. That said, the drama paid off. Tailwind landed a wave of new sponsorships in just a few days: Vercel, Google AI Studio, Theo himself, and loveable.

Hopefully, they don’t just survive. But learn something from it too.

Faster, Dumber, Fragile: Welcome to AI-Driven Development in 2025

Vincent Romanus — Mon, 29 Dec 2025 12:53:39 +0000

Code faster, ship dumber? The productivity illusion of AI

Remember when the wildest part of software development was a new JavaScript framework every week?

Now we’ve got Copilot and accomplices auto-completing entire functions. AI tools are everywhere. And according to the headlines, developer productivity is up. 25 percent, 30 percent, 40 percent, depending on who’s selling the story.

The numbers sound impressive. Studies show teams writing more code, finishing tasks faster, shipping sooner.

But the closer you look, the messier it gets.

Nearly half of all developers say they don’t trust AI-generated code. A controlled study found experienced developers actually took 19 percent longer when using AI, not because the code was better, but because they had to double-check every suggestion.

Another analysis showed that 45 percent of AI-generated code had security flaws.

And even when the code “works,” it’s often verbose, redundant, or barely maintainable. More code, more bugs, more time spent debugging instead of building. AI doesn't just increase output. It accelerates organizational debt.

Yet somehow, companies still celebrate velocity as if more lines of code equals progress. Elon Musk once claimed great developers write more code than average ones. Linus Torvalds had a fitting response:

“Anybody who thinks that's a valid metric is too stupid to work at a tech company.”

It's not about writing more code. It’s about writing the right code and trusting that it won’t blow up in production.

The dangerous myth of “we won’t need developers”

AI should revolutionize software development. In 2025, it distorted it.

Instead of empowering teams, it gave companies an excuse to cut headcount. Layoffs happened. Some of those same engineers got quietly rehired. But the worst shift? Junior developers stopped getting hired at all.

And that’s not just short-sighted. It’s dangerous.

The loudest voices claiming “you won’t need to code anymore” are either trying to inflate their AI startup valuation or have never shipped a product past a prototype. Saying developers are obsolete isn't insight. It's grift.

Even AWS CEO Matt Garman called it out directly. Replacing junior devs with AI, he said, is one of the dumbest ideas he’s ever heard.

And he backed it up with three reasons:

Juniors adapt faster to AI They’re AI and digital natives. They grew up with this tech. Over 55 percent of junior developers use AI tools daily, higher than most senior engineers. They explore, iterate, and learn in public.
They’re not the cost problem Juniors are the cheapest employees on the team. Cutting them doesn’t move the needle on cost, but it guts your ability to grow from within.
No juniors, no pipeline You don’t get senior engineers out of nowhere. Without juniors, you lose mentorship, fresh thinking, and future leadership. It's a slow death spiral.

This isn’t theory. Companies that cut junior roles in 2024 are already rehiring offshore or at reduced wages just to keep up. The work didn’t go away. They just convinced themselves it could be automated.

You don’t build a strong engineering culture by pretending AI is a replacement. You build it by investing in humans and letting AI assist them, not erase them.

Anyone telling you otherwise is just trying to cash in on the bubble before it bursts.

The death of learning by doing

AI didn’t just automate boilerplate. It skipped the learning process too, and that’s a problem.

Developers used to learn by doing. You broke things. You fixed them. You tried the wrong approach, then figured out why it failed. That struggle built context. Judgment. Real problem-solving skills.

Now? You ask ChatGPT. You accept Copilot’s suggestion. You ship something that works, but you don’t know why.

We lose the most important developer skill: engineering intuition. The ability to understand problems and choose the best solution based on the current context.

Without that, you don’t grow. You just copy, paste, and hope for the best.

Use It, Don’t Worship It

AI is great for boilerplate, quick fixes, even writing docs. But it doesn’t understand context like we do, and it won’t write long-term code for you or your team. It’s not a tool. It’s a genie without senses. Don’t expect it to understand the world. And don’t forget how to think.

Why You Should Introduce Theming at the Start of Your Project

Vincent Romanus — Wed, 03 Sep 2025 17:13:00 +0000

There are design decisions that come back to bite you later. Color is one of them. At the beginning, it always feels like a “later” problem, “Let’s just get it working first.” Fast-forward a few months, and you’re the poor soul refactoring #0FB9B1 from 17 different files because marketing decided the primary turquoise needs to be 5% darker. Lovely.

Theming isn’t a luxury. It’s hygiene.

Theming, the separation of visual styling from component logic, usually gets introduced after requirements scream loud enough. Light/Dark mode. Whitelabel support. Multi-tenancy. Accessibility. Take your pick.

But why wait?

If you know these things might show up down the line, there’s zero reason not to prep for them from day one. It’s not overengineering. It’s laying down the tracks before the train speeds up.

The Practical Starting Point: Color Token Design

Solid theming starts with a system. Not just defining --primary and calling it a day. You need structure. Context. Semantics.

This is how you build it.

Color Roles

Think in roles, not colors. Not “blue,” but “Info.” Not “green,” but “Success.” Your UI communicates states, your tokens should reflect that.

Role	Purpose
Basic	Neutral foundation (e.g., form fields)
Primary	Main interactive elements
Info	Contextual or neutral information
Success	Positive outcomes
Error	Validation errors or destructive actions

State Variants

Colors have states. A button doesn’t look the same when it’s hovered, focused, disabled, or selected, and your system should reflect that.

State	Purpose
Default	Standard visual
Muted	Disabled or low priority
Highlight	Hover/Focus state
Strong	Active/Selected state
Facing	Text or content on top of the color

Elevation Levels

Don’t forget backgrounds. Especially when dealing with nested layouts or UI depth, a layered token model is a must.

--level-0: #FFFFFF; /* Default background */
--level-1: #F5F8F9; /* First level nesting */

Selling B2B? Theming Is Non-Negotiable

If your software is meant for multiple clients, especially in the B2B or SaaS world, then theming isn't just a nice-to-have. It's a hard requirement.

Every customer will want their own logo. Sure. But it won’t stop there. The moment one of them asks for “our brand colors,” you either:

Pray they’re close to your default palette, or
Spend an unholy amount of time building what you should’ve started with: a theme system.

Supporting custom branding at scale means color flexibility is baked into your foundation. When each client gets their own palette, your design system must decouple style from structure.

Tokens are your scalable way forward.

Okay... But What If I Haven’t Done This Yet?

If you’re halfway through a project (or deep into one) and realizing you skipped theming, don’t panic. The good news? You probably don’t need a massive refactor to get back on track. You just need to start now, and you can do it incrementally.

Create a Theme CSS File

Start by defining your design tokens in a dedicated theme scope — usually tied to a root class like .my-theme or :root.

.my-theme {
  /* LEVEL */
  --level-0: #ffffff;
  --level-1: #f5f7f9;

  /* BASIC */
  --basic-default: #ffffff;
  --basic-muted: #e9ecef;
  --basic-highlight: #dfe3e7;
  --basic-strong: #b0b8c1;
  --basic-facing: #1c1e21;

  /* PRIMARY */
  --primary-default: #2f5aa8;
  --primary-muted: #d5deef;
  --primary-highlight: #4a73c2;
  --primary-strong: #24488c;
  --primary-facing: #ffffff;

  ...
}

This becomes your palette, one place to rule all styles.

And because the structure is consistent, you can now define a new theme and swap with a single class change:

.my-dark-theme {
  /* LEVELS */
  --level-0: #1a1a1a;
  --level-1: #252525;

  /* BASIC */
  --basic-default: #2f2f2f;
  --basic-muted: #3a3a3a;
  --basic-highlight: #4c4c4c;
  --basic-strong: #666666;
  --basic-facing: #d0d0d0;

  /* PRIMARY */
  --primary-default: #f72585;
  --primary-muted: #4b1e38;
  --primary-highlight: #fa58aa;
  --primary-strong: #ff7cb8;
  --primary-facing: #e8cce0;
...
}

Refactor Styles to Use Tokens

Apply the tokens in your core components. Here’s a simple button example:

.button-base {
  background-color: var(--basic-default);
  color: var(--basic-facing);

  &.disabled {
    background-color: var(--basic-muted);
  }

  &:not(.disabled) {
    &:hover {
      background-color: var(--basic-highlight);
    }
    &:active {
      background-color: var(--basic-strong);
    }
  }
}

.button-primary {
  background-color: var(--primary-default);
  color: var(--primary-facing);

  &.disabled {
    background-color: var(--primary-muted);
  }

  &:not(.disabled) {
    &:hover {
      background-color: var(--primary-highlight);
    }
    &:active {
      background-color: var(--primary-strong);
    }
  }
}

Start small, pick high-traffic components like buttons and forms. Over time, your codebase will shift from brittle and hardcoded to flexible and theme-aware.

TL;DR: Theming Isn’t a Later Decision

If your product is going to grow, team-wise, feature-wise, or audience-wise, theming from day one is the smarter path. Not for the hype, but for the foundation.

Start with color tokens. Think in roles and states. Stop seeing your UI as “blue on white,” and start seeing it as “Primary on Level-0.”

Your future self will thank you. Your future clients will demand it. And let’s be honest, you wanted a Dark Mode anyway.

Component Composition vs. Options API: Why Flexibility Always Wins

Vincent Romanus — Wed, 09 Apr 2025 15:11:52 +0000

In UI development, structure matters — not just what you build, but how you build it. Whether you're designing a basic dashboard or a deeply interactive enterprise app, your approach to UI architecture shapes how quickly you can deliver, how clean your code stays, and how far you can scale before rewrites become necessary.

Two common patterns dominate the frontend ecosystem: Component Composition and the Options API.

Component Composition, exemplified by Angular Material, encourages building UIs out of small, reusable parts. You compose templates with components, use logic where logic belongs, and work with the full expressive range of the language.

The Options API — found in libraries like DevExtreme — favors configuration. You describe the structure, behavior, and rules of your UI in a single object tree. It looks clean at first. It’s structured. It’s even tempting.

But once you move beyond basic setups — into custom interactions, reactive logic, or anything resembling actual business rules — it starts to feel like trying to do origami with steel plates.

Both models are viable. But only one scales with your brain, not against it.

Options API: “Just Configure Everything… If You Can”

Using an Options API feels great right up until you want to do something not already baked in.

Take something like DevExtreme’s DataGrid. It’s packed. You don’t write much HTML — just configure options:

<dx-data-grid
  [dataSource]="data"
  [columns]="columns"
  [remoteOperations]="true"
  [editing]="{
    mode: 'popup',
    allowUpdating: true,
    allowAdding: true,
    allowDeleting: true
  }"
  [paging]="{ pageSize: 10 }"
>
</dx-data-grid>

Cool, right? You’ve barely written code and already have sorting, filtering, grouping, paging, exporting, and editing.

But the deeper you go, the more it feels like you’re writing a spec sheet — not a UI. Here’s what a more “real-world” setup looks like:

<dx-data-grid
  [dataSource]="data"
  [columns]="columns"
  [remoteOperations]="true"
  [allowColumnReordering]="true"
  [allowColumnResizing]="true"
  [columnAutoWidth]="true"
  [rowAlternationEnabled]="true"
  [filterRow]="{ visible: true }"
  [searchPanel]="{ visible: true, highlightCaseSensitive: true }"
  [groupPanel]="{ visible: true }"
  [sorting]="{ mode: 'multiple' }"
  [editing]="{
    mode: 'popup',
    allowUpdating: true,
    allowAdding: true,
    allowDeleting: true,
    popup: {
      title: 'Edit Record',
      showTitle: true,
      width: 700,
      height: 525
    }
  }"
  [selection]="{ mode: 'multiple' }"
  [paging]="{ pageSize: 20 }"
  [pager]="{
    showPageSizeSelector: true,
    allowedPageSizes: [10, 20, 50],
    showInfo: true
  }"
  [export]="{ enabled: true, fileName: 'MyDataGridExport' }"
  [stateStoring]="{ enabled: true, type: 'localStorage', storageKey: 'gridState' }"
>
</dx-data-grid>

That’s just the grid. And you haven't even touched:

Custom cell rendering (cellTemplate)
Asynchronous data validation
Master-detail views
Virtual scrolling
Infinite scrolling
Keyboard navigation
Custom summary calculations
Load indicators
Command columns
Predefined column types
Localization
Accessibility configs

It’s not a component anymore. It’s a degree program.

You’ll find yourself crawling through documentation, Stack Overflow, DevExpress forums — not to find cool tricks, but just to do basic things like “change the icon on the edit button.”

And yet, when you need to show a tooltip on a disabled context menu item? Still no dice. All this config, and the simple stuff still breaks.

When Two Simple Things Should Work Together — But Don’t

The biggest weakness of an Options API isn't what it can do — it's what it can't combine.

Here’s a textbook example: you want a context menu item that’s disabled, but still shows a tooltip explaining why. Sounds simple, right? Two basic UI primitives: a menu and a tooltip.

With a composition-first framework, you’d just write:

<button
  mat-menu-item
  [disabled]="!isAdmin"
  matTooltip="Only admins can delete"
>
  <mat-icon>delete</mat-icon>
  Delete
</button>

Boom. You’re done. The tooltip appears even when the button is disabled. The UX is clear. It behaves exactly as expected.

Now try the same with DevExtreme’s Options API — specifically dx-context-menu:

<dx-context-menu
  [items]="contextMenuItems"
  target="#someElement"
></dx-context-menu>

You set up your menu items like this:

contextMenuItems = [
  {
    text: 'Delete',
    icon: 'trash',
    disabled: true,
    hint: 'Only admins can delete'
  }
];

You think the hint will show up as a tooltip. But it doesn’t. Why? Because the item is disabled, and DevExtreme disables everything — including pointer events. No hover. No focus. No tooltip. The two components — context menu and tooltip — don’t talk to each other, and there’s no composable escape hatch.

You can’t just wrap the item in a tooltip component. You can’t move logic into the template — because there is no template. You’re stuck in config-land, where everything is abstracted, and flexibility is gone.

The workaround? Either:

Enable the item and block interaction with custom logic (gross UX), or
Abandon the tooltip and hope the user just “gets it” (bad accessibility).

Both are compromises. All because you tried to combine two basic things that should have worked together.

That’s not a limitation of context menus. That’s the cost of a tightly-scoped Options API.

Component Composition: Build What You Want, How You Want

Now compare that to a compositional approach — like Angular Material, but this could be React, Vue, Svelte, or anything that favors building with components.

Here’s the same tooltip-on-disabled-button scenario:

<button
  mat-menu-item
  [disabled]="!isAdmin"
  matTooltip="Only admins can delete"
>
  <mat-icon>delete</mat-icon>
  Delete
</button>

No hacks. No weird tricks. It just works.

Need that in a menu? Easy:

<mat-menu #menu="matMenu">
  <button
    mat-menu-item
    [disabled]="!isAdmin"
    matTooltip="Only admins can delete"
  >
    <mat-icon>delete</mat-icon>
    Delete
  </button>
</mat-menu>

Component Composition doesn’t abstract the DOM away from you. It invites you to use it the way it was designed to be used. You write templates. You apply logic. Likewise, you get exactly what you expect.

Tables: Config Orchestration vs. Clean Logic

If you’re still wondering when to use each: let’s talk tables.

With an options-based grid (again: DevExtreme), it’s all in the setup:

<dx-data-grid
  [dataSource]="users"
  [columns]="columns"
  [editing]="{ mode: 'form', allowUpdating: true }"
  ...
></dx-data-grid>

It works, but you’re forever constrained by what’s in the config model. Want a custom filter? Custom header? Reactive interaction between columns? Prepare to override callbacks, inject raw DOM, or regret your choices.

With a mat-table, you build exactly what you want:

<table mat-table [dataSource]="dataSource" class="mat-elevation-z8">
  <ng-container *ngFor="let col of displayedColumns" [matColumnDef]="col">
    <th mat-header-cell *matHeaderCellDef>{{ col }}</th>
    <td mat-cell *matCellDef="let element">{{ element[col] }}</td>
  </ng-container>

  <tr mat-header-row *matHeaderRowDef="displayedColumns"></tr>
  <tr mat-row *matRowDef="let row; columns: displayedColumns"></tr>
</table>

Less magic. More freedom. You can customize the rendering, plug in your own sorting logic, paginate however you want — and it all feels like Angular. Not like writing a JSON spec for an alien UI framework.

When to Use What

Use an Options API when:

Your backend defines everything: layout, structure, behavior.
You want a UI engine, not a UI framework.
You don’t plan to inject much custom logic.

Use Component Composition when:

You’re building anything custom.
You want clean separation of concerns.
You like being in control of your UI, not negotiating with it.

Because at scale, composability isn’t just nicer — it’s necessary.

Tailwind: Why I love it but disagree with its creator

Vincent Romanus — Mon, 03 Feb 2025 00:16:33 +0000

Tailwind CSS has gained immense popularity in the web development community for its customizable CSS framework and extensive utility classes. These utility classes provide developers with the flexibility to create consistent and customized designs for modern and responsive web interfaces. One of the most significant benefits of Tailwind CSS is that it offers cross-browser support, and most IDEs support Tailwind CSS plugins for autocompletion.

One of the most notable features of Tailwind CSS is @apply, which merges utility classes and applies them into one CSS class. Combining BEM and Tailwind CSS through @apply is awesome, allowing for separation of concerns and ensuring readability, especially with long lists of utility classes:

.btn-primary {
  @apply py-2 px-4 rounded-lg;
  @apply text-white bg-blue-500 hover:bg-blue-700;
  @apply focus:outline-none focus:ring-2 focus:ring-blue-400 focus:ring-opacity-75;
}

However, the creator of Tailwind CSS, Adam Wathan, would disagree with this approach. He suggests that you should reuse your utility-littered HTML instead of using BEM.

While reusing utility classes can work in some cases, it can make debugging a nightmare in large projects, and it can lead junior dev developer to use !important when frustrated by implementing nested mutation while not wanting to refactor the huge chunks of utility classes. I have seen that in some projects.

Even when creating components instead of BEM, Tailwind's Utility-First approach can be challenging to use when there are variations involved:

{type === “primary” ? 
  <button className=“py-2 px-4 rounded-lg shadow-md focus:outline-none focus:ring-2 focus:ring-opacity-75 bg-blue-500 text-white hover:bg-blue-700 focus:ring-blue-400”>
    Do it
  </button> : 
  null
}
{type === “secondary” ? 
  <button className=“py-2 px-4 rounded-lg shadow-md focus:outline-none focus:ring-2 focus:ring-opacity-75 bg-purple-500 text-white hover:bg-purple-700 focus:ring-purple-400”>
    Do it
  </button> : 
  null
}

Using @apply with BEM makes things much simpler:

.btn {
  @apply py-2 px-4 text-white rounded-lg outline-none ring-2 ring-opacity-75;
  &.btn-primary {
    @apply bg-blue-500 hover:bg-blue-700 focus:ring-blue-400;
  }
  &.btn-secondary {
    @apply bg-purple-500 hover:bg-purple-700 focus:ring-purple-400;
  }
}

In summary, just using Tailwind CSS utility classes can significantly speed up projects, but for big projects with heavy nesting, components with variations, or white labeling, combining BEM and @apply is a better approach.

HTMX: The Minimalist Challenger of Angular, React, and Vue.js

Vincent Romanus — Mon, 03 Feb 2025 00:02:01 +0000

In the dynamic world of web development, where complexity often reigns supreme, a minimalist contender is making waves: HTMX. This lightweight library is gaining traction among developers who crave simplicity and minimalism. As the community splits between those who rely on robust frameworks like Angular, React, and Vue.js, and those embracing minimalism, HTMX stands out as a beacon of hope. The cure of JavaScript fatigue and what REST actually should be, an “architectural style for distributed hypermedia systems”.

What is HTMX

HTMX, short for HyperText Markup eXtensions, is a JavaScript library that allows developers to build modern web applications using simple HTML attributes. It was created by Carson Gross, who envisioned a return to the simplicity of the early web, where HTML was king, and complexity was minimized.

Key Features

Interactivity Through HTML: HTMX leverages HTML attributes to handle AJAX requests, CSS transitions, WebSockets, and server-sent events. This approach reduces the need for complex JavaScript code, making development faster and more intuitive.
No Build Step: Unlike major frameworks that often require extensive build processes and toolchains, HTMX operates directly within the browser. This makes it ideal for rapid prototyping and smaller projects.
Progressive Enhancement: HTMX embraces the principle of progressive enhancement, allowing developers to add interactive features to existing web pages without a complete rewrite. This makes it a powerful tool for incremental upgrades.

See more on htmx.org

Origins and Philosophy

HTMX is inspired by the Hypermedia as the Engine of Application State (HATEOAS) concept from RESTful APIs. It was born out of a desire to simplify web development, reducing the reliance on heavy JavaScript frameworks. Carson Gross and the HTMX community advocate for a web where HTML, CSS, and a minimal amount of JavaScript can achieve dynamic, responsive interfaces.

The HTMX Hype

The minimalist approach of HTMX has struck a chord with a growing number of developers, especially Backend developers and Go Evangelists. No more huge JavaScript frameworks or libs, just HTML with some attributes. No more discussion about how the JSON output should look like, so the API can be consumed as convenient as possible but is sustainable and extendable. Some even question if JSON was ever a good direction for RESTful APIs.

Adding to its allure is the playful and often cheeky presence of HTMX on social media. The official HTMX Twitter account has gained a reputation for its witty and sometimes trolling tweets, engaging with the community in a humorous and relatable way. This not only adds to the hype but also humanizes the technology, making it more approachable and fun. The excitement around HTMX isn't just limited to developers in forums and social media. Big-name developers on YouTube, like ThePrimeTime and Theo - t3․gg, have given HTMX and its creator a stage, showcasing its capabilities and simplicity in their videos. Their endorsements have significantly amplified the buzz, introducing HTMX to a broader audience and validating its potential in the eyes of many in the web development community.

Conclusion

HTMX is carving out a niche in the web development world, challenging the dominance of traditional and heavy JavaScript frameworks with its minimalist philosophy. It offers a refreshing, but traditional approach for developers looking to simplify their workflows and create efficient, interactive applications without the bloat.

Whether you are a seasoned developer entrenched in the world of Angular, React, and Vue.js, or a newcomer seeking a simpler way to build, HTMX presents an intriguing option.

My Take on HTMX

Despite the growing buzz and its promising features, HTMX currently has a relatively small community. While the tight-knit community fosters innovation and direct support, it also means that best practices for essential aspects such as routing, templating/components, form validation, state handling, and inter-component event handling are not established yet.

An exciting development is the ongoing enhancement of HTML itself. As HTML continues to implement basic JavaScript use cases like accordions and dialogs, this would be a massive boost for HTMX, potentially expanding its capabilities even more and reducing the need for JavaScript for basic functionality.

However, given the current state of HTMX, I wouldn't recommend using it for large-scale projects just yet. The time spent creating concepts and solutions for HTMX might outweigh the benefits, especially when such solutions are readily available in major frameworks like Angular, React, and Vue.js.

That said, I am keenly watching the evolution of HTMX. It holds great revolting promise, and I will certainly be using it for small projects and prototyping.

How Instagram fails at jobs to be done

Vincent Romanus — Sun, 30 Apr 2023 10:26:37 +0000

If you're unfamiliar with the concept of "jobs to be done," it refers to the needs that people have that a product should fulfill. For example, the job of a spoon is to make it easy to consume soup, but it shouldn't be expected to provide Wi-Fi. Conversely, a negative example would be a coffee mug that leaks or is difficult to hold. If a product fails to fulfill its job to be done, it can result in user dissatisfaction and a decline in popularity. That's a pretty simplification, for a deeper dive you can watch Clay Christensen: The Jobs to be Done Theory.

In the case of Instagram, its job is to provide a platform for visual artists to showcase their work and for users to discover new artists whose style they enjoy. However, Instagram has shifted its focus to competing with platforms like Snapchat and TikTok, even though they fulfill completely different jobs. Instagram now requires creators to make short videos (Reels), similar to TikTok's. This move has alienated creators and compromised the platform's original job of being a creator and shared-interest platform.

Instagram shift has caused issues for creators and users alike. The algorithm is poorly designed, and Reels are often just reposts or screen captures of TikTok videos. Major updates often result in backlash from users and are eventually reverted. The shop feature is underutilized, and Instagram seems to be burning through money without understanding its job to be done.

While Instagram is currently too big to fail, it's also in a fragile state. By focusing on fulfilling its original job to be done as a creator and shared-interest platform, Instagram could re-engage creators and users and improve its overall functionality.