I expected a fast car. I didn’t expect one with ten compressed-air propulsion nozzles using SpaceX-derived technology, plus an underbody suction system capable, according to Elon Musk, of pulling up to 2 G. During the demo, Tesla announced zero to 60 miles per hour, nearly 97 km/h, in 0.81 seconds. It did not disclose the measurement protocol.

This is the future I wanted to see.

The entire demonstration is in Tesla’s official livestream. Road & Track measured and described the maneuvers, while TechCrunch detailed the three versions: Performance with active aerodynamics and suction, Thrust with rear thrusters, and Rocket with a ten-nozzle propulsion system and a single seat.

Of course, we watched a prototype in a controlled demonstration. Tesla expects production to begin in 2028, and the Rocket version is not approved for public-road use. Still, an actual car left the ground, rotated, and landed. I watched it live from my office. It was spectacular.

While Musk was landing rockets and making cars fly, I was doing something far smaller and more mundane: fiddling with my websites.

Six sites in about a day

Before the Tesla event, I spent the entire day redesigning six sites:

• Akita’s AI Lair, now matching the look of my new book, Competent Enough;
• ai-memory;
• ai-jail;
• The M.Akita Chronicles newsletter;
• the newsletter archive;
• and this blog, AkitaOnRails.com.

They all started with variations of that default theme Claude makes. Dark background, purple or blue gradient, huge sans-serif type, rounded cards, a glow behind something. It works. It has also become so common that you can spot a “site made by Claude” before reading the title.

I had already tried asking Claude for different designs. It changed the color, moved the cards around, and delivered the same visual grammar. I posted some screens and the result of the change on Twitter. I’m no web designer, and for a while I accepted “it works.” Yesterday I got tired of it.

Someone suggested Stitch by Google. It’s an experimental Google Labs tool that turns instructions and images into editable interfaces and front-end code. The first version launched in 2025 on top of Gemini; the current version has become a design canvas with an agent, prototypes, and export to a DESIGN.md that other agents can follow.

I signed up, got the API token, and went to work. Stitch generated visual directions. Claude Code and Codex brought those directions into the real repositories, adapted the components, fixed responsiveness, replaced images, adjusted SEO, tested, and deployed. When one quota ran out, I continued with the other.

The six sites come from five repositories. Looking at them side by side made one thing clear: Stitch responds much better when it receives a concrete metaphor, the audience, and what the product needs to communicate. ai-memory became a memory archive. ai-jail became a cinematic prison. AI Lair adopted a 1950s and 1960s world’s fair, drawn from my book cover. The newsletter became a late-night broadcast, and this blog became an editorial archive. Five different identities instead of five variations of Claude’s same gradient.

The pretty prototype is the easy part. The job only ends when the visual language reaches internal pages, the article, the book reader, email, legal pages, error states, and mobile. That’s what the agents did inside the repositories. On ai-memory, for example, verification covered 102 pages in six languages, light and dark themes, desktop and mobile. On The M.Akita Chronicles, the same design had to work across signup, archive, newsletter detail, podcast, and the email template. A Stitch mockup solves none of that by itself.

Each site went through several rounds of prototypes. Some looked awful. Others had one good idea surrounded by bad decisions. I told the agents to throw them away, preserve one part, mix it with another attempt, and start over. Code is cheap now, so there is no reason to fall in love with the first version.

The result won’t win a design award. A professional designer would still find hundreds of things to improve. I know I could take it further by spending a few more days. It looks much better than it did, though, and for now it is competent enough.

Six existing sites redesigned, responsive, with SEO, image generation and replacement, HTML, CSS, and JavaScript adjustments, testing, and production deployment. One person. About a day. A year ago, that package would have taken weeks or months.

Keep the scale in perspective: these are small sites, mostly landing pages and content pages. Nobody is rebuilding Amazon.com’s entire collection of pages and systems in a day. The experiment shows how much repetitive work has already moved out of the way within a scope that one experienced person can understand and review. Large projects remain large, full of private rules, old integrations, strange states, and decisions that do not fit in a prompt.

Even the first proofreading pass can be automated

As part of the same process, I had agents review the sites as different readers. This wasn’t grammar correction. I wanted to know what someone would understand in the first few seconds, where they would get lost, which promise would sound suspicious, and whether they could complete a task without already knowing the product.

On ai-jail, I used two isolated sessions. One played a skeptical engineer who approves every prompt and had never heard of the project. The other was a non-engineer managing eight developers, trying to decide whether to approve the tool for the company. On ai-memory, I used three: an engineer learning AI tools, a manager evaluating a pilot, and a parent with no agent experience who worried about AGI and jobs. Each one read the site without seeing the others’ reports.

Anyone can do the same thing. Run the application locally or open a preview deployment, start fresh sessions, and give each agent a concrete task. A basic prompt can look like this:

Open this site on desktop and mobile: [URL].

You are [persona], know [context], and have never seen this product.
Your goal is [specific decision or task].

Navigate as this person. Do not read code or internal documentation first.
Record:
- what you understood in the first ten seconds;
- what you think the product does and who it is for;
- where you did not know the next step;
- contradictory, absolute, or hard-to-believe promises;
- terms the site uses before explaining them;
- reading, keyboard, contrast, touch, and responsiveness problems;
- what would stop you from trying, buying, or approving it.

