DEV Community: Jhonathan Reis

What's the most annoying 'small' interactive feature you've had to add to a server-rendered page?

Jhonathan Reis — Wed, 28 Oct 2026 15:32:20 +0000

Every server-rendered app eventually gets a ticket like this:

Small UI tweak. When the user checks "Same as billing address", hide the shipping fields. Should be quick!

The page is HTML from the server. It works. It has worked since before some of your coworkers were born. And now it needs to do one small thing in the browser.

Then you discover that "one small thing" also needs to:

remember its state when validation fails and the server re-renders the form,
not break the old jQuery plugin on the same page,
still work when the user presses Back,
be accessible,
and somehow not need a build step, because this part of the app has never had one.

So I'm curious: what's the most annoying "small" interactive feature you've had to add to a server-rendered page?

My nominees

To get things started, here are a few I think deserve an award:

🏆 The "Same as billing address" checkbox. Hide fields, copy values, un-copy values when they uncheck it, and remember all of it after a failed submit. Small, they said.

🏆 The character counter. "142 / 280". Easy, until emoji count as two characters, the server counts differently than the browser, and someone pastes a whole novel.

🏆 Dependent dropdowns. Pick a country, then the region list changes. Pick a region, then the city list changes. Now edit an existing record and make all three load correctly in the right order.

🏆 "Select all" on a paginated table. Does "all" mean this page or every page? Nobody knows, including the person who wrote the ticket.

🏆 The live search filter. Type, the list narrows. Then: debounce it, highlight matches, show "no results", and keep the filter in the URL so people can share it.

🏆 "Are you sure you want to leave? You have unsaved changes." The one feature everyone wants until it shows up after they've just saved.

My own entry

Tell me yours

I'd love to hear:

What was the feature?
What made it harder than it looked? The state? The old code around it? The browser's Back button?
What did you end up using? Vanilla JS, jQuery, a small library, a framework, or "a 400-line file named utils2.js that nobody touches"?

Bonus points for the worst ticket title you've ever received.

My learning project became a JavaScript framework: Brio.js v5

Jhonathan Reis — Wed, 28 Oct 2026 15:24:08 +0000

On February 12, 2024, I committed a file with the message:

A not so good scope architecture

Five days later, the next commit said:

New scoping system

That's the most honest summary of how Brio.js was built. I wrote something, I learned why it was wrong, and I wrote it again. I did that a lot, for fun and to learn how the frameworks I used every day actually work.

