July 27th, 2023 In praise of DSLs; joy to those working in restricted domain! By Jeffrey M. Barber

An element of the technical strategy that I focus on is limiting the scope of the battlefield. If you attest a desire towards simplicity, then discipline in focusing the battlefield is essential. This may seem paradoxical given the scope of this platform, but this platform is way simpler than other stacks out there. While it is true that I’ve taken on a tremendous engineering burden, I believe this is preferable to letting the inmates run the asylum. Case in point, I upgraded my ubuntu (for reasons), and this site just plain broke…

So, a good distinction between complexity and simplicity was made by Rich Hickey many moons ago. However, humans are great sources of complexity and you can just look at the ever-changing tax code as proof. My philosophy for dealing with human complexity is “put it in a box” which is what I did professionality using JavaScript. With Adama, I believe I’m building a rather impressive box, and I’m working with others to probe the boundaries in a professional and entrepreneurial endeavor.

At core, I believe we build products in too open of domains. The more options that you have in your building process, then your value is diluted by inconsistency. Let’s focus on building web apps.

There are way too many choices. First, you have web frameworks like React, Vue, etc, etc etc. Then you have your back-end language of node.js, PHP, Ruby, python and associated frameworks. Then you have a variety of databases with their own trade-offs in different domains. Then you have a copious number of services to integrate.

Honestly, the current state of affairs makes me sad. There are too many choices! It’s madness. The current situation is only good for developers that want a steady job, but is it good? Is this the desired work-life balance? Is this good for small businesses?

I believe life should be better spent.

As such, I believe those that have professed the awesomeness of domain specific languages were right in many ways. Instead of having everything available and all power enabled which requires great responsibility, we need fewer things that work well together. As an example of this, I have a client building an entire business using the fullness of this platform from back to front. Perhaps this is madness, but the client and contractors have taken well to the frontend technology: RxHTML.

RxHTML is not a typical framework. Instead, it asks what did HTML not have, and then adds it. In a way, it’s similar to HTMX which is a great technology. RxHTML differs in that it biases towards templates rather than mark-up. However, instead just one-time generation templates, it does reactive data binding along with view state manipulation.

Let’s make this concrete with an example.

  <b><lookup path="owner_name"></b>
  <button rx:click="toggle:show_pets"> Show Pets </button>
  <div rx:if="view:show_pets">
    <ul rx:iterate="pets">
      <li><lookup path="name"></li>
    </ul>
  </div>

Here, we have a snippet of RxHTML that you could find within a pet management software. You see the owner name, and then a button to reveal the owner’s pet. In this example, there is:

  • the <lookup> element that pulls a value
  • the rx:iterate attribute that iterates over an array of objects
  • the rx:if attribute to mount/unmount child elements based on view data
  • the rx:click attribute to execute a view state manipulation

Those four things compose well. At the time of this writing, RxHTML has 16 commands to execute from an event, a simple attribute template language with 3 concepts, 6 new elements, and a few pieces of glue. RxHTML isn’t big, but it does require a compilation step where RxHTML files are validated as proper HTML (which is a bonus over a traditional template) and then converted to JavaScript. The browser really should have a reactive data binding concept.

Now, suppose this is all a giant mistake and I’m gloriously wrong because I’m just a dumb fool building a personal castle out of sand. Maybe I should have just used React…

Well, since the definition is so small, any reasonable developer could convert the RxHTML template to React. So, I don’t feel particularly bad about using this technology at a start-up as their engineering spend is focused nearly 100% on product definition. Furthermore, since RxHTML’s semantics are declarative, there is no maintenance needed on the assets as the concepts are minimal.

This restrictive domain has powerful advantages, but it comes at the cost of unlimited power. However, the capability of unlimited power comes with great costs. Could you conceivably convert a React app to Vue? Maybe with new AI, but would you trust it? Here, the primary task on the frontend is to learn HTML and CSS (or, in my case Tailwind) and then just bind it to data.

By fixing the browser, the number of things to master are focused on the primary domain (being the product within the browser). We forget that React or Vue isn’t the thing to master. The browser is the thing to master as it is the true medium, and everything else is just junk in the way.