For every finding, show the page and visible evidence.
Separate factual bugs, usability problems, and subjective preferences.
Do not propose a broad redesign. Suggest the smallest change that solves the problem.

I prefer three independent sessions over an agent roundtable. Once one reads another’s report, it starts agreeing by inertia. A separate session can then consolidate repeated points, discard matters of taste, and check every claim against the code and product documentation. A review can flag a sentence as wrong; it has no authority to invent the right one.

The most useful results tend to fall into four groups: positioning, information order, path to the first action, and trust. Traditional automated tests still handle broken links, contrast, accessibility, overflow, and error states. The persona tells you that a technically accessible button appeared five screens below where the person needed it.

During the ai-jail proofreading, both profiles agreed that the site took too long to show a concrete risk and started speaking like engineering documentation too early. The threat of a poisoned page moved directly below the hero. New sections explained “What changes on day one” and “For the person who must approve this,” including operating cost, limitations, and the keys a company actually exposes. The review also caught a technically incorrect claim repeated across several pages: the network does not stay entirely off by default. The agent’s own API host and, on Linux, registries remain accessible. This kind of reading catches documentation bugs too.

The ai-memory report found permissions described in contradictory ways, privacy promises that were too absolute, and the basic explanation buried under advanced features. During the second round, the profiles noticed that remote-access instructions told users to use HTTP before requiring TLS, that an unauthenticated curl promised the wrong response, and that important choices appeared far too late on mobile. The collection guide moved from about 4,364 pixels from the top to 1,617; the individual and team paths moved from 5,300 to 2,489. That’s an objective improvement born from simulated reading.

In the AI Lair redesign, the new-reader review reorganized the entry path. A later revision made it explicit that my setup with multiple agents and two monitors is a mature configuration, not a requirement for starting. One person, one project, and one agent are enough. It also produced a pilot plan for managers: a reversible task, non-sensitive data, an acceptance criterion, deadline, budget, and measurement. The next audit found invalid ARIA and an animation that hid the opening copy from assistive technologies; the fix took axe-core from four serious violations to zero.

Simulated personas still fall far short of human feedback. They carry the models’ same biases, may agree with the prompt, never feel the irritation of someone who lost twenty minutes, and never take the risk of entering their own credit card. The reports serve as hypotheses. A real user will always find the case that I, the agent, and the test suite failed to imagine.

Before the first user exists, however, the alternative is usually no review at all. Two or three independent readings already catch contradictory promises, unexplained jargon, buried information, and a flow that only makes sense to its author. These readings cost little and make the product less stupid before it reaches actual people.

HTML was never programming

For years, I watched people perform some remarkable mental gymnastics to argue that “HTML is a programming language” and therefore anyone who writes HTML is a programmer.

HTML is markup: it describes a document’s structure. CSS describes presentation. That has value, requires knowledge, and can become terribly complex. Accidental complexity does not turn markup into programming.

There is no shame in that. I started building sites in the 1990s. I received a Photoshop layout and turned it into HTML. I sliced images, built tables, adjusted pixels, opened the result in multiple browsers, went back, and tried again. It was honest work and paid my bills.

It was also basically mechanical work: copy, paste, adjust, look, repeat. Exactly the category computers should automate.

Today I still chose the visual direction, rejected bad proposals, decided what each site needed to communicate, and recognized when the result was good enough. The agents handled the grunt work. This should have happened years ago.

The bubble delayed automation

For much of the 2010s, US interest rates stayed near zero. Cheap money flooded funds, startups, and large companies. Hiring more people was easy, and the market absorbed any amount of manual labor disguised as engineering.

Low rates explain only part of tech’s expansion. A field breaking hiring records has little incentive to eliminate its own repetitive work. If you can put fifty more people to work assembling screens, you put fifty more people to work assembling screens.

Anyone who attended my talks at tech events in the 2010s may remember Constraint == Innovation. Yes, the original title used two equal signs. I gave that talk at DevConf 2019, the 83 slides are on my SlideShare, and I had already written the same argument in 2013 in “Constraints are liberating: less is more”.

It’s the old maxim: necessity is the mother of invention. Constraints force choices. Choices force priorities. When the conventional path cannot fit the money, deadline, or available capacity, someone has to find another path. That’s where real innovation often comes from.

Money funds expensive research, buys equipment, and gives people time to experiment. Excess money without pressure for results does something else: it hides inefficiency with brute force. There is no need to automate, simplify, or discover a better solution while you can keep hiring and growing the spreadsheet. Too much abundance turns a technical problem into an operating expense and postpones the difficult decision.

I repeated this warning at the beginning of 2026: the programming bubble managed to replace efficiency with volume. Constraints returned when cheap money ended. Coincidentally, agents arrived at the same time and gave companies a practical way to automate the mechanical work they had spent a decade scaling through hiring.

That’s how we spent a decade recreating the same admin dashboard and calling it innovation. Every week brought the next front-end savior: React, Angular, Vue, Svelte, another bundler, another framework on top of the framework. They are useful tools in the right context, but none addressed the obvious question: why is a human still hand-writing the thousandth variation of the same form?

The hiring bubble burst in 2022 and ended the party. At the end of that year, ChatGPT brought language models to the public. GPT-2, just to keep the chronology straight, had come out in 2019. Four years after ChatGPT, agentic programming became a normal work tool.

