Introducing Erstwhile Framework

The eagle-eyed among you may have noticed a little tidbit hidden on the footer of RestlessIDE: (the future best web-based development environment!)

What the heck is Erstwhile? That’s what we’re talking about today.

Erstwhile Framework is a Javascript library for building modern, Single Page Application web apps.

It fills a similar role to React or Angular, but is based on the Model-View-Controller programming pattern. It takes some queues from other frameworks like Rails but also introduces its own innovations.

The word “erstwhile” means “former,” and is slightly archaic. Erstwhile Framework is meant to feel familiar to programmers from a slightly different era, back before there were 10 new Typescript libraries each month that you were expected to know about. Back when programming was about building things and not build pipelines. When you could focus on the code and just have fun creating.

A Brief History

This part may meander a bit, if you want to skip to the discussion of the actual framework, click here.

The project came about a few years ago when I got into a discussion with the Backend Standup crew. For new readers, this is a group of coworkers from a project I was on a few years ago, and we had set up a meeting before our company-mandated standup where we got our story straight before talking to the larger team. Anyway, over the years most of us left the job, but this random meeting was still on our personal calendars, so we kept it going. It became a forum to talk about life and code for 30 minutes every morning.

In this meeting, I became known as the resident React skeptic. Since my role is usually more nuts-and-bolts backend stuff, I was almost always in the position of consuming other peoples’ React code, and I didn’t like it. It felt like every 6 months a new paradigm would become popular and get half-implemented before the next one would take over, and every dev that touched the codebase would organize things slightly differently, leading to one having to look for components all over the place.

Oh, and Components!

Everything in React is a Component, no matter how different in functionality, or how large, or how small. This one does routing, controlling the user’s navigation through the whole darn application, and this one wraps around a <select>. This one is the nav bar, except this one small part of the nav bar, which is a different component for some reason.

It’s almost like the term is meaningless, with each developer just dropping components all over the place like a drunken sailor in ill-fitting flip flops walking on a cobblestone street.

Also, I find JSX ungainly. It’s not quite code and not quite markup, but a weird hybrid where the syntax rules feel made up and arbitrary. I mean, I know something can parse it, but it just doesn’t look right.

After one of my characteristic rants, someone from the crew asked how I think a framework should look, and that got me thinking. A lot.

It’s one thing to critique another’s project, but quite another to try to do it yourself and put something out there to be judged. But what the heck, I like a challenge.

I had already been kicking the tires on RestlessIDE back in early 2023, so I decided to make the frontend framework my project for that summer. At each stage I tried to think through my own coding philosophies, and what it meant to Get the Model Right when it came to organizing frontend code meant to run in a browser.

With RestlessIDE now ready for public consumption, I think it’s a good time to also start talking about the code underpinning it. It has been used in a production application, after all!

Framework Highlights

I don’t intend to write a detailed primer of the entire framework in a blog post. For those interested in diving deeper, there is a whole website to help you get started.

I do want to give you a few things to entice you to visit that website, though. Here are some of the features that I think make Erstwhile stand out.

1. It Follows an MVC Architecture

Unlike React, your code in Erstwhile generally follows the path structure of your website. This is meant to aid in discoverability, so that new developers on a project know intuitively where to go when they need to figure out how to change or create something. It uses ES6 classes to achieve this.

Note: This is describing default behavior, but it can be overridden when needed.

The file structure is heavily based on early versions of Ruby on Rails. They say you always remember your first.

 

If you look at your application’s URL structure, you’ll see something like /widgets/edit/1234. You’d find the controller in /app/controllers/WidgetsController.js, in the method editAction(id). The view would be in /app/views/widgets/edit.ejs. Easy peasy.

There are also specialty methods such as preAction() and postAction() in the controller class for cases when you need to have some functionality fire before or after the specified action. For cases where you want to assign an action to the root of the controller (such as /widgets) you can use the indexAction() method.

2. It Has an Extensible Templating Language Called ErML, Which is a Superset of XHTML.

Said in another way, ErML is just XHTML, but where you can make your own elements. I’ve been experimenting with this type of thing for many years now; HTML has just been just been crying out for extensibility.

Here’s an example of a signup form:

