How a simple side project led me to Alpine.js (and why I am glad it did)

When I offered to help turn an existing solution, which utilised Microsoft Excel, into a browser run UI, which would also feel smoother, I did not have in mind that such javascript frameworks as Alpine.js exist.

Currently, and for the next few months, I am serving in a desk position, where one of the tasks is to send emails that contain mostly predefined content but require a few of their words to be modified before they are on their way. Until now, the team handled this using an Excel sheet that worked well enough: change a few values in dedicated cells and the final text would appear in another cell ready to copy.

The constraints

Sounds like an easy UI to develop and have it run on the browser, right? It surely is! But here are some constraints, I considered, on my own, to take into account before running the ng new <name> (initialize new angular project) command on my terminal:

• most of its users would have basic computer skills (no programming knowledge)
• it should start by using the double left click of the mouse, just one time (same way you open an excel file)
• modifications in the files (data or src files) should not require any other action than saving the file, that was just modified, before taking effect
• offline mode (no internet connection)

These requirements quickly ruled out options that require node.js or python, which are tools that I could easily use to develop the UI.

Discovering Alpine.js

Thus, as a next step, I turned to an AI chat, to inform me about available options based on the specific requirements. Thankfully, it came back with options like petite-vue, knockout.js and alpine.js. All of these libraries would work by simply including them with a <script ..></script>in the HTML file. Considering I was unfamiliar with all of them, I looked for the one that has the most following on github. Interestingly enough, it is the same one that seems to be the only one maintained up to today, Alpine.js (the other two haven’t had any changes committed for more than a few years).

Everything clicked into place

• Bootstrap v5.3 for the UI components
• Alpine.js for reactive behavior
• individual .js or .json files for predefined data
• a single .html file, for the user to start using the tool

In only a couple of hours I had a demo UI ready to showcase to the parties involved, in order to get some feedback and understand whether I should proceed on that path. Who wouldn’t prefer a clean UI, running on a browser tab, over the condensed cells of an excel sheet? Although, I am pretty sure what they loved the most was using a clocktime-picker component for entering some number inputs, whose values would go up to 59.

The code

Below there are examples of an Alpine.js implementation, where directives of the library are showcased:

• x-data defines state
• x-model binds user input
• x-text updates live
• x-for create DOM elements by iterating through a list

<div x-data="{ name: 'World' }">
  <input x-model="name" class="form-control" />
  <p class="mt-2">Hello, <strong x-text="name"></strong>!</p>
</div>

<div x-data="{ options: ['Alpha', 'Bravo', 'Charlie'], selected: '' }">
  <select x-model="selected" class="form-select">
    <option value="">Choose one...</option>
    <template x-for="item in options" :key="item">
      <option x-text="item"></option>
    </template>
  </select>

  <p class="mt-2">You selected: <span x-text="selected"></span></p>
</div>

New path unlocked (final thoughts)

Discovering the middle space between Vanilla JavaScript and Front end Javascript frameworks, helped me avoid unnecessary boilerplate and build steps.

If you ever need to build a small but interactive piece of UI, like a form tool, editor, dashboard, widget, prototype and want to avoid a complex setup, try Alpine.js.

It might surprise you the same way it surprised me.