DEV Community: Eduardo Ottaviani Aragão

SSR and SSG in Web Components

Eduardo Ottaviani Aragão — Sat, 19 Apr 2025 05:44:21 +0000

As front-end developers, we eventually face a common challenge: how to distribute features in a tech-agnostic way.

When systems grow — especially in large organizations — it becomes necessary to integrate features built by different teams, sometimes even from different companies. The result? A mix of technologies and frameworks coexisting in the same ecosystem.

So how do we share features effectively in such environments?

One powerful option is to use Web Components, especially when trying to stay framework-independent. And that’s where the real conversation begins.

😵 The Problem: Coupled HTML and JS

Most modern Web Component solutions (and frameworks) couple HTML with JavaScript. Whether through template strings or JSX, this coupling often creates friction when:

You want to render HTML on the server (SSR or SSG).
You care about bundle size.
You need flexibility for teams to modify the layout independently from the logic.

Wouldn’t it be great if we could separate logic and HTML entirely?

Spoiler: we can. 😉

✅ The Solution: Split HTML and Logic

By separating HTML from your JavaScript logic, you unlock some serious advantages:

📦 Smaller Bundles – Only JS is shipped. HTML stays out of your JavaScript.
✨ More Flexibility – Frontend teams can modify layout freely.
⚡️ SSR/SSG Friendly – Static HTML can be rendered ahead of time without simulating the app on the server.

Let’s walk through an example using a setup based on Jails, a 9kb micro-framework focused on reactive components with minimal overhead.

🔧 The Setup

I’ve created a demo repo that illustrates this concept using Parcel with TypeScript and Pug:

mfes/
├── mfe-a
├── mfe-b
└── mfe-swiper/
    ├── app.ts        ← Logic
    ├── index.ts      ← Entry point
    ├── index.css     ← Styles
    ├── index.pug     ← HTML template
    └── page.pug      ← Shell page

The build process outputs:

🧠 The Logic with Jails

Let’s look at how a simple Banner component (like a Swiper) looks using Jails:

export default function appSwiper({ main, on, elm, state, dependencies }) {
  const wrapper = elm.querySelector('.swiper')
  const { Swiper } = dependencies
  const swiper = new Swiper(wrapper)

  main(() => {
    elm.next = next 
    elm.prev = prev 
    elm.goto = goto 
    elm.useSwiper = useSwiper

    on('click', '[data-next]', next)
    on('click', '[data-prev]', prev)
    swiper.on('slideChange', onchange)
  })

  const onchange = () => {
    state.set({ page: swiper.activeIndex + 1 })
  }

  const next = () => swiper.slideNext()
  const prev = () => swiper.slidePrev()
  const goto = (n) => swiper.slideTo(n - 1)
  const useSwiper = (fn) => fn(swiper)
}

export const model = {
  page: 1
}

This small function connects your component’s logic to the HTML — without bundling the HTML itself.

It exposes methods like next(), prev(), and goto(n), while keeping the actual DOM markup flexible and customizable.

Here’s how we register and start the component:

import Swiper from 'swiper'
import { register, start } from 'jails-js'
import * as appSwiper from 'components/app-swiper'

register('app-swiper', appSwiper, { Swiper })
start()

The Swiper dependency is injected externally — this means you don’t include the Swiper library in your bundle unless you need it. 💡

🧱 Using the Component

Let’s see how to use it on a page:

<app-swiper>
  <div class="swiper" html-static style="height: 300px">
    <div class="swiper-wrapper">
      <div class="swiper-slide"><img src="https://picsum.photos/800/300?random=1" /></div>
      <div class="swiper-slide"><img src="https://picsum.photos/800/300?random=2" /></div>
      <div class="swiper-slide"><img src="https://picsum.photos/800/300?random=3" /></div>
      <div class="swiper-slide"><img src="https://picsum.photos/800/300?random=4" /></div>
    </div>
  </div>
  <p>Page: <strong html-inner="page">1</strong></p>
  <div class="d-flex justify-content-between">
    <button class="btn btn-primary" data-prev>Previous</button>
    <button class="btn btn-primary" data-next>Next</button>
  </div>
</app-swiper>

This gives consumers full control over the HTML structure, styling, and layout — all while maintaining access to component logic and reactive state.