Any task that consists of copying a pattern, adapting an example, running it, looking at the error, and trying again is already within these agents’ reach. Front-end is the most visible target because it accumulated an absurd amount of this work. The rest of programming has no mystical shield. Plenty of back-end work is CRUD, glue between APIs, and repetitive configuration. That will be automated too.

Fine by me. Programming was never about typing code. Programming is making a computer do something useful.

VS Code is the new punch card

I wrote about exactly this in April in “VS Code Is the New Punch Card”.

For decades, the interface between intention and computer kept changing. First you connected wires and switches. Then you punched cards. Then you wrote Assembly, C, high-level languages, frameworks, and configuration. Each generation looked at the previous one and automated another layer of manual work.

No sane person would argue today that operating a card punch was the essence of computer science. It was the available interface. Typing every tag and CSS rule into VS Code was also the available interface.

Now I describe the intention, show references, evaluate the result, and tell the agent to fix it. I still need to understand browsers, networks, caching, accessibility, semantics, responsiveness, and SEO. Without the fundamentals, I couldn’t tell whether the agent delivered a solution or a pretty time bomb. The keyboard lost importance; judgment gained it.

Today, every Tier A model I test, from Claude to Kimi, can reliably execute the mechanical front-end work that appeared in these six projects. I can say without hesitation that any front-end task that merely turns an already-made decision into code is automatable. They needed direction to create the six designs. None required me to hand-write the flexbox, breakpoint, or component I had already explained.

That covers an enormous share of the work while leaving the most valuable part. Someone still has to know the framework’s tradeoffs, understand the browser, choose the architecture, notice when a library is being forced against its design, and find out why an apparently correct solution breaks under a particular combination of device, language, state, and real data. The agent writes the code; an experienced professional provides direction, limits the damage, and owns the result.

Front-end still exists. The excess mechanical work and the people hired only to follow a finished recipe lose value. A great front-end professional can direct agents and deliver far more than they could alone. A mediocre professional who spent years mistaking component typing for engineering will compete for fewer openings. The market gets smaller and more selective, with its best professionals producing more. The goal remains what it always was: get close to the top, where judgment and experience still make a difference.

And it doesn’t stop at the browser. Pick the framework: Android with Flutter or Kotlin, iOS with Swift and SwiftUI, desktop with Rust/Tauri, Flutter, C#, or Electron. Modern agents generally know the components, build tools, tests, and peculiarities of these platforms. They still need direction, feedback, and verification, just as they do on the web front-end. The mechanical part is already automatable.

I tested this in my own small open-source projects. FrankYomik has a Flutter client for Android and Linux, plus the server and extension. Frank Sherlock is a Rust/Tauri desktop app that produces an AppImage for Linux, a DMG for macOS, and a .exe installer for Windows. I also built Frank Karaoke in Flutter for Android and FRANK MANGA+ in Rust/Tauri for desktop. There are several others on my GitHub.

None came out perfect from the first prompt. Flutter and Tauri gave me trouble, especially on the early projects. Reliable means the agent can move forward, receive a correction, create tests, fix what broke, and reach a working application without making me take over the manual typing. After testing web, Android, and desktop across different stacks, I’m very satisfied with the result. The pattern repeats: mechanical work became agent work.

At two in the morning, I had agents making the final adjustments to this blog without losing pace. That’s what I need.

When the web still didn’t know what it was

At the peak of the dot-com bubble, career designers were creating websites. The web had not yet decided how a page should work, so there was real room to experiment. It was often ugly and almost always heavy, but actual creation was happening.

The iPhone opened another window in 2007. Suddenly everything had to fit on a small screen, respond to touch, and work without a mouse. Years of experimentation followed before the market settled on a reasonably stable grammar for navigation, gestures, forms, and content.

Today nobody needs to rediscover a menu, a list, a checkout, or an article page. The patterns are documented, millions of examples are public, and models have seen more interfaces than any person could study in a lifetime.

The most valuable work remains: understanding the product, the person who will use it, the constraints, and what deserves to appear first. Converting a finished decision into hundreds of predictable lines has become a perfect candidate for automation.

Jobs disappear. Others appear

The world has never stopped to preserve a job function.

Punch-card operators entered data and programs on paper cards. Telephone operators physically connected calls. Typists kept offices running. Linotype operators cast lines of hot metal to print newspapers. Technology reduced or eliminated these occupations at scale. The Bureau of Labor Statistics’ current list of fastest-declining occupations still includes data entry keyers, typists, and telephone operators. Nobody proposes bringing them back to protect jobs.

At the same time, jobs appeared that a person in 1926 could not even name: mobile developer, SRE, experience designer, Internet video creator, cloud specialist, machine learning engineer. The web itself killed old work and opened an entire industry.

The real story is messier than the caricature. The ILO shows that technology tends to automate tasks without necessarily eliminating entire occupations. Some functions shrink, others change, and new jobs appear. That statistical consolation does nothing for the person who became obsolete today. The individual has to react before the economic average reacts for them.

Compare 2026 with 1926, three years before the crash of 1929. It looks like another planet, even though a century is very little on history’s scale. No contract guarantees that your current function will survive the next ten years, much less the next forty.

How does a junior gain experience now?

It will get harder. The old ladder began with someone paying a beginner to assemble simple screens, fix CSS, and copy components. An agent does much of that faster and cheaper. No company has an obligation to preserve inefficient work as a training program.