<div class="row">
  <div class="col-lg-6 col-md-8 offset-3">
    <Card>
      <div class="row">
        <h2 class="pb-2">Sign Up</h2>
        <hr />
        <div id="initial-signup-form">
          <Alert id="signup-alert" color="danger" light="true" dismissible="true" hidden="true" message="@.page.errorMessage"></Alert>
          <Form id="signup-form" >
            <TextInput name="username" label="Username" required="true" />
            <PasswordInput name="password" label="Password" required="true" />
            <TextInput name="first_name" label="First Name" required="true" />
            <TextInput name="last_name" label="Last Name" required="true" />
            <EmailInput name="email" label="Email" required="true" />
            <Button color="primary" onclick="@.page.submitForm">Signup</Button> 
            <p class="mt-3">
              Already have an account? Click <a href="/login">here</a> sign in.
            </p>
          </Form>
        </div>
      </div>
    </Card>
  </div>
</div>

With ErML, I tried to address my gripes with JSX. As you can see, it’s just a markup language, but with a little bit extra to make it dynamic.

To define new elements, you extend a base class called ErswhileComponent and implement a the appropriate methods for the functionality you need, which can differ a lot depending on the complexity of your component. There’s a description on what is needed in the documentation. The name of your class becomes the tag, and they are CamelCapped out of convention rather than necessity. You can also override actual XHTML elements if you want, as the engine that generates the HTML output for the browser looks at your components first.

You can get into all kinds of mischief.

ErML uses a concept called Scoped Variables to deal with passing dynamic variables and functions into ErML components. Basically, within your controllers, you can assign variables and functions to $App.scopes.session, $App.scopes.page and $App.scopes.modal (for modals) and those can then be passed into your components through attributes like message="@.page.errorMessage". If the scoped variable (or function) changes at some point, the component is notified and can take action to refresh itself.

Erstwhile also implements the concept of Layouts in the Rails sense. Webpages often have chrome that exists across different paths, including navigation, logos, menus, player bars for media sites, etc, and layouts let you place all of these outer elements in a special component while specifying where to insert the controller’s action template into the DOM.

Erstwhile views are ejs templates, and you can drop into Javascript scriptlets within your template to iterate over arrays, print out page-scoped variables, or whatever you need to do. The output of your ejs is then run through the ErML engine to create the final HTML that goes to the browser. There are several layers of dynamism you can use.

3. Erstwhile is Meant to be Themed

Visual components in Erstwhile are bundled into themes, which are just directories full of component definitions with some additional metadata.

Over time, I’d like to work with interested theme designers to create a set of standard component definitions (specific tag names, attributes, and data inputs) similar to Bootstrap that will give theme developers a baseline when creating their own themes; if we’re able to build out this ecosystem, switching the UI of Erstwhile applications will be as easy as changing a string in a config file.

If you are a theme designer and want to get in on the ground floor of this amazing opportunity, please check out the website and get in touch!

In the meantime, Erstwhile is bundled with a sample theme based on the MIT-licensed Mazer Bootstrap theme. It should provide enough to show how components are built.

In addition to themes, Erstwhile applications can have local components, located in /app/components which add additional components that are app-specific, or which override those in the theme if you need some different functionality than what comes with the theme. It’s very easy to work with.

4. Painless Models

For those building or using REST APIs in their backend applications, Erstwhile includes a Node module for your server to make your job a lot easier.

It specifies a JSON format that you can store in a config file in your API that describes the API. The module then lets you serve up this file on your dev server, both as JSON and as handy HTML documentation for the frontend dev team.

With this file in place, your Erstwhile frontend can grab that description file and automatically create your local model files right in your /app/models directory so you can consume the API entirely in Javascript objects with no explicit API calls needed.

Let the computer do the work for once!

Conclusion

I wrote Ersthile for a few different reasons. In no particular order:

• I wanted to see what went into building a frontend framework. Having spent so much time on the server side, I wanted to experience life in the browser.
• I wasn’t crazy about the current alternatives. They didn’t really do things the way I thought they should.
• I was building a new product, and if I’m committing to something long term I want it to be something I enjoy using.
• It didn’t seem like it would take too long to do. This was mostly right, it was about 2 months of part-time work, plus bug fixes while building out RestlessIDE.

Do I have visions of being the next DHH or Jordan Walke? No, I do not. Do I think React devs everywhere will realize the errors of their ways and jump ship? Of course not. A lot of people genuinely love it and it has a wonderful ecosystem of training, support, and add-ons that make it the logical choice for a new app being built in 2025.

Every programmer has a different threshold for that imaginary meter that points to either “buy/use an existing solution” or “build something new”, and mine is admittedly weighted on the latter side. I just like building things, and seeing what goes into it. Leaving my own footprint.

That said, I do hope some other devs out there find Erstwhile helpful, and that it models the process of building web apps in a way matches their own. Maybe it can even convince someone to do their own thing and build the future they want to see.

A future with a little less JSX.

Til next time.

(Image by David Harper from Pixabay)