At some point the "learning project" quietly started running in one small production project of mine. Then it got tests. Then docs. Then a playground, a starter CLI, and a website with a small creature on it (we'll get to the creature).

This week I released Brio.js v5 and made the whole thing public. This post is the "hello, here's what I've been doing in my free time" post.

What Brio is

Brio adds reactivity to HTML with b-* attributes. It works on the real DOM, in place. No virtual DOM, no JSX, no required compiler, and no runtime dependencies.

Here's the smallest useful Brio app. You can save it as a file and open it from any static server:

<div id="counter" b-cloak>
  <button b-on-click="$data.count++">
    Count: <span b-text="$data.count"></span>
  </button>
</div>

<script src="https://cdn.jsdelivr.net/npm/@jnreis/briojs@5.1.1/dist/brio.min.js"></script>
<script>
  brio.createApp({ state: () => ({ count: 0 }) }).mount('#counter');
</script>

(Add <style>[b-cloak] { display: none; }</style> so the button doesn't flash before Brio starts.)

That's it: one script tag, one mount, and a button that counts. If you want a build setup instead, npm create brio@latest gives you a starter.

Meet the creature

Every framework website needs a demo. Most use a todo list. I made a small creature with feelings.

You pick a mood, a color, a size, and a name, and the creature updates as you go. There's also a 🎲 Surprise me button, because it's fun.

Here's a trimmed version of the real markup from the homepage. The horns only exist while it's being mischievous:

<div role="img" b-bind-aria-label="$data.greeting"
  b-bind-class="['creature', 'is-' + $data.mood]"
  b-bind-style="{ '--body': $data.color, '--size': $data.size / 100 }">
  <span class="creature-zzz" b-if="$data.mood === 'sleepy'">z z z</span>
  <span class="creature-horns" b-if="$data.mood === 'mischievous'"></span>
  <span class="creature-eyes"><i></i><i></i></span>
</div>

<label><input type="radio" name="mood" value="sleepy" b-model="$data.mood"> 😴 Sleepy</label>
<input type="range" min="70" max="130" b-model.number="$data.size">

And the greeting is just a getter on the state:

get greeting() {
  const name = this.name.trim() || 'This creature';
  if (this.mood === 'sleepy') return `${name} needs a nap.`;
  if (this.mood === 'mischievous') return `${name} is up to something.`;
  return `${name} is having a great day.`;
},

The best part: the playground opens with this exact creature. You can edit its HTML, CSS, and JavaScript and see the changes right away. Give it a fourth mood. Give it a hat. I won't stop you.

Three things I'm excited about

1. Every value says where it came from

In Brio templates you write $data.count, $props.label, or $for.item. Not count, label, or item.

Yes, it's a little more typing. I went back and forth on this for a long time. It became a deliberate breaking change in 4.0, because once lists and components were nested inside each other, "where does item come from?" stopped being a fun puzzle. Now you can read any expression and know which drawer to open. (There's a whole post coming on this decision.)

2. It only owns what you mount

You can mount Brio around one form in a Rails view, one menu in a WordPress theme, or one calculator in an old PHP page. It doesn't care what's around it, and it won't touch anything outside the element you gave it. When the widget is removed, it cleans up after itself.

That's the use case Brio was born from, and the one I care about most: adding interactivity to pages that already exist, without asking the rest of the page to change.

3. It grows with you

It starts with a single counter, but it doesn't stop there:

Five starters from npm create brio: widget, multi-page, SPA, Astro islands, and plugin.
Optional add-ons for routing, HTTP, persistence, extra inputs, and observers. You load only what you use.
A public plugin API for your own directives and helpers. I moved some of Brio's own features out of the core into add-ons built on that same API, partly to prove it works.
Parts: copy-paste dialog, disclosure, menu, and tabs components you own and can change.
Ten example apps, from a counter to a TodoMVC, a 1,000-row table, a Kanban board, and a collaborative editor.
Integration guides for Rails, Laravel, Django, WordPress, and plain HTML with Express.

There are 36 directives in total, and 1,258 tests that are much stricter with me than I am with myself.

What it's not good at (yet)

I'd rather you hear this from me than find out an hour into trying it:

Strict CSP needs a separate build. The standard build uses new Function, which a policy that forbids unsafe-eval blocks. Since 5.1 there's a CSP build (@jnreis/briojs/csp) that runs without eval. It hydrates only components defined in JavaScript, so plain page markup stays inert.
Server-side rendering. Brio enhances HTML your server (or Astro) already rendered. It doesn't render on the server itself.
Old browsers. It targets modern evergreen browsers.
It's young, and it's one person. I'm the only maintainer. The ecosystem is the docs, the examples, and whatever you and I build next. If you need a big community and long-term guarantees today, that's a fair reason to wait.

Why share it now?

Because I've reached the point where I can't see its flaws anymore. I know where everything is, so everything feels obvious. That's exactly when you need people who don't know where everything is.

So here's my ask, and it's a small one:

Open the playground, break the creature, and tell me what confused you.
Answer this in the comments: if you had to add interactivity to one part of a page you already have, what would it be? A filter? A form that shows and hides fields? Something weirder?

Every answer helps me decide what to write about and build next.

Links:

Website: briojs.com
Playground: briojs.com/play
GitHub: github.com/jnreis/briojs
Discussions: Say hi or ask anything

Thanks for reading. Bean says hi. Bean is also asleep.

Unlock Your Developer Potential: How to Apply Atomic Habits to Your Software Development Journey

Jhonathan Reis — Fri, 06 Sep 2024 15:47:03 +0000

As software developers, we're constantly navigating a landscape of evolving technologies, complex problems, and tight deadlines. In this high-pressure environment, it's easy to lose sight of our long-term growth. Recently, I discovered a powerful framework for personal development in James Clear's book, "Atomic Habits." While not specifically aimed at developers, its principles offer a transformative approach to enhancing our skills, productivity, and overall effectiveness as software professionals.

In this article, we'll explore how to apply these concepts to our daily work, turning small, consistent actions into significant improvements in our coding practices and career trajectories. Whether you're a seasoned developer or just starting your journey, these strategies can help you unlock your full potential and navigate the ever-changing world of software development with confidence and purpose.

The Power of Incremental Improvements

Clear's central thesis is that tiny, consistent changes can lead to remarkable results over time. This concept aligns perfectly with the iterative nature of software development. Here's how we can apply it:

Daily Code Refactoring: Dedicate 15 minutes each day to improving a small section of your codebase. This could involve optimizing an algorithm, breaking down a complex function, or improving variable names for clarity.
Continuous Learning: Commit to learning one new feature, method, or best practice in your primary programming language or framework each week. Over a year, that's 52 new tools in your developer toolkit.
Documentation Habit: End each coding session by writing or updating documentation for the code you've just written. This not only helps your future self but also improves team collaboration.
Version Control Mastery: Practice using advanced Git features daily, such as interactive rebasing or creating focused, atomic commits.

By consistently applying these small improvements, you'll see a compound effect on your code quality and professional growth over time.

Focus on Systems, Not Just Goals

While setting goals is important, Clear argues that the real power lies in creating systems that lead to consistent progress. In software development, this translates to:

Robust Code Review Process: Implement a structured code review system where team members regularly review each other's code. This could involve pair programming sessions, asynchronous reviews, or dedicated code review meetings.
Comprehensive Coding Standards: Develop and regularly update a set of coding standards that cover not just syntax preferences, but also architectural principles, performance considerations, and security best practices.
Automated Quality Checks: Set up a suite of automated tools that run on every commit or pull request. This could include linters, static code analyzers, test coverage reports, and performance benchmarks.
Continuous Integration/Continuous Deployment (CI/CD): Implement a robust CI/CD pipeline that automates testing, integration, and deployment processes, ensuring that every change is thoroughly vetted before reaching production.
Regular Retrospectives: Schedule periodic team retrospectives to reflect on processes, identify areas for improvement, and celebrate successes.

By focusing on these systems, you create an environment that naturally fosters high-quality code and continuous improvement.

Design Your Development Environment

Clear emphasizes the significant impact our environment has on our habits. For developers, optimizing our workspace can lead to dramatic improvements in focus, productivity, and job satisfaction:

Customized IDE Setup: Invest time in configuring your integrated development environment. This includes setting up syntax highlighting, code completion, and shortcuts that match your workflow.
Ergonomic Workspace: Create a comfortable physical environment with proper lighting, an ergonomic chair, and potentially a standing desk option to promote better health and focus.
Distraction Management: Use tools like website blockers during focused coding sessions, and consider noise-cancelling headphones if you work in a noisy environment.
Knowledge Management System: Implement a personal system for organizing code snippets, useful articles, and learning resources. Tools like Notion, Evernote, or even a well-organized GitHub repository can serve this purpose.
Productivity Toolkit: Curate a set of tools that enhance your workflow. This might include time management apps, project management software, or communication tools that integrate well with your development process.

By thoughtfully designing your environment, you create a space that naturally encourages productive coding habits and minimizes barriers to deep work.

Habit Stacking for Success

Habit stacking is a powerful technique where you attach a new habit to an existing one. Here's how developers can leverage this concept:

Code Review After Stand-up: Make it a habit to review a colleague's pull request immediately after your daily stand-up meeting.
Learning with Lunch: Use your lunch break to watch a coding tutorial or read a technical article while eating.
Refactoring Before Committing: Before committing any new code, take a few minutes to refactor and improve the clarity of what you've just written.
Testing After Feature Completion: Whenever you complete a new feature, immediately write or update the corresponding unit tests.
Documentation with Deployment: After deploying a new feature or fix, update the project documentation to reflect the changes.

By linking new, beneficial habits to existing parts of your routine, you can more easily integrate continuous improvement into your daily workflow.

Embrace Immediate Feedback

Clear emphasizes the importance of immediate feedback for habit formation. In software development, we can apply this principle through:

Real-time Linting: Configure your IDE to provide instant feedback on code quality, style violations, and potential bugs as you type.
Continuous Integration Feedback: Set up your CI pipeline to provide quick feedback on every commit, including test results, code coverage, and performance metrics.
Peer Programming Sessions: Engage in regular pair programming to get immediate feedback on your code and problem-solving approaches.
User Testing: Implement features that allow for quick user feedback, such as A/B testing or beta user groups, to gauge the real-world impact of your code.
Performance Monitoring: Use application performance monitoring (APM) tools to get immediate insights into how your code changes affect system performance in production.

By creating these feedback loops, you accelerate your learning process and can quickly adjust your coding practices for better outcomes.

Cultivating a Developer Identity

One of Clear's most powerful concepts is the idea of identity-based habits. As developers, we can leverage this by focusing on who we want to become, rather than just what we want to achieve. This shift in mindset can lead to more sustainable and meaningful growth.

Consider these identity statements:

"I am a developer who prioritizes code readability and maintainability."
"I am a continuous learner, always exploring new technologies and best practices."
"I am a collaborative team member who values clear communication and knowledge sharing."

By internalizing these identities, we naturally align our actions with our aspirations. For instance, if you see yourself as someone who prioritizes code readability, you're more likely to invest time in refactoring and documenting your code, even when faced with tight deadlines.

This approach also helps in overcoming imposter syndrome, a common challenge in our field. By focusing on your identity as a capable and growing developer, you can build confidence and resilience in your professional journey.

Remember, becoming the developer you aspire to be is a gradual process. Embrace small, consistent actions that reinforce your chosen identity, and watch as they compound into significant personal and professional growth over time.

Conclusion: Your Journey to Developer Excellence

As we've explored, the principles from "Atomic Habits" offer a powerful framework for continuous improvement in our software development practices. By focusing on incremental changes, building robust systems, optimizing our environment, stacking habits, embracing feedback, and cultivating a strong developer identity, we can transform our coding skills and career trajectory.

Remember, the key is consistency. It's not about making drastic changes overnight, but rather about implementing small, sustainable improvements that compound over time. Start by choosing one or two areas from this article to focus on, and gradually build your own system of atomic habits for software development.

As you embark on this journey, be patient with yourself and celebrate the small wins along the way. Every refactored function, every new concept learned, and every improved process is a step towards becoming the developer you aspire to be.

I encourage you to share your experiences and insights as you apply these principles. What atomic habits have you found most impactful in your development work? How has focusing on small, consistent improvements changed your approach to coding? Let's continue this conversation and support each other in our pursuit of developer excellence.