Beginners will have to build their own ladder with real projects and problems they are responsible for. That includes reading the code the agent generated, breaking and repairing it, studying documentation and source code, writing tests, and contributing to open projects. An agent gives any student access to an amount of practice that once required a team. Anyone who uses that access only to generate code they do not understand will remain a junior for a long time.

The market will reward people who make that extra effort. It always has. When someone asks how a junior can gain experience without the easy tasks, the hidden question is often different: “how do I get a better salary without doing the hard work of getting good?” The easy position, with rising pay and little pressure, was a distortion of the bubble. Adapting includes accepting that entry has become more competitive.

My career never stayed in one place

I started with multimedia and static websites. Then I worked in a digital agency, enterprise consulting, SAP integration, startups, video, education, and now AI. In my Akitando episode about SAP, I tell part of that phase when I had to learn a world completely different from what I had done before.

I lived through the dot-com crash, the 2008 crisis, and the end of the zero-rate bubble. I survived because I never treated my current function as a permanent identity. I kept studying, gaining experience, and changing direction.

A productive career should not consist of repeating the same mechanical task for decades. If your value depends on the market continuing to pay someone to push tags and pixels by hand, the problem did not begin with AI. The problem was betting that the present would last forever.

Many people understand “being prepared” as studying the bare minimum required for today’s open position. That’s the fastest recipe for becoming obsolete. Do the short-term work, but study beyond it. Learn the things that seem useless today. Fundamentals, operating systems, networks, databases, business, economics, history. You don’t know which combination will save your career five years from now.

I spent years talking about this on Akitando. Revisit the I Warned You and Which course should I take? playlists. If you have to start with one video, start with the Definitive Guide to Learning How to Learn. No course can save someone who still outsources their own learning.

The world has no shortage of opportunity. Most people feel they never get one because they are always unprepared when it appears. Once the opportunity lands in front of you, it is too late to start preparing.

So I won’t mourn the fact that this package of six small sites, which used to take weeks or months, fit into about a day. I’m happy as hell. I gained time to think about what to build, experiment more, and throw away bad versions without wasting weeks of my life.

Today I watched a car spin in midair and land. In about a day, I put six sites with new designs into production without writing most of the HTML and CSS. The future I wanted did not arrive perfect, cheap, or evenly distributed. It arrived far enough for me to work with it.

Accept what ended. Study what comes next. Be ready before the next opportunity appears.

And be sure to subscribe to my new newsletter The M.Akita Chronicles!

–

There’s an obsession in the market that frontend = React. Or Vue. Or Svelte. Or the framework of the week. What if I told you it’s possible to have a modern, responsive frontend with dark mode, email-compatible, multi-platform — without a single line of JavaScript framework?

I’m not talking about static sites from the 2000s. I’m talking about Tailwind CSS v4 on Rails, Hugo with the Hextra theme for the blog, and email templates that work from Gmail to Outlook 2016. All in the same project, with one developer.

Tailwind CSS v4: The End of Handcrafted CSS

I have a confession: CSS has always been my kryptonite. Not because it’s hard — but because it’s unpredictable. You change a margin-top and break the layout of a page you never touched. Cascade, specificity, inheritance — it’s a minefield.

Tailwind solves this in the most pragmatic way possible: utility classes right in the HTML.

<div class="flex items-center gap-4 p-6 bg-white dark:bg-gray-800
            rounded-xl shadow-sm border border-gray-200 dark:border-gray-700">
  <img class="w-12 h-12 rounded-full" src="/images/avatar.jpg">
  <div>
    <h3 class="font-semibold text-gray-900 dark:text-gray-100">Título</h3>
    <p class="text-sm text-gray-500 dark:text-gray-400">Descrição</p>
  </div>
</div>

“But this is just inline style with extra steps!” — No, it isn’t. It’s a design system with constraints. You don’t pick “margin: 17px” — you pick m-4 (16px) or m-5 (20px). That constraint forces visual consistency without needing a design system documented across 40 pages.

And Tailwind v4, which came to Rails via tailwindcss-rails, has a fundamental change: CSS-first configuration. No more tailwind.config.js. Everything is CSS:

@import "tailwindcss";

@theme {
  --color-brand: #8b5cf6;
  --font-sans: "Inter", system-ui, sans-serif;
}

One less config file. One less build step. Simpler.

Dark Mode: Respect Your User

Something that deeply annoys me is a site that ignores the operating system’s theme preference. The user set dark mode on the OS — respect that.

With Tailwind, dark mode is trivial:

<body class="bg-white dark:bg-gray-900 text-gray-900 dark:text-gray-100">

The dark: prefix applies the style when the operating system is in dark mode (via prefers-color-scheme: dark). No JavaScript needed. No toggle needed. No cookie needed. It works.

But “it works” is the bare minimum. The real challenge is maintaining consistency across dozens of components. Every color you use needs a dark: variant. Every background, every text, every border.

The trick: create conventions and follow them. Main background? bg-white dark:bg-gray-900. Primary text? text-gray-900 dark:text-gray-100. Secondary text? text-gray-500 dark:text-gray-400. Borders? border-gray-200 dark:border-gray-700. With 4-5 pairs defined, 90% of components are covered.

Hugo + Hextra: Blog Without a Database

The project’s blog runs Hugo with the Hextra theme. Hugo is a static site generator written in Go — absurdly fast. A full rebuild in <500ms even with dozens of pages.