🧪 Live Demo

Wanna see it in action?

Try the live version here 👉

🔗 StackBlitz Demo

✍️ Final Thoughts

Web Components are incredibly powerful — especially when designed with separation of concerns in mind.

By letting HTML live outside your logic, and exposing a clean API through JS, you empower teams to reuse features without framework lock-in, and without bloating bundles.

This strategy is particularly useful in micro-frontend environments, but works just as well in traditional apps that value performance, maintainability, and clarity.

In a future post, I’ll show how to encapsulate this component into a remote micro-frontend for full plug-and-play reuse.

Until then, feel free to explore Jails and give your components a lightweight, flexible edge 🚀

Astro + Jails - A Perfect Match

Eduardo Ottaviani Aragão — Sun, 23 Feb 2025 06:04:03 +0000

Astro.js is a modern framework that prioritizes zero JavaScript by default for static pages, aiming to deliver faster load times and better performance.

It allows developers to build dynamic websites with minimal JavaScript, only loading it when necessary.

This "zero JavaScript" approach helps optimize user experience by reducing the amount of client-side code and improving page speed, while still enabling the flexibility to add interactivity when required. Astro’s focus is on efficiency and scalability.

But you might be wondering:

what can I use to make the static parts of my application more dynamic, taking advantage of Astro's island architecture concept?

Zero Client Javascript + Only Client Javascript

Jails is a library designed to bring best practices to software development, specifically in JavaScript for Fron-tend. It focuses solely on adding client-side functionality in the simplest and most elegant way possible, leveraging the full potential of the language.

Jails offers a range of features for your web components, allowing you to choose between building your entire application based on web components or creating solutions that can be distributed agnostically to other projects.

How about taking a quick peek?

The markup: src/pages/index.astro

---

---

<script>
    import { start, register } from 'jails-js'
    import * as helloworld from 'components/hello-world'
    register('hello-world', helloworld)
    start()
</script>

<hello-world>
    <h1>Hello World!</h1>
    <p>A simple Counter</p>
    <button class="btn add">+</button>
    <span html-inner="counter">0</span>
    <button class="btn subtract">-</button> 
</hello-world>

The Javascript: src/components/hello-world/index.ts

export default function helloWorld ({ main, on }) {

    main(() => {
      on('click', 'button.add', add)
      on('click', 'button.subtract', subtract)
    })

    const add = () => {
      state.set( s => s.counter += 1 )
    }

    const subtract = () => {
       state.set( s => s.counter -= 1 )
    }
}

TodoMVC Example

The Benefits

Astro was built to deliver zero JavaScript and maximize performance. On the other hand, Jails was designed to minimize JavaScript by separating HTML from its JavaScript logic, resulting in smaller bundles and more efficient, streamlined code.

Web components are a great solution for building more agnostic, cross-application compatible solutions, but developing applications with pure JavaScript can be time-consuming.

Jails strikes a balance between developing solutions directly, as we typically do with pure JavaScript, and leveraging the power of modern frameworks for DOM updates, local and global state management, and functionality sharing.

Check out a collection of examples using Jails here: https://stackblitz.com/@Javiani/collections/jails-organization

More: https://jails-js.org/

Thank you!

Dependency Injection, Inversion of Control & Jails 5

Eduardo Ottaviani Aragão — Sat, 09 Mar 2024 21:50:03 +0000

Cover from: https://www.linkedin.com/pulse/understanding-dependency-injection-alex-merced

In software engineering, dependency injection is a programming technique in which an object or function receives other objects or functions that it requires, as opposed to creating them internally. ( Wikipedia )

Alright, here's the deal: Dependency Injection is like the secret sauce for untangling your system. It's a straightforward method to loosen up the connections between components. With this approach, you're basically flipping the switch on who's calling the shots in a component or module. And trust me, it can totally revolutionize how you structure your code.

Inversion of Control

You know, Inversion of Control (IoC) is baked right into the core of JavaScript. It's like second nature for us JavaScript devs, and honestly, it's a breeze to pull off in this language, especially with callback functions.
IoC lets us split up generic behavior from the nitty-gritty specifics, which gives us some awesome reusability perks too.

Example - Find a user by id from a list and remove it from the list.