What makes Hextra special is that it’s a documentation theme adapted for blogs. Navigation sidebar, integrated search, table of contents — everything ready. And customizable via partial layouts:

layouts/
├── _partials/
│   ├── custom/
│   │   └── head-end.html          # Injects analytics, fonts, custom CSS
│   └── section-box.html           # Shared partial (DRY, see below)
├── blog/
│   └── home.html                  # Custom homepage
├── newsletters/
│   └── single.html                # Individual newsletter template
├── podcast-transcripts/
│   └── list.html                  # Episode listing
└── shortcodes/                    # 17 shortcodes — components without JS
    ├── podcast-turn.html          # Speech bubble in the transcript
    ├── akita-comment.html         # Akita's comment
    ├── marvin-comment.html        # Marvin's comment
    ├── history-timeline.html      # Historical events timeline
    ├── market-ticker.html         # Financial tickers table
    ├── market-map.html            # FinViz S&P 500 map
    ├── subscribe-cta.html         # Subscription call-to-action
    ├── score.html                 # Relevance badge (high/medium/low)
    ├── holidays.html              # Holidays and commemorative dates
    ├── ref-stories.html           # Reference links
    ├── book-downloads.html        # Book download links
    ├── hacker-news.html           # ┐
    ├── anime-ranking.html         # │ Section boxes — delegate to
    ├── youtube-digest.html        # │ section-box.html (see below)
    ├── world-events.html          # │
    ├── market-news.html           # │
    └── qa.html                    # ┘

Each content type has its own template. Newsletters have a navigation sidebar and visual sections. Podcast transcripts have an embedded player and dialogue formatting. The same Markdown content is rendered differently depending on the type in the frontmatter.

Shortcodes: Components Without JavaScript

Hugo shortcodes are the equivalent of React components, but without a build step:

<!-- layouts/shortcodes/podcast-turn.html -->
{{ $speaker := .Get "speaker" }}
{{ $isAkita := eq $speaker "akita" }}

<div class="podcast-turn" style="display: flex; {{ if $isAkita }}flex-direction: row{{ else }}flex-direction: row-reverse{{ end }};">
  <img src="/images/{{ $speaker }}.jpg"
       style="width: 40px; height: 40px; border-radius: 50%;">
  <div class="bubble {{ if $isAkita }}akita-bubble{{ else }}marvin-bubble{{ end }}">
    {{ .Inner | markdownify }}
  </div>
</div>

In Markdown, the author writes:

{{< podcast-turn speaker="akita" >}}
Então, vamos falar sobre o que aconteceu essa semana no mundo tech...
{{< /podcast-turn >}}

And Hugo renders a styled chat bubble, with avatar, correct alignment, and processed markdown. Zero JavaScript. Zero framework. HTML + CSS + template logic.

DRY With a Shared Partial

With 17 shortcodes, duplication becomes a problem fast. Seven of them — the “section boxes” that wrap newsletter sections (Hacker News, Anime, YouTube, etc.) — have the same visual structure: icon, title, colored border, Markdown content. Only the color and label change.

The solution is a shared partial that takes parameters:

<!-- layouts/partials/section-box.html -->
<div class="section-box {{ .class }}">
  <div class="section-box-header">
    <span>{{ .icon }}</span> {{ .label }}
  </div>
  <div class="section-box-content">{{ .content | markdownify }}</div>
</div>

And each shortcode becomes a one-liner:

<!-- layouts/shortcodes/hacker-news.html -->
{{ partial "section-box" (dict "class" "hacker-news" "icon" "&#128274;" "label" "The Hacker News" "content" .Inner) }}

It’s the Hugo equivalent of component inheritance: a polymorphic partial parameterized by dict. The CSS in custom.css defines colors per class (.hacker-news, .anime-ranking, etc.) with light/dark variants. Result: 7 shortcodes that used to have duplicated HTML are now 7 lines + 1 partial + CSS.

But there’s a crucial catch: shortcodes are exclusive to Hugo. The same content that goes to the blog also goes out by email. And email doesn’t understand shortcodes.

The Challenge: Same Content, Two Renders

Here’s the central frontend problem in this kind of project: the same Markdown file needs to work in two completely different contexts.

On the blog (Hugo):

• Shortcodes work (\{\{< subscribe-cta >\}\})
• CSS with classes (Tailwind, Hextra)
• Dark mode via prefers-color-scheme
• Responsive images
• Flexible layout

In email (Rails → Amazon SES):

• Shortcodes are dead text — they have to be removed
• CSS must be inline (many email clients ignore <style>)
• Dark mode? Forget it for 80% of clients
• Images with absolute URLs and fixed size
• Layout with <table> (yes, in 2026)

The solution: two independent rendering pipelines. The Markdown content is the source of truth. Hugo transforms it for the web. Rails transforms it for email. Each one with its own rules.

On the Rails side, the MarkdownToHtml service needs to:

1. Process standard Markdown
2. Convert \{\{< shortcode >\}\} into equivalent HTML or strip them — via a SHORTCODE_PATTERNS hash that maps each shortcode to a regex + inline template with CSS
3. Apply the theme (light/dark based on the subscriber’s preference)
4. Inject inline CSS for email client compatibility
5. Rewrite image URLs to absolute

It’s more work than it sounds. Each shortcode needs an email-safe equivalent. Comment avatars need absolute URLs. Sections with colored backgrounds need <td style="background-color:..."> instead of CSS classes.

Email HTML: The Worst Frontend in the World

If you think cross-browser compatibility is hard, try cross-email-client compatibility. Outlook 2016 renders HTML using the Microsoft Word engine. Yes, Word. That’s not a joke.

The survival rules:

1. Layout with <table>. display: flex? grid? They don’t exist in Outlook.
2. Inline CSS on every element. <style> tags are ignored by several clients.
3. No margin on images. Use padding on the parent <td>.
4. Web fonts don’t work. Use a font stack: font-family: -apple-system, BlinkMacSystemFont, 'Segoe UI', sans-serif;
5. Themes are a subscriber preference, not automatic detection — many email clients don’t reliably support prefers-color-scheme.

The project’s email template is an ERB that takes theme variables:

<td style="padding: 8px 28px; color: <%= @theme[:text] %>;
           background: <%= @theme[:card_bg] %>;">
  <%= raw @content %>
</td>

The theme defines all the colors:

THEMES = {
  light: {
    text: "#1a1a1a",
    card_bg: "#ffffff",
    link_color: "#7c3aed",
    # ...
  },
  dark: {
    text: "#e6edf3",
    card_bg: "#161b22",
    link_color: "#a78bfa",
    # ...
  }
}

Each subscriber picks their theme at signup time. The email is rendered with the correct colors for that person. No media queries, no automatic detection — because email clients don’t support it reliably. It’s simpler to give the user the choice.

Color Palette: HSL and the Science Behind the Choices

“But how did you pick these colors?” — Not by eyeballing it. There’s a science behind it, and it’s called HSL (Hue, Saturation, Lightness).