Without Dependency Injection and Inversion of Control

const findUserAndRemove = (id, list) => {
  let newlist = []
  list.forEach( user => {
    if( user.id !== id )
      newlist.push( user )
  })
  return newlist
}

There's nothing completely wrong with the code above, it's easy to understand and it does its job. However, we might encounter scenarios where we want to locate a user based on another property, or where we desire to do more than simply remove the user from a list; we may wish to modify or enhance the user with additional properties, for instance. In such cases, not only will the name of our function lose its relevance, but it will also expand with increasingly complex behaviors, potentially rendering it difficult to manage.

There are at least two different behaviors on that code, the first is the iteration over a list, the second one is by identifying a case where we are looking for and do something with it. The findUserAndRemove function has 100% of control of what is going on on that task.

So how can we decouple those two behaviors and make it more reusable?

The solution is already inherent in the language. The filter array method is an implementation that achieves Inversion of Control by incorporating a callback function.

Therefore, the filter function's purpose is to iterate over each element of the list and return a new list containing only elements that satisfy a given condition.

In the initial code snippet, the findUserAndRemove function possesses complete control over the user selection process.

However, the filter method reverses this control dynamic, empowering you to determine the criteria for selecting the user:

With Dependency Injection and Inversion of Control

const newlist = list.filter( user => user.id !== id )

With a single line we did exactly the same as we did before and filter can be reused for many other cenarios.
If we want to find a particular user without changing the size of items of a particular list, we can use the map method for it:

const newlist = list.map( user => {
  if( user.id == id )
    user.role = 'admin'
  return user 
})

DI & IC in Frameworks

Those concepts are so deeply ingrained in the language that they shouldn't become more complex when transitioning into Frameworks.

Indeed, React lacks a dedicated Dependency Injection (DI) mechanism; it is inherently built into the framework due to the functional nature of its components. Consequently, all that's required is to anticipate a callback function within your generic component, and there you have it.

In contrast, Angular doesn't offer such simplicity. To inject dependencies, you must invest time in understanding its mechanisms, and familiarize yourself with concepts like Services, Decorators, Injectable, Providers, if you haven't already done so.

With that said, it's clearer, at least to me, that the more a framework or library aligns with the language's native features and functionality, the easier it becomes to accomplish tasks.

DI & IC in Jails

Jails is all about simplicity, so naturally, those things should be straightforward in Jails, right? Yeah… and they are:

// at home.js
import jails from 'jails-js'
import router from 'jails.pandora/router'
import store from 'jails.pandora/store'

import * as myComponent from './components/my-component'

jails.register('my-component', myComponent, { router, store, ... })
//...other components registering

Component usage

export default function myComponent ({ main, dependencies }) {

  const { router, store } = dependencies 

  main( _ => {
    router.get('/', log)
  })

  const log = () => console.log('Hello World!')
}

The injection occurs during the component registration phase, and the purpose of Dependency Injection (DI) and Inversion of Control (IC) in Jails aligns precisely with what we discussed earlier in this article.

It's all about decoupling generic behavior from specific logic. Moreover, it involves sharing capabilities and instances between components, as illustrated in the example above.

A Real World Use Case

Form Validation poses an ongoing challenge in the Front End realm. Eventually, every framework and library will offer a general abstraction to handle this task, and Jails is no exception.

Recently, I developed a validation component using Jails and shared it in a repository. While I don't anticipate creating numerous abstractions with Jails, as the philosophy of this application library prioritizes full interoperability with the Vanilla JavaScript ecosystem, there's an exception for Form Validation.

The challenge in crafting such an abstraction lies in ensuring its generic nature, enabling anyone worldwide to utilize it irrespective of regional specificities. To achieve this, we must discern between what aspects should be generic and what should remain specific.

The generic aspect entails attaching event handlers to validate functions, updating the view with error feedback when necessary, and removing errors upon validation. This segment manages events and applies classes to DOM elements for programmers to utilize in handling UI errors.

Conversely, since validations can vary based on regions, business rules, etc., all validations should be externally provided to the component, adhering to a defined contract to ensure correct behavior of the generic abstraction.

Additionally, dynamic configurations must be accessible to specify the validations a field requires.

Introducing - Form Validation Component