Most developers think about color as hex (#e8eef8) or RGB (rgb(232, 238, 248)). Those are machine formats — useful for rendering, useless for designing. When you look at #3b50a2 and #c93030 side by side, there’s no way to intuitively know if they’ll work together. They’re just numbers.

HSL solves this. Instead of mixing light channels (Red, Green, Blue), you describe color in human terms:

• Hue: the position on the color wheel, from 0° to 360°. Red = 0°, green = 120°, blue = 240°.
• Saturation: how “vivid” the color is. 0% = gray, 100% = pure color.
• Lightness: how light or dark. 0% = black, 100% = white.

With HSL, you control each dimension independently. And that’s where building the palette comes in.

Step 1: Distribute Hues Around the Color Wheel

The newsletter has 8 section types, each with its own color. For all of them to “belong” visually to the same project, the hues are distributed evenly around the 360° wheel:

Eight hues spaced around the wheel. That’s not random — it’s the same logic as a polychromatic palette in color theory. When hues are equidistant, the human eye perceives harmony even with completely different colors. It’s the same principle artists have been using with a 12-color wheel since the 18th century.

Step 2: Lock Saturation and Lightness Per Layer

Here’s the trick that makes it all work together. Each visual “layer” (background, text, border) has fixed saturation and lightness — only the hue changes:

Light theme:

• Backgrounds: ~92-95% lightness, moderate saturation. With lightness that high, even different saturations result in pastel colors with similar visual weight — no section “screams” louder than another.
• Text: ~15-20% lightness. Dark enough to guarantee >7:1 contrast ratio against the light background (above the WCAG AAA minimum of 7:1).
• Borders: ~45-55% lightness. The chromatic accent — visible but not dominant.

Dark theme:

• Backgrounds: ~10-12% lightness. Uniform depth — every section has the same “darkness”.
• Text: ~80-85% lightness. Light enough for >6:1 contrast ratio on the dark background.
• Borders: same lightness range as in the light theme — they work as accents in both contexts.

In practice, this means generating the dark variant of any color is mechanical: keep the hue, invert the lightness. A background that was 94% becomes 11%. Text that was 18% becomes 83%. That’s not design — it’s arithmetic.

Step 3: Check Contrast (WCAG)

Pretty colors nobody can read are worthless. The WCAG standard (Web Content Accessibility Guidelines) defines minimum ratios:

• AA: 4.5:1 for normal text, 3:1 for large text
• AAA: 7:1 for normal text, 4.5:1 for large text

The light backgrounds at ~95% lightness against text at ~20% lightness give a ratio >7:1 — WCAG AAA. The dark backgrounds (~11%) against light text (~82%) give >6:1 — comfortably WCAG AA, near AAA.

This isn’t altruism. Low-contrast email is harder to read, generates less engagement, and in extreme cases is flagged by email clients’ accessibility filters.

The Result

When you open the newsletter and see the Hacker News section (purple), followed by YouTube (red), followed by Anime (blue) — they look like “the same project” despite being completely different colors. That’s HSL at work: different hues, same saturation, same lightness. The eye perceives coherence without knowing how to explain why.

And the best part: adding a new section is trivial. Pick a hue that isn’t taken on the wheel, apply the same saturation/lightness rules per layer, and the new section automatically “belongs” to the existing design.

# The comment in the code sums up the rules:
# - Hues evenly spaced: blue 210, green 140, sepia 35, amber 45, royal 225, purple 270, red 0, teal 180
# - Light backgrounds: ~95% lightness, ~25% saturation
# - Light text: ~20% lightness (>7:1 contrast ratio on light bg)
# - Dark backgrounds: ~10-12% lightness
# - Dark text: ~80-85% lightness (>6:1 contrast ratio on dark bg)
# - Borders: ~45-55% lightness

Six rules. Eight hues. Two themes. 100% deterministic. Zero subjective “I think this blue looks pretty” decisions — it’s a design system derived from geometric properties of the HSL color space.

Well-Formed HTML: The Spam Filter Nobody Tells You About

Everything I described above — tables, inline CSS, font stacks — solves the rendering problem. But there’s a second reason to follow these rules that most developers ignore: email providers analyze the quality of your HTML to decide if it’s spam.

Gmail, Outlook, Yahoo — all of them run your email’s HTML through heuristics before showing it to the user. Malformed HTML is one of the classic spam signals. It makes sense: spammers don’t test templates. They spit out broken HTML generated by cheap mass-mailing tools. If your email looks like spammer output, it gets treated as spam.

The signals that trip filters:

1. Unclosed or improperly nested tags. A <div> that opens and never closes, or a </td> before the </tr>, is an immediate flag. Providers expect HTML that parses without errors — not HTML “that the browser fixes up”.
2. Unbalanced image-to-text ratio. An email that’s basically a giant image with little text? Classic spam. Providers want to see real text — not text inside images. The rule of thumb is to keep at least 60% text, 40% images.
3. Missing alt attribute on images. Beyond accessibility, an empty or missing alt is a sign of carelessness — and carelessness correlates with spam. Every <img> needs a descriptive alt.
4. CSS that hides content. display: none, visibility: hidden, font-size: 0, text the same color as the background — those are classic keyword stuffing techniques. Even if you use them legitimately for responsive email, the filter doesn’t know the difference.
5. Excessively heavy HTML. An email with 500KB of HTML raises suspicion. Keep it light — the actual content rarely needs more than 100KB of HTML.
6. Links with text that doesn’t match the href. <a href="https://site-real.com">https://site-falso.com</a> is textbook phishing. Even subtle discrepancies (domain in the text different from the domain in the link) are penalized.

The point that ties it all together: the same practices that make email render correctly in Outlook are the ones that keep your emails out of spam. Tables with clean structure? Well-formed HTML. Inline CSS on every element instead of hacks with <style>? No hidden CSS. Images with explicit dimensions and alt text? Legitimate content.

It’s no coincidence. Email providers calibrated their filters by watching what spammers do — and spammers do exactly the opposite of well-built HTML email. When you follow best practices for compatibility, for free you’re also signaling legitimacy to spam filters.

The practical lesson: treat your email’s HTML as if it were an XML document. Validate, test, and make sure every tag opens and closes in the right order. Use tools like Email on Acid or Litmus to test in multiple clients — they also report spam scoring issues. And resist the temptation to copy ready-made templates from the internet without validating them — many are a disaster of malformed HTML that slips past Gmail but gives Outlook a heart attack and gets Yahoo’s spam filter to flag you as suspicious.

RSS Feeds: The Forgotten Frontend

A detail web developers ignore: RSS is a frontend. Podcasts on Spotify and Apple Podcasts are consumed via RSS. The feed needs:

• Valid XML (podcast parsers are strict)
• Complete metadata (title, description, duration, file size)
• Image URLs that actually work (Spotify validates them)
• Cover art with minimum dimensions (1400×1400 for Spotify)
• Unique GUIDs per episode

Hugo generates RSS automatically, but the default template doesn’t have the fields podcast platforms require. A custom template with iTunes tags is necessary:

<itunes:duration>{{ .Params.duration_seconds }}</itunes:duration>
<itunes:image href="{{ .Params.cover_image | absURL }}"/>
<enclosure url="{{ .Params.audio_url }}"
           length="{{ .Params.file_size }}"
           type="audio/mpeg"/>

The Philosophy: Content First, Framework Never

The pattern that emerges from this whole setup is: content is sovereign. Markdown with YAML frontmatter is the universal format. Each frontend (blog, email, RSS, podcast player) consumes the same content and renders it its own way.

There’s no “React component that fetches data from an API”. There’s a Markdown file read by whoever needs it. This is radically simple — and radically powerful. Swap the blog engine from Hugo to something else? Change the templates, the content stays the same. Swap the email provider from SES to Sendgrid? Change the mailer, the templates stay the same.

It’s the Unix philosophy applied to frontend: each tool does one thing well, connected by a universal format (Markdown + YAML).

Conclusion

You don’t need React to have a modern frontend. Tailwind v4 gives you a design system with constraints, native dark mode, and zero JavaScript. Hugo gives you an absurdly fast blog with flexible templates. ERB with inline CSS gives you emails that work in any client.

The real investment is understanding the constraints of each platform and building rendering pipelines for each one. The payoff comes from that, not from learning the trendy framework that’ll die in 18 months.

At the end of the day, the best frontend abstraction is none at all. HTML, CSS, and Markdown. Simple, debuggable, and going to work 10 years from now.

Rails 5.2 Beta is almost upon us, and I would bet that most of the Rails projects out there are in the 4.2 version, still thinking about doing the jump to 5.0 (which is not so bad an upgrade).

By the way, in case you didn’t know, the official Rails Guides website has a section dedicated to upgrades. It’s called A Guide for Upgrading Ruby on Rails. The process of upgrading is not actually so difficult if, and only if:

• You have a fairly good test coverage. You should have, at the very least, feature specs for the most important parts of your system.

• You should upgrade to just one subsequent version at a time, never going straight to the most recent one. For example, If you’re in Rails 4.1, you must first upgrade to 4.2, make sure everything works. Then go to 5.0. And only then go to 5.1. Each version has many deprecations, changes in behavior, changes in default boilerplate configuration, added new features. You must attend to each very carefully.

So, what are you missing if you’re still in Rails 4.2?

Again, in case you didn’t know, the official Rails Guides website also compiles detailed and easy to read Release Notes for each new version. The most recent are the Ruby on Rails 5.1 Release Notes.

Starting a new project

The rails new command has a lot of new flags. And I think these are the ones most people will use:

rails new --skip-action-mailer --skip-coffee --webpack=react my_fancy_new_project

You can disable features you don’t need such as ActionMailer or ActionCable. You can disable CoffeeScript. It was cool for a while but now that ES6 exists we should just use it.

Rails 5.1 comes with the support for webpack. But until Rails 5.2 comes up, we need to use the webpack-dev-server manually in development mode so we can hot reload assets. For that end, I recommend installing good old Foreman. Install it like this:

gem install foreman

And add a Procfile.dev file to your project with the following content:

web: ./bin/rails s -b 0.0.0.0 -p 3000
webpack: ./bin/webpack-dev-server

And now you can start up your development server like this:

foreman start -f Procfile.dev

In production, you don’t need the webpack-dev-server as the bin/rails assets:precompile task should be able to compile all the assets you need as static, timestamped files in public/assets.

Front-end Specific Changes

Now, you can rejoice with Yarn, Webpack, and no more jQuery pre-installed. Samuel Muller has a nice article that summarizes most of these changes in more detail.

Now Ruby on Rails officially supports every bell and whistle from the Javascript ecosystem. There is nothing left behind that you might miss.

No more manually vendoring JS assets in vendor/assets/javascripts directory. No more need to use Rails Assets, which was a secondary RubyGems source specific to package JS libraries into RubyGems.

Let’s say that, for some reason, you want jQuery back. You can now just do:

yarn add jquery

And, as usual, you can simply add it to your app/assets/javascripts/application.js manifest file:

// app/assets/javascripts/application.js
...
//= require jquery
...
//= require_tree .

The so-called “support for Yarn in Rails 5.1” boils down to a few wrappers and boilerplate. So you can run rails yarn:install and have the dependencies installed, but you can just as easily type yarn and it will install everything you need that is declared in the package.json file, as with any other Javascript-only project.

Now, the whole magic of the integration comes from the inclusion of the Webpacker gem. It adds a bunch of boilerplate configuration for webpack. And, bonus fact you can include it today in your current Rails 4.2+ projects as well. Just start by adding the webpacker gem to your Gemfile:

# Gemfile
gem 'webpacker', '~> 3.0'

Then bundle install as usual and run:

bundle exec rake webpacker:install

If you didn’t use the --webpack=react flag to the rails new command, you can add it later. Or you can add Angular as well:

bundle exec rake webpacker:install:angular
bundle exec rake webpacker:install:react 

You should replace bundle exec rake for bin/rails if you’re in Rails 5.1.

Adding proper React components is a bit more than the command above though. And the details are more than I want to cover in this post.

Andy Barnov has a good post on how to follow the Rails 5.1 packs convention to add your React components in the pipeline. As he recommends, don’t fight the conventions and you should be golden.

Oddly enough, even though I used the --webpack-react flag to the rails new I still had to run the following command to bootstrap the webpack and react supports:

./bin/rails webpacker:install:react

But once you do, you will get a new place to add React components, and that’s in a proper app/javascripts/packs. And in the views, instead of the usual javascript_include_tag you will use the brand new javascript_pack_tag. I believe you can figure out the rest from the example component hello_react.jsx that it generates for you.

Final Thoughts

You now have a whole lot more options for Javascript, as Rails 5.1 fully embraces the current standards.

Once upon a time, no one properly knew how to streamline an Asset Pipeline. It was very messy to compile all your assets in a single file with proper cache busting timestamps, but the Sprockets gem did it.

Once upon a time, Javascript 5 was a damn mess. Libraries such as jQuery actually “fixed” most of the browser DOM situation, and CoffeeScript normalized the language in a way that made it enjoyable. ES6 came to take over the reins but it’s very unfair to criticize jQuery and Coffee as neither ES6 nor HTML5 were there to solve the situation almost 10 years ago. jQuery and Coffee were there, and they solved it.

When Angular, Ember, and React were starting, we already had a good enough solution for javascript-heavy websites with Turbolinks. This is still a very good solution that you should consider using instead of adding a full-blown (and sometimes unnecessary) React/Redux solution at once.

CSS is another matter entirely. The Rails community also created Sass (which then Twitter envied and copied to Less for the Bootstrap framework).

It’s easy to see the current landscape and just repeat that Coffee is bad or Sprockets is bad. But for the past 10 years, those tools were the best of breed in a time where people didn’t have Yarn, Webpack, React and all the tools that popped up in the past 3 years or so.

Rails 5.1 is a very good release to marry the best of Rails with the best that kinda stabilized today in the Javascript mad arena. And I highly recommend that any new, greenfield project, start with Rails 5.1 in mind.

One thing that led me to write this post is to highlight that many people ask questions that are mostly answered in the official Rails Guides. Not only on how to install and use the many components of the framework but also how to upgrade and what the new features of each release are. So you should definitely take a better look there.