So, to invert the control of the Form Validation component and ensure its generic usability across various scenarios, the Form Validation Component leverages the Jails Dependency Injection system to inject specific validation rules. Additionally, it retrieves configuration data from HTMLFormElement.

So that's it… That's all I got for you guys.

Checkout the Demo hosted on StackBlitz so you can learn more about that.

See you!

Jails 5 - A Front-end Library for new (old) trends

Eduardo Ottaviani Aragão — Sun, 10 Sep 2023 20:37:52 +0000

In the not-so-distant past, crafting a simple rounded corner on a webpage was a formidable challenge, requiring intricate manipulation of layout grids, animations, and wrangling with browser limitations. However, today's web development landscape appears considerably less daunting. JavaScript has undergone numerous enhancements, the language itself has evolved, and DOM APIs, browser capabilities, CSS, bundlers, development tools, editors, and the entire platform have seen significant updates.

The Contemporary Era

Modern JavaScript frameworks have introduced diverse solutions to address client-side complexities, but they've also ushered in a new era of intricacy that troubles many, myself included. I was never an advocate of JSX; I believed that embedding HTML within our JavaScript code blurred the lines between concerns. Yet, the influence of conferences and tech giants gradually led to wider acceptance of this practice, even though it never quite felt right to me.

Time has a knack for illuminating the wisdom of certain ideas, and in the realm of software engineering, concepts tend to ebb and flow cyclically. Single Page Applications (SPAs) are no longer in vogue, and the idea of housing all HTML definitions inside JavaScript files has been recognized as detrimental to site performance due to the resulting bloated bundles.

Static site generation and server-side rendering have gained momentum as more performant alternatives. Moreover, these frameworks tend to lock developers into their ecosystems. Once you choose a front-end library, you're compelled to embrace their entire stack. This can be a frustrating experience, as I've personally witnessed projects rewritten from the ground up solely because React was chosen as the client-side library, necessitating a shift from platforms like Rails or PHP to Node.js.

But something is changing, a shift toward simplicity or greater agnosticism perhaps. I'm referring to emerging technologies like Astro and Htmx.

Astro and Htmx: The New Wave

With Htmx, you can leverage any back-end language, enhancing your HTML applications with directives and using the library to seamlessly replace DOM elements and update them with HTML responses. This approach bears resemblance to the days of .NET MVC, where partial views were returned for XMLHttpRequest.

Astro, on the other hand, allows you to remain within the Node.js realm for server-side rendering (SSR) while granting you the freedom to select any client-side library for static site generation (SSG).

This 'new' trend instills a glimmer of hope that we are returning to a simpler approach to web development. Frameworks, it seems, are obstructing the progress of many applications. As senior engineers who recall simpler times, even amidst technological limitations, it's crucial that we retain the capacity for critical evaluation.

My Contribution to the Community

As a tech lead and principal, working with teams necessitates a pragmatic approach. While staying updated with new technologies is vital, it's equally crucial to empower teams with the autonomy to choose their preferred tech stack. I have immersed myself in the realm of modern front-end frameworks for some time now.

However, I have steadfastly clung to the belief that we don't need the excessive complexities prevalent today. This conviction led me to initiate a project called "Jails" eight years ago. I had the privilege of testing this project in various applications within the companies I've collaborated with. The support and shared vision of like-minded developers encouraged me to pursue this indie project in critical applications.

The intent behind Jails was to create a contemporary client-side library that embodies several key principles:

Agnosticism, enabling compatibility with any SSR or SSG system, as well as other vanilla JavaScript libraries.
Simplicity and speed.
Event-driven architecture with modern techniques like DOM diffing and local state management.
Platform-oriented, aligning closely with vanilla JavaScript and browser compatibility.
A functional approach, devoid of classes, 'this', decorators, private/public members, or inheritance. Functional, but deeply rooted in the JavaScript paradigm.

To utilize Jails, simply encapsulate the markup requiring dynamic behavior within a custom element and register a Component module in a separate JavaScript or TypeScript file containing the logic.

In summary, I've been working diligently with Jails, and I wholeheartedly believe it provides an elegant and classic approach to crafting client-side applications. I invite you to explore it, offer your suggestions, and join in on this project. You can find more information at https://jails-js.org/.

Thank you for your time, and until next time!